On Thu, 9 Feb 2023 at 23:59, Bramus Van Damme <bra...@chromium.org> wrote:
> OTOH: Will authors actually need to feature detect this? I mean, feature > detection won’t make a difference to visitors as it will have the same net > outcome to them: the nested styles will not be applied in browsers that > don’t support nesting. Only difference is that the parser might need to > parse a bunch of extra things instead of being able to discard entire > blocks upfront. > Without feature detection, authors are left with three choices: 1. Always include both nested and unnested rules ⇒ more network traffic 2. Only include nested rules ⇒ layout is broken for browsers not supporting nested rules 3. Avoid nesting rules ⇒ CSS Nesting failed None of those choices is great and I am relatively confident that the majority of authors will choose option 3 to avoid page breakage or unnecessarily bloating their pages. We already have a similar issue with the adoption of @layer which is currently also not feature detectable (because browsers don't support @supports at-rule() <https://github.com/w3c/csswg-drafts/issues/2463#issuecomment-1016720310> yet). Sebastian > On Thu, Feb 9, 2023 at 11:29 PM Bramus Van Damme <bra...@chromium.org> > wrote: > >> >> On Thursday, February 9, 2023 at 3:20:34 PM UTC+1 obr...@igalia.com >> wrote: >> This is another reason to delay the shipment: reducing the number of >> users in 109 and 110 will make the check somewhat more reliable. >> >> If they want, authors can work around this mistake by also testing for a >> feature that ships in any release after M110. A good candidate would be >> cos(), which ships in M111: `@supports selector(&) and (scale: cos(90deg)) >> { … }`. That way M109 and M110 are excluded. Admittedly, this is a very >> nasty workaround. >> >> OTOH: Will authors actually need to feature detect this? I mean, feature >> detection won’t make a difference to visitors as it will have the same net >> outcome to them: the nested styles will not be applied in browsers that >> don’t support nesting. Only difference is that the parser might need to >> parse a bunch of extra things instead of being able to discard entire >> blocks upfront. >> >> 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 a topic in the >> Google Groups "blink-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/a/chromium.org/d/topic/blink-dev/eFCrkiLynfU/unsubscribe >> . >> To unsubscribe from this group and all its topics, 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/32a43824-1b71-4b67-b1ce-05c4e9b1fc7dn%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32a43824-1b71-4b67-b1ce-05c4e9b1fc7dn%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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAERejNYum3B5CP3-YmQGTYdON_j9WCNR%2B5dpC1DbYWVHjuHFfw%40mail.gmail.com.
