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. > > 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/CAOMQ%2Bw8SD56Qq00V-B2f60uW-OjfQDVQ7Omx3sO_J7vnfP8yXA%40mail.gmail.com.
