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.
