Intent to Ship: Deprecate old CSS custom state syntax

[Joey Arhar]

Contact emails

jar...@chromium.org

Explainer

None

Specification

https://github.com/whatwg/html/pull/8467

Summary

CSS custom state, which allows custom elements to expose their own pseudo-classes, was shipped here: https://groups.google.com/a/chromium.org/g/blink-dev/c/dJibhmzE73o/m/VT-NceIhAAAJ

This feature has not been implemented in gecko or webkit yet. I recently made an effort to spec this feature in CSSWG and WHATWG, but there was pushback to change the syntax back from :--foo to :state(foo), and the CSSWG has resolved to do this as well: https://github.com/w3c/csswg-drafts/issues/4805

The UseCounter is currently at 0.03% https://chromestatus.com/metrics/feature/timeline/popularity/3796

This deprecation will have a window where we support both the old syntax and the new syntax so websites can switch to the new one.

Blink component

Blink>HTML>CustomElements

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Websites which are currently using the old syntax and don't migrate to the new syntax will have CSS selectors which become invalid which would impact the styling of their custom elements.

Gecko: No signal

WebKit: No signal (https://github.com/whatwg/html/pull/8467#issuecomment-1381645661)

Web developers: No signals

Other signals:

Activation

Switching to the new syntax should be quite easy.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

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 on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

No milestones specified

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140610730426368

This intent message was generated by Chrome Platform Status.

[Joey Arhar]

The spec for the new syntax hasn't been merged yet, I haven't finished implementing it in chromium yet, and I don't have estimated milestones yet, but I'd like to get the API owners thoughts on whether this deprecation would be acceptable to help guide the spec discussion.

I did some analysis of the top 8 websites on the chromestatus entry to see what the breakage would be like: https://docs.google.com/document/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing
I found that most of them had the affected custom elements behind display:none rules that I had to manually remove in order to use them. There was only one website where there was actual breakage by default, in which case the carousel buttons didn't work on firefox and safari. If the new syntax is just for the CSS property and we keep CustomStateSet the same, then the affected website's buttons would continue to work but whatever custom styles they have (which I couldn't trigger) wouldn't apply anymore.

Personally, I think that this breakage would not be bad especially if we keep CustomStateSet the same, and I kind of like :state(foo) more than :--foo. However, I might have not made it clear in the spec discussions yet that we have already shipped :--foo by default for several years.

[Alex Russell]

hrm, this is another instance of bikeshedding after shipping, and I'm not inclined to approve. Perhaps we can discuss at next week's API OWNERs meeting?

Adding others who I know are interested in this topic.

[Yoav Weiss]

On Friday, September 29, 2023 at 9:32:16 PM UTC+2 Alex Russell wrote:

hrm, this is another instance of bikeshedding after shipping, and I'm not inclined to approve. Perhaps we can discuss at next week's API OWNERs meeting?

We should definitely discuss this broader subject!

 

Adding others who I know are interested in this topic.

On Friday, September 29, 2023 at 9:16:13 AM UTC-7 Joey Arhar wrote:

The spec for the new syntax hasn't been merged yet, I haven't finished implementing it in chromium yet, and I don't have estimated milestones yet, but I'd like to get the API owners thoughts on whether this deprecation would be acceptable to help guide the spec discussion.

I did some analysis of the top 8 websites on the chromestatus entry to see what the breakage would be like: https://docs.google.com/document/d/1BHoO12ts0E-NQQH9AMwR2sKAIV0OPB-FA_8QXMpolz0/edit?usp=sharing
I found that most of them had the affected custom elements behind display:none rules that I had to manually remove in order to use them. There was only one website where there was actual breakage by default, in which case the carousel buttons didn't work on firefox and safari.

Have Firefox and Safari implemented the new syntax?

 

If the new syntax is just for the CSS property and we keep CustomStateSet the same, then the affected website's buttons would continue to work but whatever custom styles they have (which I couldn't trigger) wouldn't apply anymore.

Personally, I think that this breakage would not be bad especially if we keep CustomStateSet the same, and I kind of like :state(foo) more than :--foo. However, I might have not made it clear in the spec discussions yet that we have already shipped :--foo by default for several years.

0.03% is not nothing. 1/8 ratio of breakage there is encouraging, but we'd probably need slightly broader sampling approach to get a sense of real-life breakage. (e.g. ~20 random sites)

 

On Fri, Sep 29, 2023 at 9:15 AM Joey Arhar <jar...@chromium.org> wrote:

Contact emailsjar...@chromium.org

ExplainerNone

Specificationhttps://github.com/whatwg/html/pull/8467

Summary

CSS custom state, which allows custom elements to expose their own pseudo-classes, was shipped here: https://groups.google.com/a/chromium.org/g/blink-dev/c/dJibhmzE73o/m/VT-NceIhAAAJ

This feature has not been implemented in gecko or webkit yet. I recently made an effort to spec this feature in CSSWG and WHATWG, but there was pushback to change the syntax back from :--foo to :state(foo), and the CSSWG has resolved to do this as well: https://github.com/w3c/csswg-drafts/issues/4805

The UseCounter is currently at 0.03% https://chromestatus.com/metrics/feature/timeline/popularity/3796

This deprecation will have a window where we support both the old syntax and the new syntax so websites can switch to the new one.

Blink componentBlink>HTML>CustomElements

TAG reviewNone

TAG review statusNot applicable

Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5140610730426368

[Joey Arhar]

> Have Firefox and Safari implemented the new syntax?

No, I don't think they have started implementing anything yet.

[Jeffrey Yasskin]

+1 on the API owners discussing this.

I'd like to understand better how we wound up shipping :--foo and then having the CSSWG ask us to change it to :state(foo) instead, and what we could do in the future to avoid it happening again.

It looks like the initial proposal was :state(foo); the CSSWG asked to change it to :--foo in 2020; we shipped that in M90 in 2021 (with a feature entry that still says :state 🙃); then Ryosuke suggested undoing that change in January 2023, and the CSSWG accepted that suggestion in August. As far as I can see, nobody asked for the ergonomic evidence that https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews says we can expect after Chrome has shipped a feature. It doesn't seem like this feature was so contentious that the team needed to use a name change as a bargaining chip, so we should probably have insisted on more evidence before agreeing with the change. Maybe that's still a "should" instead of a "should have": Joey's second email might say that the CSSWG's resolution about this isn't as committed as it appears to an external observer?

Should we generally hold off on shipping CSS features until they land in an official draft, or even in a CR? Should we be clearer to the CSSWG when we decide to ship ahead of their consensus that the bar for changes is going up? There's not good support for this kind of per-WG restriction in Chrome Status yet, but maybe it'll fit near https://github.com/GoogleChrome/chromium-dashboard/issues/3390...

Jeffrey

[Joey Arhar]

> I'd like to understand better how we wound up shipping :--foo and then having the CSSWG ask us to change it to :state(foo) instead, and what we could do in the future to avoid it happening again.

I think if this was specced before shipping that would have been better and is a practice that I (and we?) currently follow, but this was shipped a number of years ago.

> As far as I can see, nobody asked for the ergonomic evidence that https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews says we can expect after Chrome has shipped a feature.

This was my bad, I didn't realize or didn't completely consider usecounters before I presented the name change to the CSSWG.

I am hoping that with an answer from the API owners, I can go back to the CSSWG and potentially change it back.

There is still no merged spec in HTML or CSS for this feature yet, but I have open PRs in both specs.

[Jeffrey Yasskin]

On Wed, Oct 4, 2023 at 1:08 PM Joey Arhar <jar...@chromium.org> wrote:

> I'd like to understand better how we wound up shipping :--foo and then having the CSSWG ask us to change it to :state(foo) instead, and what we could do in the future to avoid it happening again.

I think if this was specced before shipping that would have been better and is a practice that I (and we?) currently follow, but this was shipped a number of years ago.

Yeah, good point: it's totally possible that our more recent process rigor is sufficient, and we don't need anything new to prevent this in the future. No matter what, we should expect the occasional old feature to pop up and be an exception.

I do think that it's worth finding a way to write down your current practice, so that it doesn't regress if you switch teams. I think you mean that you do "hold off on shipping CSS features until they land in an official draft", so let's try to record that if it's our idea of the solution.

 

> As far as I can see, nobody asked for the ergonomic evidence that https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews says we can expect after Chrome has shipped a feature.

This was my bad, I didn't realize or didn't completely consider usecounters before I presented the name change to the CSSWG.

I am hoping that with an answer from the API owners, I can go back to the CSSWG and potentially change it back.

There is still no merged spec in HTML or CSS for this feature yet, but I have open PRs in both specs.

Thanks!

[Jeffrey Yasskin]

Apparently +Chris Wilson had part of this discussion with Alan Stearns in April at https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1524167658, and the suggestion was that if a CSS spec for a feature is "unstable" (meaning 'not at CR'?), then we should either post "we're about to send an intent" to the last issue discussing it, or file an "Is X ready to ship?" issue. I think +Chris Harrelson is likely to have the strongest opinions about this: should we add such a rule to our launch process for CSS features?

Jeffrey

[Chris Wilson]

Oh yes, I recall this now.  :) IIRC, we generally follow this convention anyway; that feature had some communication gaps, but we did follow that convention.

[Chris Harrelson]

On Wed, Oct 4, 2023 at 2:24 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

Apparently +Chris Wilson had part of this discussion with Alan Stearns in April at https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1524167658, and the suggestion was that if a CSS spec for a feature is "unstable" (meaning 'not at CR'?), then we should either post "we're about to send an intent" to the last issue discussing it, or file an "Is X ready to ship?" issue. I think +Chris Harrelson is likely to have the strongest opinions about this: should we add such a rule to our launch process for CSS features?

I think we generally shouldn't ship CSS features before there is robust discussion and consensus at the CSSWG, and I think Chromium features have done a good job at that. The CSSWG resolution mechanism, and the various stages of W3C standardization help to build confidence about the degree of consensus and commitment, as do signals from other browser vendors. I don't think we should additionally require filing an "is X ready to ship?" issue at the CSSWG for CSS features.

 

--
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/CANh-dXnPrTj5PhthsMfcr5kd340pbfzuCZik1%2B7J7FC-YkKL1g%40mail.gmail.com.

[Chris Harrelson]

Regarding why change to :state() instead of :--: as is typical, it was done in order to gain consensus; in particular, the CSSWG resolution notes indicate (see comment from the chair) one motivation is to align with WHATWG and not end up with a situation where two standards groups have opposing positions in a gray-area situation and no progress is made.

I don't think that 0.03% is a big problem to deprecate, and recommend we just make the change to match a hard-won consensus and move on. It's easy enough to support both syntaxes for some amount of time before removing the old one.

[Brian Kardell]

I don't normally weigh in on these but I just wanted to say that I think this one is pretty unique for a whole bunch of reasons and it's not just an example of bikeshedding after shipping by a specific vendor or something.  It's more than that.  As much as I think this is important, and wanted it, there were a million other things to talk about re: custom elements that were ahead of it and it just didn't get the level of oxygen that it needed from many quarters, it seems to me, in order to surface the right thoughts.  As it's picked up, over the last few years there were disagreements, counterpoints, etc at many stages through WHATWG, TAG, CSSWG... It feels like it would be good to summarize all of it somewhere - and I'm not even saying the decision here is "right" or something ... I'm just saying that I don't think it is as simple as "bikeshedding after shipping" implies

[Alex Russell]

Hey all,

We've spent a LOT of time discussing this one in API OWNERS, and my disinclination to allow this to move forward remains. What we're observing in this Intent is an anti-pattern in which:

• Chromium engineers follow a process that is designed to put developer needs above implementer preferences, explore the design space earnestly, work with developers to vet a solution, and work to build interest with other vendors.
• Other projects fail to implement and/or implement alternatives.
• The API OWNERS take a calculated risk to ship first. That is premised on collateral the development team provides that the design solves an important problem well, demonstrating developer support and that our process for open development has given ample time for others to engage and help shape the design.
• Time passes (often years).
• Without implementing themselves, other vendors demand that the design change to achieve "consensus" within a standards body, but without demonstrating real deficiencies in the shipped API or even feedback from developers that we were wrong in some important way.

Or put another way, spec fiction is being allowed to trump real-world problem solving, and that's not what our process is designed to facilitate. 

Not only does this pattern further escalate the costs involved in the process to deliver a feature where we have already paid treble to ice-break, it potentially breaks applications -- remember that we suffer from enterprise blindness in our use counters, so it's probable that we will also need to reach out to, e.g., Salesforce and ask them to help collect data. This pattern also drags us away from other work that would expand the platform for users and developers in productive ways.

These costs may seems small on an individual feature basis, but they add up fast and set terrible precedent. I'm extremely unhappy that we seem to be engaging in more of it over the past year, particularly without strong arguments for why the new design is superior. Even the recent debate over this feature is largely about non-committal mild preferences:

https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980

At this point I've read substantially all of the minutes related to these design choices, and this is absolutely late bikeshedding by folks who haven't implemented either alternative and were widely consulted at the time we backstopped the initial I2S.

Per our conversation yesterday, I'm struggling to get to "yes" on this. At a minimum, I need a stronger argument for why we should make this change than that someone in the CSS WG had a mild preference years after the CSS WG was first consulted on the problem. It would help if we had a commitment from the Intent proposers to avoid this sort of change in future. Deciding to ship this would also need to be clearly disclaimed as non-precedent, and I'd be looking from support of the managers of these teams to prevent this sort of make-work in future. How close are we to agreement on that?

Best,

Alex

[Chris Harrelson]

The API owners met yesterday and discussed this intent. Our consensus was that we would like to wait until another browser has implemented and is shipping :state before we approve shipping it in Chromium. We also don't recommend spending more time on further bikeshet spec discussions for it in the meantime, and leave the spec as-is.

We think this plan is a reasonable approach to reduce work for web developers and Chromium implementers in the short term while still achieving interop in the future.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fa862fff-e9eb-4aad-acc3-ca0849c72b06n%40chromium.org.

[Chris Harrelson]

On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson <chri...@chromium.org> wrote:

The API owners met yesterday and discussed this intent. Our consensus was that we would like to wait until another browser has implemented and is shipping :state before we approve shipping it in Chromium. We also don't recommend spending more time on further bikeshet spec discussions for it in the meantime, and leave the spec as-is.

"bikeshed", that is.

[Domenic Denicola]

Thanks Chris and the API Owners for having this discussion! I am sympathetic to this being a hard problem with the strong potential to set a bad precedent.

On Fri, Oct 20, 2023 at 3:00 AM Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson <chri...@chromium.org> wrote:

The API owners met yesterday and discussed this intent. Our consensus was that we would like to wait until another browser has implemented and is shipping :state before we approve shipping it in Chromium. We also don't recommend spending more time on further bikeshet spec discussions for it in the meantime, and leave the spec as-is.

"bikeshed", that is.

With my HTML spec editor hat on, I have a clarifying point and question.

"Leave the spec as-is": right now there are unmerged CSS and HTML spec PRs, plus a WICG spec. So it's not clear exactly which spec you're referring to, but I guess the advice is for Chromium engineers to not invest effort in changing any of these three work items for bikeshed considerations. (Let me know if this is incorrect.) Of course, other community members can continue to work on the spec if they wish.

For the purposes of WHATWG's multi-implementer support criteria: I will assume we cannot check the box for "Chromium supports this feature" until a different browser has shipped :state() to their stable channel. (Let me know if that is incorrect.)

[Chris Harrelson]

On Thu, Oct 19, 2023 at 6:48 PM Domenic Denicola <dom...@chromium.org> wrote:

Thanks Chris and the API Owners for having this discussion! I am sympathetic to this being a hard problem with the strong potential to set a bad precedent.

On Fri, Oct 20, 2023 at 3:00 AM Chris Harrelson <chri...@chromium.org> wrote:

On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson <chri...@chromium.org> wrote:

The API owners met yesterday and discussed this intent. Our consensus was that we would like to wait until another browser has implemented and is shipping :state before we approve shipping it in Chromium. We also don't recommend spending more time on further bikeshet spec discussions for it in the meantime, and leave the spec as-is.

"bikeshed", that is.

With my HTML spec editor hat on, I have a clarifying point and question.

"Leave the spec as-is": right now there are unmerged CSS and HTML spec PRs, plus a WICG spec. So it's not clear exactly which spec you're referring to, but I guess the advice is for Chromium engineers to not invest effort in changing any of these three work items for bikeshed considerations. (Let me know if this is incorrect.) Of course, other community members can continue to work on the spec if they wish.

Those PRs should be finished and landed. My/our comment was only about bikeshedding.

For the purposes of WHATWG's multi-implementer support criteria: I will assume we cannot check the box for "Chromium supports this feature" until a different browser has shipped :state() to their stable channel. (Let me know if that is incorrect.)

Chromium does support the feature, and it should be marked as such in the WHATWG. (We've shipped it in fact, just with a slightly different name for the moment.)

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_nhUTf5QZWscrcBZ5h6ixUkwLv%2BxKk9temGqPRt%3De_tw%40mail.gmail.com.

[Joey Arhar]

> > For the purposes of WHATWG's multi-implementer support criteria: I will assume we cannot check the box for "Chromium supports this feature" until a different browser has shipped :state() to their stable channel. (Let me know if that is incorrect.)

> 

> Chromium does support the feature, and it should be marked as such in the WHATWG. (We've shipped it in fact, just with a slightly different name for the moment.)

Yeah I'm worried that not merging the spec would be a confusing signal to Apple and then they might never implement anything. I'd like to see the HTML spec get merged as :state().

[Chris Harrelson]

On Fri, Oct 20, 2023 at 9:00 AM Joey Arhar <jar...@chromium.org> wrote:

> > For the purposes of WHATWG's multi-implementer support criteria: I will assume we cannot check the box for "Chromium supports this feature" until a different browser has shipped :state() to their stable channel. (Let me know if that is incorrect.)

> 

> Chromium does support the feature, and it should be marked as such in the WHATWG. (We've shipped it in fact, just with a slightly different name for the moment.)

Yeah I'm worried that not merging the spec would be a confusing signal to Apple and then they might never implement anything. I'd like to see the HTML spec get merged as :state().

+1!

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2Bbw61Ekw_4D%3Dw31U_WcDQbOrO0HpbbRSvq7TmTPpFQpA%40mail.gmail.com.

[Domenic Denicola]

On Sat, Oct 21, 2023 at 1:10 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Oct 20, 2023 at 9:00 AM Joey Arhar <jar...@chromium.org> wrote:

> > For the purposes of WHATWG's multi-implementer support criteria: I will assume we cannot check the box for "Chromium supports this feature" until a different browser has shipped :state() to their stable channel. (Let me know if that is incorrect.)

> 

> Chromium does support the feature, and it should be marked as such in the WHATWG. (We've shipped it in fact, just with a slightly different name for the moment.)

Yeah I'm worried that not merging the spec would be a confusing signal to Apple and then they might never implement anything. I'd like to see the HTML spec get merged as :state().

+1!

I'd like to get confirmation from this from the API Owners as a whole before moving forward. This is the first time that Chromium, or indeed any implementer, has said "we will not ship the contents of this PR" (until some future condition, outside your control, comes to pass). But, supports merging the PR. Indeed, this goes against the "should" in the WHATWG working mode for feature additions; "we would be willing to implement this after another implementer ships to stable" is very different from "we would like to implement this soon".

So I'd appreciate it if the API Owners could, in their next discussion of this topic, resolve whether or not Chromium supports :state() being added to the HTML Standard, even before any other engine ships it.

[Chris Harrelson]

On Sun, Oct 22, 2023 at 9:32 PM Domenic Denicola <dom...@chromium.org> wrote:

On Sat, Oct 21, 2023 at 1:10 AM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Oct 20, 2023 at 9:00 AM Joey Arhar <jar...@chromium.org> wrote:

> > For the purposes of WHATWG's multi-implementer support criteria: I will assume we cannot check the box for "Chromium supports this feature" until a different browser has shipped :state() to their stable channel. (Let me know if that is incorrect.)

> 

> Chromium does support the feature, and it should be marked as such in the WHATWG. (We've shipped it in fact, just with a slightly different name for the moment.)

Yeah I'm worried that not merging the spec would be a confusing signal to Apple and then they might never implement anything. I'd like to see the HTML spec get merged as :state().

+1!

I'd like to get confirmation from this from the API Owners as a whole before moving forward. This is the first time that Chromium, or indeed any implementer, has said "we will not ship the contents of this PR" (until some future condition, outside your control, comes to pass). But, supports merging the PR. Indeed, this goes against the "should" in the WHATWG working mode for feature additions; "we would be willing to implement this after another implementer ships to stable" is very different from "we would like to implement this soon".

Chromium support already meets the "must" part of the definition you linked to. It also meets the "should" part as written. "We would like to implement this soon" is true.

 

So I'd appreciate it if the API Owners could, in their next discussion of this topic, resolve whether or not Chromium supports :state() being added to the HTML Standard, even before any other engine ships it.

The API owners are not in charge of the kind of decision. My API owner hat off, I (and Mason) have provided support as owners of the relevant part of Chromium.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra936hzGxQT%2BRvnXqtsS8CL6OHdiPCkBO%2BXaGL1hKucLgA%40mail.gmail.com.

[Daniel Bratell]

From my API owner hat: I don't mind the change in general but don't think we should change from something that exists to something different unless it brings more interoperability, which is why I think it is a reasonable decision to not ship until at least another browser does the same. 

The suggestion to avoid further massaging of the spec until another browser has caught up was a suggestion, and not a MUST, and was not intended to prevent anything already in the pipeline from landing.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8zRq6Ua6Ut9P40xN4bQm8zMUwmoEDD_zGZSmDHqqJ77w%40mail.gmail.com.

[Chris Wilson]

I'll raise this at the next WHATWG SG meeting (tomorrow) as a working mode question, but I would be willing to say that "we will agree to make this change if someone else commits via shipping" would fulfill "we would like to implement this soon".  The WHATWG Working Mode doesn't go into great detail about what happens if support is withdrawn prior to implementation - my informal understanding is that such features would end up getting pulled.  I think this particular situation ends up effectively putting double the "supports" emphasis on another implementer; merging of the spec PR would be strongly driven by understanding of Apple's (in this case) commitment to support.  This is personal opinion, of course, and I'll reflect back the discussion with the SG.

[Alex Russell]

For the avoidance of doubt, would just like to re-emphasise that landing a new syntax is less attractive than compatible additions to the existing one. If there are new problems being solved by the new syntax, it might be helpful to explain what they are in a short summary somewhere, with bonus points for why they cannot be addressed with compatible additions to the shipped syntax.

Best,

Alex

[Luke]

Fwiw CustomStateSets with the :state() syntax is now enabled by default on WebKit trunk. https://github.com/WebKit/WebKit/compare/8faf2e8d8d0c...26f4507be15d

[Joey Arhar]

Thanks Luke!

Now that WebKit is shipping, can I get approval to implement and ship :state(foo) alongside :--foo, then deprecate and remove :--foo?

[Chris Harrelson]

LGTM1 to ship.

--
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/CAK6btwJ5%3DbeekOhSGVSURGGD6U7Lm6AE5wbxvUNOq7FwFg92sg%40mail.gmail.com.

[TAMURA, Kent]

The plan looks good, but I think chromestatus.com can't handle the removal of the old syntax and the addition of the new syntax in a single entry.

Joey, can you create a new entry for shipping the new syntax?

--

TAMURA Kent
Software Engineer, Google

[Joey Arhar]

> The plan looks good, but I think chromestatus.com can't handle the removal of the old syntax and the addition of the new syntax in a single entry.
> Joey, can you create a new entry for shipping the new syntax?

Sure: https://chromestatus.com/feature/5586433790443520

Should I start another intent to ship thread for it as well?

[Mike Taylor]

If you don't mind - that way it will show up in our review queue.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwK42RLxygrC5wLdt25_658xSjwoknrUfAAQV5y%2BSokVWw%40mail.gmail.com.

[Nils Intfeld]

Is it possible to refresh the chrome status sites?

So far I see two status tickets:

The feature of the new Syntax: https://chromestatus.com/feature/5586433790443520

The removal of the old Syntax: https://chromestatus.com/feature/5140610730426368

There are some things which are misleading for me:
- The removal ticket has no active development and no estimated shipping milestone.

- The feature ticket says, the estimated shipping milestone is 125, but what does that mean? Removal  or add of the new syntax or both?

- I see deprecation warnings in 123 which lets me suggest that there will be a removal soon?

- The chromestatus roadmap does not include  that tickets (just an entry  in 122 for "behind a flag")

Can you help me get those things clear?

[Joey Arhar]

The new syntax is shipping in the milestone on the chromestatus, and at that time both syntaxes will work at the same time. To fix the deprecation message, just migrate to the new syntax.

I will put down a milestone for the removal when I have everything ready including an enterprise policy to re-enable the old syntax for a while.

[Nils Intfeld]

Was a bit confused cause the deprecations are printed to console as errors and not as warnings. So I thouht we have to handle that fast in our software and I was not sure when the removal will be done.

Is the output as an error the correct way to go? Cause until the milestone is not reached, I can`t  upgrade to new syntax.

But glad we have no time issues here. Thanks a lot for your fast response.