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 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/32a43824-1b71-4b67-b1ce-05c4e9b1fc7dn%40chromium.org.
