+1 to Rick's notes about "*why the hurry*"; there is a high cost to not
doing the good we can do in a timely way, and shipping important features
is how we make the world better -- and also worse, which is why we hold the
train in many cases, but only for a limited time. Transpilers are a tax,
not a solution, and if our mental model of platform development admits a
view that we should tax developers with transpilers constantly, we've
failed.
For context, we first proposed a compatible nesting syntax in 2011:
https://www.youtube.com/watch?v=qzA60hHca9s
Like variables and many other long-delayed CSS features, this is so far
overdue that doing *something* is strongly preferable to being wrong.
So, on balance, this is an easy one. It doesn't need another vote, but in
the interest of overwhelming support, LGTM5.
Best,
Alex
On Fri, Jan 27, 2023 at 4:56 PM Rick Byers <rby...@chromium.org> wrote:
> Yes thanks for weighing in Oriol, I appreciate it - especially in cases
> like this when reasonable and well-meaning people may disagree strongly on
> the best course of action. I agree that we should do our reasonable best to
> identify and resolve such outstanding issues to minimize the risk of having
> a future compat problem.
>
> I do want to candidly address your "why the hurry" question though. I
> personally see having some urgency to ship as being an important balance
> against the tendency to get stuck debating some design detail well past the
> point of being a reasonable ROI. All engineering is a cost/benefit tradeoff
> and I always advise web teams that we should be happy to invest 10x the
> cost of "going it alone" in order to get consensus, but not 100x the cost.
> There's a fixed level of investment available for making the web better,
> and when we fall into the trap of spending 100x in trying to get broader
> consensus, it means we're depriving 9 other features in the 10x bucket from
> existing.
>
> So for nesting, I'm personally reacting to what feels to me like an overly
> long debate around the core syntax of this feature. We surveyed developers
> about this question a full 6 months
> <https://developer.chrome.com/blog/help-css-nesting/>ago
> <https://developer.chrome.com/blog/help-css-nesting/>, and we're
> apparently still spending huge amounts of energy debating this syntax
> choice. As an API OWNER, I have a responsibility to the chromium community
> to empower them to proceed with improving chromium without being blocked
> indefinitely. In this case I was unable to come up with anything reasonable
> I could ask an engineer to do to realistically unblock the core debate, so
> rather than tell them they need to keep waiting and hoping for total
> consensus I feel I must say "please ship the best design you've got given
> the large investment made in consensus so far". Alternately, if there's
> really no harm for the web to have developers just continuing to use
> preprocessors, then we could instead cancel the feature as being too high a
> cost given the apparently low benefit and save us all the hassle.
>
> But this is a tricky tradeoff, I'm seeing only a tiny bit on the surface
> myself and not deep into it like yourself (both an advantage and
> disadvantage). I'm open to being wrong and appreciate being able to have a
> candid and respectful public conversation about the tradeoffs. If you and
> other folks active in the CSSWG discussions feel that another month of hard
> work would lead to a much more stable and agreed upon design, then I'm
> willing to support slipping another milestone. So I think that leaves me
> with the same basic question as Philp - what is the concrete and pragmatic
> list of work necessary to get this feature to a reasonable and pragmatic
> state for shipping a v1.0 soon, on top of which we can continue iterating
> together?
>
> Thanks,
> Rick
>
>
> On Fri, Jan 27, 2023 at 3:46 AM Philip Jägenstedt <foo...@chromium.org>
> 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 <obru...@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/CAFUtAY_GfAW6OMy%3DV1ziiqSR2Qrs405KN8nd%2BBzF%3DHb8pqisFg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_GfAW6OMy%3DV1ziiqSR2Qrs405KN8nd%2BBzF%3DHb8pqisFg%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/CAA44PQigK8BLZtNCNA3ErURVvrC9UrUwRZHMbbyuC1-X33KRKA%40mail.gmail.com.
