I appreciate your perspective on this, Emilio. I don't understand the
norms around comments in the Mozilla standards-position repo (but have
noticed that many position requests go unanswered as of late), but even
informal comments like this are helpful (to me at least) when evaluating
new features.
On 2/26/25 9:06 AM, Emilio Cobos Álvarez wrote:
From the WG discussions, I don't think anyone on the working group
objects to these in principle (can't authoritatively speak for WebKit
of course, and I can try to get to that standards-position if you
think it's urgent).
However I do think it might be wise to let authors and other CSS
experts experiment with it and find issues with these features (and
more importantly, with the design of these features) for a bit longer.
As that post says, we've been bit by this in the past, also with
nesting...
There's a tension here: more people are likely to use it if you ship
it, and we can get away with changing _some_ of these things after
shipping (though Chromium folks have sometimes used the "it has
shipped, can't change this" argument a couple times), so it's never
easy to find the right balance.
But speedrunning to get the current spec issues sorted out with barely
any time to test the implementation and the practical implications of
those spec fixes for authors before shipping doesn't feel great.
A few of these things do feel kinda rushed. Some of these changes
(which are somewhat significant) have been discussed last week, like
[1] for a concrete example, and the spec hasn't even been updated yet...
-- Emilio
[1]: https://github.com/w3c/csswg-drafts/issues/11500
On 2/25/25 10:31 PM, Mike Taylor wrote:
Thanks for the feedback, Alan.
Worth noting that the Mozilla and WebKit position requests have been
open for 1 month, which seems to me to be a reasonable amount of time
for them to register concerns. Same goes for TAG, but there are
initial positive signals at https://github.com/w3ctag/design-reviews/
issues/1045#issuecomment-2653010192.
On 2/25/25 4:05 PM, Alan Stearns wrote:
This is a feature that is greatly desired by developers, and as such
runs increased risk that whatever gets shipped first gets heavily
used and then cannot be improved due to web compat. I think it’s
premature to ship without signals from other engines and without a
TAG review. We should have more time with this feature behind a flag.
Another signal for implementing behind a feature flag for now:
https://blog.kizu.dev/intent-to-experiment-for-longer/
On Tuesday, February 25, 2025 at 9:24:18 AM UTC-8 moo...@google.com
wrote:
Contact emails
moo...@google.com, and...@chromium.org
Explainer
https://docs.google.com/document/
d/1mbHBUR40jUBay7QZxgbjX7qixs5UZXkdL9tVwGvbmt0/edit?
usp=sharing
Specification
https://drafts.csswg.org/css-values-5/#if-notation
Summary
The CSS if() function provides a concise way to express
conditional values. It accepts a series of condition-value
pairs, delimited by semicolons. The function evaluates
each condition sequentially and returns the value
associated with the first true condition. If none of the
conditions evaluate to true, the function returns an empty
token stream. This allows web authors to express complex
conditional logic in a simple and concise way. Example:
<style> div { color: var(--color); background-color:
if(style(--color: white): black; else: white); } .dark
{ --color: black; } .light { --color: white; } </style>
<div class="dark">dark</div> <div class="light">light</div>
Blink component
Blink>CSS <https://issues.chromium.org/issues?
q=customfield1222907:%22Blink%3ECSS%22>
Search tags
css <https://chromestatus.com/features#tags:css>, css-
values <https://chromestatus.com/features#tags:css-
values>, if <https://chromestatus.com/features#tags:if>,
inline-conditionals <https://chromestatus.com/
features#tags:inline-conditionals>
TAG review
https://github.com/w3ctag/design-reviews/issues/1045
TAG review status
Pending
Risks
Interoperability and Compatibility
None
/Gecko/: No signal (https://github.com/mozilla/standards-
positions/issues/1167)
/WebKit/: No signal (https://github.com/WebKit/standards-
positions/issues/453)
/Web developers/: Positive
/Other signals/: https://geoffgraham.me/unconditional-
love-for-conditional-css/ https://lea.verou.me/blog/2024/
css-conditionals/ https://geoffgraham.me/conditionals-on-
custom-properties/ https://www.bram.us/2025/02/18/css-at-
function-and-css-if/ https://x.com/LeaVerou/
status/1801192208025940200
WebView application risks
Does this intent deprecate or change behavior of existing
APIs, such that it has potentially high risk for Android
WebView-based applications?
None
Debuggability
Ties into CSS Value Debugger work: https://
docs.google.com/document/
d/1zyKdPREtKT8OU4WtlHV_Wxet3SvyUtAXrTdFLPmYmdU
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, ChromeOS, Android, and Android
WebView)?
Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/
docs/testing/web_platform_tests.md>?
Yes
https://wpt.fyi/results/css/css-values?label=master&q=if-
<https://wpt.fyi/results/css/css-values?label=master&q=if-
> https://wpt.fyi/results/css/css-values/if-
cycle.tentative.html -the cycles behaviour has been
resolved in https://github.com/w3c/csswg-drafts/
issues/11500, but the spec does not address the resolution
yet.
Flag name on about://flags
CSSInlineIfForStyleQueries, CSSInlineIfForMediaQueries,
CSSInlineIfForSupportsQueries
Finch feature name
CSSInlineIfForStyleQueries, CSSInlineIfForMediaQueries,
CSSInlineIfForSupportsQueries
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/346977961
Estimated milestones
Shipping on desktop 136
Shipping on Android 136
Shipping on WebView 136
Anticipated spec changes
Open questions about a feature may be a source of future
web compat or interop issues. Please list open issues
(e.g. links to known github issues in the project for the
feature specification) whose resolution may introduce web
compat/interop risk (e.g., changing to naming or structure
of the API in a non-backward-compatible way).
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6313805904347136?
gate=5199452060778496
Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/
CAAO7W_D9CCHOcXKNkbaVDFzUOWO7o9tcH1t7rS0xUaeKupYDTQ%40mail.gmail.com
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/45a12b35-349b-473b-8d8c-
e44d45faaf8bn%40chromium.org <https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/45a12b35-349b-473b-8d8c-
e44d45faaf8bn%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org <mailto:blink-
dev+unsubscr...@chromium.org>.
To view this discussion visit
https://groups.google.com/a/chromium.org/
d/msgid/blink-dev/16718dbd-f022-4833-b475-3641cc6b8273%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/16718dbd-
f022-4833-b475-3641cc6b8273%40chromium.org?
utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7cfb5512-a274-47e6-8e08-33cfdf99cb2a%40chromium.org.
