Will second the thanks, Emilio, but will reiterate that Blink's test here isn't WG consensus, but rather web developer feedback. If there's concern among developers that this proposal isn't on the right trajectory, would be good to hear that now.
Best, Alex On Friday, February 28, 2025 at 1:12:38 PM UTC-8 Mike Taylor wrote: > 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/042bd0b1-85fd-467b-9094-f055c8c12495n%40chromium.org.
