Topic: [Site change feedback] The new tag preview system has removed the previews of implied tags

The site changelog for September 3, 2025 announced this change:

Changed [Tags] Add a new tag preview. (#1111) [ binaryfloof ]

I like the fact I don't need to manually click a tag preview button in order to check my added tags. But unfortunately this change has also lost some important functionality.

The previous tag preview system showed all the tags that would result from the current edit: both the tags I entered, and the additional ones that would be added via implications (which were indicated with "->").

That was very useful because it meant that I could see what extra tags I'd get "for free" from my additions, without having to type them manually. Sometimes, those implied tags were surprising, and gave me ideas/jogged my memory for other tags that I could add.

It was also useful because it alerted me to tags that didn't have the implications that they probably should have, which occasionally led to me suggesting implications and BURs.

e.g. I could type text_on_t-shirt, look at the preview, and see what else would be added via implications. Turns out it doesn't have any. So I could type text_on_shirt instead, and see that it would also give me shirt, topwear, text on topwear, text on clothing, text and clothing at the same time. Being able to see that at a glance has two benefits: it saves me some typing, and it makes me think: Hmm, maybe I should suggest a similar pattern of implications for text_on_t-shirt, for consistency?

Also, sometimes I tried to remove an incorrect tag from a post, only to find that I couldn't remove it because it was added through implications. The preview system let me look at the implications chain at a glance, to see which dependent tags needed to be removed alongside it.

But now, today's new tag preview system doesn't show the implications. I don't like this removal of useful information!

Did anyone else use the old preview system in the same way that I did? Or is it just me who finds this a change for the worse?

(I wasn't sure whether to post this under Bug Reports & Feature Requests. Since unless this was an unintended change it's not really either a bug or a new feature request, and because the recent UI change topic was in General, I've put it here.)

it's also kinda annoying that it's always open and directly under the tag box. it moves the recent tags and quick tags way down under to bottom of the screen on mobile.

I am kind of hating it. I use the quick tags a lot, and that thing keeps popping up on the way of the quick tags, and jostling them around whenever I add or remove anything, which is throwing off my muscle memory really badly.

also, yeah, not having clear implication chains to figure out why, like, breasts is still on a post, which was-- kinda the entire point of the final tag preview before (or even show any of the implied tags that will end up on a post at all, for that matter) makes this a pretty significant downgrade.

Not being able to see implication chains or access the quick tags easily makes this a rather poor change.

Anyways remember to put your feedback here to pressure a change:
https://coda.io/form/Share-Your-Feedback_dU9JQnoELGI

"in functionality identical to re6's live tag preview" not really, it's missing implications, doesn't highlight added tags, and has post count after each tag which adds more clutter.

Also I'd like to take this opportunity to request that tags in that list be sorted vertically (as an option), if possible.

Edit: you can hide it by adding .tag-preview {display: none} to Custom CSS

Edit 2: replace that with div:has(>.tag-preview) {display: none} to hide "Fetching Tags..." message as well, thanks BrokenClock for pointing this out

waydence said:
"in functionality identical to re6's live tag preview" not really, it's missing implications, doesn't highlight added tags, and has post count after each tag which adds more clutter.

Also I'd like to take this opportunity to request that tags in that list be sorted vertically (as an option), if possible.

Edit: you can hide it by adding .tag-preview {display: none} to Custom CSS

Thanks for the fix, though the "Fetching Tags..." still temporary pops up for me.

I wish the pop up could be opened optionally with a button because it does have some useful information, but if I'm going through a tag and adding the same 5 quick/recent tags (like beard, blonde_hair, long_ears, horn, and mature_male for asgore) having all the post's tags listed twice above my quick/recent tags is just something to scroll past.

snpthecat said:
Not being able to see implication chains or access the quick tags easily makes this a rather poor change.

Anyways remember to put your feedback here to pressure a change:
https://coda.io/form/Share-Your-Feedback_dU9JQnoELGI

Do they still want feedback through that link? I notice they stopped adding it to the changelog posts 5 months ago. I got the impression that admins were getting kinda defensive from all the pushback on the new site changes. I'd like to add my two cents, but I don't wanna get in trouble for like dogpiling or w/e

brokenclock said:
Do they still want feedback through that link? I notice they stopped adding it to the changelog posts 5 months ago. I got the impression that admins were getting kinda defensive from all the pushback on the new site changes. I'd like to add my two cents, but I don't wanna get in trouble for like dogpiling or w/e

The message by Cinder accompanying the changelog in the discord contains that link, so I'm sure it's still in use... hopefully

This really is an awful change. It's immediately made tagging changes more annoying for me. Personally I'd find this box of tags a lot more useful if clicking one just added or removed tags instead of sending me off to the wiki page, but I'd rather they not be there at all. Not being able to properly hide this via site settings is the problem, really.

I'm a fan of the re621 tag preview, but this isn't it...

• The re621 tag preview still left the vanilla site's tag preview button to view the implication chains, which now can't be seen at all?
• Actually, it doesn't even show any implied tags. That is presumably a bug(?) because the preview on the GitHub shows them.

A step in the right direction, but I don't think this was ready to be deployed.

It also probably needs a real way of disabling it, because anybody hiding it with custom CSS is still going to be making the HTTP requests.

waydence said:
... and has post count after each tag which adds more clutter.

I'm not able to check right now, but I'm pretty sure that functionality is the same as re621.

It also makes sense to me to show the number because it's going to make it a lot easier to identify that you've made a typo if the number is lower than expected.

faucet said:
It also makes sense to me to show the number because it's going to make it a lot easier to identify that you've made a typo if the number is lower than expected.

The auto-complete helps show that already, since it shows the post count or lack of use, too. Especially on longer tags, you can even notice as you type, rather than waiting for the tag list to update.

What bothers me is clicking Edit causes the page to scroll instead of simply opening the edit interface. The tag input box is forced to the top of the page, pushing even the image off screen, requiring a scroll back to get the image back in view (which is kind of important to see when adding/removing tags to ensure the change is correct).

brokenclock said:
Do they still want feedback through that link? I notice they stopped adding it to the changelog posts 5 months ago. I got the impression that admins were getting kinda defensive from all the pushback on the new site changes. I'd like to add my two cents, but I don't wanna get in trouble for like dogpiling or w/e

No, we just forgot. It's far preferable to these forum threads.

People are far more detailed and specific & far less aggressive when filing feedback through a form than the forums, people can attach pictures & other relevant files, feedback is categorized for better sorting, & (as the results are piped into a web app purpose-built for this sort of thing) it's far easier to mark duplicates, keep track of the status of the feedback (whether it's been verified, if it's already been fixed, etc.).

snpthecat said:
The message by Cinder accompanying the changelog in the discord contains that link, so I'm sure it's still in use... hopefully

It's still in use; I'm looking at it now.

I've been keeping an eye on this thread & been reporting back; we're aware of the feedback & are working on improving it.

snpthecat said:
https://coda.io/form/Share-Your-Feedback_dU9JQnoELGI

still dosn't support Fenix-based browsers, annoyingly.

dba_afish said:
still dosn't support Fenix-based browsers, annoyingly.

Get someone else to submit it for you

This is a change nobody asked. How do I hide the preview?

cuenta_nsfw said:
This is a change nobody asked. How do I hide the preview?

Put

div:has(> .tag-preview ) { display:none; }

in your custom css (settings -> advanced -> scroll down)

Hmm, can we just get it moved to the bottom, instead? Rule of least surprise and it also makes it not change positions constantly of the others.

snpthecat said:
Put

div:has(> .tag-preview ) { display:none; }

in your custom css (settings -> advanced -> scroll down)

thanks

post #2305115

cuenta_nsfw said:
thanks

post #2305115

The site just got updated, the tag preview can be minimised, and stay that way..

As SNP noted, the tag preview has been updated, & allows you to hide the preview by default.

To those of you using Custom CSS to hide the tag preview, I'd recommend using the Hide tag preview/Show tag preview toggle under the tag preview pane, as this will let you easily switch it on and off again at your leisure, will prevent the preview from being created/updated while it is hidden, & is better insulated from volatility than Custom CSS. If you'd like to try it without removing your Custom CSS, you can surround the relevant entry with /* & */ to have that part not be processed.

This update also lets you see which tags are implied, although showing what implies them was too big a hurdle for the turnaround time (as we'd have to update that element every time a single implying tag is added/removed instead of only when it goes between 0 & 1 implying tags); we're currently working through potential solutions.

Looking much better now.

I think it will be useful if normal click would remove the tag, and all tags that imply it, while tag's wiki page will only open if you do a new tab click. Kind of like in suggestions autocomplete list.

/* (Tag preview) Increases visibility of implied tags */
.tag-preview {padding-left: .8rem; grid-template-columns: repeat(auto-fill,15rem);}
.tag-preview-tag[data-implied="true"] {position: relative; & .implied {font-size: 85%;}}
.tag-preview-tag[data-implied="true"]:before {content: "+"; position: absolute; right: 100%;}

/* (Tag preview) More compact Show/Hide button */
#tag-string-editor { @media only screen and (min-width: 65rem) {
.tag-preview-area {position: relative; margin-bottom: 0;}
.tag-preview-area > a {position: absolute; right: 1%;} } }

waydence said:

I think it will be useful if normal click would remove the tag, and all tags that imply it, while tag's wiki page will only open if you do a new tab click. Kind of like in suggestions.

How would that work on mobile?

snpthecat said:
How would that work on mobile?

Not to mention that trackpads might not even have a MMB function, or if they do it's usually either clicking both physical buttons or tapping with 3 fingers, both of which are annoying to do

Rather than messing with anything like that just add a small minus off to the side of the text, if anything

snpthecat said:
How would that work on mobile?

donovan_dmc said:
Not to mention that trackpads might not even have a MMB function, or if they do it's usually either clicking both physical buttons or tapping with 3 fingers, both of which are annoying to do

Rather than messing with anything like that just add a small minus off to the side of the text, if anything

I mean, most of the buttons on the site that do JavaScript stuff already have hrefs that don't activate on click and will only happen if you middle-click or right-click (long tap on mobile) -> open link in new tab.

the tag quick complete menu items all link to a search of the individual tag, the quick tags/recent tags/related tags buttons in the edit box also all have links to wiki pages. and there's a bunch of other examples on the site of links that don't link with a normal click.

dba_afish said:
I mean, most of the buttons on the site that do JavaScript stuff already have hrefs that don't activate on click and will only happen if you middle-click or right-click (long tap on mobile) -> open link in new tab.

the tag quick complete menu items all link to a search of the individual tag, the quick tags/recent tags/related tags buttons in the edit box also all have links to wiki pages. and there's a bunch of other examples on the site of links that don't link with a normal click.

I believe these might be holdovers from earlier implementations; regardless, the primary functionality should be preserved on mobile. I'll add this to the list of feedback to discuss with the preview's developer.

aacafah said:
I believe these might be holdovers from earlier implementations; regardless, the primary functionality should be preserved on mobile. I'll add this to the list of feedback to discuss with the preview's developer.

I do feel like the primary functionality of stuff in the edit box should be editing the post, and not linking off-page.

I have to say, live preview has opened some really useful possibilities (live checklist, for example).

One issue I encountered is if you typed in an alias to a tag (i.e. pussy instead of vulva), then for a tag in preview box, "data-name" property stores that alias, while "data-alias" stores the final name of the tag (that will end up in the post). So you can't simply rely on "data-name".

I think it would make more sense if that was the other way around.