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_JmF6Q6P_4T8uUqUb5mR7_i%3DDbsA7%2B-kYh6hi4DAsxZqA%40mail.gmail.com.
