2025 want list (Interop 2025)
There's been a boat load of activity over at the rust jxl github repo today out of seemingly no where. Was mostly dead for months but now my inbox is full of pull request messages. Good to see somethings finally happening.
https://github.com/libjxl/jxl-rs/pulls?q=is%3Apr+is%3Aclosed
113 Replies
😮 hopefully mozilla stopped being a picky little kid and actually helped with the rust implementation
they don't want the c++ version, but also aren't (weren't) helping the rust version - the language they invented
Just to have the link back to the old discussion handy: https://discord.com/channels/436251713830125568/1237381483707236373
thank you!
you read my mind 🤣
Think I may have mentioned CSS fit-width before but now Chrome has an "Intent to Prototype: CSS fit-width text" https://groups.google.com/a/chromium.org/g/blink-dev/c/I3aG24t4bwI/m/xLBLyAJKDwAJ
thats to make the text fit within a width?
kinda like svg?
Yep, folks use SVG or JS for things like this right now. In the screen shot the font size is changed per line to fit to the width. This is from the Chrome explainer: https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md#combining-behaviors
that looks good
An update: The jxl-rs folks worked all week last week and are back at it again this week. No idea how close any of this is to being handed over to the browsers for implementation but it's great so see things happening on this: https://github.com/libjxl/jxl-rs/pulls?q=is%3Apr+is%3Aclosed
oh yeah!
finally some amazing news
Not sure if I just missed this or if there really hasn't been any mention of this before but Webkit seems to be prototyping CSS
random(). There's a note in the Technology Preview 218 blog post about a change to the implementation: https://webkit.org/blog/16861/release-notes-for-safari-technology-preview-218/i remember you spoke about it, but there weren't any updates since then
but that is awesome
So something a little different: here's the Chrome stats % of pages that use
mask. mask clean up/un-prefixing was part of Interop 2023.
https://chromestatus.com/metrics/css/timeline/popularity/357
Fun fact, some browser reps told me that it would be a waste of time to work on mask because no one would use it....
While the numbers were low at the time we kept pushing for it because we knew folks wanted to use it. The issue clearly was the terrible implementations.
in other news, cold water kills thirst more than hot water
if the implementation is good, people will use it
so in the case of
mask that was true but border-image inconsistencies were fix in Interop 2023 as well but the numbers are pretty much flat since. So it's a case by case for sure.
Chrome just put out an "Intent to Ship: CSS sibling-index() and sibling-count()" https://groups.google.com/a/chromium.org/g/blink-dev/c/opsqx1cBPyc/m/pJaRwh7UAAAJnice!
we finally wont need 500k of css to count elements
what's left that ya'll are using that still needs prefixing?
line-clamp 😄
yep yep, that's one for sure. Looks like chromium has been working on this alot: https://issues.chromium.org/issues/40336192.
Appears to work un-prefixed and without any of the
display: box; stuff in canary now?
might be behind a flag. Safari also has preview support: https://webkit.org/blog/15978/release-notes-for-safari-technology-preview-204/
but there still seem to be a lot of issues related to line-clamp open in the csswg: https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue%20state%3Aopen%20%22line-clamp%22
according to https://chromestatus.com/metrics/css/popularity the top 10 most used webkit prefixed properties are:
webkit-appearance
webkiit-user-select
webkit-font-smoothing
alias-webkit-transform
webkit-tap-highlight-color
alias-webkit-text-size-adjust
alias-webkit-transition
webkit-box-orient
alias-webkit-box-shadow
webkit-line-clampI didn't even know we had to prefix appearance still??? That feels like something that's coming from auto-prefixer or something?
The box-orient and line-clamp is the only thing in there that makes sense to me, lol.
And
alias-webkit-box-shadow???some aliases are required by the spec
i meant properties
i think clip-path is one that requires the webkit prefix, as per the spec
the spec doesn't require prefixes for anything. Prefixes are when browsers would implement something that wasn't quite up to the spec, or not even in the spec at the time.
like the scrollbar styling things (which I'm surprised aren't in that list, tbh)
I doubt the spec even mentions prefixes anywhere
i remember the spec saying something about a property required to be added with the prefix
i will find it or prove myself wrong
MDN might mention it for non-standard things, where the only way to do it is prefixed (which is the purpose of a prefix). They're a thing of the CSS3 days when browsers were rushing to implement stuff more than anything else, now they tend to use either flags, before still pushing things out a bit early anyway, lol)
i remember it being in the spec
but im on a phone now, so, will try to find later
appearance got cleaned up as part of Interop 2022. Browsers are required to support the -webkit-appearance and appearancefor backwards compatibility.
https://wpt.fyi/results/css/css-ui?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2022-formsi knew i wasnt crazy!
caniuse says the only browser that requires
webkit-appearance is QQ Browser which is at .22% . I think that's a chromium browser but i'm not sure. Given caniuse's bad track record with documenting these smaller mobile browsers i'd say in reality who knows.
https://caniuse.com/?search=appearance... that's a lie, i didn't knew it 🤣
that is interesting, to be honest
here are some more of those
-webkit things all browsers are required to support. I'm pretty sure there are a lot more of them but I don't think clip-path is one of them. https://wpt.fyi/results/compat?label=experimental&label=master&alignedno, it isnt
i checked
do you know if there was any progress for the
element() background image?pretty sure nothing has happened on that. Problem of rendering the same thing twice in a performant way that's the issue. I tried running a
<video> tag as a background-image once with -moz-element and it ran like dog poo.i wouldnt expect 30fps from it
The prototype of
flex-wrap: balance; is in canary behind a flag: https://x.com/Una/status/1923424825009373249
just noticed that corner-shape is listed under "Enabled by default" for Chrome 139. https://chromestatus.com/roadmap😮
so, it was released?
not yet, 139 is current DEV edition, current stable is 137
i guess what it means it that its coming out from behind the current flag in canary. Still looks like it would be 2 months until it hit stable
that's not too long
Firefox 139 (stable as of yesterday) supports the Temporal API: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/139#javascript
latest Igalia Chat episode talks about a bunch of on going CSSWG conversation (and a bit about how the processes work). Good overview if you don't have the time to poke around in the issues yourself. It's long (47min) but there's always 2x speed: https://www.youtube.com/watch?v=xcBs7ru0irs
State of CSS survey is out: https://survey.devographics.com/en-US/survey/state-of-css/2025
gap decoration is going to be in a dev trial in Chrome 139: https://groups.google.com/a/chromium.org/g/blink-dev/c/vmO3X2aYL2Y
lots of demos here: https://microsoftedge.github.io/Demos/css-gap-decorations/
that is weirdly interesting
so excited for this 😄
Chrome has an Intent to Ship for
corner-shape. Target version is still 139: https://groups.google.com/a/chromium.org/g/blink-dev/c/OoX4xjqSPt4/m/m-DV3dV0BAAJ
also looks like Timani has started playing around with corner-shape: https://css-tip.com/hexagon/Happy to see it in a browser to play with... but once again, seems like Chrome is jumping the gun considering the spec page has this plastered on it, lol
to be fair the spec has had the "not ready for implementation" label plastered on it for over 10 years that this point. Someone does actually have to pull the trigger. But yeah would like to see it stay behind a flag at least until Safari has a chance to get an implementation together as well.
the other thing is that the spec on the whole has a lot more in it than just
corner-shape I don't know if its really necessary to put off implementing corner-shape while they look at, for example, border-clip/border-limit.thats a good point. I started looking at it omre this afternoon and there is a fair bit in there.
the other thing is that last line "Before attempting to implement this spec, please contact the CSSWG..." which they clearly did. The engineer from Chrome who's working on the implementation is listed as a spec editor. So I guess they are following the rules there.
wow hadn't thought of this until now but CSSbattle is going to change significantly with
corner-shape. Lots of things that have been legit difficult to do will just become one liners.
so popped into the jxl-rs repo and it looks like there still working on it. No release yet but there is an issue with a checklist that's looking mostly checked off: https://github.com/libjxl/jxl-rs/issues/58. No clue what this means on when anything will be ready for browser test implementations though.tone mapping is probably for hdr content in sdr displays
so
corner-shapeis now marked as "approved" for 139 instead of having the previous "review in progress" label. So stable on july 30th
Related: another element shape related property border-shape was added to the features list: https://chromestatus.com/feature/5459864205393920 This one is about using <css-shape> values like shape(), polygon() etc to create an element shape.that is awesome
and here's Chrome's official "Intent to prototype" for border-shape: https://groups.google.com/a/chromium.org/g/blink-dev/c/FAgQ2UkHJSs
just saw Kevin's latest youtube quiz and
:nth-column was one of the options. Anyone know whats up with this? I remember the conversation starting on it around the late 2010s. And seems we're no where for implementation?
The spec is a Working Draft but there's no big "don't implement" label on it: https://www.w3.org/TR/selectors-4/#table-pseudosyeah, I thought I'd completely made it up to be honest, but looked it up and found the
:nth-col(). I'd love to have this, but there probably isn't enough pressure for people asking for it?the spec references "2D grid" and then there is an example of a table. So I assume "grid" in this is just a generic term and not
display: grid; specific. So I'd think this would apply to display: grid;, <table>,columns and maybe wrappeddisplay: flex;??A lot of mentions of how it's based on "semantics of the document language only", so maybe it only would work in tables?
Maybe? I can see it starting as a conversation around replacing the weirdness of
<colgroup> and <col/> but I just don't see them not taking the next step to apply it to grid at least? But maybe not and that's why no browser has jumped on it?
searched Webkit and Mozilla standards position repo and there's no entry for this in either. Ditto on the chromium mailing list.
so apparently I'm not the only one that's confused on what it applies to but the working group is confident that it's not confusing: https://github.com/w3c/csswg-drafts/issues/6590im reading the spec and it's a mess
here's a bug for chrome which was seemingly wrongly closed: https://issues.chromium.org/issues/41477400
and a bug for Mozilla that's been open for... 18 years: https://bugzilla.mozilla.org/show_bug.cgi?id=371323
The double-association of a cell in a 2D grid (to its row and column) cannot be represented by parentage in a hierarchical markup language.what does this even mean!? this part sounds cool, but indeed needs work
This unlocks a memory of a time when all the CSS specs use to be written in this overly academic style. I don't remember when exactly but the working group made a conscious decision to stop writing like this in favor of a more easily readable style. Lots of things got rewritten but I guess not everything.
"it's clear that our grid structural selectors aren't for grid" 🫣
Just change it to "table structural selectors"...
And that the definition implies it's for tables without saying it's for tables is annoying too. Just say "this is for tables" and then explain how it's based on the markup, and it's clear...
But yeah, definitely feels old-school. It's always fun when you end up in those, re-read something a few times, and still have no clue what it's talking about.
it really needs to be re-written
if it is just for tables, the usefulness drops like a rock on a puddle
we can do huge selectors that do that work already
lots of
:nth-child(... of ...)I'm 99% sure I was in a convo with Tab about selecting grid cells, or something very similar, which would make it all easier, but I can't find any issues about it.
We were at a bar, late at night in Amsterdam though, so my memory might not be spot on 😆
do you remember coming to any conclusion?
Nope, but it was definitely something conversations were happening about. It might have been very early? I donno. I figured I'd be able to find something on it, but never did
🤔
i do have an opinion on this: if it is just for tables, it's past it's time
maybe this one? https://github.com/w3c/csswg-drafts/issues/499
oh, thats interesting...
MathML core is now a Candidate Recommendation: https://mastodon.social/@w3cdevs@w3c.social/114737449350300420
wait, mathml???
isnt that in use for a decade??
yeah but it's been super inconsistent and just generally kinda poo, this is the effort to fix that
https://github.com/web-platform-tests/interop/issues/197 an explanation in an interop proposal from 2022
oh
is that why people use mathjax (or whatever the name is)?
looks like
sibling-index() and sibling-count() are now live in stable chrome 138.awesome!
neat, ::after and ::before are going to be default implied anchors to the generating element for anchor position: https://github.com/w3c/csswg-drafts/issues/11792
oh that's fantastic
Firefox's intent to prototype a
:heading selector to replace having to write out each heading: https://groups.google.com/a/mozilla.org/g/dev-platform/c/SlPKz6WrEv4ah that's amazing. Had completely forgot about it, but it's been on my wish list for awhile
wasn't there also a nicer syntax to replace nested repeats like
ul ul ul ul? Did that ever happen? Or get spec-ed?that's the
:where
use to be :anyi think it's
toggle() i was thinking of and it looks like it got booted from values-4 to values-5: https://drafts.csswg.org/css-values-5/#toggle-notationhttps://drafts.csswg.org/css-values-5/#inherit-notation 😮
this would be so awesome
well that was fast.
:heading is available under a flag in Firefox nightly already: https://mastodon.social/@keithamus@indieweb.social/114778625629180547
Safari TP 222 added the implied anchor functionality for pseudos: https://webkit.org/blog/17181/release-notes-for-safari-technology-preview-222/
from the border-4 spec (https://drafts.csswg.org/css-borders-4/#corner-sizing):
for example border-top-radius would be a new shorthand for border-top-left-radius and border-top-right-radius which would be super useful.
there's a chrome issue open but don't see anything in any other browser yet:
https://issues.chromium.org/issues/330854559nice! nice! finally something less painful to use
related to the above while for example
border-top-radius isn't a thing yet corner-top-shape will be a thing in chrome when corner-shape releases. Would hope that the border-*-radius stuff wouldn't be far behind?
there's finally a caniuse listing for corner-shape related stuff. Seems to be pulled from MDN data: https://caniuse.com/?search=corner-shape
anyone know what ever happened to the linear-stripe() thing? Feels like another one of those things we've been waiting on forever...
so, the working group resolved to make individual *-stripe() functions as replacement for stripe() almost 2 years ago but it just never got changed in the draft spec I guess? https://github.com/w3c/csswg-drafts/issues/7244
https://drafts.csswg.org/css-images-4/#stripes🤔 i read the draft and ... can't you already do this without this function?
yep, we can fake stripes with gradients but we have to do the weird manual anti-aliasing sometimes, this would take care of that automatically. It also creates a more straight forward syntax specifically for stripes. Having said that... your response is possibly going to be what the browser vendors might say and then just not bother with it. We'll have to see.
i wouldn't be surprised if it was the response, as i can see it all being a huge pain to implement
yep, that just means we'll have to make a good case for it. Do what we can to show that its worth the effort on their end. Going to write something up this weekend to drop in the standards position repos to see if we can get a browser vendor to have a look at it.
that would actually be awesome
caret styling is a thing that's getting worked on:
caret-color,caret-animation and caret-shape. https://blogs.igalia.com/mrego/playing-with-the-new-caret-css-properties/finally!
but caret color already exists 🤔
honestly not sure but I think there were/are some
caret-colorinconsistency between browsers. Looks like most of the new work is on caret-shape.i haven't found any, but it is something i don't use at all
never needed it, to be honest
i tested it a tiny bit to check out but that's it
Monthly-ish JXL update: the tracking issue now only has one checkbox left to be checked. It's for tone_mapping. https://github.com/libjxl/jxl-rs/issues/58
On the surface at least this seems like a good sign. In reality though who really knows how close this is to being handed over to browser vendors.
maybe next month we will see support for this being better handled by browsers
so far, only safari embraced jpegxl and the rest just shunned it
I think next month is realistically way too soon to expect something in browsers. No idea for sure but I don't thinks it's as simple as "plug and play" for the browsers to get this sort of thing implemented once it's handed over. Maybe 6 months??
This also assumes that when the browsers look at what these folks have provided they say "yeah looks good" and get to work right away, not "yeah we'll use it but... could you go back and have another pass at this bit before we integrate it"
I feel like possibly this is pointing to JXL finally getting accepted to Interop 2026.
i mean, a month to at least say "yeah, we will check this" or google say "no"?
that is very realistic, in my opinion
just that is better than what they have been doing all this time
it baffles me how google decided that forcing a video encoding format to display a static image was more advantageous than doing what people and companies were requesting and they had working in a very basic level
looks like Safari has the first test implementation of CSS
random(). Tests marked as tentative for now but: https://wpt.fyi/results/css/css-values/random-computed.tentative.html?label=experimental&label=master&aligned😮 that's awesome!
looks like the beginning of the 3rd quarter is "lets all work on backdrop-filter" time: https://wpt.fyi/interop-2025?feature=interop-2025-backdrop-filter
was there something missing from it?
Safari still had
backdrop-filter behind a -webkit prefix up until last year and there are still some small inconsistencies in how they render cross browser. Have a look at the tests and click the COMPARE link on a fail listing to see the rendering issue https://wpt.fyi/results/css/filter-effects/backdrop-filter-basic-blur.html?label=experimental&label=master&aligned&view=interop&q=label%3Ainterop-2025-backdrop-filtersafari's result looks better than the expected
yeah, i can see what you mean. I'm guessing the tests line up with the spec text?? Maybe there's some issues?
the intended result is probably more accurate
maybe it fits better some svg spec copied over, or something
now that i take a look at it, randomly (i forgot the tab was open), i can see that the "expected result" is completely different to the other browsers
state of HTML survey is open: https://survey.devographics.com/en-US/survey/state-of-html/2025
still seems to be a lot of work going into Chromium -webkit-line-clamp bug. Amazes me how complicated implementing this must be: https://issues.chromium.org/issues/40336192
i can see it being a royal pain, specially since you need to take hyphens,
<wbr> and ­ into attention, as well as other stylesI was also going to say "a lot of work for a property that I don't think was going to have a super high usage ceiling" but apparently the -webkit version is already in 40% of page loads? https://chromestatus.com/metrics/css/timeline/popularity/260
i've used it a few times myself
Jen Simmons is asking what people want in Safari over on Mastodon: https://mastodon.social/@jensimmons@front-end.social/114915019733312117
people want to remove it and use chrome with blink and v8 🤣
corner-shape goes live is chrome stable 139 (and probably edge as well??) tomorrow.
The Firefox bug looks to have a volunteer giving it a try: https://bugzilla.mozilla.org/show_bug.cgi?id=1726232
Webkit bug has an Assignee again (same person that did some prep work for it earlier this year): https://bugs.webkit.org/show_bug.cgi?id=277912State of CSS 2025 results were released this weekend: https://2025.stateofcss.com/en-US/