Proposal: Iconset update -- tag

Development
1

Context

While working on XWIKI-15069: Make Tags use IconThemes (see PR #5161), with @MichaelHamann we found out that our IconSet’s tag is actually just a self-mapped Silk compatibility entry, pointing to Silk’s literal “XML tag” glyph. It’s not the label-shaped icon we thought it would be. Silk does have one for this, tag_blue, it’s just not exposed under any generic name that could also work for FontAwesome (FA) or the iconSet.

Problem

tag is overloaded:

  • it’s the natural name for the “label” concept (used by Tags and livetable.css);
  • it’s a legacy Silk self-mapping, guaranteeing that requesting tag under the Silk theme gives back Silk’s own icon.

Solutions

  1. Add a new IconSet entry for the “label” concept (e.g. label), mapped to FA’s tag and Silk’s tag_blue. This solution leaves the existing tag untouched.
  2. Repoint Silk’s tag mapping to tag_blue, turning tag into a real, theme-independent IconSet entry. This breaks the “every Silk name maps to itself” assumption.

Proposal

Apply solution 2 and repurpose the tag icon name.

Explanation

+1 for solution 2 from me because:

  • tag is genuinely the concept’s name in XWiki.
  • The only known usages of Silk’s tag_XXX icons are the two spots just fixed in #5161 and only one in livetable.css, so the backwards-compatibility risk looks low. There’s no use of tag itself currently in XS. This mapping is actually quite bad so I doubt a lot of customizations relied on it (HTML tag in Silk vs label-like tag in FA).

Conclusion

Do you agree that the IconSet should be expanded to properly cover this “label” concept?
Do you agree with solution 2 or would you rather keep tag untouched and introduce a new name like label instead (solution 1)?

I’ll close this topic in a week if it doesn’t spur a large discussion.

Thank you for your interest in the topic! I’m looking forward to your answers :slight_smile:
Lucas C.

2

+1 for solution 2.

Thanks,
Marius

3

As I’ve mentioned in the chat already, I’m also +1 for solution 2. My main reasons are:

  • Having to use “label” in code that is full of “tag” feels very unnatural, and I fear it’s error-prone (we might use “tag” without noticing, in particular as it looks the same in our default icon theme).
  • If anybody relied on “tag” being an XML-tag, that assumption was already broken long ago by our default Font Awesome icon theme.
4

+1 for solution 2 as well, thanks