Feature detection will be possible using `@supports selector(&)`. Due to a bug there was a false positive with the flag turned off, but that's been fixed in https://bugs.chromium.org/p/chromium/issues/detail?id=1414012 today and a backport to 111 has been requested.
The false positive will remain in Chrome 109 and 110. That's unfortunate, but I don't see a clear way to get around the problem. On Sat, Feb 4, 2023 at 12:30 PM Sebastian Zartner < sebastianzart...@gmail.com> wrote: > I believe, one major issue for the adoption of nesting and which should > block shipping it is feature detection. There needs to be a clear way for > authors to detect whether the browser supports nesting rules, i.e. provide > them with a way to transition to nesting. Without feature detection, > authors will write pages that break in browsers that don't support it or > they will simply not use the feature. > I've therefore created an issue > <https://github.com/w3c/csswg-drafts/issues/8399> to discuss this. > > Sebastian > > On Friday, January 27, 2023 at 9:46:38 AM UTC+1 Philip Jägenstedt wrote: > >> Hi Oriol, >> >> Thanks for raising that there may be some spec changes that don't match >> the current implementation. Can you list which issues >> <https://github.com/w3c/csswg-drafts/labels/css-nesting-1> you think >> need to be resolved? There are already 3 listed upthread, and I agree that >> anything that has a non-trivial risk of causing interop/compat problems >> down the line is worth spending extra time on. >> >> Best regards, >> Philip >> >> On Fri, Jan 27, 2023 at 2:17 AM obr...@igalia.com <obr...@igalia.com> >> wrote: >> >>> I don't see the danger of a priority of constituencies inversion. >>> Authors can use preprocessors, just like they have been using for several >>> years, so I don't get where the hurry comes from. >>> In fact, I would argue that hurrying to ship a future without having >>> discussed the details just tends to result in a messier language that ends >>> up causing more author frustration in the long-term. >>> And it's not just about the bigger controversy of choosing "option 3" vs >>> something else, with the risk of a formal objection. There are various >>> other relevant details. >>> For example, just yesterday the CSSWG resolved that `:is(.baz, !&)` >>> should count as containing `&`, and thus match any `.baz` in the page, not >>> just `& .baz` like the current implementation. >>> It was also resolved that raw properties in a nested media rule are >>> wrapped in a `& {}` rule, which matches Blink, but there are still some >>> details to discuss, which may or may not match the implementation. >>> And there are more issues in the agenda. >>> Some of these topics may be minor, or might be fixed before 112 goes >>> into beta. But I don't see why risk shipping something in a hurry without >>> proper discussion, potentially leading to compat problems when trying to >>> change the behavior later. >>> >>> -- Oriol Brufau >>> >>> El dia dimecres, 25 de gener de 2023 a les 18:31:03 UTC+1, >>> rby...@chromium.org va escriure: >>> >>>> We discussed this in the API owner meeting today (Philip, Rego, Daniel, >>>> Chris, Yoav, Mike Taylor and myself). We appreciate that there's not yet >>>> full consensus on the API syntax, but also that we've been in this state >>>> for several months and we've heard pretty clearly from web developers that >>>> as a whole they want us to ship something and overwhelmingly support >>>> option 3 >>>> <https://webkit.org/blog/13607/help-choose-from-options-for-css-nesting-syntax/>. >>>> It seems to me we're in real danger of a priority of constituencies >>>> <https://www.w3.org/TR/design-principles/#priority-of-constituencies> >>>> inversion here with authors continuing to lose out as a result of >>>> indecision from the implementer and standards community. >>>> >>>> Therefore, since option 3 seems to have the bulk of support from web >>>> developers and browser implementers, I agree with Philip that, absent any >>>> stronger consensus emerging, we should proceed with shipping it for M112 >>>> (not M111 which is branching this week). *LGTM2* (with the same >>>> criteria as Philip). >>>> >>>> However, if the CSSWG resolves to materially change the design or the >>>> TAG completes their review >>>> <https://github.com/w3ctag/design-reviews/issues/791> and requests >>>> specific breaking changes prior to Chrome 112 going to Beta around *March >>>> 1st*, then I'd retract my LGTM and ask us to flag it back off and >>>> circle back here to allow for a new attempt at building more consensus. As >>>> always, some breaking changes may be possible after that point too, but >>>> it'll depend on the realities of web compat. >>>> >>>> API owners also agreed that we'd look for 4 LGTMs in this case instead >>>> of the usual 3. >>>> >>>> Thanks, >>>> Rick >>>> >>>> On Wed, Jan 25, 2023 at 11:24 AM Philip Jägenstedt <foo...@chromium.org> >>>> wrote: >>>> >>>>> LGTM1 >>>>> >>>>> I had a chat with Steinar today to answer my questions. Out of the >>>>> open issues, the important ones to resolve before shipping are: >>>>> https://github.com/w3c/csswg-drafts/issues/7850 >>>>> https://github.com/w3c/csswg-drafts/issues/7971 >>>>> https://github.com/w3c/csswg-drafts/issues/7972 >>>>> >>>>> Those don't seem controversial. My LGTM is assuming spec and tests are >>>>> updated and that we pass those tests before the feature reaches stable. >>>>> >>>>> The final test failure is related to #7850 and is an easy fix. >>>>> >>>>> Regarding the syntax, there's still disagreement in the CSSWG. >>>>> Unanimous consensus among all WG members doesn't seem possible here, for >>>>> any proposal. Crucially, other browser vendors appear to be OK with >>>>> "option >>>>> 3". I would definitely reconsider my LGTM if there were signs that other >>>>> browser vendors are not keen on shipping option 3, since that would create >>>>> an interop problem, and eventually site compat problems as well. >>>>> >>>>> As always, we should be receptive to new information even after an >>>>> intent has been approved and the flag has been flipped. >>>>> >>>>> On Wed, Jan 25, 2023 at 11:20 AM Manuel Rego Casasnovas < >>>>> re...@igalia.com> wrote: >>>>> >>>>>> Adding to Philip questions, there seems to be quite a lot of ongoing >>>>>> discussions around this topic on the CSSWG, for example today there's >>>>>> a >>>>>> special meeting only for CSS Nesting topics: >>>>>> https://lists.w3.org/Archives/Public/www-style/2023Jan/0011.html >>>>>> >>>>>> What's their impact on the current implementation? >>>>>> >>>>>> Thanks, >>>>>> Rego >>>>>> >>>>>> On 23/01/2023 18:00, Philip Jägenstedt wrote: >>>>>> > I think that we should ship this. It's a high profile and in-demand >>>>>> new >>>>>> > feature >>>>>> > <https://2022.stateofcss.com/en-US/usage/#missing_features_freeform>, >>>>>> so >>>>>> > I have a few questions and comments first. >>>>>> > >>>>>> > Taking a look at the open spec issues >>>>>> > (https://github.com/w3c/csswg-drafts/labels/css-nesting-1 >>>>>> > <https://github.com/w3c/csswg-drafts/labels/css-nesting-1>) some >>>>>> are >>>>>> > explicitly ideas for future changes, but are there any where >>>>>> shipping >>>>>> > amounts to a decision that isn't easily changed? I'm thinking >>>>>> especially >>>>>> > of the CSSOM issues. >>>>>> > >>>>>> > In https://wpt.fyi/results/css/css-nesting >>>>>> > <https://wpt.fyi/results/css/css-nesting> there's a single subtest >>>>>> > failure, related to how a rule serializes. Is that implemented per >>>>>> spec, >>>>>> > or is it tied up with the open CSSOM issues? >>>>>> > >>>>>> > Regarding the threat of a formal objection, there doesn't appear to >>>>>> be >>>>>> > any solution that would fully satisfy everyone, but I trust your >>>>>> > judgment that this is the best option. Additionally, we should not >>>>>> > pre-commit Blink to shipping parser changes, and accept the >>>>>> possibility >>>>>> > that what we ship now is the final shape of the feature. >>>>>> > >>>>>> > On Fri, Jan 20, 2023 at 10:42 AM 'Steinar H. Gunderson' via >>>>>> blink-dev >>>>>> > <blin...@chromium.org <mailto:blin...@chromium.org>> wrote: >>>>>> > >>>>>> > Contact emails: se...@chromium.org <mailto:se...@chromium.org>, >>>>>> > fut...@chromium.org <mailto:fut...@chromium.org> >>>>>> > Explainer: None >>>>>> > >>>>>> > Specification: https://drafts.csswg.org/css-nesting >>>>>> > <https://drafts.csswg.org/css-nesting> >>>>>> > >>>>>> > Summary: Add the ability to nest CSS style rules inside other >>>>>> style >>>>>> > rules, >>>>>> > combining selectors from the outer with the inner rule for >>>>>> increasing >>>>>> > modularity and maintainability of style sheets. >>>>>> > >>>>>> > Blink component: Blink>CSS >>>>>> > >>>>>> > TAG review: https://github.com/w3ctag/design-reviews/issues/791 >>>>>> > <https://github.com/w3ctag/design-reviews/issues/791> >>>>>> > >>>>>> > TAG review status: Pending >>>>>> > >>>>>> > Risks: There is a threat of a formal objection in CSSWG. >>>>>> > >>>>>> > Interoperability and Compatibility: >>>>>> > >>>>>> > Gecko: Positive >>>>>> > (https://github.com/mozilla/standards-positions/issues/695 >>>>>> > <https://github.com/mozilla/standards-positions/issues/695>) >>>>>> > WebKit: Positive >>>>>> > (https://github.com/WebKit/standards-positions/issues/69 >>>>>> > <https://github.com/WebKit/standards-positions/issues/69>) >>>>>> > >>>>>> > Debuggability >>>>>> > Nesting style rules will be a big change for editing and >>>>>> displaying >>>>>> > style rules in the inspector: >>>>>> > >>>>>> > - Showing displaying nested rules for matching declarations >>>>>> > - Editing selectors >>>>>> > - Inserting nested rules >>>>>> > - etc... >>>>>> > >>>>>> > Tracking issue for devtools support: https://crbug.com/1172985 >>>>>> > <https://crbug.com/1172985> >>>>>> > Devtools says they're on track for shipping in M111. >>>>>> > >>>>>> > Will this feature be supported on all six Blink platforms >>>>>> (Windows, >>>>>> > Mac, Linux, >>>>>> > Chrome OS, Android, and Android WebView)? Yes >>>>>> > >>>>>> > Is this feature fully tested by web-platform-tests? Yes >>>>>> > >>>>>> > Flag name: CSSNesting >>>>>> > >>>>>> > Requires code in //chrome? False >>>>>> > >>>>>> > Tracking bug: https://crbug.com/1095675 < >>>>>> https://crbug.com/1095675> >>>>>> > >>>>>> > Estimated milestones >>>>>> > DevTrial on desktop 109 >>>>>> > DevTrial on Android 109 >>>>>> > Shipping 112 >>>>>> > >>>>>> > >>>>>> > Anticipated spec changes: See above. >>>>>> > >>>>>> > Link to entry on the Chrome Platform Status: >>>>>> > https://chromestatus.com/feature/5800613594529792 >>>>>> > <https://chromestatus.com/feature/5800613594529792> >>>>>> > >>>>>> > Links to previous Intent discussions: >>>>>> > Intent to prototype: >>>>>> > >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com >>>>>> < >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/YzrEmc%2BqlqPv72Au%40google.com >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Software Engineer, Google Norway >>>>>> > >>>>>> > -- >>>>>> > 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+...@chromium.org >>>>>> > <mailto:blink-dev%2bunsu...@chromium.org>. >>>>>> > To view this discussion on the web visit >>>>>> > >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/Y8ph9gk50U2D92f3%40google.com >>>>>> < >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/Y8ph9gk50U2D92f3%40google.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+...@chromium.org >>>>>> > <mailto:blink-dev+...@chromium.org>. >>>>>> > To view this discussion on the web visit >>>>>> > >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdMTE%3DjWA4AVXeJfGGTZ5WNzQCR4MiHONuZD3gq43PAOg%40mail.gmail.com >>>>>> < >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdMTE%3DjWA4AVXeJfGGTZ5WNzQCR4MiHONuZD3gq43PAOg%40mail.gmail.com?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+...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYckGUc%3DxjifpXRrOi_UQ2SCXO%2B68GuDAT4r0B%2B8qC4WSw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYckGUc%3DxjifpXRrOi_UQ2SCXO%2B68GuDAT4r0B%2B8qC4WSw%40mail.gmail.com?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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZmCS69D9C0XW6Ah0KbM7Gyin-LVKh-mYyF5bm%3D1tCLQ%40mail.gmail.com.
