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 <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980> (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. On Thu, Oct 5, 2023 at 1:49 PM Chris Harrelson <chris...@chromium.org> wrote: > > > On Wed, Oct 4, 2023 at 2:24 PM Jeffrey Yasskin <jyass...@chromium.org> > wrote: > >> Apparently +Chris Wilson <cwi...@google.com> 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 <chris...@chromium.org> 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. > > >> >> Jeffrey >> >> On Wed, Oct 4, 2023 at 1:15 PM Jeffrey Yasskin <jyass...@chromium.org> >> wrote: >> >>> 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! >>> >>> On Wed, Oct 4, 2023 at 1:00 PM Jeffrey Yasskin <jyass...@chromium.org> >>>> wrote: >>>> >>>>> +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 >>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-591547956>; >>>>> we shipped that in M90 in 2021 >>>>> <https://chromestatus.com/feature/6537562418053120> (with a feature >>>>> entry that still says :state 🙃); then Ryosuke suggested undoing that >>>>> change in January 2023 >>>>> <https://github.com/whatwg/html/pull/8467#issuecomment-1381645661>, >>>>> and the CSSWG accepted that suggestion in August >>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980>. >>>>> 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 >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/wPAHJzIvAQAJ> >>>>> might >>>>> say that the CSSWG's resolution >>>>> <https://github.com/w3c/csswg-drafts/issues/4805#issuecomment-1663111980> >>>>> 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 >>>>> >>>>> On Fri, Sep 29, 2023 at 12:32 PM Alex Russell < >>>>> slightly...@chromium.org> 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? >>>>>> >>>>>> 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. 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. >>>>>>> >>>>>>> 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 >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3ECustomElements> >>>>>>>> >>>>>>>> TAG reviewNone >>>>>>>> >>>>>>>> TAG review statusNot 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 >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>> ?Yes >>>>>>>> >>>>>>>> Flag name on chrome://flagsNone >>>>>>>> >>>>>>>> Finch feature nameNone >>>>>>>> >>>>>>>> Non-finch justificationNone >>>>>>>> >>>>>>>> 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 >>>>>>>> <https://chromestatus.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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnPrTj5PhthsMfcr5kd340pbfzuCZik1%2B7J7FC-YkKL1g%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/CAOMQ%2Bw-TtrRDb2VBLHM6jh3CvZYm1JfcLVCmT_-Z60yZx4COxQ%40mail.gmail.com.
