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 [email protected] <[email protected]> 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, > [email protected] 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 <[email protected]> >> 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 < >>> [email protected]> 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 >>>> > <[email protected] <mailto:[email protected]>> wrote: >>>> > >>>> > Contact emails: [email protected] <mailto:[email protected]>, >>>> > [email protected] <mailto:[email protected]> >>>> > 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 [email protected] >>>> > <mailto:blink-dev%[email protected]>. >>>> > 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 [email protected] >>>> > <mailto:[email protected]>. >>>> > 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 [email protected]. >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeGxw4yt09JEG_Mp-MWCOM%3DbqN_muDyPKe%2Bj4CLP5XPsA%40mail.gmail.com.
