Repository navigation
[css-values-5] Do we need media-progress() and container-progress()? #11826
Description
Given you can write progress(100vw, 200px, 4000px) and progress(100cqw, 100px, 400px)... do we even really need media-progress() and container-progress()?
progress() with viewport units even has the advantage of letting you choose among sv*,lv*, and dv*.
So are there use cases that require media-progress() or container-progress() or should we keep things simple and drop them in favor of progress()?
Reacted by Scott Kellum
Activity
fantasai commentedon Mar 5, 2025
CC @kizu @mirisuzanne @scottkellum
kizu commentedon Mar 5, 2025
I think the only thing that
container-progresscurrently provides: an ability to mention the container name, for which I would prefer #7858 anyway.Also, I don't know if it is a limitation of the current prototype in Chrome Canary, but by quickly playing with the
container-progress(), I couldn't even make what I wanted with it, and it felt more verbose than with justprogress(), even from the syntax standpoint.I would be totally fine with dropping the
media-progress()andcontainer-progress(), especially given custom functions could allow us to experiment with the syntax for something more container/media-related, and if there will emerge a much more convenient pattern, we could always adopt it later as a built-in funciton.andruud commentedon Mar 5, 2025
(These functions are about to ship in Chrome; I've notified the I2S thread of this issue. cc @danielsakhapov)
+1 to dropping them until they clearly provide additional value.
Please do reach out and tell us more. :-)
mirisuzanne commentedon Mar 5, 2025
I think it's ok to drop for now.
nt1m commentedon Mar 12, 2025
WebKit is happy to remove if that ends up being the spec resolution.
astearns commentedon Mar 17, 2025
Seeing no disagreements in the thread, I think we can handle this resolution asynchronously
The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.
Proposed Resolution: Drop media-progress() and container-progress() for now
Unship media-progress() and container-progress()
scottkellum commentedon Mar 18, 2025
I’m happy with dropping
media-progress()andcontainer-progress()and only keepingprogress()👍🏻Unship media-progress() and container-progress()
astearns commentedon Mar 24, 2025
RESOLVED: Drop media-progress() and container-progress() for now
[css-values-5] Drop media-progress() and container-progress() for now #…
ByteEater-pl commentedon Jun 7, 2026
Why was
media-progress()deemed redundant? IIUC, it could read values from any numeric media feature, not just those expressible with viewport units. And there's nomedia()function that makes media features available in CSS values.mirisuzanne commentedon Jun 9, 2026
I imagine people would be open to bringing these back, if someone wanted to flesh out the use-cases that are not covered. Do you have something specific in mind?
ByteEater-pl commentedon Jun 9, 2026
Having images, filters, shadows and similar stuff depend on
color. If there's little depth, the author may accept that quality will be poorer anyway and use a simpler style in exchange for lower requirements on transfer, bandwidth, compute and memory.tabatkins commentedon Jun 9, 2026
Note that
coloris, in practice, fixed to the value 8. B&W devices might set it to 0, but I'm not sure that happens in reality.ByteEater-pl commentedon Jun 10, 2026
I didn't know. In that case, it's something implementors should be pestered with.