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/CALgRrLnKSR3WUm2vw9F1i4uQddufV-FNLub1xBD%3DCdimouDgaw%40mail.gmail.com.
