*(Hmm, looks like something went wrong with posting my previous message
through the web UI. For clarity, I’m re-sending the relevant part.)*
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.
B!
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/CAD425FLd79OPqJTfavH7Rs-6nVC0Oq65vcT0_qg03gJZ3DGVng%40mail.gmail.com.
