Thanks PhistucK. So why isn't there an option to disable the text highlighting in the web API? .
The first poster in the thread started sharing qualitative feedback about this feature, so it seem seems appropriate to continue that. On Tue, 10 Oct 2023, 11:04 PhistucK, <phist...@gmail.com> wrote: > crbug.com is the place for asking for a feature request/changes to > Chromium and Chrome. This thread simply is not, it is a technical thread > about a web API, not about a browser user interface. Please, use the proper > place and it will be considered just like any other feedback. > > ☆*PhistucK* > > > On Mon, Oct 9, 2023 at 4:05 PM Adam Semenenko <adam.semene...@gmail.com> > wrote: > >> Hi, scroll to text links can come from any location. They're implemented >> by adding some guff to the end of any URL. For example, someone could send >> me a link, or a website could include them. I don't think it's reasonable >> for me to expect that everyone changes their habits, so I won't do that. It >> would be reasonable for Chrome to re-implement the opt-out flag, however. >> This is what I asked for in this thread a while ago, so I think it makes >> sense to keep the thread focused rather than spreading it out. If you'd >> like to forward my comments to another forum then please, feel free. >> >> On Fri, 6 Oct 2023, 08:24 K. Moon, <km...@chromium.org> wrote: >> >>> You haven't said where your scroll-to-text links are coming from, but I >>> assume it's a search engine, which is the most common case. If you don't >>> like the quality of the links, the proper place to address your complaint >>> is to that search engine. >>> >>> As this feature has shipped (it appears all the way back in M80), >>> complaining on this thread isn't going to accomplish anything. If you want >>> the spec to change, there are other forums for that. If you want Chrome's >>> behavior to change, you should file a feature request (or ideally, find an >>> existing one). >>> >>> On Thu, Oct 5, 2023, 12:10 PM Adam Semenenko <adam.semene...@gmail.com> >>> wrote: >>> >>>> The feature can be disabled in Safari >>>> https://www.reddit.com/r/MacOS/comments/14l1gcu/how_to_disable_safari_automatically_highlighting/, >>>> so it's a Chrome specific issue that it can't be disabled >>>> >>>> On Fri, 6 Oct 2023, 08:06 K. Moon, <km...@chromium.org> wrote: >>>> >>>>> (Incidentally, it appears Safari 16+ also supports this feature, >>>>> further illustrating that this is not a Chrome-specific concern.) >>>>> https://caniuse.com/url-scroll-to-text-fragment >>>>> >>>>> On Thu, Oct 5, 2023, 12:01 PM 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/CAAyoetScKktfiiNQOSLNutEOaBboSeh7%2BnhZguTMT2A6OK97wQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetScKktfiiNQOSLNutEOaBboSeh7%2BnhZguTMT2A6OK97wQ%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/CAAyoetS%3DtrxMAdP38aHidTiMH9cod%3DAO8R4ywKr%3DTYZJqQXEHQ%40mail.gmail.com.
