TL;DR

If a theme is truly broken we need to fix it, not force grammars to work around broken themes by renaming CSS classes.

The tail-end of the discussion that prompted this is below. A grammar author was suggesting that they use keyword in their grammar for what are clearly "built_ins" because they dislike how some themes choose to use the same color for number as for built_in... I think this goes against "theme autonomy" (the idea that themes decide their own destiny - no matter how ugly someone else thinks it might be).

I personally don't care for many of the themes, but I don't have to like them all. Style is a very personal choice. Not all the themes are as usable as others... I'm not sure they have to be. Again, users are free to choose any theme they wish.

We shouldn't allow grammars to redefine the meanings of our CSS classes anymore than we should allow grammars to include direct CSS/color overrides for themes they disagree with. Theming is a decision of the theme. Semantics is a decision of the grammar. If a grammar author wants to publish their own "best-in-class" theme, they are welcome to do so.

If someone doesn't like a theme, don't use it. If the theme is actually truly broken (the author perhaps didn't account for something or didn't realize something semantically) then we should fix the theme - not encourage grammar authors to just use classes randomly based on their favorites themes or "what looks best" (at a given moment in time!).

This Discussion

I opened this discussion mostly to discuss long-term theme issues. There are definitely theme issues that could use review.

• If a theme was a one time contribution and the author has no interest in it now, is anyone now free to "improve it"?
• Do we truly allow any themes at all do we have standards?
• How do we handle maintenance of themes over time as the library improves (see the high fidelity discussions Discuss: Higher fidelity language highlighting (in general) #2500 )?

I understand this grammar author's point - about "keyword looks better"... but to me this ultimately points to one of two things:

• The theme author didn't realize this outcome and may want to update their theme (to improve things).
• The theme author purposely made the choice they did and has their reasons.

And in both cases the solution lies with the theme, not with the grammar.

From the original discussion:

Well, this is the point, where the "theme reality" hits. Many of the themes have built_in in the same style class as number which makes absolutely no sense in our case.

By my count:

• Themes where they are the same: 40
• Themes where they are different 51

Without looking it's easy to find themes that blend type and keyword also (15 at a quick count)... many themes are "quirky". I personally find many unattractive - but that's just me - there is no accounting for taste. Since we currently don't have any objective standards on what makes a "good" theme (or what themes we include)... my bent leans heavily towards theme autonomy - letting themes determine their own look based on the semantic meaning of the terms - rather than allowing grammar one at a time to "cheat" themes because they disagree with theme choices.

I expect most sites/implementors typically use a single theme (or two) and if they have issues/disagreements with that theme then they can customize it. (using CSS or not aliases)

So while I agree that built_in should fit better here

This kind of seals the deal for me... these are indeed more built-ins than they are keywords. Your reasoning from a purely visual perspective.

using keyword will give much better results in many themes.

I think this is very dependent on how you define "better results". When your results become "the opposite of what the theme author intended" that is not better. I get that your heart is in the right place here, but I feel this is short-term thinking... perhaps it does make your theme slightly better today but it costs the whole library tomorrow in terms of muddier semantics, theme authors not being certain of what things mean what in which grammars, etc...

...now a theme author who already clearly expressed "really i want numbers and built-ins to look the same" (for whatever reason) has to add a special case CSS to handle Mathematica because you pulled the rug right out from underneath them by calling your built-ins keywords.

If there is a true issue with our themes here then we need to work with the theme authors (or a visual designer) to actually fix the themes, not just let grammars one at a time redefine the semantic meaning of the terms in order to achieve a certain "look". This is the road to insanity. This probably also touches on the broader long-term initiative of higher fidelity grammars.

We could surely use some help here, but the solution isn't grammars just going rogue like this. I will spin this off into a new issue.

Originally posted by @joshgoebel in #2706 (comment)