A case for CSS-Like Languages
For many years now, it seems that almost not a week goes by where I don't wind up thinking about the same topic while reading threads. Occasionally, I bring it up in private conversations, and recently it seems some others are starting to discuss something around the edges, so I thought that I should probably write a post...
The first "S" in CSS ("Style") governs a lot its design in both theory and practice. Much about it, ultimately, is designed toward, and limited by constraints around potentially fast-changing visual style. As my colleage Eric Meyer cleverly noted:
[W]eb browsers are actually 60fps+ rendering environments. They’re First-Person Scrollers.
What's interesting though, is how natural it seems to want to write things "in CSS" that don't fit into those neat little constraints. CSS is literally full of concepts which could be deployed toward other problems: Separation of concerns, sheets, media queries, selectors, pseduos, rules, ua-stylesheets, properties, functions, computed values and the complex and automatic application of all of those things.
It's been an almost regular occurence that people desire to somehow deploy those concepts toward ends that are not, strictly speaking, about potentially fast-changing visual style.
Some of many examples
Over the years, this has taken many shapes. Sometimes we try to rationalize about how it is style, sometimes we try to shoehorn a solution. Occasionally we have even had proposals and experiments that tried to somehow attempted to tap some aspect of this problem and some of those same concepts to bear on a different problem. Before CSS, Action Sheets proposed that actions and styles should be considered. Simple Tree Transformation Sheets offered ways to transform the DOM (that would be mentioned in Håkon's thesis on CSS itself). Shortly after, there was an attempt to add behavioral extensions to CSS - Microsoft even implemented some stuff. Another take on this introduced XBL to creating a 'binding' that could be applied via CSS. Public Web Components discussion began when trying to decide what to do with XBL, and they initially included a similar concept to bind in CSS via decorators.
A completely different angle of this was CSS Speech which reasoned that this was simply "aural styles".
Except, of course, in each of those cases the particular needs and constraints are a bit different. They shouldn't change at 60fps, in fact. Things that are kind of verbotten or impossible in CSS today might be totally solvable and fine, if only it weren't somehow shoe-horned into CSS, proper.
CSS...ish
Several years ago, discussions like these led Elika Etemad (aka Fantasai) of the CSS Working Group to make a suggestion to Tab Atkins (now a prolific CSS editor) which yielded a sketch for something called Cascading Attribute Sheets. As they say, it's not the first such take, it's just a nicely linkable, well-informed and dated illustration of a proposal to create a CSS-like language which repurposes major concepts and parts of the architecture toward other aims. As Tab noted in his CAS post, internally, browsers do this to an extent already.
In 2012, I was on a very similar page. I was doing things at my company which did exactly this. My partner and I went about trying to decouple what we could in order to share this with Tab and others in order to hopefully participate in the discussion. We began creating a version of this called Bess on Github, but it was incomplete and full of some bad internal ideas. It did, ultimately lead us to sharing something far more limited (HitchJS) and allow us to begin a much bigger discussion about what made this and a whole lot of other useful things (like, polyfilling something in CSS) way too hard. I even used this to create a kind of polyfill for Tab's CAS Proposal. I don't think it's particularly a great proposal as it stands - but there's clearly something there.
These discussions also led to the establishment of a new joint task force between members of the W3C Technical Architecture Group and the CSS Working Group: Houdini. In the very first meeting of this task force, the group agreed that making it possible for us to repurpose architectural aspects in order to explore "CSS-like languages" was ideal.
Now...
A lot has happened since that time, but realistically, we really haven't had a lot of time to talk about or pursue the stuff that would better enable us to explore CSS-like languages.
I think that's a real shame because we continue to have problems and ideas where at least advancing discussions on this would seem very useful.
Cascading Spicy Stuff
Consider our <spicy-sections> work in OpenUI, for example. It seems very natural to use the basic language and paradigms of CSS to express this. We're not entirely sure about some things, so we're waiting to see what pans out with the CSS Toggles.
This is also (I think naturally) shaping up larger conversations and ideas about whether we could just have "state machines" in CSS, and how we can share state and so on.
However, at the same time, it is also very unclear whether something which changes semantics and interactions at fixed points really belongs in CSS and the 60fps profile itself.
I pretty much agree with Mia here
I get very excited by the idea of a declarative language for managing state on the web.
— Mia (but older) (@TerribleMia) March 3, 2022
And I get very excited about CSS being able to manage basic presentation states.
And I think we need to draw a line between those two ideas, or each one will end up complicating the other.
There probably are things that work just fine in CSS - but at some point, we've entered something of an uncanny valley, and things get harder. We can't know where things should develop and live without a larger conversation.
I guess what I am trying to say, in the end, is that I love all of the convesations that are suddenly happening, and I'd love it even more if we spent some time thinking about how we might draw these lines and explore CSS-like solutions.