Another Discussion On Tags And Tagging

[TW_Tones]

@nemo

tags can have icons set though

Keep in mind all tiddlers can have a color or icon set and that is how $:/TagManager works.

The only issue I find is if you transfer tags to a wiki with saved icon and color preferences you may break some aspects of an existing tag/tiddler.

This makes me ask the question could we build a data tiddler containing titles and colour that one then uses to apply those colors to those tiddlers if the color field is/is not empty. But in a generic way one could do this for other fields, which incidently includes title and the creation of missing tiddlers.

• One obviouse use is to add system tiddlers that are not yet used in the wiki.
• Click to create tiddlers/tags from a list using the listed color
• Similarly one could capture same to a tiddler for export.

title: fieldname

eg title: color

t1: blue
t2: green

Such a tool could use an advanced search filter tab and export button.

[Eskha]

Hello,

In oder to help keeping color and icon consistency for tags, I sort them in categories and use a dedicate toolbar to help with categories, icon and color assignment:

You can go in the sidebar > mor > tagging > categories in the following TiddlyWiki :

DelphesNotes Demo

(This toolbar is included in the DelphesNotes/TagsSidebar plugin)

BR,

Eskha

[Springer]

@TW_Tones

This makes me ask the question could we build a data tiddler containing titles and colour that one then uses to apply those colors to those tiddlers if the color field is/is not empty.

This comment pulls in a slightly different direction, but:

Tag COLORS (other than the single default tag-background and tag-foreground) are among the only aspects of TiddlyWiki’s interface that remain especially resistant to palette integration.

I do use different palettes in different wikis (helps me orient to “where I am” given that I may be actively shifting between them in open tabs). AND this means that bringing the tag-pill color along for the ride, when I import a tag’s tiddler, may actually be a small bit of undesired awkwardness to tweak after import.

I use the linkstyle solution in all my wikis, so that some of my tiddler titles and links always display in, say, the current palette’s code-foreground color. I’m also used to tweaking certain interface elements by adding 2 alpha/opacity digits to palette colors in order to get nice effects, etc. Even your filter-pill macro can work with the palette if you set a variable (<$let thisColor={{{ [{$:/palette}getindex[code-foreground]]}}}>…<<filter-pill "[tag[essay]!tag[archive]]" """current essays""" $(thisColor)$ "white">>)

But with tags, it’s either the active palette’s primary default tag color or a hard-selected hex-value as selected for the color field (no alpha, no colour-macro magic). Right?

The result is that a change of palette makes for very different contrast conditions.

I do see why many people prefer explicit fixed colors for certain kinds of tags (hooking into color-associations with green-yellow-red for example… note recent palettes sometimes include such fixed-color options, presumably because of such needs).

Still, sometimes contrast and aesthetic unity is key, and since the palette has a default tag color, it’s quite odd not to be able to work flexibly with other palette-driven ways of working with tags. Generally, I want my wikis (such as my intended biblio community edition) to have tag-contrast AND to be friendly to palette changes.

I suppose I could try to rig something with cascade conditions and the color action plugin… For example, we could make tags respond to their place in a tag-hierarchy with, say, opacity-changes (progressively “diluting” a hex value at the top/parent tag)… or make it so that tags with natural-language strings in their color field (green, red, etc. — which don’t currently work and are hard to edit, given the color-field’s fixation on hex values) would remain rigid…, while other tag-colors would get remapped in harmonious ways (perhaps especially promising on the flexioki-enhanced palette)… Also, we could get a cascade to tweak colored tagpills based on light palette vs dark palette flag… It’s not a high priority for me now though! Just one way in which our support for palettes seems still to be lagging.

[Scott_Sauyet]

@Springer

Tag COLORS (other than the single default tag-background and tag-foreground) are among the only aspects of TiddlyWiki’s interface that remain especially resistant to palette integration.

I wonder if the only underlying change required would be to wikify the color value of a tiddler before using it, allowing, say:

title: Concepts
tags: Reference
list: Cascades ColourPalettes Commands ... WikiText
color: <<colour download-background>>

...

There would have to be UI changes to allow this, as the field selector couldn’t be a simple color-picker, but it feels like that would solve this relatively well. Now, I have no idea how many times the color field is actually used across the source code. There might be a lot. This might not be a simple change to make, but AFAICT, it would not be actively harmful. Existing CSS values wouldn’t change on wikifying.

BTW, it doesn’t work now. I did try, and when I set the color field to <<colour download-background>>, the tag pills just use the default color. It’s non-trivial to test, since the normal editor won’t let you enter text for color. But you can set it programmatically, with a button:

Changing tag color.json (772 Bytes)

I’m curious as to what problems this might cause; it seems a simple enough idea.

[Springer]

@Scott_Sauyet

you can set it programmatically, with a button:

You can also just add the field with the value already specified (typed out) within the field-editor’s add-new-field interface, or by using Commander and other utilities. I also have tried such things, and have tried lots of “clever” variations in an attempt to make a “smarter” (more palette-friendly, or just more condionally savvy) color for a tag …

[Scott_Sauyet]

@Springer

You can also just add the field with the value already specified (typed out) within the field-editor’s add-new-field interface

D’oh! Sometimes the obvious is just not obvious! Usually if I want something like this, I export the tiddler, change it in a text editor and reimport it… silly!

[TW_Tones]

@Scott_Sauyet

There would have to be UI changes to allow this, as the field selector couldn’t be a simple color-picker, but it feels like that would solve this relatively well.

Actualy I have played with similar changes before and think this may be easier to do that you would think. The trick to maintain backwards compatibility to to check if the color is a valid code or name and use that and if not wikify the field and use the result.

One way may be to use filters that resolve the color value as a function may.

Another approach may be to give the user another layer of control, a custom pallet, one when can reference existing pallets, a pallet whos values can be retrived by macro/procedure, function or more.

• For example one could set a border around a tiddler according to if a field value is positive or negative, but automaticaly leverage a day/night switch.

[Scott_Sauyet]

@TW_Tones

The trick to maintain backwards compatibility to to check if the color is a valid code or name and use that and if not wikify the field and use the result.

I’m thinking it may be even simpler than that: always wikify.

There are many different formats of CSS colors, but I don’t think any of them use syntax that would invoke wikitext processing, so they would simply be left alone by $wikify. (I’m not certain about this, but I think if there are cases, they’re pretty rare.)

I know there are some plans for better color handling in 5.4.x. I wonder if this would fit with those plans.