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.
