That is a question for the standards working group - https://github.com/WICG/scroll-to-text-fragment/issues
☆*PhistucK* On Tue, Oct 17, 2023 at 11:38 PM Adam Semenenko <adam.semene...@gmail.com> wrote: > 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/CABc02_J-5sj4oVPqWzTgyokvLyz7QYQTVaBGSK5yhcKzJx_mvg%40mail.gmail.com.
