Feature request: Bottom-up tag deletion

The rules of the implication are such that adding a child tag automatically adds a parent tag.
However, this implication does not seem to apply when deleting a tag. Of course, there is a concern that deleting a child tag may also delete its parent tag, which may have a common meaning.

So I propose a feature like this.
I'd like to see a feature where when you delete a tag, if there are any parent tags of that tag, you can use something like a snackbar in javascript to see the parent tags and choose to delete them as well. This snackbar will disappear when you click outside or press [Esc]. Hmm, is that how it's supposed to work?
This happens when you backspace a tag in a post that has already been uploaded, and in order to detect this, we need to be able to see which tag the cursor is currently pointing at, if the word has been removed, and if it has a parent tag.

So here's an example of what We would use.

Removing pinafore_dress and sleeveless_dress

If we were deleting tags in bulk, we could think of an exception that would allow us to exclude the search for parent tags.

Take a look at forum #435471

This would probably require either some ugly dialog or a bunch of client-side checks for every tag edit submission, and it'd probably invoke a lot of xkcd #1172.

Plus the question on what to do with multiple implications. I believe some people have already made similar userscripts, but doing the UI in an intuitive way is always a big problem, and what you show doesn't look particularly great for it.

ANON_TOKYO said in forum #435526:

This would probably require either some ugly dialog or a bunch of client-side checks for every tag edit submission, and it'd probably invoke a lot of xkcd #1172.

Plus the question on what to do with multiple implications. I believe some people have already made similar userscripts, but doing the UI in an intuitive way is always a big problem, and what you show doesn't look particularly great for it.

I always wonder whether you've actually used the script, or at least read the README, before leaving impressions on it. Otherwise I don't see why you'd bother leaving this kind of pointless comment on a concept draft from about three years ago.

AkaringoP said in forum #435539:

I always wonder whether you've actually used the script, or at least read the README, before leaving impressions on it. Otherwise I don't see why you'd bother leaving this kind of pointless comment on a concept draft from about three years ago.

I mean I was talking about an actual potential site implementation, not your vibe-coded script, so I'm not sure what you're even trying to get at.

ANON_TOKYO said in forum #435547:

I mean I was talking about an actual potential site implementation, not your vibe-coded script, so I'm not sure what you're even trying to get at.

So what you're describing is an "actual potential site implementation" on the client side. I proposed it, implemented exactly that, and included a forum link in the OP.
After all that, you're still not sure what I'm trying to get at?

AkaringoP said in forum #435562:

So what you're describing is an "actual potential site implementation" on the client side. I proposed it, implemented exactly that, and included a forum link in the OP.
After all that, you're still not sure what I'm trying to get at?

... I know what you're trying to get at though? Your script doesn't help as a built-in implementation, and there hasn't been an actual comment on the viability of that here. A 2.5 kLOC mess isn't going to help that, but I do wonder if someone like evazion has an idea for a better approach on this, since it might have been further thought about before.

ANON_TOKYO said in forum #435564:

... I know what you're trying to get at though? Your script doesn't help as a built-in implementation, and there hasn't been an actual comment on the viability of that here. A 2.5 kLOC mess isn't going to help that, but I do wonder if someone like evazion has an idea for a better approach on this, since it might have been further thought about before.

Yeah, I don't see myself paying attention to your opinions going forward, so let's not waste each other's time.

what if when you typed -tag in the tag script box it showed a warning if the tag has implications and let you click on a button to add those implications to the tag script?

we already have a dialog that shows when an implication couldn't be removed. maybe typing -tag in the tag edit box in a post could warn you about implications that weren't removed

edit: nvm, i think i misread

trapster77 said in forum #435576:

what if when you typed -tag in the tag script box it showed a warning if the tag has implications and let you click on a button to add those implications to the tag script?

we already have a dialog that shows when an implication couldn't be removed. maybe typing -tag in the tag edit box in a post could warn you about implications that weren't removed

If the warning interrupts mid-typing, the user would have to break their flow to reach for the mouse and click; falling back to keyboard shortcuts would risk colliding with the autocomplete's own key bindings.

And when a tag implies multiple tags(;d), or when implications are chained(Idolmaster Cinderella Girls U149) the user often wants to remove only some of them — which means stopping mid-tagging to make a per-case judgment, again breaking the flow.

So the design I'd lean toward is: focus on tagging while tagging, then review all the relevant implication candidates in one place when submitting. That seems to match the user's flow better.

AkaringoP said in forum #435609:

If the warning interrupts mid-typing, the user would have to break their flow to reach for the mouse and click; falling back to keyboard shortcuts would risk colliding with the autocomplete's own key bindings.

And when a tag implies multiple tags(;d), or when implications are chained(Idolmaster Cinderella Girls U149) the user often wants to remove only some of them — which means stopping mid-tagging to make a per-case judgment, again breaking the flow.

So the design I'd lean toward is: focus on tagging while tagging, then review all the relevant implication candidates in one place when submitting. That seems to match the user's flow better.

if you are REMOVING tags that have implications you SHOULD be making a per-case judgement. if you don't that just means you'll leave hanging tags like multiple boys in posts tagged 1boy because someone removed 2boys and forgot about multiple boys

trapster77 said in forum #435613:

if you are REMOVING tags that have implications you SHOULD be making a per-case judgement. if you don't that just means you'll leave hanging tags like multiple boys in posts tagged 1boy because someone removed 2boys and forgot about multiple boys

This topic was originally suggested to prevent that very situation, so is there a reason why we should interrupt mid-tagging rather than click "Submit" and check everything at once?

This thread will not get anywhere if the tensions keep being this high. Please remember that in the end everyone here is working for a better tagging experience so our goal is mutual.