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 <bratel...@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 <dome...@chromium.org> >> wrote: >> >>> >>> >>> On Sat, Oct 21, 2023 at 1:10 AM Chris Harrelson <chris...@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 <chris...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Oct 19, 2023 at 6:48 PM Domenic Denicola < >>>>>> dome...@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 < >>>>>>> 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. >>>>>>> >>>>>> >>>>>> 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 < >>>>>>>>> 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: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- 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/CAA44PQjRwok9Q0PMiOLt94CV_XfzTi7K8FAh_3YeDg02vUEd6Q%40mail.gmail.com.
