Requested feature overview description.
Add sub-categories to general tags, and display this in the same font size as the tags, but light grey or ij italics with the same show/hide buttons as the main tag categories (Artists, Species, General, Meta, etc.).

Some tags would show in multiple categories, this is fine as some relational tags are in more than one category (ie. older_male is both Age and Gender).

On the backend, this would be achieved by distributing a JS object (dictionary) to users of all indexed tags. Keys being tag names, and each value being its key's categories (maybe an 8 digit binary sequence, each category having it's digit as a toggle gender:10000000, clothing:01000000, age:00100000, etc., making a single pair in the dictionary like "older_male":10100000.

This could all be implemented in under a few dozen lines of JS, that could be run after the initial page load like a greasemonkey script if enabled by the user. It would require no communication to the server aside from fetching existing tags and checking for tag changes weekly (which could be maintained as a json text file on github or something if I were to make a third party wrapper for this). It could work with the finished HTML of the page, simply indexing the tags displayed on it

Why would it be useful?
This would improve readability of the tag list for casual consumers, power users, and janitors alike. It could reduce the odds of forgetting to remove an implicator of a tag (ie. removing hat but forgetting fedora, causing hat to automatically re-added on save).

Large amounts of tags would be easier to maintain because one could review all relevant tags sequentially and uninterrupted by tags that are irrelevant to a particular group.

What part(s) of the site page(s) are affected?
Post listing page, post view pages, and the post edit page.

This could also be applied to the recent edits on the tag search page, although that list is chronologically sorted already.

Also perhaps a setting in the account setting to opt-in right below the hotkeys toggle.

magikarp said:
Requested feature overview description.
Add sub-categories to general tags, and display this in the same font size as the tags, but light grey or ij italics with the same show/hide buttons as the main tag categories (Artists, Species, General, Meta, etc.).

Some tags would show in multiple categories, this is fine as some relational tags are in more than one category (ie. older_male is both Age and Gender).

On the backend, this would be achieved by distributing a JS object (dictionary) to users of all indexed tags. Keys being tag names, and each value being its key's categories (maybe an 8 digit binary sequence, each category having it's digit as a toggle gender:10000000, clothing:01000000, age:00100000, etc., making a single pair in the dictionary like "older_male":10100000.

This could all be implemented in under a few dozen lines of JS, that could be run after the initial page load like a greasemonkey script if enabled by the user. It would require no communication to the server aside from fetching existing tags and checking for tag changes weekly (which could be maintained as a json text file on github or something if I were to make a third party wrapper for this). It could work with the finished HTML of the page, simply indexing the tags displayed on it

Why would it be useful?
This would improve readability of the tag list for casual consumers, power users, and janitors alike. It could reduce the odds of forgetting to remove an implicator of a tag (ie. removing hat but forgetting fedora, causing hat to automatically re-added on save).

Large amounts of tags would be easier to maintain because one could review all relevant tags sequentially and uninterrupted by tags that are irrelevant to a particular group.

What part(s) of the site page(s) are affected?
Post listing page, post view pages, and the post edit page.

This could also be applied to the recent edits on the tag search page, although that list is chronologically sorted already.

Also perhaps a setting in the account setting to opt-in right below the hotkeys toggle.

Hmm, maybe something to integrate with 'Preview Final Tags'?

alphamule said:
Hmm, maybe something to integrate with 'Preview Final Tags'?

Strictly as a utility to help tagging, yes, but this would also be for making it more readable for people that explore the tags when looking for stuff. E621 does an interesting selection of tags and it's hard to find them the more tags a post has due to the general category being quite large.

I always wondered if there should be more categories because the general category can become a pretty overwhelming list, especially when people start tagging the colour of every individual body part for example. Although too many categories could also become overwhelming so the idea of subcategories could be a good solution.

themasterpotato said:
I always wondered if there should be more categories because the general category can become a pretty overwhelming list, especially when people start tagging the colour of every individual body part for example. Although too many categories could also become overwhelming so the idea of subcategories could be a good solution.

Pretty much this. I have alternative suggestions too, but they would function differently and thus should probably be their own feature requests.

I might make some various mockups when I get home and post them separately as a general ideas thread. I can definitely see the utility for assisting with tagging but I am curious as to what other casual users would want.

magikarp said:
It could reduce the odds of forgetting to remove an implicator of a tag (ie. removing hat but forgetting fedora, causing hat to automatically re-added on save).

That particular category of problem should be fixed by .. actually fixing it. ie. the server should be fully capable of making the inference that the removal of a tag that is implicated by one of the remaining tags is a user error, and bringing up a dialog to allow the user to specify what they actually meant to do.

As for your technical approach, it seems logical but I think it won't scale, ie. you'll end up with more than 53 categories, and javascript won't deal correctly with that

As a practical matter, Javascript integers are limited to about 2^53 (there are no integers; just IEEE floats)

You would need a dictionary key: [list,of,integer,values], and the mask definition would need to correspondingly provide both a 'which integer' index and a 'mask with' value.

savageorange said:
That particular category of problem should be fixed by .. actually fixing it. ie. the server should be fully capable of making the inference that the removal of a tag that is implicated by one of the remaining tags is a user error, and bringing up a dialog to allow the user to specify what they actually meant to do.

I would use a recursive function that removes a tag and all parent tags if the parent is the ONLY implicator, because more than one tag implication means that the parent could be coincidental.

Regardless of the approach, this is only tangential to this original request and could be implemented independently.

As for your technical approach, it seems logical but I think it won't scale, ie. you'll end up with more than 53 categories, and javascript won't deal correctly with that
You would need a dictionary key: [list,of,integer,values], and the mask definition would need to correspondingly provide both a 'which integer' index and a 'mask with' value.

I see what the issue is from the url alone lol. It would be saved as a string, not an int, but just converting it to a string to read each digit anyways. If space becomes a concern (due to having many categories, which most of whoch would be disabled and leftover tags would be filed under "Other") then I could convert it to base64 or hex before storing as json to shorten the string by like 10x.

Again though, this is only tangentially related- however, that tangent point is the category number and is something worth discussing.

- On Topic starts here -

If there were 53 categories then there would be other issues, like having some tags show up in 10 categories, and most categories never being used. The point of categories would be to pull together large group of tags. Ie. describing all the clothes in a drawing of an elaborate costume party would probably create like 30 tags, a slew of colored general clothing tags, general clothing tags, and specific clothing tags.

However, having a category for tags that may only get one or two on most images like "Sports", is much less useful for image organization. (Each category could have a minimum number of tags required for it to show up, categories like Gender, Clothing, Body Features, Anatomy, and Sex Organs could be considered "default" and require only 1 or 2 tags before the category pops up; other less common categories like Sports, Vehicles, etc. would have a higher threshold for tags before the category would show and the tags would be moved there and out of the Other category at the bottom.

Additionally, categories could be enabled if an image has over a certain number of tags in the "Other" category and would use any groups of 2 or more tags to lower that number back below a threshold (for example, it could be 10 tags) or until it runs out of tags that have categories (I assume that there will be many uncategorized tags for quite a while, but on the other hand it would be quite easy to assign them en masse, since the implications of a bad category are minimal).

magikarp said:
I would use a recursive function that removes a tag and all parent tags if the parent is the ONLY implicator, because more than one tag implication means that the parent could be coincidental.

That would be prone to misuse. A tagger may not realize a given tag is valid since it's added by an implication, and try to remove it believing it's not valid. For example, a tagger feels bestiality doesn't apply because it's a sapient feral+anthro pokemon, not a human with a non-sapient feral. So they delete bestiality, which would cause anthro_on_feral to be deleted despite being valid. We've had a number of people come and ask "why can't I remove tag X?", with the answer being "because it's implicated by Y, which is valid, making X valid." Sometimes that leads to a discussion on whether Y should implicate X, that leads to removing/fixing erroneous implications.

You can use the Preview Final Tags button to see why a tag is getting added back, although the way it lists them is messy (it shows all implications, not just ones for tags being added, and there's no order to the tags being added). But it's better to use that, IMO, and make sure you're tagging properly, than to have tags automatically removed to prevent an implication that may be valid.

magikarp said:
If there were 53 categories then there would be other issues, like having some tags show up in 10 categories, and most categories never being used. The point of categories would be to pull together large group of tags. Ie. describing all the clothes in a drawing of an elaborate costume party would probably create like 30 tags, a slew of colored general clothing tags, general clothing tags, and specific clothing tags.

Duplicate/triplicate tag listings would be a problem. Tags showing up multiple times under different categories would cause the tag list to grow and make it more unwieldy to look through. There would likely be disagreements on what categories should exist, and probably disagreements on what categories certain tags should belong to. Older_male, for example, doesn't indicate a particular age. It only indicates relative age to another character (which can be in the same age range, e.g. an older adult male with a visibly younger but still adult female, or a teenage male with an older but still teenage male), so it doesn't seem to me like it should be in the same "Age" category along side young or child, that specify an absolute age range. Absolute age and relative age tags serve different functions, and people get confused with them already (~younger_male ~younger_female ~older_male ~older_female solo has 8 pages of results, currently), so putting them together in the same Age category would add to the confusion and cause more mistags, IMO.

watsit said:
That would be prone to misuse...

Yeah, probably. Maybe if an option is enabled then the tagger can use shift+backspace to delete a tag and its parents. Or it could only be done from the Preview Final Tags menu and is a button rather than hidden behaviour.

Should someone make a thread for this? It is unrelated to my suggestion of adding sub-categories for tags.

...You can use the Preview Final Tags button to see why a tag is getting added back, although the way it lists them is messy (it shows all implications, not just ones for tags being added, and there's no order to the tags being added). But it's better to use that, IMO, and make sure you're tagging properly, than to have tags automatically removed to prevent an implication that may be valid.
[/quote]

That specific feature is independent of what I suggested originally, although imo: the searchbox is helpful in its current state.

Still: potential improvement would be to have the "Preview Final Tags" button auto-focus to a searchbox after the menu pops up and then the user can type to filter the menu contents with a fuzzy search ranking. It would only reference the content already on the page, so this feature would be PURELY frontend.

Duplicate/triplicate tag listings would be a problem. Tags showing up multiple times under different categories would cause the tag list to grow and make it more unwieldy to look through. There would likely be disagreements on what categories should exist, and probably disagreements on what categories certain tags should belong to. Older_male, for example, doesn't indicate a particular age. It only indicates relative age to another character (which can be in the same age range, e.g. an older adult male with a visibly younger but still adult female, or a teenage male with an older but still teenage male), so it doesn't seem to me like it should be in the same "Age" category along side young or child, that specify an absolute age range.

Yes, it would grow the tag list. Perhaps by default it would only assign the tag to a category once, and some categories would have priority so once a lower priority category gets to pick its tags from the pool, it can only take the ones that haven't been absorbed already.

Some optional features to supplement this behaviour.

• Users could rearrange the categories in a list in the settings to change priority.
• Each category would have a "force copy" checkbox, indicating that it will pull its tags from the pool and copy its tags from the other categories (behaving like the original behaviour, creating duplicates, but also removing tags from the pool so that its tags cannot be copied by categories following the rule).
• (Easiest) A toggle to disable the rules entirely and just have a longer list containing multiple duplicates like originally suggested.

Absolute age and relative age tags serve different functions, and people get confused with them already (~younger_male ~younger_female ~older_male ~older_female solo has 8 pages of results, currently), so putting them together in the same Age category would add to the confusion and cause more mistags, IMO.

Again, there's probably a solution (I made a new topic because this is OT here)