State of CSS
web.dev
web.dev
Before the flexbox/grid arrival, there were years of near-zero progress.
The flexbox/grid release, uniquely coordinated across browsers (for once), was an excellent milestone, but not really a movement.
These last 2 years though feel almost like a revolution in comparison to CSS's history. Somebody is pushing very hard.
These are some very serious improvements that address core needs and gaps. In particular scaling CSS in large applications, with things like @layers, @scope and container queries.
The second goal seems to be to make CSS preprocessors obsolete.
Compliments to whoever is working on this. My favorite upcoming one has to be toggle, controversial or not, the idea that for simple interactions you don't even require JS anymore is a good development.
The luxury problem this creates is the slow adoption rate. Something extraordinarily powerful as grid is still barely used. Old habits die hard.
When it comes to Chrome-only non-standards Safari is right where it needs to be: not implementing this bullshit.
It’s good that both browsers are a hindrance to Google just shipping stuff and that stuff becoming a de facto web standard. It’s even good that they have different priorities because that gives them different perspectives from which to catch mistakes before they’re almost totally irreversible.
They have a large network of "developer advocates" whose only job is to promote Google and Chrome under the guise of promoting web standards. And, of course, these "web advocates" will often go out of their way to vilify other browsers.
They own web.dev where they push out propaganda pieces and present their own work as fait accompli often without as much as mentioning that no, these are not standards.
Coupled with the fact that Chrome is actually the most dev-friendly browser, and you have huge swaths of dev community lapping up whatever Chrome throws over the wall without a single second thought.
There's no such thing as a PWA. There are a dozen disparate standards, and everyone has their own idea which collection of standards constitutes a PWA.
Mobile Safari supports the absolute vast majority of those standards.
IIRC the only "major" standard from that bunch that mobile Safari didn't support was push notifications.
Or am I doing something wrong?
The other thing is that no website can ask you to install it like on Android. You have to go to the "share" menu and add to homescreen. Most users don't know about that.
You mean codecs developed exclusively by Google (often in rapid succession) and which Google aggressively pushes by abusing its dominant position https://www.protocol.com/youtube-tv-roku-issues
Worth noting that Safari is starting to roll out support for VP9, one of the formats by Google. Unfortunately this format is already rather outdated, and if Apple was going to support a free format now they should have gone for AV1. Which goes to show how slow they are
Both WebM [1] and WebP [2] have been supported by Safari for nearly two years now.
WebKit added support for AVIF (essentially the single-frame version of AV1) back in September [3]; AV1 is expected during the iOS 16/macOS Ventura release cycle.
[1]: https://webkit.org/blog/11648/new-webkit-features-in-safari-...
[2]: https://webkit.org/blog/11340/new-webkit-features-in-safari-...
[3]: https://webkit.org/blog/13152/webkit-features-in-safari-16-0...
Which was incredibly late. For example, Firefox had it since v28 [1], which was 8 years ago. Firefox has also supported AV1 for 3 years already. And obviously Chrome supported both for longer
So we’re doing this? Instead of acknowledging your statement was incorrect, now it’s about how supposedly late Apple was in supporting the formats you said they didn’t support.
And no disrespect to Firefox, but them having WebP support 8 years ago (and AV1 support 3 years ago) in the big picture doesn’t matter that much outside of the web developer/HN/geek echo chamber and the single digit percent of market share Firefox represents. Nothing got held up; a properly designed site would fall back to JPEG or PNG if WebP wasn’t supported by a particular browser. Not the end of the world.
But when your device is in a “billion pockets y’all” it matters. That was true a few years ago when Oprah said it; it’s closer to two billion pockets (and desks and backpacks).
It’s pretty common on HN to trash Safari when it doesn't support web standards and then find another way to trash Safari when it does support those standards and then ignore Safari when it ships a feature first and pretend it didn’t happen or doesn’t matter.
A quick list of web features shipped first:
• first browser engine to implement the new color syntax defined in CSS Color Module Level 4
• first browser to support drawing shapes, text, gradients, and shadows with wide gamut CSS colors on Display P3 canvases
• first browser to ship a proposed web standard for measuring advertising in a privacy-preserving way – Private Click Measurement
• the only browser that supports lch() and lab() color functions (and probably the only browser to support these predefined color spaces: a98-rgb, prophoto-rgb, rec2020, xyz)
• first browser to ship large, small and dynamic viewport units
• first browser to ship :has() parent selector (March vs August 2022 and later for Google and Mozilla)
There are more but these are the most current ones after a few minutes of Googling. Depending on the use case, some of these may be critical to some web developers.
I get it—Safari being current and in some cases, ahead with their support of web standards that they, Google/Microsoft and Mozilla have agreed to—I’m discounting the proposals from Google when they ship stuff only they want/care about—doesn’t fit the prevailing HN narrative that “Safari is the new IE” and is holding the web back. Just objectively examining the state of the web back then would show how laughably ahistorical [1] this view is, but that’s where we are.
[1]: ahistorical—lacking historical perspective or context
I think you should re-read my comment. Fyi I already knew that Safari now supports vp9 webm. As a web dev I keep up with this stuff. In my comment I said that they are so behind.
There's another list of Safari's failures here: https://httptoolkit.tech/blog/safari-is-killing-the-web/. In fact from the article
> According to Can I Use's metrics, Safari is lacking about 10% behind Firefox and 15% behind Chrome in feature support.
And if these were only features that Google cared about, then Safari wouldn't be behind Firefox. But they are.
And in terms of webm/webp support, imo this stuff does matter. Webm/webp is much more efficient than gifs for audioless video content. But if a startup is moving fast and they see Safari doesn't support webp, they simply aren't going to use it. They're not going to bother storing two formats for everything. So now everybody's page load speed is impacted.
Your comment:
> Safari is so behind in terms of lack of support for free media formats/codecs like webm, webp, and av1. You can't even switch browsers to view them, since it's all webkit
Maybe you do keep up with this stuff, and you did say they are so behind, but you also said "You can't even switch browsers to view them", which is not true.
Last release of version 9 was in 2016, 6 years ago.
I do agree you shouldn’t need to buy Apple hardware or pay anyone else money to test in their web browser though.
and of all the browsers, Safari is the one that tends to render differently from others in a unwanted way. working with dozens of written languages, the ways it f~ks up text rendering and copy wrapping is sometimes baffling too.
and this is without talking about the weird UI, sometimes I try updating a URL and the cursor just starts deleting characters from the wrong place. it's so annoying. and a lack of status bar, unless you manually enable it. what a piece of sh~t browser.
Vite takes care of the boring stuff, I can write vanilla CSS with nested declarations in it, and it just works.
edit: don't get me wrong, i'd love to be 100% native CSS, but there are some things where preprocessors shine
I wonder if it's just about how some people's brains are wired.
I grok CSS. I won't claim to know everything about it, but I'd say I'm 90% proficient and prefer it to JavaScript.
But I think this is because JavaScript somehow never fully made sense to me. I can read it and figure out what it's doing, but it was never intuitive to me the way CSS is.
I read comments on HN frequently from people who are good a JS, but can't deal with CSS.
I think it's just how some languages "click" with different people. Some are comfortable in Lisp, while others are AP/L, or Rust, or something else.
Perhaps it's good to have multiple ways to achieving the same thing, rather than obsessing about one perfect/standard/preferred/"best practice" way of doing things.
(Disclosure: I work on the style team in Chromium)
One particular thing about CSS... <img> seems to never behave in any kind of auto-sizing container the same way a regular div would; it seems to need pixel dimensions to work as expected in all scenarios, especially when things are resizing dynamically. Idk how other people deal with that. That alone was my motivation for trying things my own way.
I did something similar developing an app long ago for the iPhone 4. Calculated all my dimensions in C macros cause AutoLayout made no sense. Tons of apps using AutoLayout broke anyway when the new screen sizes came out, but my app was fine. "Math is math."
CSS handles it just fine. That's how they deal with it.
The additional complexity of images is that you nearly always want to maintain the aspect ratio, whereas a p or a div can be a radically different shape depending on the amount of content and viewport size and only have issues at the extremes (like very long lines at 4k@1x, or one word per line at high zoom)
Naturally I first tried making an outer flexbox'd div then putting a {width: 100%, height: 100%} img inside that with whatever fit option. And several variations on that, including the "width: auto" or "width: 0" tricks. Somehow it'd always either go outside the div boundaries or exhibit some other glitchy behavior. On top of that, there's the issue you mentioned where the image isn't loaded yet, causing funky resizing beforehand. You're simply better off with exact pixel dimensions.
There are tons of SO questions from confused individuals in my same situation, all with different answers that only work in certain scenarios. For example https://stackoverflow.com/a/21103679 which only works for auto-resizing the width, not the height. I think your suggestion has a similar caveat.
Almost everything can be made to look correctly but somehow the right solution is the last one I'd ever think of.
#menu { display: flex; justify-content: space-between; orange; border-bottom: 1px solid red;
background-color: orange; color: #111; }
#menu >a { font-size: 1.2em; margin-right: 1em; border: 1px solid #000; }
A bit of an unconventional way to write it, but I found it really helps keeping a bit of overview because so much more fits on your screen, and because CSS is fairly simple the extra density doesn't hurt readability all that much IMO.
The biggest thing I missed was variables; but that's been solved now.
Now I just want line comments (// ..). I dislike /* .. */ comments with a passion.
Container queries will allow us to fine-tune the not-so-predictable gaps between our predictable breakpoints. Breakpoints will probably still be used for larger-picture layout, but container queries will help with the smaller parts especially in UI that have many moving dynamic parts.
The rest are just icing and honestly I wouldn't be surprised if it takes a while for many of them to become mainstream.
The major browsers (Chrome, Edge, Safari, Opera) support it except for Firefox, which has it behind a flag still. ~76% of users are covered.
:has() CSS relational pseudo-class - https://caniuse.com/css-has
- 4 months ago Chromium enabled :has() selector by default
- 3 months ago, CCS Working Group made a small design decision ("resolution") which may affect how Firefox implements it
- 22 days ago: "has() implementation is experimental, that's why it's not enabled anywhere by default."
I think the good news is that it's in active development, and seems fairly close to release.
Bugzilla: Implement the :has() pseudo class - https://bugzilla.mozilla.org/show_bug.cgi?id=418039
(and was posted a number of times then)
What might be more interesting if it's your area is the currently running State of CSS Survey https://stateofcss.com
Having access to these cool new features so early on is nice, of course, but be ready and willing to deal with possible breaking changes or even future removal.
Here's a recent example of once such breaking API change in the `:has()` selector spec being discussed on the Firefox tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=418039#c44. It will be interesting to see how the other browsers that have already released the outdated implementation to production deal with this.
@container queries are going to help a ton in making components more reusable - components that react to their own size rather than the browser size have been needed for a long time, and currently the only way to really do it is with the javascript observer api, which comes with huge performance tradeoffs.
Color-mix() is another item I've been wanting for some time, not because I need to mix things like red + blue, but because we've needed a native way to add opacity to css variables for a long time now. Having opacity be independent means we can have a robust design system that doesn't expand exponentially, while still providing opacity levels when needed.
Masonry layouts will greatly simplify a very common use case, color level 4 and 5 will make the web more dynamic and beautiful, and loosely typed properties will help add fallbacks. Definitely excited for these changes.
--color-primary: 172,250,83;
background: rgba(var(--color-primary), 0.4);
I don't think this is a failure of CSS -- I think CSS has turned out to be brilliant with some blind spots and part of the most spectacularly flexible UI layer that's ever been created. But it works at a lower level and leaks easily and that plus some cultural factors has generally pulled people towards a below-component development focus lots of devs would rather have abstracted away.
Container queries are one of several things that can move the dev culture more towards component level.
Don't forget, the core of HTML and CSS until this day basically relies on "we can lay everything and display it in a single pass".
Double pass (for tables) didn't appear in standards until 2001 if I remember correctly (but won't be able to find).
And then you have the IE-era draught of no features.
https://web.dev/state-of-css-2022/#accent-color
Sure it's a "nice to have" but it bloats the spec? Look at the current actual implementation:
https://web.dev/accent-color/#guaranteeing-contrast
chrome and firefox already tint differently...
How is this better than a good ol CSS variable and leaving it up to the designer to manage?
Sure http://dowebsitesneedtolookexactlythesameineverybrowser.com/ but when the exec is like "why is our brand color slightly different on ff vs. chrome... we are back to square one.
"Disregard logic, acquire funds" - Ducreux
(The workaround was creating a fake element that looked like a checkbox that overlapped the actual checkbox.)
Lean on the primitives we already have, enable flexibility, and if someone wants to make a SaSS wrapper or CSS function to do it, enable that vs. more random places for browsers to diverge on "standards".
It plays out like this:
"Oh, I wanna change the UI element style, thats a new feature! Accent-color! Nice. Oh wait, browsers are doing different things. Dang. Am I okay with that? vs. "I wanna change a UI element style, Oh, browsers now support classic CSS styling attributes on these elements! Nice! Designers sets colors, all browsers just read the designer's palette.
i've seen safari and chrome (but not firefox) expose some form input components as shadow DOM (e.g., slots), but wasn't sure if it was actually reimplemented.
There is also a newer workaround by styling the input element it self by using appearance: none. You can do some clever stuff with the :checked selector, multiple backgrounds, clip-paths, masks, etc.
If you were able to style the element with "classic" CSS primitives like border/background/color would that not have also solved the problem without introducing new syntax with new quirks?
input[type="range"]::-moz-range-thumb,
input[type="range"]::-webkit-slider-thumb {
background-color: red;
}
input[type="range"]::-moz-range-thumb {
background-color: red;
}
input[type="range"]::-webkit-slider-thumb {
background-color: red;
}I'm super excited for some of these additions. Perhaps they are meant for designer-developers such as myself and not for the casual CSS developer who doesn't already reach for existing advanced features.
But the state of CSS for implementors is still abysmal, in my opinion, and I'd like to see more of the spec formally defined for some of the most fundamental parts of it.
It would be nice if the spec matured for implementors, too.
Like, could we please get a formal definition of the CSS processing model? The lack of one means that particular events MAY OR MAY NOT exist in user agents.
Those events may exist in large implementations--and when a CSS standard eventually pops up to utilize those vendor specific events, some implementations may not even have them, because they process CSS in an entirely different way!
An HTML5 moment for CSS would be very welcome.
I'm hysterical about the state of affairs for these exact sorts of things, but comparatively almost no one is an implementor, so most people have no idea how bad it can be.
So basically for 25 years, as far as I understand, no one said, hey given a set of known layout constraints and rasterization parameters, let's create automated tests.
For 25 years.
Maybe I'm wrong, but I keep looking for these tests and the ones that exist for normal flow are a nonstarter.
I'd almost bet there are probably more people who have reimplemented OpenGL in software than people who have read and understand how CSS compositors work.
For example, if you asked someone how user agents create backing tiles for CSS, they'd look at you like you spoke in a foreign language.
You totally don't need to know this stuff, but if you were doing say, high-perf UIs in WebKit (iOS), you'd probably at least want to know how to hint to WebKit that something needs its own render target or how to minimize subtree redraw.
I built massively performant large UIs for payroll systems on iPad years ago and found that if you optimized your UI just right, you could get smooth scroll performance that showed cracks in how fast the iPad was able to draw backing tiles at the time.
You'd get whole squares black scrolled into view while WebKit asynchronously drew in elements.
https://www.w3.org/Style/CSS/Test/Overview.en.html
https://web-platform-tests.org/
better specs are great, but tests will actually find the edge cases and lead to more convergence.
I still prefer to use tables to layout my websites.
Question: Say I want a layout that has a top row, a middle row and a bottom row. Each row gets 33% of the screen space. Unless the content does not fit. Then the row should expand to the content.
Here is the table version:
https://jsfiddle.net/vg2ey8r9/
How do you do that without a table?
https://jsfiddle.net/3hfosn5k/
Scroll down and you will see that the blue color of the bottom row ends and the text overflows it.
But I want what table cells do: Expand if their content is too large to fi.
Just like Tables have <table> and then <tr> - your div's need a similar parent-child relationship to work.
Here's a working fiddle: https://jsfiddle.net/0389jsca/
When I try, I don't get the nice behavior of tables, but a stiff layout that does not adapt to its content. Instead the content overflows the rows:
https://jsfiddle.net/3hfosn5k/
The nice thing about tables is that I know the table cells will always surround their content. Nothing will flow out of the cells.
One of the nice things about grid is that you can size the tracks on the parent element, and all you have to do on the children is specify which rows/columns they span. It works much better when you want to do the sort of things you use rowspan and colspan for with tables.
EDIT: Setting height: 100% was also preventing the grid from expanding. Try this JSFiddle https://jsfiddle.net/c3m2194b/
Yep, it's nice to have an alternative to flex (where children determine their own size with flex-grow / flex-shrink / flex-basis).
> Setting height: 100% was also preventing the grid from expanding. Try this JSFiddle https://jsfiddle.net/c3m2194b/
This is an issue I've run into a lot. Well the opposite, when I want overflowing grid cells to gain a scroll bar instead of expanding the parent. Turns out this is only doable if the grid element has an explicitly defined height, which means hard-coding a height like `height: 50vh` or ensuring every ancestor of the grid has `height: 100%` defined, which is pretty gross.
display: flex;
align-items: center;
margin: 1px;
The border still kind of looks better on the table one, it's like the flexbox border is not the same size vertically and horizontally.
Once you add enough text that they need to re-shape, they both behave differently. I kind of like the look of the flexbox one better though.
Table https://jsfiddle.net/gs73eyd5/1/
Flexbox https://jsfiddle.net/g4qv2dr6/2/
Also they both break pretty badly if you put some content so long that would require an automatic line-break (make sure you scroll to the right to see) With flexbox the content overflows outside of the container, but it preserves the sizing of the other elements. Table expands the whole container but in doing so ruins the other two rows.
https://jsfiddle.net/ysu7fgk1/ vs https://jsfiddle.net/q6dcph0x/
And that request will come.
If only for some presentational aspect of an internal design system I’m building, it’s a dream come true.
I think only Firefox is without.
I was really excited to see GSS (http://gss.github.io), however at the time it was far too slow to be usable in real projects.
I imagine container queries will totally change the way I write CSS as soon they are broadly supported.
Of course this would not make for a truly constrained-based layout definition. But it would at least make working this way somewhat possible.
The example where flex-directon is switched using a container query is spot-on. That's exactly ly what I sometimes miss being able to do in HTML+CSS.
Apparently there is a JS polyfill (awesome given the problem) but I haven't tried it and I assume the performance implications are bad.
> Gradients can't be animated though. They are too flexible and too complex for the browser to "just derive" how you want them to animate.
Animating gradients can be joyful work (with obvious caveats that such animations need to respect accessibility concerns eg prefers-reduced-motion). I assume that CSS gradient animation is difficult because of the way gradients, and animations, get defined in the stylesheet?
[1] - linear gradient demo - https://scrawl-v8.rikweb.org.uk/demo/canvas-003.html
> Cascade layers
Feels like we only need this because cascading works less and less well once you start to include multiple frameworks or pieces thereof. At some point people find themselves in a jungle of !important. If you keep the cascade small and clean, you'll most likely not need that.
> Container queries
Probably the designs I have to implement are not complicated enough, but I could work very well with media queries so far.
Also this blurs the lines between markup and styling furthermore. Now you are defining IDs/classes in CSS which will make the code harder to debug.
> accent-color
Yeah, this is kind of nice. On the other hand we should not forget where the "this always gets styled by the system" comes from: Accessibility. With accent-color I can now totally easy screw up various kinds of inputs in the name of corporate design.
> Color level 4 and 5 & hwb()
Oh come on, this must be a joke. Color management is VERY hard to do, now we put more of that into CSS. But yes, advertisements can then be delivered with a wide gamut colorspace for more impact. Great.
> inert
What? This is just as bad as highjacking the scrollbar behaviour. Now you can make your website behave modal although there's no modal. Feels like another "right clicks are forbidden"-level when your paragraphs are set to inert and you can't interact with those anymore.
> Viewport units
More units of measurement is totally what CSS was missing. /s
> :has()
The parent selector looks like the only useful thing to me from that list. It will (theoretically) help clearing up the markup mess because you need less containers etc. if you want to style surrounding elements differently depending on their child content.
But the implementation they’ve chosen with named containers is not my favorite. I’d prefer one that is simply based on the parent component or the closest component with a container attribute set; this would work better alongside tools like Tailwind and CSS-in-JS.
Edit: Nvm after reading more, it looks like the container name is optional and the default behavior is what I described - excellent!
Many of us are not in that state due to piles of tech debt. One of my work projects is modernizing a 20ish year old, 300 page php app, and the css tech debt is awful. We're all looking forward to layers for some sanity.
(strong agree on your other points)
It also gives you a much clearer idea of where in your styling stack something is coming from.
> Container queries
Have you ever built a piece of functionality that goes on pages you don't control? For instance, I built software that displayed a map on people's pages. but I don't know the width of the map itself. They could be displaying it on the full width of their page or in a container. Media queries don't work in this scenario. Making the map correctly responsive forced me to use JavaScript to get the element's width.
The other solution people have for this is iframes, which suck too.
Just because you don't have a need for something doesn't mean nobody does.
I find most of this useless/overcomplicated. Who needs rounded corners? I like my png slicing. And what are box shadows anyway? There's nothing flexbox can do that I can't achieve with tables. Transitions are bad, transparency is for Apple fanbois, animations the devil's farts, and don't get me started on media queries. Phones should remain Nokia bricks.
This isn't even a straw man. Further down we're still having the tables vs CSS debate. I'm so happy we got all of the above and more and can't wait to see what's next.
In OP's defense, I still say those things about the CSS3 changes.
container queries are also neat, but still rely on having a wrapper container, which isn't ideal--why can't i style the component itself based on its own calculated height/width rather than having to involve a parent element?
i'm still waiting for chrome to implement subgrid, which will simplify any kind of card-type layout.
i also wish we had native "mixins" (@apply had this potential, but it was removed from the spec), so we could have a bundle of styles we could inject into different declarations as a group. then you could have different sets of styles in orthogonal groups (layout, spacing, border, text, inline) that you could apply in any combination. this is especially useful if you want to style a base html element a certain way and then also have a utility class with the same style later in the stylesheet (with maybe a slight tweak) that can be applied to more than just that type of element (like <div>s, <article>s, and <section>s).
edit: oh, and lch/oklch for more perceptually uniform and expanded colorspaces, combined with the new color functions (e.g., color-mix) is exciting too.
You’re complaining about the mere availability of color functions, that alone kills the rest of the comment.
Letting the world's largest advertising corporation be in charge of browser standards is probably not the best idea.
I do agree that it could be better. They have been adding print-related features though, at least I remember some in CSS3. CSS Colors Level 4 includes cmyk functions.
Feels like we’re stuck in a “yes, it meant to be a universal platform” / “no, it meant to be a document viewer” loop.
Color math is a massive rabbit hole that deserves its own "things programmers believe about..."
Right now I need to worry about the user's contrast preferences, light/dark preferences. Decide if I want to force a decent font or end up with the user's default (which probably sucks). I need to decide the text size (because their default probably sucks) and decide how wide the reading area should be.
What a mess to try and just pick something that the user wants.
- mixins. Like SCSS and SASS has had for a decade now. 'apply' was supposed to add mixins but 'apply' was cancelled in favour of 'part', and 'part' doesn't work. https://stackoverflow.com/questions/74097950/how-do-i-create...
That's actually it. We already have aspect-box, adding gradients for borders would be nice but I can live without them.
>The default color space also changes to LCH instead of sRGB.
Since LCH is the worst one to my eyes.
Is this just an issue with my monitor?
I owe my professional career development to a lot of awesome people whom I met on the Internet and helped me at each turn, without asking for nothing in return.
If it’s already awesome for you, please just give us display:constraints and fiddle with these boxes and grids as much as you want.
`@edition(2023)` could make `box-sizing: border-box` the default
dialog was so problematic that the same people that are now promoting it were in favor of removing it entirely. Literally none of the issues were solved, but now it's a great new element that we all should use.
What's the benefit to:
@scope(.card) {
header {
}
}
.card header {
}
div {
width: 640px;
aspect-ratio: 16 / 9;
}So basically not supported, and you have to go back to div hell.
There should be some future.js file that you can import to make all this stuff just work in older browsers.
I've been using if for months with no issues in cross-browser testing, and I haven't enabled any experimental flags.
What browsers? There is only Chromium left...
who the f thinks this is readable: grid-template-rows: auto 40px 1fr 80px;
But there is the middle ground of flexbox... honestly flexbox seems to work in nearly everything I use.
i don't agree btw. grid is voodoo declarations that is worse than tables. pretty much need to stackoverflow to do anything
I don't see why not.
I could imagine (and I think I am possibly observing) CSS going a similar direction to JavaScript; we might soon see the CoffeeScript of CSS, and then eventually something more sophisticated and well-designed like the Elm of CSS.
CSS — like JavaScript — might become the styling bytecode of the web.
Re your second point that CSS might become a compilation target for styling... have you never heard of Sass, Less, Tailwind, or any of a million UI frameworks that provide alternative ways to write CSS, or even avoid writing it directly altogether? This isn't exactly new.
Many newer features that have been added over the years don't actually enable anything new. Not that I'm arguing in favour of table-based layouts either.
> have you never heard of Sass, Less, Tailwind, or any of a million UI frameworks that provide alternative ways to write CSS, or even avoid writing it directly altogether? This isn't exactly new.
I have written CSS in a serious capacity for several years. I am more than familiar with Sass, Less, etc., which is exactly why I wrote "languages that aren't just supersets of the status quo".
I'm guessing you aren't writing binary in your day to day work, are you? I'm fairly certain whichever language you're working with is more featureful and ergonomic than working directly in binary.
Similarly, Elm has a different surface area from JavaScript, and yet JavaScript is the compilation target.
CSS doesn't need to be featureful to be a compilation target.