This is another reason to delay the shipment: reducing the number of users in 109 and 110 will make the check somewhat more reliable.
El dia dimecres, 8 de febrer de 2023 a les 17:32:50 UTC+1, Philip Jägenstedt va escriure: > 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 <sebastia...@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/6437adf7-1c0b-4e95-945f-8b8b1971acdan%40chromium.org.
