Hi all, Is there a way to remove this option yet? The usability is getting worse for me. Now the ugly highlighting is sticking around for longer.
I don't need Chrome to randomly highlight an arbitrary sentence of some websites in a different colour. It's distracting and annoying. I'd like to turn it off. Kind regards, Adam On Tue, 4 May 2021, 20:40 Adam Semenenko, <[email protected]> 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 < > [email protected]> 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 [email protected] >> 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 <[email protected]> wrote: >>>>> >>>>>> LGTM1 >>>>>> >>>>>> >>>>>> On Wed, Dec 11, 2019, 22:03 Nick Burris <[email protected]> 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 [email protected]. >>>>>>> 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 [email protected]. >>>>>> 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 >> [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetRLA%3Da5WScarBrGJnBOpiR9A7eBNJ6nt%3DR4CXDB7czLCg%40mail.gmail.com.
