Thanks Luke! Now that WebKit is shipping, can I get approval to implement and ship :state(foo) alongside :--foo, then deprecate and remove :--foo?
On Sat, Dec 23, 2023 at 12:17 PM Luke <lukewarlow...@gmail.com> wrote: > Fwiw CustomStateSets with the :state() syntax is now enabled by default on > WebKit trunk. > https://github.com/WebKit/WebKit/compare/8faf2e8d8d0c...26f4507be15d > > On Tuesday 24 October 2023 at 01:47:10 UTC+1 sligh...@chromium.org wrote: > >> 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 >> >> >> On Mon, Oct 23, 2023, 3:47 PM Chris Wilson <cwi...@google.com> wrote: >> >>> 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. >>> >>> On Mon, Oct 23, 2023 at 2:15 PM Daniel Bratell <brat...@gmail.com> >>> wrote: >>> >>>> 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 >>>> On 2023-10-23 16:46, Chris Harrelson wrote: >>>> >>>> >>>> >>>> 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 <https://whatwg.org/working-mode#additions> 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. >>>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>> On Fri, Oct 20, 2023 at 8:55 AM Chris Harrelson < >>>>>>> chri...@chromium.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>>>>>> <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. >>>>>>>>> >>>>>>>> >>>>>>>> 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.) >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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 < >>>>>>>>>>> sligh...@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: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- 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/CAK6btwJ5%3DbeekOhSGVSURGGD6U7Lm6AE5wbxvUNOq7FwFg92sg%40mail.gmail.com.
