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 <chris...@chromium.org> wrote: > > > On Thu, Oct 19, 2023 at 10:59 AM Chris Harrelson <chris...@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 <https://github.com/w3c/csswg-drafts/pull/8213> and HTML <https://github.com/whatwg/html/pull/8467> spec PRs, plus a WICG spec <https://wicg.github.io/custom-state-pseudo-class/>. 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.) > > >> >> 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. >> >> On Thu, Oct 12, 2023 at 11:41 AM Alex Russell <slightly...@chromium.org> >> wrote: >> >>> 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 >>> >>> <https://www.w3.org/2019/09/17-components-minutes.html#:~:text=chrishtr:%20I%20think%20having%20custom%20states%20was%20the%20%231%20request%20on%20top%20of%20parts>, >>> explore the design space earnestly, work with developers to vet a >>> solution, >>> and work to build interest with other vendors >>> >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/CApU9QIu3TM/m/LPKLLLahDQAJ> >>> . >>> - 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 >>> >>> On Wednesday, October 11, 2023 at 7:49:09 AM UTC-7 Brian Kardell wrote: >>> >>>> 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 >>>> >>>> >>>> >>>> On Thursday, October 5, 2023 at 4:54:26 PM UTC-4 Chris Harrelson wrote: >>>> >>>>> 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 <chri...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>> >>>>>>> Jeffrey >>>>>>> >>>>>>> On Wed, Oct 4, 2023 at 1:15 PM Jeffrey Yasskin <jyas...@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 < >>>>>>>>> jyas...@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 < >>>>>>>>>> sligh...@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+...@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/fa862fff-e9eb-4aad-acc3-ca0849c72b06n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fa862fff-e9eb-4aad-acc3-ca0849c72b06n%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/CAM0wra_nhUTf5QZWscrcBZ5h6ixUkwLv%2BxKk9temGqPRt%3De_tw%40mail.gmail.com.
