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: >>>>>>>>>>>> >>>>>>>>>>> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_nhUTf5QZWscrcBZ5h6ixUkwLv%2BxKk9temGqPRt%3De_tw%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/CAOMQ%2Bw_v9OchLD0K-PScOn02iM6_QfZp7zB%3D_fN1SbSdFC6KGQ%40mail.gmail.com.
