Interop Priority Game
- Published on:
- Categories:
- Interoperability, Interop 2024, CSS 61
- Current drink:
- Yunnan tea
Introduction
Today, Brian Kardell posted a question in his blog, in an entry named “Let’s Play a Game”, let me quote it:
It’s Interop 24 planning time! Let’s play a game: Tell me what you prioritize, or don’t and why?
In the post, he asks to try to sort a list of the proposed focus and investigation areas to our liking, alongside some commentary. That’s what I’ll do!
There are more than 90 proposals! I can’t cover them all, and I lack expertize in many areas (sure, JPEG XL sounds cool! I have no idea about image compression, how it compares to other formats and so on, so I cannot weight on it; if you can — go ahead!).
I will order things from those I need right now, needed them yesterday, and probably needed them 10 years ago, to things that would be nice to have. Likewise, I think almost all the proposals make sense and are things I’d want to see — the “game” is not trying to tell what is good or not, but to prioritize, after all. If I don’t mention something, that means that I don’t have enough to say about it, at least at the current moment.
Top Ten Interop Proposals, as Sorted by Me
1. Scroll-driven Animations
I am biased: I wrote multiple articles about them, describing the weirder use cases which become possible when using scroll-driven animations.
As I mentioned in Igalia Chats, when I first saw the scroll-driven animation specs, I did not think I would write all these articles. I did not understand at the time how powerful it is to get access to the elements’ positions and dimensions in CSS in the way scroll-driven animations allows us.
But here we are — with them unlocking so many effects and use cases! And now that they’re in Chrome Stable, let’s prioritize shipping them everywhere.
And — in an interoperable way.
There is one fear I have — with so many techniques I (and others) come up with, what are the chances they would work even when other browsers would implement scroll-driven animations? There are so many moving pieces: @property, interactions of custom CSS properties with animations, and more.
But, without shipping the scroll-driven animations in the first place, we couldn’t even come closer to all these techniques, and with them in place, arguing towards interop for @property and custom CSS properties would be easier.
2. CSS style container queries (custom properties)
Ugh, I still need to write a proper article about style container queries. In my first initial experiments around their workarounds I stumbled upon the “cyclic toggles” technique, and during “CSS Day 2023” conference many speakers did mention, and did provide very real use cases for style container queries. Having them available everywhere would unlock so much.
Maybe one reason why I’m not writing this article is that it would expose so many things I’ll need right now, that the style container queries absence would hurt even more.
3. Unit division and multiplication for mixed units of the same type within calc()
This is such a powerful thing! Stripping a unit from length values in CSS calculations is something I wanted for ages. This would unlock countless use cases.
Today, we have only wild hacks like the tan(atan2()) hack by Jane Ori, or have to define our values unitless. But we really require this as a native feature, available in all browsers at the same time. It might be complicated to work around interop issues in calculations, as the current atan2() issues show.
4. attr() support extended capabilities
An ability to get an HTML attribute, and use it not as a string, but as any other CSS value is something that would also unlock so many use cases!
Yes, it can be worked around by using custom properties, but they are much more cumbersome, especially if we’d want to just reuse the existing attributes on regular HTML tags.
And irregular as well: with custom elements, we can name our attributes as anything. Imagine if we could use them directly in CSS, as proper values? Instead of <my-component style="--foo: 10; --bar: 5"> we could do just <my-component foo="10" bar="5">. In addition to just added convenience, this would remove the potential CSS variables clashes, where right now we have to namespace them, but with attributes on custom elements we won’t have this issue.
5. CSS element() function
I only recently started using Firefox, so I did not yet experiment with element(), but it was for sure on my radar for a while. An ability to reuse the visuals of some element on the page? Huh? This can be so powerful! And it is almost impossible to work around otherwise (except for some very specific cases where we could use -webkit-box-reflect).
6. Popover
Ok, I need to confess: this element of the list is that high only because it’s related to anchor positioning. Moving the Popover API forward would mean more use cases and need for anchor positioning, which is in a much earlier stage to be present in the Interop 2024, but I want to do everything possible to move towards it.
And the Popover API is cool by itself, of course. But it would be so much cooler with anchor positioning! I just can’t stop mentioning anchor positioning. Sorry. By the way, my next article on my main site would be about them, for once, and not about scroll-driven animations! Stay tuned! That article won’t even be the last time I’ll write about anchor positioning this year, can you imagine?
7. CSS Multi-Column Layout block element breaking
I will take any improvements to multi-column layout, to be honest. One dream I have is to have Overflow In The Block Dimension For Multicol. Please? Of course, handling the element breaking is something required for mutlicol to be viable as well. Improving interop for them, giving more developer hands for multicol layout, fragmentation, all of that, would be so good!
8. Relative Color Syntax
We now have color-mix() which can cover some relative color syntax use cases (CodePen by Lea Verou), but from all of them.
Functions like fade(), darken(), lighten() and so on in preprocessors are sometimes the last reason to continue using them. Being able to dynamically adjust colors, by modifying some components, and not just replacing them, would be invaluable, especially for design systems.
9. text-box-trim
And, text-box-edge and other related properties, of course. I’ll take anything that allows us to improve typography and aligning things around text. The cap unit is almost here, and while it will cover some use-cases (like vertical alignment of icons near text), text-box-trim would allow for so much more precise control over how things look in relation to text.
10. Declarative Shadow DOM
I did briefly write recently about one use case for the Declarative Shadow DOM. As with many other items in this list, I look at this issue as a part of something bigger. In this case, as a path towards Declarative Custom Elements which would be so nice to have! But, yes, I’ll take Declarative Shadow DOM as well, especially given I now have at least one use case for it, with the “fully transparent” elements.
Participation Award
I could continue writing and writing, scoring and sorting the proposals, but hey, I’m doing this in my less polished blog, so I need to stop at some point! Some other notable mentions that could get into a top 15, if I’d get to write more about them:
And so many more other things. So many things I did not even mention, only from the CSS proposals, and there were even more…
Final Words
I really hope at least some of the things I did mention will get into the Interop 2024. I encourage everyone to go, read the proposals, vote for what you’ll find interesting, and provide your use cases in the issues if you have some.
Very often browser vendors do not know if developers really want the features, or if existing workarounds are enough, if the use cases were covered by something else, and so on.
I believe that by writing about what you care about, you move things forward, give a signal that that thing you wrote about is something you still need.