| > Right, and I don't see the HTML and the CSS as separate concerns when the HTML describes a GUI, not a document. You know that you can create themes in GTK (a Desktop GUI) using CSS nowadays, right? Whether a document or a GUI, behavior (how it works) and presentation (how it looks) are still separate concerns. > (Multiple styles)'s not a thing I've ever needed to worry about. Yeah, others have though - both as consumers and as integrators. If you are okay with the idea of re-inventing wheels every time you want to have a different color, plenty of people are not. > I'm not afraid of touching the HTML It's not a matter of being afraid to touch HTML. It's a matter of not being able to! Whether in terms of ability (some marketing person that is putting together a wordpress or Shopify store and can only go with different artifacts provided to them) or from the nature of the source code (e.g, imagine you want to make a RSS/Atom feed reader, embed a Tweet on your site with a custom styling or use an OSM tile editor), if you are not able to touch the code but you can select different styles, then it is fundamental that the data is separated from the style definition. You might not think that this is important for you to do your job, but I think that is extremely short-sighted. What made the web as interesting as an application platform was the idea that the user agent could be extended. It is in our interests as users to keep the web open and able to be tinkered with, and the easier it is to separate the layers that people want to improve, the better. |
Does GTK offer CSS layouts? Do I describe the elements of the UI using HTML? As far as I know they just use a subset of CSS - aren't the selectors predefined by the framework? I don't recall, exactly. But GTK provides an entirely different set of primitives, I don't think it's the same problem at all if you're just providing fonts and colours. Again, I'm talking about something rather specific, creating complex, desktop-like user interfaces using HTML and SPA frameworks.
> behavior (how it works) and presentation (how it looks) are still separate concerns.
Yeah, but I wouldn't say that that distinction maps to the distinction between CSS and HTML at all, not in my context. HTML, especially document structure, is also presentational. That's really what I mean when I say it's not a "document".
And any way, no matter which approach (and platform, I'd wager) you use, if you want to completely restyle a complex GUI application like what I'm writing in the way you could restyle HTML documents like the Zen garden, you're looking at some serious engineering effort in keeping the so-called behavioural HTML and Javascript in check and documented. It won't just be about how you handle the CSS, it'll be about how you handle everything.
> Yeah, others have though - both as consumers and as integrators. If you are okay with the idea of re-inventing wheels every time you want to have a different color, plenty of people are not.
I actually feel like I have better control of my colours with Tailwind than I ever did. Currently I'm using a limited selection specified in the Tailwind theme. They have names like $adjective-$colour, so it'd be weird to change them, but if that's important to you that things are themable, as I stated, you can put in the effort to set it up with semantic names and make them customizable at build time or at run time. I still think you'd have a better experience than making separate classes for every tag and reimplementing that for each theme.
> It's not a matter of being afraid to touch HTML. It's a matter of not being able to! ...
And all of these things you list are not what I do. The examples that you list have a different set of trade-offs. I'm not embedding other people's code in my GUI, and I don't expect them to take a random chunk of my application and put them into theirs. OpenDoc was a fun idea, but it didn't take off.
> What made the web as interesting as an application platform was the idea that the user agent could be extended.
I don't really know about that in the general case, I think there are more reasons than that, but in the specific case I'm certain it's wrong. The reason my company is doing what it's doing on the web is 100% about distribution. Arguably, the web stack isn't even that good for making the kind of UIs I do - but if we did what we're doing in Java, we wouldn't get any users (or investors).
I totally agree with you about openness, but openness in my space means providing good APIs and integrations with other services, not allowing user stylesheets. A user stylesheet for my app would mean a twenty page list of weirdly interdependent CSS selectors, and the end result for someone who implemented it would be something like a colour theme that only works for app. Explain to me who would want that.