(On Android, some Chromium-based browsers support extensions, for example, Kiwi browser <https://kiwibrowser.com/>. It says it supports "most Chrome desktop extensions", but I haven't tested the extension in question.)
On Thu, Oct 5, 2023 at 9:24 PM 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> >>>>>>> . >>>>>>> >>>>>> -- 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/CALgRrL%3DWgrmfLH_vjL6RzM4MXowLGhLtfH9Ep-xXy9443OA4cQ%40mail.gmail.com.
