Thanks for the explanation. But I don't like the scroll to text fragments. They're annoying, and have never been useful.
There seem to be only two ways that this feature is used: 1. The first sentence of a page is highlighted, which is completely redundant and patronising. Yes Chrome, thank you for highlighting the very first sentence. However could I cope without you. 2. A random sentence halfway through the page is highlighted. This is never what I want: I always want to read the page so that I can understand the sentence in context. On Fri, 6 Oct 2023, 08:01 K. Moon, <km...@chromium.org> wrote: > If the URL doesn't contain a scroll-to-text fragment, then this feature > doesn't get invoked. The site that serves you the URL is responsible for > deciding whether or not to include a scroll-to-text fragment. > > On Thu, Oct 5, 2023, 11:59 AM Adam Semenenko <adam.semene...@gmail.com> > wrote: > >> Sorry, I'm not sure what you mean. I only get usability issues related to >> this feature in Chrome, which to me indicates it's a Chrome issue >> >> On Fri, 6 Oct 2023, 07:53 K. Moon, <km...@chromium.org> wrote: >> >>> If your complaint is about the URLs (and the resulting behavior), isn't >>> that a site authoring issue, not a Chrome issue? >>> >>> On Thu, Oct 5, 2023, 10:25 AM Adam Semenenko <adam.semene...@gmail.com> >>> wrote: >>> >>>> Sorry Thomas, I should have specified that I am using Android. From >>>> what I can tell there's no way to disable this anti-feature on Android. >>>> >>>> Also, while the macOS option removes some distraction, Chrome still >>>> pollutes the URL with unnecessary content that's awkward to remove. (I've >>>> never wanted to share a URL with this 'jump to text' option.) >>>> >>>> On Thu, 5 Oct 2023, 20:54 Thomas Steiner, <to...@google.com> wrote: >>>> >>>>> See https://web.dev/text-fragments/#disabling-text-fragments for >>>>> disabling the feature. >>>>> >>>>> On Thu, Oct 5, 2023 at 8:51 AM Anton Bershanskyi < >>>>> bershans...@gmail.com> wrote: >>>>> >>>>>> Hi Adam, >>>>>> >>>>>> > Is it still not possible to disable this distraction yet? >>>>>> >>>>>> Chrome used to have an option to disable this feature, but the flag >>>>>> was removed. It is possible to remove highlights with extensions. I >>>>>> found "Disable >>>>>> Google Search Text Highlights" >>>>>> <https://chrome.google.com/webstore/detail/disable-google-search-tex/ompocnnmgiaoieoanemepjflbokldhom> >>>>>> on CWS, but never used it. It's open source (GitHub link on store page). >>>>>> The source seems fine (albeit I would have written it with declarative >>>>>> network rules for efficiency, but very few developers are familiar with >>>>>> this API). >>>>>> >>>>>> Hope this helps. >>>>>> >>>>>> On Thursday, October 5, 2023 at 2:26:18 AM UTC+3 Adam Semenenko wrote: >>>>>> >>>>>>> Is it still not possible to disable this distraction yet? I found a >>>>>>> wonderfully ironic example today - see attached screenshot. >>>>>>> >>>>>>> There seem to be only two ways that this feature is used: >>>>>>> >>>>>>> 1. The first sentence of a page is highlighted, which is completely >>>>>>> redundant and patronising. Yes Chrome, thank you for highlighting the >>>>>>> very >>>>>>> first sentence. However could I cope without you. >>>>>>> >>>>>>> 2. A random sentence halfway through the page is highlighted. This >>>>>>> is never what I want: I always want to read the page so that I can >>>>>>> understand the sentence in context. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, 5 May 2021, 06:40 Adam Semenenko, <adam.se...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Do you know if there's a consistent and easy way to disable this >>>>>>>> yet? It's really distracting for me. When I google something and click >>>>>>>> on a >>>>>>>> result, I like consistent behaviour and to see the whole page from the >>>>>>>> start. I feel disrupted when I'm randomly dropped into the middle of a >>>>>>>> page >>>>>>>> with a garish colour jumping out at me. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Adam >>>>>>>> >>>>>>>> On Mon, 26 Apr 2021 at 21:54, 'Grant Wang' via blink-dev < >>>>>>>> blin...@chromium.org> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> It’s been roughly nine months since we first utilized Scroll To >>>>>>>>> Text Fragment in featured snippets in Google Search. In that time, >>>>>>>>> we’ve >>>>>>>>> seen that Scroll To Text Fragment links help us towards our goal to >>>>>>>>> get >>>>>>>>> users the information they need. In particular: >>>>>>>>> >>>>>>>>> 1. We find that Scroll To Text Fragment links increase >>>>>>>>> engagement -- users are less likely to visit a page and then >>>>>>>>> quickly hit >>>>>>>>> the back button, because they can more readily understand how >>>>>>>>> relevant the >>>>>>>>> page is to their search after arriving at the page. >>>>>>>>> >>>>>>>>> 2. In user surveys, we find that users prefer being scrolled >>>>>>>>> to the relevant section of a page that’s in a featured snippet. >>>>>>>>> Users who >>>>>>>>> were scrolled to the relevant section preferred the experience at >>>>>>>>> a rate of >>>>>>>>> 2:1; even users who were not scrolled in the control group >>>>>>>>> preferred the >>>>>>>>> option of being scrolled to the relevant section at the same 2:1 >>>>>>>>> rate. >>>>>>>>> >>>>>>>>> Besides their usage on Google Search, we’ve noticed scroll to text >>>>>>>>> fragments links during our crawls of the web. One of the best use >>>>>>>>> cases >>>>>>>>> has been wikipedia citations. For instance, citation 9 >>>>>>>>> <https://en.wikipedia.org/wiki/Melbourne_Cup_%28greyhounds%29#:~:text=%22How%20the%20Cup%20Was%20Won%22.%20Sandown%20Greyhounds.%20Retrieved%2017%20March%202021.> >>>>>>>>> on this page: >>>>>>>>> https://en.wikipedia.org/wiki/Melbourne_Cup_(greyhounds) provides >>>>>>>>> the detailed attribution to the fastest-ever time at the Melbourne >>>>>>>>> Cup. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Grant >>>>>>>>> On Thursday, December 12, 2019 at 12:24:40 PM UTC-8 >>>>>>>>> sligh...@chromium.org wrote: >>>>>>>>> >>>>>>>>>> LGTM4 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thursday, December 12, 2019 at 12:17:49 PM UTC-8, Daniel >>>>>>>>>> Bratell wrote: >>>>>>>>>>> >>>>>>>>>>> LGTM3 >>>>>>>>>>> >>>>>>>>>>> /Daniel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thursday, 12 December 2019 19:45:38 UTC+1, Chris Harrelson >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> LGTM2 >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Dec 11, 2019 at 10:27 PM Yoav Weiss <yo...@yoav.ws> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> LGTM1 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Dec 11, 2019, 22:03 Nick Burris <nbu...@chromium.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> We feel that we're now in good shape for shipping. We have >>>>>>>>>>>>>> addressed all of the shipping blockers that I listed in my >>>>>>>>>>>>>> previous email, >>>>>>>>>>>>>> and the corresponding implementation changes have landed in >>>>>>>>>>>>>> Chrome. We're >>>>>>>>>>>>>> still continuing to make improvements to the spec, >>>>>>>>>>>>>> functionality, and web >>>>>>>>>>>>>> platform tests but we consider the outstanding issues to be >>>>>>>>>>>>>> minor and >>>>>>>>>>>>>> wouldn't have an effect on interop, so we don't believe they're >>>>>>>>>>>>>> ship-blocking. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have received positive signal on the feature from Safari, >>>>>>>>>>>>>> thank you Maciej for the reply on webkit-dev >>>>>>>>>>>>>> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030996.html>! >>>>>>>>>>>>>> Note that we actually do have feature detectability specified >>>>>>>>>>>>>> implemented >>>>>>>>>>>>>> per my reply >>>>>>>>>>>>>> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html>. >>>>>>>>>>>>>> My apologies this was not mentioned in the initial intent to >>>>>>>>>>>>>> ship email, it >>>>>>>>>>>>>> developed a few emails down the line. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Nick >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thursday, October 31, 2019 at 11:50:21 AM UTC-4, Nick >>>>>>>>>>>>>> Burris wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks so much for the detailed feedback! Here's a specific >>>>>>>>>>>>>>> list of blockers, with some comments inline. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Specification issues >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - #64 >>>>>>>>>>>>>>> <https://github.com/WICG/ScrollToTextFragment/issues/64> >>>>>>>>>>>>>>> - Prevent invocation from popup >>>>>>>>>>>>>>> - #66 >>>>>>>>>>>>>>> <https://github.com/WICG/ScrollToTextFragment/issues/66> >>>>>>>>>>>>>>> - Clarify how scroll to fragment is performed >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Web platform test cases >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Security restrictions >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#should-allow-text-fragment> >>>>>>>>>>>>>>> - Setting window.location.fragmentDirective has no effect >>>>>>>>>>>>>>> - All combinations of optional parameters in text >>>>>>>>>>>>>>> directive >>>>>>>>>>>>>>> - Matching TextMatchChar >>>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#textmatchchar>s >>>>>>>>>>>>>>> and PercentEncodedChar >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#percentencodedchar>s >>>>>>>>>>>>>>> (in particular the syntactical characters ‘,’ and ‘-’) >>>>>>>>>>>>>>> including non-ASCII >>>>>>>>>>>>>>> - Multiple matches in the page (currently we only test 0 >>>>>>>>>>>>>>> or 1 match) >>>>>>>>>>>>>>> - Cross-whitespace/node matching (i.e. context terms and >>>>>>>>>>>>>>> match terms can be separated by whitespace and node >>>>>>>>>>>>>>> boundaries) >>>>>>>>>>>>>>> - Test matching hidden and shadow DOM >>>>>>>>>>>>>>> - Test horizontal scroll into view >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thursday, October 31, 2019 at 10:17:56 AM UTC-4, Frédéric >>>>>>>>>>>>>>> Wang wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 30/10/2019 15:52, Yoav Weiss wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This intent received a lot of feedback, but some of it more >>>>>>>>>>>>>>>> relevant to the general Blink process in general than to this >>>>>>>>>>>>>>>> intent >>>>>>>>>>>>>>>> specifically. So, let me try to sum up where I believe things >>>>>>>>>>>>>>>> are and what >>>>>>>>>>>>>>>> is and isn't blocking this intent from my perspective. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While the original intent could have done a better job at >>>>>>>>>>>>>>>> expressing the outreach efforts done, and potentially a better >>>>>>>>>>>>>>>> job reaching >>>>>>>>>>>>>>>> out to WebKit folks, that *should not block* the current >>>>>>>>>>>>>>>> intent. Official signals from other vendors would be most >>>>>>>>>>>>>>>> welcome, but I >>>>>>>>>>>>>>>> would not block the intent on getting them. (The Blink process >>>>>>>>>>>>>>>> needs to >>>>>>>>>>>>>>>> establish the best ways to get feedback from other vendors in >>>>>>>>>>>>>>>> reasonable >>>>>>>>>>>>>>>> timeframes. That discussion is beyond the scope of this intent) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A list of blockers for this intent from my perspective: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Anne's security concern >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/392#issuecomment-510855073> >>>>>>>>>>>>>>>> seems >>>>>>>>>>>>>>>> like something we should address in spec. Even if Chrome >>>>>>>>>>>>>>>> security folks >>>>>>>>>>>>>>>> don't consider this a blocking issue, assuming Mozilla >>>>>>>>>>>>>>>> does, that would get >>>>>>>>>>>>>>>> in their way if they wished to follow us. >>>>>>>>>>>>>>>> - Daniel's feedback on augmenting the Privacy & >>>>>>>>>>>>>>>> Security section with feedback from the Chrome security >>>>>>>>>>>>>>>> seems valuable, and >>>>>>>>>>>>>>>> I'd like to see it addressed before shipping. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Forgot to note that David did address this in #62 >>>>>>>>>>>>>>> <https://github.com/WICG/ScrollToTextFragment/issues/62>, I >>>>>>>>>>>>>>> believe the security and privacy >>>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#allow-text-fragment-directives> >>>>>>>>>>>>>>> section now details all of the feedback and work we've done >>>>>>>>>>>>>>> here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - Regarding Rego and Fréd's feedback on WPTs - I'd like >>>>>>>>>>>>>>>> for us to reach agreement on which test cases should be >>>>>>>>>>>>>>>> added beyond what's >>>>>>>>>>>>>>>> currently covered in order for the test suite to be >>>>>>>>>>>>>>>> considered complete. >>>>>>>>>>>>>>>> Rego/Fréd - do you have such a list of cases in mind? Once >>>>>>>>>>>>>>>> we reach >>>>>>>>>>>>>>>> agreement on what that list should be, we should block >>>>>>>>>>>>>>>> shipping until the >>>>>>>>>>>>>>>> test suite is complete. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> People developing the feature probably know better the >>>>>>>>>>>>>>>> things to test. That said, after checking a bit the spec and >>>>>>>>>>>>>>>> tests, it >>>>>>>>>>>>>>>> looks like the features can be divided into the following >>>>>>>>>>>>>>>> categories: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (1) Fragment directive, IDL interface and TreeWalker >>>>>>>>>>>>>>>> navigation >>>>>>>>>>>>>>>> This is the core of the proposal, so it would probably >>>>>>>>>>>>>>>> be a blocker if it >>>>>>>>>>>>>>>> is not tested extensively. Exiting tests already cover >>>>>>>>>>>>>>>> several cases, but >>>>>>>>>>>>>>>> I suspect more can be tested here (e.g. check the >>>>>>>>>>>>>>>> actual value >>>>>>>>>>>>>>>> of window.location.fragmentDirective for different >>>>>>>>>>>>>>>> cases, check that >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Note that window.location.fragmentDirective does not >>>>>>>>>>>>>>> actually expose the fragment directive string, for now it is >>>>>>>>>>>>>>> just specified >>>>>>>>>>>>>>> for feature detectability (see #19 >>>>>>>>>>>>>>> <https://github.com/WICG/ScrollToTextFragment/issues/19> >>>>>>>>>>>>>>> and spec >>>>>>>>>>>>>>> <https://wicg.github.io/ScrollToTextFragment/#feature-detectability> >>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> setting it has no effect, doing query for all >>>>>>>>>>>>>>>> combinations of >>>>>>>>>>>>>>>> mandatory/optional parameters, TextMatchChar, percent >>>>>>>>>>>>>>>> encoding of special >>>>>>>>>>>>>>>> characters, non-ascii chars, more complex test pages >>>>>>>>>>>>>>>> with 0, 1 or more >>>>>>>>>>>>>>>> matches, with whitespace, with different locales, etc) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (2) Security & Privacy >>>>>>>>>>>>>>>> Apparently people have raised concerns about this so it >>>>>>>>>>>>>>>> seems important to >>>>>>>>>>>>>>>> tests any mitigation or protection described in the >>>>>>>>>>>>>>>> spec, if any (and if >>>>>>>>>>>>>>>> possible with the current WPT infrastructure). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (3) Navigating to a Text Fragment >>>>>>>>>>>>>>>> It seems that the idea of the proposal is to rely on >>>>>>>>>>>>>>>> existing concepts >>>>>>>>>>>>>>>> like Range/TreeWalker and APIs similar to >>>>>>>>>>>>>>>> window.find/scrollIntoView. >>>>>>>>>>>>>>>> I think it would be good to have minimal tests checking >>>>>>>>>>>>>>>> that (scroll >>>>>>>>>>>>>>>> position actually changed, scroll alignment/behavior, >>>>>>>>>>>>>>>> hidden DOM/CSS, etc) >>>>>>>>>>>>>>>> but this does not need to be exhaustive, since it is >>>>>>>>>>>>>>>> assumed that these are >>>>>>>>>>>>>>>> already implemented, tested and inter-operable (See >>>>>>>>>>>>>>>> comment below though). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (4) Indicating The Text Match >>>>>>>>>>>>>>>> The spec explicitly says it is UA-defined so it cannot >>>>>>>>>>>>>>>> really be >>>>>>>>>>>>>>>> tested. I guess one could write a minimal != reftest to >>>>>>>>>>>>>>>> check that highlight >>>>>>>>>>>>>>>> actually happens but it would be very weak anyway, so >>>>>>>>>>>>>>>> I'm not sure it's >>>>>>>>>>>>>>>> necessary. These will instead likely be >>>>>>>>>>>>>>>> browser-specific tests. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Agreed, I think this should be left as browser-specific; we >>>>>>>>>>>>>>> only want to specify the matching/scroll-into-view behavior and >>>>>>>>>>>>>>> leave it up >>>>>>>>>>>>>>> to the UA/browser how the specific text is actually indicated. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> BTW, I don't think my comment regarding BroadcastChannel is >>>>>>>>>>>>>>>> a blocker, I just believe it would be nice to avoid relying on >>>>>>>>>>>>>>>> non-interoperable APIs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Though not a shipping blocker I definitely want to fix this, >>>>>>>>>>>>>>> I spoke to some WPT experts and using WPT's Stash >>>>>>>>>>>>>>> <https://web-platform-tests.org/tools/wptserve/docs/stash.html> >>>>>>>>>>>>>>> seems like a viable option. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Besides tests, I share Anne's concern on Mozilla repo >>>>>>>>>>>>>>>> regarding lack of existing primitive for actually performing >>>>>>>>>>>>>>>> the scroll to >>>>>>>>>>>>>>>> text. I opened >>>>>>>>>>>>>>>> https://github.com/WICG/ScrollToTextFragment/issues/66 for >>>>>>>>>>>>>>>> that purpose. Right now it's unclear to me if this is >>>>>>>>>>>>>>>> well-specified and >>>>>>>>>>>>>>>> tested in the current proposal, and this may be considered a >>>>>>>>>>>>>>>> blocker. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Frédéric Wang >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 blin...@chromium.org. >>>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1238c06f-dcd1-434c-87b8-97a373fdf735%40chromium.org >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1238c06f-dcd1-434c-87b8-97a373fdf735%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 blin...@chromium.org. >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgFMwT1ArGjrHMcWZ9pKe8%2Bsv%2BJHDLpOd4ofOQss0a-zA%40mail.gmail.com >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgFMwT1ArGjrHMcWZ9pKe8%2Bsv%2BJHDLpOd4ofOQss0a-zA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to a topic in >>>>>>>>> the Google Groups "blink-dev" group. >>>>>>>>> To unsubscribe from this topic, visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/topic/blink-dev/zlLSxQ9BA8Y/unsubscribe >>>>>>>>> . >>>>>>>>> To unsubscribe from this group and all its topics, 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/e9c07baa-3c2a-4835-9014-9d5a2b249618n%40chromium.org >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9c07baa-3c2a-4835-9014-9d5a2b249618n%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/6969a528-2a88-40ab-8b07-9aa9e522946an%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6969a528-2a88-40ab-8b07-9aa9e522946an%40chromium.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Steiner, PhD—Developer Relations Engineer ( >>>>> https://blog.tomayac.com, https://twitter.com/tomayac) >>>>> >>>>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany >>>>> Geschäftsführer: Paul Manicle, Liana Sebastian >>>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>>> >>>>> ----- BEGIN PGP SIGNATURE ----- >>>>> Version: GnuPG v2.3.4 (GNU/Linux) >>>>> >>>>> >>>>> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom. >>>>> hTtPs://xKcd.cOm/1181/ >>>>> ----- END PGP SIGNATURE ----- >>>>> >>>> -- >>>> 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/CAAyoetTfq0Yt6UTv_7xa%3DvEGKESREoVqwHoDWZrgn46yXsKwfw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetTfq0Yt6UTv_7xa%3DvEGKESREoVqwHoDWZrgn46yXsKwfw%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/CAAyoetRKLi4P4uL-mRSbRmyMfc6p6LHHcP%2BMGRhj%3DV%3DoM7ouGQ%40mail.gmail.com.
