With the placeholder themes inside sugar, you would expect them to be completely skipped if a theme overrides it. But it doesn’t. This can be a problem for theming. For example, the php sugar’s PH themes are all prefixed with php:

As they are more specific than just:

The second one, in the our theme, gets ignored. This means our themes can’t just use general styles, like “variable”, or “function”, as the placeholder theme selectors take more precedence as they’re more specific. Perhaps this is up to the sugar creator, but that will make theming less… easy

Thoughts?

Initially I made the selectors less specific (like you’re suggesting), but I guess they interfere with the default theme or other placeholder themes? Anyway Jan had added the php prefix. I’ll wait to see what he says.

Placeholder themes are combined with user themes (unless overridden), but in the case where they are actually active (not overridden) their rules are treated exactly like a user theme. Hence, a placeholder theme must ensure its rules don’t start affecting other languages (like the PHP placeholder used to before I made them more specific). Since Espresso tries to ignore the concept of a global language for a file in most of the subsystems (this promotes embedded language thinking), all theme rules should be considered on the syntax tree only, not what user-visible language is selected.

Actually, now that I re-read this post I realize that it sounds like a bug—when your user theme overrides the php placeholder, none of those rules should have any effect at all.

Jan: Yeah, I agree about the theme. I just wanted to make sure you understood that it’s unnecessary to append the language name to every … single … zone … name in your LanguageSyntax.xml - originally, all of the shipped sugars did that. There’s no need, because they’re all a subset of the “languagename” language anyway, which we can hook onto with the CSS selectors. I was kinda surprised that you did that, actually d-: