Intent to Ship: Scroll To Text Fragment

[Nick Burris]

Contact emails

nbu...@chromium.org, bo...@chromium.org, bmcq...@chromium.org

Explainer

https://github.com/WICG/ScrollToTextFragment

Spec

WICG draft spec: https://wicg.github.io/ScrollToTextFragment/

TAG review: https://github.com/w3ctag/design-reviews/issues/392

Summary

Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow deep-linking references to information.

Link to “Intent to Implement” blink-dev discussion

Intent to implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/aKI6doxffgQ/7dzrVvo4CAAJ

Intent to experiment: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/NySZyk6UMEs

Link to Origin Trial feedback summary

We requested feedback in the form of Github issues: https://github.com/WICG/ScrollToTextFragment/issues

We did not get specific feedback from origins other than Google Search, who used the origin trial to link featured snippets to the text fragment in the page that they are quoting. Google Search provided the following feedback:

“We experimented with Scroll To Text on Featured Snippets on Google Search, where it scrolls to and highlights the same passage on the source page upon opening. We see improvements in the search experience as a result of this feature. By allowing users to jump to the content that is most relevant to their queries, we observe that users consume content on the source page more effectively. Additionally, users end up consuming content from a wider range of search results. There are already two other similar launches within Google Search on small fraction of traffic. This feature will help greatly expand the coverage.”

This feedback provides a strong signal that the feature improves user engagement and helps surface information on the web.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

With the feature enabled (in latest canary with --enable-blink-features=TextFragmentIdentifiers)

https://en.wikipedia.org/wiki/Cat#Characteristics:~:text=Claws-,Like%20almost,the%20Felidae%2C,-cats

Risks

Interoperability and Compatibility   

There is some small compatibility risk due to the fragment directive behavior. This was added to minimize compatibility risk on pages that use the fragment for state. Because we now strip the section of the fragment after the delimiter, links that contain that delimiter :~: will be mutated. We’ve analyzed the Google search crawler’s database of “seen links” in the last 5 years and didn’t get any hits. We’ve also added Blink UseCounters to track how often we see :~: in the URL fragment unrelated to this feature without any hits yet (will get stable data with M78). Biggest risk here is corporate intranets where we have little visibility.

The usual interop risk of other browsers not implementing this feature applies. However, the risk should be low since links using this syntax will be interpreted as a regular fragment in UAs not implementing it; the page will still load but without intended scrolling/highlighting. This seems like a low-severity fallback with users unlikely to even notice. Similar rationale applies in the event we’d need to unship this feature.

One point worth highlighting relates to the fragment directive behavior mentioned above. Some existing pages break when any fragment is specified at all (due to page script using the fragment). E.g. (https://www.webmd.com/pain-management/knee-pain/picture-of-the-knee). Adding any fragment to this link will cause the page to load in a broken state. The fragment directive works around this. However, a UA that doesn’t implement it and loads a link like this will see this breakage e.g. (https://www.webmd.com/pain-management/knee-pain/picture-of-the-knee#:~:text=Knee). We expect the number of pages like this is very low; webmd.com is the only one we’ve seen that breaks catastrophically like this but this is a risk as there isn’t a good way to measure it.

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: 

We’ve seen some positive sentiment from twitter users:

Positive: https://twitter.com/brucel/status/1168888603671433222

Positive: https://twitter.com/rem/status/1168864475379916802

Neutral/Informational: https://twitter.com/glenngabe/status/1164850052608774145 

Neutral/Informational: https://twitter.com/brodieseo/status/1172724843302621184

Ergonomics

The default usage of this feature is independent of other platform APIs. When the feature is activated, Chrome must search the page for the target text on page load, however this is followed by a user-visible scroll and highlight assuming the target text is found. We observed a median latency of 26 milliseconds from the time we start processing the text fragment directive until the end of the scroll.

Activation

The feature is easy to use as-is; simply append :~:text=example to the URL fragment (i.e. append #:~:text=example to a URL with no fragment) to activate the feature.

The feature would benefit from a reference implementation for determining what the optimal text directive parameters are for a given text fragment on a page. We are working on a Chrome extension that generates scroll to text links, and plan to open source this extension on https://github.com/GoogleChromeLabs to serve as a reference.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://wpt.fyi/results/scroll-to-text-fragment/scroll-to-text-fragment.html

All tests pass on the Chromium implementation when the feature is enabled (wpt expectations are set to “not run” for Chromium as the feature is disabled by default).

Entry on the feature dashboard

https://chromestatus.com/feature/4733392803332096

[Brian Birtles]

Sorry to be a broken record, but the original I2I thread mentioned the "intent to go through the standards process". Any chance this could moved onto a standards track (not WICG) before shipping?

The explainer itself says, "Once we're satisfied that we understand the space sufficiently, this work will move into the appropriate standardization forum." I guess if we're shipping we understand the space sufficiently?

Thanks!

2019年10月10日木曜日 3時10分24秒 UTC+9 Nick Burris:

[Anne van Kesteren]

On Thu, Oct 10, 2019 at 12:57 AM Brian Birtles <br...@birchill.co.jp> wrote:
> Sorry to be a broken record, but the original I2I thread mentioned the "intent to go through the standards process". Any chance this could moved onto a standards track (not WICG) before shipping?
>
> The explainer itself says, "Once we're satisfied that we understand the space sufficiently, this work will move into the appropriate standardization forum." I guess if we're shipping we understand the space sufficiently?

Yeah, that would be great. I only found out two hours ago that the
plan of record does involve changes to the URL parser, despite that
plan being seemingly abandoned six days ago due to pushback from the
URL community. The feature definitely seems interesting, but could use
some more refinement and collaborative design work.

(Also, I don't think anyone got back to me with regards to the
security issue I pointed out in
https://github.com/w3ctag/design-reviews/issues/392#issuecomment-510855073.)

[Yoav Weiss]

On Thu, Oct 10, 2019 at 4:25 PM Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Oct 10, 2019 at 12:57 AM Brian Birtles <br...@birchill.co.jp> wrote:
> Sorry to be a broken record, but the original I2I thread mentioned the "intent to go through the standards process". Any chance this could moved onto a standards track (not WICG) before shipping?
>
> The explainer itself says, "Once we're satisfied that we understand the space sufficiently, this work will move into the appropriate standardization forum." I guess if we're shipping we understand the space sufficiently?

Yeah, that would be great. I only found out two hours ago that the
plan of record does involve changes to the URL parser, despite that
plan being seemingly abandoned six days ago due to pushback from the
URL community. The feature definitely seems interesting, but could use
some more refinement and collaborative design work.

I think there are two distinct questions here: venue and collaboration.

When it comes to venue, the current spec's processing seems to be mostly monkey-patching the HTML and URL specs, indicating that WHATWG is probably the right venue for this to graduate to.

At the same time, landing features in WHATWG specs require multi-engine commitment, and looking at Mozilla's 2.5-months-old standards position issue doesn't really indicate implementer commitment, or anything at all. From a practical standpoint, it's clearer and easier for the spec to live as a standalone document rather than a WHATWG PR, while we're waiting for multi-engine commitment.

But, that in no means preclude collaboration. The spec is in WICG, which was built specifically to enable multi-vendor collaboration when incubating new ideas. I'm sure everyone would be thrilled to have your feedback directly there, to make sure we get this right.

(Also, I don't think anyone got back to me with regards to the
security issue I pointed out in
https://github.com/w3ctag/design-reviews/issues/392#issuecomment-510855073.)

Good point. Added a comment on a related issue to make sure this doesn't fall through the cracks.

 

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78gQciCj-UfNDn4cWjyHKkfymkxOq0-wUKH4yOQMrzLyWg%40mail.gmail.com.

[Yoav Weiss]

Thanks for working on this! This is an exciting change that many people's first reaction when hearing about it is "I wanted that for years!" (myself included).

On Wed, Oct 9, 2019 at 8:10 PM Nick Burris <nbu...@chromium.org> wrote:

Contact emails

nbu...@chromium.org, bo...@chromium.org, bmcq...@chromium.org

Explainer

https://github.com/WICG/ScrollToTextFragment

Spec

WICG draft spec: https://wicg.github.io/ScrollToTextFragment/

TAG review: https://github.com/w3ctag/design-reviews/issues/392

I believe we'd need to address the security concerns from Anne before shipping. Would also be good to hear back from Tess about the interoperability concerns she raised and confirm that they were fully addressed.

Summary

Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow deep-linking references to information.

Link to “Intent to Implement” blink-dev discussion

Intent to implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/aKI6doxffgQ/7dzrVvo4CAAJ

Intent to experiment: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/NySZyk6UMEs

Link to Origin Trial feedback summary

We requested feedback in the form of Github issues: https://github.com/WICG/ScrollToTextFragment/issues

We did not get specific feedback from origins other than Google Search, who used the origin trial to link featured snippets to the text fragment in the page that they are quoting. Google Search provided the following feedback:

“We experimented with Scroll To Text on Featured Snippets on Google Search, where it scrolls to and highlights the same passage on the source page upon opening. We see improvements in the search experience as a result of this feature. By allowing users to jump to the content that is most relevant to their queries, we observe that users consume content on the source page more effectively. Additionally, users end up consuming content from a wider range of search results. There are already two other similar launches within Google Search on small fraction of traffic. This feature will help greatly expand the coverage.”

This feedback provides a strong signal that the feature improves user engagement and helps surface information on the web.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

With the feature enabled (in latest canary with --enable-blink-features=TextFragmentIdentifiers)

https://en.wikipedia.org/wiki/Cat#Characteristics:~:text=Claws-,Like%20almost,the%20Felidae%2C,-cats

Risks

Interoperability and Compatibility   

There is some small compatibility risk due to the fragment directive behavior. This was added to minimize compatibility risk on pages that use the fragment for state. Because we now strip the section of the fragment after the delimiter, links that contain that delimiter :~: will be mutated. We’ve analyzed the Google search crawler’s database of “seen links” in the last 5 years and didn’t get any hits. We’ve also added Blink UseCounters to track how often we see :~: in the URL fragment unrelated to this feature without any hits yet (will get stable data with M78). Biggest risk here is corporate intranets where we have little visibility.

The usual interop risk of other browsers not implementing this feature applies. However, the risk should be low since links using this syntax will be interpreted as a regular fragment in UAs not implementing it; the page will still load but without intended scrolling/highlighting. This seems like a low-severity fallback with users unlikely to even notice. Similar rationale applies in the event we’d need to unship this feature.

One point worth highlighting relates to the fragment directive behavior mentioned above. Some existing pages break when any fragment is specified at all (due to page script using the fragment). E.g. (https://www.webmd.com/pain-management/knee-pain/picture-of-the-knee). Adding any fragment to this link will cause the page to load in a broken state. The fragment directive works around this. However, a UA that doesn’t implement it and loads a link like this will see this breakage e.g. (https://www.webmd.com/pain-management/knee-pain/picture-of-the-knee#:~:text=Knee). We expect the number of pages like this is very low; webmd.com is the only one we’ve seen that breaks catastrophically like this but this is a risk as there isn’t a good way to measure it.

What's the feature detection story here? How can referrers avoid from adding such links to non-supporting UAs?

 

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: 

We’ve seen some positive sentiment from twitter users:

Positive: https://twitter.com/brucel/status/1168888603671433222

Positive: https://twitter.com/rem/status/1168864475379916802

Neutral/Informational: https://twitter.com/glenngabe/status/1164850052608774145 

Neutral/Informational: https://twitter.com/brodieseo/status/1172724843302621184

Ergonomics

The default usage of this feature is independent of other platform APIs. When the feature is activated, Chrome must search the page for the target text on page load, however this is followed by a user-visible scroll and highlight assuming the target text is found. We observed a median latency of 26 milliseconds from the time we start processing the text fragment directive until the end of the scroll.

Activation

The feature is easy to use as-is; simply append :~:text=example to the URL fragment (i.e. append #:~:text=example to a URL with no fragment) to activate the feature.

The feature would benefit from a reference implementation for determining what the optimal text directive parameters are for a given text fragment on a page. We are working on a Chrome extension that generates scroll to text links, and plan to open source this extension on https://github.com/GoogleChromeLabs to serve as a reference.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://wpt.fyi/results/scroll-to-text-fragment/scroll-to-text-fragment.html

All tests pass on the Chromium implementation when the feature is enabled (wpt expectations are set to “not run” for Chromium as the feature is disabled by default).

Entry on the feature dashboard

https://chromestatus.com/feature/4733392803332096

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/86d944c6-b29d-4a51-8dd2-c310142d0d42%40chromium.org.

[David Bokan]

Apologies, we did go over this internally with our security reviewers but I forgot to reply on the thread. The outcome was that we consider this one of several mitigations, rather than a hard security boundary. Given that this means a popup is visible, and the attacker would need to phish user gestures, and they can only search on word boundaries, and they would still need some exploit to determine a cross-origin scroll, we felt that this wasn't concerning enough to add a ton of complexity to lock down further. 

Regarding the other security restrictions, they're documented in the explainer - I just opened up a PR to add normative text into the spec for those.

Yeah, that would be great. I only found out two hours ago that the
plan of record does involve changes to the URL parser, despite that
plan being seemingly abandoned six days ago due to pushback from the
URL community. The feature definitely seems interesting, but could use
some more refinement and collaborative design work.

That was a bit miscommunication from me (sorry again). The plan to allow using multiple '#' in a URL was abandoned. The parsing of the fragment (to split it on the :~: token) needs to be specified somewhere. The URL spec seemed to make sense to me at first but I think it could be made a part of HTML by moving the spec text wholesale and making this an HTML-only concept. FWIW, Chrome's implementation doesn't make any low-level URL-parsing changes so this probably makes sense. I'm happy to continue following up on this either in https://github.com/whatwg/url/issues/445 or in a new issue in the WICG

FWIW, we've been openly and productively collaborating with a number of outside contributors from other W3C working groups and made lots of improvements based on their feedback. I'd be happy to move this into WHATWG but, as Yoav mentioned, that'll require interest from a second implementer. It's worth noting that the Edge team has been interested and experimenting with something very similar in parallel and we've been in contact with them but, given we're both Blink based now, I'm not sure if that would be grounds for moving into WHATWG.

[Chris Palmer]

(Sorry, ignore my previous message.)

Yeah, I agree that handling the new token in the fragment fits better in the HTML spec than in the URL spec.

[Nick Burris]

We want to add a window.location.fragmentDirective object to allow feature detection:

typeof(window.location.fragmentDirective) != 'undefined'

This object is empty in the initial implementation, but could be expanded to provide APIs on top of the fragment directive, for example whether we found a match (we don't want to simply expose the fragment directive text as it may contain privacy sensitive information). I recently added a section to our draft spec on feature detection; also see #19.

 

 

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: 

We’ve seen some positive sentiment from twitter users:

Positive: https://twitter.com/brucel/status/1168888603671433222

Positive: https://twitter.com/rem/status/1168864475379916802

Neutral/Informational: https://twitter.com/glenngabe/status/1164850052608774145 

Neutral/Informational: https://twitter.com/brodieseo/status/1172724843302621184

Ergonomics

The default usage of this feature is independent of other platform APIs. When the feature is activated, Chrome must search the page for the target text on page load, however this is followed by a user-visible scroll and highlight assuming the target text is found. We observed a median latency of 26 milliseconds from the time we start processing the text fragment directive until the end of the scroll.

Activation

The feature is easy to use as-is; simply append :~:text=example to the URL fragment (i.e. append #:~:text=example to a URL with no fragment) to activate the feature.

The feature would benefit from a reference implementation for determining what the optimal text directive parameters are for a given text fragment on a page. We are working on a Chrome extension that generates scroll to text links, and plan to open source this extension on https://github.com/GoogleChromeLabs to serve as a reference.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://wpt.fyi/results/scroll-to-text-fragment/scroll-to-text-fragment.html

All tests pass on the Chromium implementation when the feature is enabled (wpt expectations are set to “not run” for Chromium as the feature is disabled by default).

Entry on the feature dashboard

https://chromestatus.com/feature/4733392803332096

--
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+unsubscribe@chromium.org.

[David Bokan]

If it's helpful, I've made our security review document public. It lists the threats and mitigations we've considered and might help explain some of our rationale and decisions relating to the design.

Scroll To Text Security Issues Doc

[Yoav Weiss]

On Tue, Oct 15, 2019, 07:35 David Bokan <bo...@chromium.org> wrote:

If it's helpful, I've made our security review document public. It lists the threats and mitigations we've considered and might help explain some of our rationale and decisions relating to the design.

Scroll To Text Security Issues Doc

That's extremely helpful!! Thanks for making it public!

--

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51def0f9-4fd4-450a-b0c2-c976c398c58e%40chromium.org.

[Daniel Bratell]

Indeed, that information is valuable to anyone implementing this features.

bokan, nburris, I think the spec should be updated to include information about the feature's vulnerability to timing attacks, unless implemented with proper safeguards as you have done. I see nothing about it in the security/privacy part of the specification right now.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgOKEiMJ%3DQjOQdv1ATQ_y7YQHR5cynQCqVMF_F%3DpZyhxw%40mail.gmail.com.

[fantasai]

On 10/9/19 8:10 PM, Nick Burris wrote:
>
> Summary
>
> Scroll To Text allows URLs to link to a piece of text in a webpage rather than
> just linking to an existing element fragment. The motivating use cases are to
> enable user sharing of specific content and allow deep-linking references to
> information.

So, like, this sounds conceptually like a great feature to have for the Web.
But this

> Edge: No signals
>
> Firefox: No signals <https://github.com/mozilla/standards-positions/issues/194>
>
> Safari: No signals

makes it seem like you really haven't put much effort into figuring out where
the other browser vendors stand on the issue. Given this is an Intent to Ship,
I interpret not having figured out where the other vendors stand even at the
coarse level of “excited to have spec, plan to implement”, “supportive but not
prioritizing; will accept patches”, or “opposed to the feature in its current
state” as not really caring what they think. You have contacts into these
organizations; I am sure you could solicit such answers where there aren't any
if you thought it was necessary.

Google engineers keep asserting that, no, we really care about standardization
and moving the Web forward together with the other browser vendors. Look at
the processes we made to help us do that! But Web standardization efforts have
always tried to move forward on the basis of consensus. Meanwhile the attitude
here seems to be ”There was a template for the positions of other browsers, a
blank answer could be provided in the template, nobody reviewing it cares that
there was a blank answer, so let's just ship the thing we (Google) want.”

If this was a blank code review in your template, I imagine you would try
harder to get the reviewer's answer, and give a good explanation of your
attempts and their failure if indeed you could not solicit a response, before
asking for lgtm.

Yoav Weiss wrote:

> When it comes to venue, the current spec's processing seems to be mostly
> monkey-patching the HTML and URL specs, indicating that WHATWG is probably
> the right venue for this to graduate to. At the same time, landing features
> in WHATWG specs require multi-engine commitment, and looking at Mozilla's
> 2.5-months-old standards position issue doesn't really indicate implementer
> commitment, or anything at all. From a practical standpoint, it's clearer
> and easier for the spec to live as a standalone document rather than a
> WHATWG PR, while we're waiting for multi-engine commitment.
>
> But, that in no means preclude collaboration. The spec is in WICG, which
> was built specifically to enable multi-vendor collaboration when incubating
> new ideas. I'm sure everyone would be thrilled to have your feedback directly
> there, to make sure we get this right.

I would like to point out a couple things:

1. WICG is explicitly billing itself an incubation venue, not a
standardization venue. At the point you're planning to ship a feature, I think
that qualifies as beyond incubation, yes? So continuing work there at this
point would be inappropriate.

2. If the WHATWG rules for incorporating something are too stringent to allow
standardization in a timely manner, maybe you should consider changing them?
It's not like Google has no say in the WHATWG process. Perhaps something like
“two implementation commitments *or* implemented in one browser with other
browsers at least in favor of the feature and willing to implement it at some
point in the future even if they haven't committed to apply their own
resources yet” could be enough for inclusion.

To paraphrase Sir Tim Berners-Lee, process is a tool to help you do good work:
if your process is inhibiting you from doing said work, you should fix said
process. Allowing Google to do standardization work in an appropriate
multi-vendor standards forum, and using that process to seek positive
consensus on its proposals prior to deciding to ship, would be better than the
circumvention of the standardization processes *and spirit* being demonstrated
here, I would think.

~fantasai

[Yoav Weiss]

If you look at the linked TAG review issue, you could see that we have solicited and got opinions from various engineers working for said browser vendors. (and addressed multiple concerns raised)

However, at least when it comes to Mozilla, my understanding is that opinions of their engineers don't count for the purpose of stating support, unless expressed on their standards positions repo alongside an official commitment.

An issue was opened on that repo almost three months ago, trying to solicit their opinions and commitment. We have received zero replies on that issue.

If you have any suggestions as to what we could have better done on that front, we'd definitely take them into consideration for next time.

 

Yoav Weiss wrote:

> When it comes to venue, the current spec's processing seems to be mostly
> monkey-patching the HTML and URL specs, indicating that WHATWG is probably
> the right venue for this to graduate to. At the same time, landing features
> in WHATWG specs require multi-engine commitment, and looking at Mozilla's
> 2.5-months-old standards position issue doesn't really indicate implementer
> commitment, or anything at all. From a practical standpoint, it's clearer
> and easier for the spec to live as a standalone document rather than a
> WHATWG PR, while we're waiting for multi-engine commitment.
>
> But, that in no means preclude collaboration. The spec is in WICG, which
> was built specifically to enable multi-vendor collaboration when incubating
> new ideas. I'm sure everyone would be thrilled to have your feedback directly
> there, to make sure we get this right.

I would like to point out a couple things:

1. WICG is explicitly billing itself an incubation venue, not a
standardization venue. At the point you're planning to ship a feature, I think
that qualifies as beyond incubation, yes? So continuing work there at this
point would be inappropriate.

The WICG is indeed not a standardization venue, and once we have support from other vendors, we should definitely move the specification to one. But as can be noted reading through the Blink interoperability principles document, "being on a standards track" is not a shipping requirement for a feature.

We aren't always going to wait until Mozilla and/or Apple are officially in favor of the feature before we ship it. At the same time, one lesson we can take from this is that when other browsers haven't come to an official position at all, we should do a better job of capturing the outreach we've attempted.

 

2. If the WHATWG rules for incorporating something are too stringent to allow
standardization in a timely manner, maybe you should consider changing them?
It's not like Google has no say in the WHATWG process. Perhaps something like
“two implementation commitments *or* implemented in one browser with other
browsers at least in favor of the feature and willing to implement it at some
point in the future even if they haven't committed to apply their own
resources yet” could be enough for inclusion.

Such a rule would still not have helped in this particular case, where we have no official signal from other vendors that can qualify as "in favor".

 

To paraphrase Sir Tim Berners-Lee, process is a tool to help you do good work:
if your process is inhibiting you from doing said work, you should fix said
process. Allowing Google to do standardization work in an appropriate
multi-vendor standards forum, and using that process to seek positive
consensus on its proposals prior to deciding to ship, would be better than the
circumvention of the standardization processes *and spirit* being demonstrated
here, I would think.

I strongly reject your accusation that working in the open (for the last 9 months) and actively seeking out feedback from the web community at large and from other vendors in particular is somehow "circumventing the standardization processes and spirit"!

~fantasai

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aea912b9-01c6-e518-7abe-4478d3354348%40inkedblade.net.

[Maciej Stachowiak]

> On Oct 24, 2019, at 1:49 PM, fantasai <fantasa...@inkedblade.net> wrote:
>
> On 10/9/19 8:10 PM, Nick Burris wrote:
>> Summary
>> Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow deep-linking references to information.
>
> So, like, this sounds conceptually like a great feature to have for the Web.
> But this
>
>> Edge: No signals
>> Firefox: No signals <https://github.com/mozilla/standards-positions/issues/194>
>> Safari: No signals
>
> makes it seem like you really haven't put much effort into figuring out where the other browser vendors stand on the issue. Given this is an Intent to Ship, I interpret not having figured out where the other vendors stand even at the coarse level of “excited to have spec, plan to implement”, “supportive but not prioritizing; will accept patches”, or “opposed to the feature in its current state” as not really caring what they think. You have contacts into these organizations; I am sure you could solicit such answers where there aren't any if you thought it was necessary.
>
> Google engineers keep asserting that, no, we really care about standardization and moving the Web forward together with the other browser vendors. Look at the processes we made to help us do that! But Web standardization efforts have always tried to move forward on the basis of consensus. Meanwhile the attitude here seems to be ”There was a template for the positions of other browsers, a blank answer could be provided in the template, nobody reviewing it cares that there was a blank answer, so let's just ship the thing we (Google) want.”
>
> If this was a blank code review in your template, I imagine you would try harder to get the reviewer's answer, and give a good explanation of your attempts and their failure if indeed you could not solicit a response, before asking for lgtm.

I don’t think anyone at Apple was asked to provide a position. It’s true this spec has been out there for a while, but there’s so many specs these days that it’s hard to predict which will be up for an Intent to Ship next.

I often see links to an Intent to Ship or Intent to Implement where Safari is noted as “no public signals” or “no signals” but no one actually asked us. Sometimes I even see this stated when we clearly said somewhere (perhaps in an issue comment) that we think the feature is a bad idea, at least as proposed.

So on the whole, I don’t think Chrome engineers do as good a job as they could of actively soliciting signals. Members of the WebKit team at Apple are usually happy to provide an opinion if asked, or at least point to someone who can give an informed opinion. We also make sure to sync internally on things like this, to be able to give relatively official opinions.

It’s possible that this is a Blink process problem, and that maybe “no signals” should be accompanied by a record of the lack of signal and/or attempt to solicit one, to remind Blinkers to actively ask. Assuming that’s the intention of the signals section.

(This is not an opinion on the specific spec; it seems like a generally good feature, but the fragment directive syntax and requirement for UAs to strip it seems bound to cause interop problems with browsers that don’t implement this spec.)

>
> Yoav Weiss wrote:
>
>> When it comes to venue, the current spec's processing seems to be mostly monkey-patching the HTML and URL specs, indicating that WHATWG is probably the right venue for this to graduate to. At the same time, landing features in WHATWG specs require multi-engine commitment, and looking at Mozilla's 2.5-months-old standards position issue doesn't really indicate implementer commitment, or anything at all. From a practical standpoint, it's clearer and easier for the spec to live as a standalone document rather than a WHATWG PR, while we're waiting for multi-engine commitment.
>> But, that in no means preclude collaboration. The spec is in WICG, which was built specifically to enable multi-vendor collaboration when incubating new ideas. I'm sure everyone would be thrilled to have your feedback directly there, to make sure we get this right.
>
> I would like to point out a couple things:
>
> 1. WICG is explicitly billing itself an incubation venue, not a standardization venue. At the point you're planning to ship a feature, I think that qualifies as beyond incubation, yes? So continuing work there at this point would be inappropriate.

It’s especially concerning that WICG does not require either multiple implementation experience (like W3C WGs do) or multiple implementor support (like WHATWG does). As a result, single-implementation specifications with no track to multi-engine implementation look exactly the same as incubation projects with multi-implementor support. In addition, because WICG requires “multiple party” (but not multiple implementation) support, sometimes we end up with specs using the WICG “Community Group Draft Report” logo while in an individual’s personal repo rather than in WICG.

I think these are process problems with WICG.

(Note, I’m not commenting on whether this CG report would never have multiple implementations).

>
> 2. If the WHATWG rules for incorporating something are too stringent to allow standardization in a timely manner, maybe you should consider changing them? It's not like Google has no say in the WHATWG process. Perhaps something like “two implementation commitments *or* implemented in one browser with other browsers at least in favor of the feature and willing to implement it at some point in the future even if they haven't committed to apply their own resources yet” could be enough for inclusion.

For clarity, WHATWG rules do not require implementation commitments for a feature addition, just nonbonding “support”:
https://whatwg.org/working-mode#additions

So the situation you describe would be more than enough.

In principle WHATWG process could be changed to require a statement of support from only a single implementation. But I think that would be a change for the worse, and I’d likely oppose it if proposed.

[Manuel Rego Casasnovas]

Apart from other issues that were already pointed out on this thread,
one more comment inline.

On 09/10/2019 20:10, Nick Burris wrote:
> https://wpt.fyi/results/scroll-to-text-fragment/scroll-to-text-fragment.html
>
> All tests pass on the Chromium implementation when the feature is
> enabled (wpt expectations are set to “not run” for Chromium as the
> feature is disabled by default).

This is just 1 test with 16 cases, 5 of them passing already in Firefox.
Is this good enough? Don't we need more tests here?

My 2 cents,
Rego

[David Bokan]

On Fri, Oct 25, 2019 at 5:11 AM Daniel Bratell <brat...@gmail.com> wrote:

bokan, nburris, I think the spec should be updated to include information about the feature's vulnerability to timing attacks, unless implemented with proper safeguards as you have done. I see nothing about it in the security/privacy part of the specification right now. 

Thank you for pointing that out, it was an accidental omission when I added the

security section. I've created a PR with some text about this.

On Fri, Oct 25, 2019 at 5:49 AM fantasai <fantasa...@inkedblade.net> wrote:

> Edge: No signals
> Firefox: No signals <https://github.com/mozilla/standards-positions/issues/194>
> Safari: No signals

makes it seem like you really haven't put much effort into figuring out where
the other browser vendors stand on the issue. Given this is an Intent to Ship,
I interpret not having figured out where the other vendors stand even at the
coarse level of “excited to have spec, plan to implement”, “supportive but not
prioritizing; will accept patches”, or “opposed to the feature in its current
state” as not really caring what they think. You have contacts into these
organizations; I am sure you could solicit such answers where there aren't any
if you thought it was necessary.

It can be somewhat difficult, especially for those of us who don't actually have

many cross-vendor contacts, to get these kinds of signals. In particular, turning

private e-mail discussions with individual engineers into official and public

statements of support/opposition from the organization can be somewhat daunting

(or at least, there doesn't seem to be a standard process to follow).

That said, I can see your point and how this appears to those outside and I agree

I should have done a better job here. Why don't we take a step back and consider

this I2S temporarily suspended while I take another stab at this and we work on

incorporating some of the spec feedback above. 

I'd like to make a related process point as someone who isn't steeped in
the standards process: it's often difficult to get meaningful engagement from
other vendors until we're ready to ship. It's understandable; everyone's busy
with their own work to review all the early-stage proposals floating around. I

reached out to engineers from other vendors early and filed bugs in WHATWG

but it's hard to get someone to meaningfully engage.

The kind of feedback we received here would have been wonderful to have

several weeks ago. What should we be doing to get to this step earlier? I don't

want to be constantly spamming individuals and lists as I don't think that'll

scale, but I think it'd be useful to have some standard way to signal "we're

serious about this proposal, and it's baked enough at this point that we need

other implementers to review it". I was under the impression TAG reviews

serve at least part of this purpose.

[Anne van Kesteren]

On Fri, Oct 25, 2019 at 10:59 AM 'David Bokan' via blink-dev
<blin...@chromium.org> wrote:
> The kind of feedback we received here would have been wonderful to have
> several weeks ago. What should we be doing to get to this step earlier?

For WHATWG, PRs against standards tend to help as they require review,
implementer commitments, and adequate test coverage. And editors will
provide guidance for all of those.

[David Bokan]

On Fri, Oct 25, 2019 at 5:40 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

> All tests pass on the Chromium implementation when the feature is
> enabled (wpt expectations are set to “not run” for Chromium as the
> feature is disabled by default).

This is just 1 test with 16 cases, 5 of them passing already in Firefox.

Each case is testing an individual piece of functionality, I don't think it makes much difference whether they're in separate files vs file with multiple cases.

The passing tests in Firefox and Edge are those that are ensuring negative behavior (i.e. don't scroll into view if the context doesn't match). A non-implementing UA will pass those, they're mostly interesting if the positive-behavior passes as well.

Is this good enough? Don't we need more tests here?

We can and will continue to improve these though I think these cases cover the broad functionality and so serve as a good starting point. I think we can work on adding some edge-cases.

[David Bokan]

On Friday, October 25, 2019 at 6:13:18 PM UTC+9, Anne van Kesteren wrote:

For WHATWG, PRs against standards tend to help as they require review,
implementer commitments, and adequate test coverage. And editors will
provide guidance for all of those.

Thanks, I'll keep that in mind next time - I never would have thought of this since I'd assume a PR against WHATWG be closer to the final steps.

[Yoav Weiss]

On Fri, Oct 25, 2019 at 4:04 AM 'Maciej Stachowiak' via blink-dev <blin...@chromium.org> wrote:

> On Oct 24, 2019, at 1:49 PM, fantasai <fantasa...@inkedblade.net> wrote:
>
> On 10/9/19 8:10 PM, Nick Burris wrote:
>> Summary
>> Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow deep-linking references to information.
>
> So, like, this sounds conceptually like a great feature to have for the Web.
> But this
>
>> Edge: No signals
>> Firefox: No signals <https://github.com/mozilla/standards-positions/issues/194>
>> Safari: No signals
>
> makes it seem like you really haven't put much effort into figuring out where the other browser vendors stand on the issue. Given this is an Intent to Ship, I interpret not having figured out where the other vendors stand even at the coarse level of “excited to have spec, plan to implement”, “supportive but not prioritizing; will accept patches”, or “opposed to the feature in its current state” as not really caring what they think. You have contacts into these organizations; I am sure you could solicit such answers where there aren't any if you thought it was necessary.
>
> Google engineers keep asserting that, no, we really care about standardization and moving the Web forward together with the other browser vendors. Look at the processes we made to help us do that! But Web standardization efforts have always tried to move forward on the basis of consensus. Meanwhile the attitude here seems to be ”There was a template for the positions of other browsers, a blank answer could be provided in the template, nobody reviewing it cares that there was a blank answer, so let's just ship the thing we (Google) want.”
>
> If this was a blank code review in your template, I imagine you would try harder to get the reviewer's answer, and give a good explanation of your attempts and their failure if indeed you could not solicit a response, before asking for lgtm.

I don’t think anyone at Apple was asked to provide a position. It’s true this spec has been out there for a while, but there’s so many specs these days that it’s hard to predict which will be up for an Intent to Ship next.

I often see links to an Intent to Ship or Intent to Implement where Safari is noted as “no public signals” or “no signals” but no one actually asked us. Sometimes I even see this stated when we clearly said somewhere (perhaps in an issue comment) that we think the feature is a bad idea, at least as proposed.

So on the whole, I don’t think Chrome engineers do as good a job as they could of actively soliciting signals. Members of the WebKit team at Apple are usually happy to provide an opinion if asked, or at least point to someone who can give an informed opinion. We also make sure to sync internally on things like this, to be able to give relatively official opinions.

What would be the best way to solicit such feedback in a scalable way? No all engineers sending intents personally know someone on the WebKit team to ask for their opinion.

Would opening an issue on WebKit's bugzilla be the right way to get such an opinion?

 

It’s possible that this is a Blink process problem, and that maybe “no signals” should be accompanied by a record of the lack of signal and/or attempt to solicit one, to remind Blinkers to actively ask. Assuming that’s the intention of the signals section.

(This is not an opinion on the specific spec; it seems like a generally good feature, but the fragment directive syntax and requirement for UAs to strip it seems bound to cause interop problems with browsers that don’t implement this spec.)


>
> Yoav Weiss wrote:
>
>> When it comes to venue, the current spec's processing seems to be mostly monkey-patching the HTML and URL specs, indicating that WHATWG is probably the right venue for this to graduate to. At the same time, landing features in WHATWG specs require multi-engine commitment, and looking at Mozilla's 2.5-months-old standards position issue doesn't really indicate implementer commitment, or anything at all. From a practical standpoint, it's clearer and easier for the spec to live as a standalone document rather than a WHATWG PR, while we're waiting for multi-engine commitment.
>> But, that in no means preclude collaboration. The spec is in WICG, which was built specifically to enable multi-vendor collaboration when incubating new ideas. I'm sure everyone would be thrilled to have your feedback directly there, to make sure we get this right.
>
> I would like to point out a couple things:
>
> 1. WICG is explicitly billing itself an incubation venue, not a standardization venue. At the point you're planning to ship a feature, I think that qualifies as beyond incubation, yes? So continuing work there at this point would be inappropriate.

It’s especially concerning that WICG does not require either multiple implementation experience (like W3C WGs do) or multiple implementor support (like WHATWG does). As a result, single-implementation specifications with no track to multi-engine implementation look exactly the same as incubation projects with multi-implementor support. In addition, because WICG requires “multiple party” (but not multiple implementation) support, sometimes we end up with specs using the WICG “Community Group Draft Report” logo while in an individual’s personal repo rather than in WICG.

 

There's ongoing discussion on making the CG templates look less authoritative. Once that lands, it will hopefully make it clear that specifications on WICG are in no way a standard.

Requiring multiple implementations for an incubation would defy the purpose of incubations. The "barrier for entry" to getting a WICG repo is proving that you have a use-case that's interesting to solve, not that you have an well-thought-out solution. That comes later, as part of the incubation work.

And even incubations that are being worked on by multiple implementers should not look authoritative at first, as presumably they are still in flux. At the point where a multi-implementer incubation is stable, it should probably graduate to the appropriate WG.

Regarding personal specifications with a "CG draft report" logo, that sounds like a bug. Could you point me to such examples?

Maybe we can improve the tooling to make sure that doesn't happen.

I think these are process problems with WICG.

(Note, I’m not commenting on whether this CG report would never have multiple implementations).

>
> 2. If the WHATWG rules for incorporating something are too stringent to allow standardization in a timely manner, maybe you should consider changing them? It's not like Google has no say in the WHATWG process. Perhaps something like “two implementation commitments *or* implemented in one browser with other browsers at least in favor of the feature and willing to implement it at some point in the future even if they haven't committed to apply their own resources yet” could be enough for inclusion.

For clarity, WHATWG rules do not require implementation commitments for a feature addition, just nonbonding “support”:
https://whatwg.org/working-mode#additions

So the situation you describe would be more than enough.

In principle WHATWG process could be changed to require a statement of support from only a single implementation. But I think that would be a change for the worse, and I’d likely oppose it if proposed.

>
> To paraphrase Sir Tim Berners-Lee, process is a tool to help you do good work: if your process is inhibiting you from doing said work, you should fix said process. Allowing Google to do standardization work in an appropriate multi-vendor standards forum, and using that process to seek positive consensus on its proposals prior to deciding to ship, would be better than the circumvention of the standardization processes *and spirit* being demonstrated here, I would think.
>
> ~fantasai
>

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/989C4174-E645-4547-AE07-F52AF1A66F6D%40apple.com.

[Frédéric Wang]

On 25/10/2019 11:29, David Bokan wrote:

On Fri, Oct 25, 2019 at 5:40 PM Manuel Rego Casasnovas <re...@igalia.com> wrote:

> All tests pass on the Chromium implementation when the feature is
> enabled (wpt expectations are set to “not run” for Chromium as the
> feature is disabled by default).

This is just 1 test with 16 cases, 5 of them passing already in Firefox.

Each case is testing an individual piece of functionality, I don't think it makes much difference whether they're in separate files vs file with multiple cases.

The passing tests in Firefox and Edge are those that are ensuring negative behavior (i.e. don't scroll into view if the context doesn't match). A non-implementing UA will pass those, they're mostly interesting if the positive-behavior passes as well.

nit: Actually it's really 15 if we ignore the harness status https://github.com/web-platform-tests/wpt.fyi/issues/62 :-)

Anyway, I agree that what matters are subcases and this kind of passing tests for browsers without support is expected.

However, I think rego's point is that 15 test cases is probably still a small amount compared to the specification size. Do you agree? (see more below)

Is this good enough? Don't we need more tests here?

We can and will continue to improve these though I think these cases cover the broad functionality and so serve as a good starting point. I think we can work on adding some edge-cases.

Improving the tests sounds good, especially to help this to be reviewed and implemented by other browser vendors. Some random comments after quickly skimming over the spec and tests:

- Do you know how much of the spec is covered by tests? I can't find the case "#:~:text=textStart,-suffix" for example and I assume 0, 1 or multiple matches should be tested in each case.

- Should %c be tested for character other that space? For example searching strings involving non-ascii and non-BMP characters seems an important use case for that feature? Or character that is part of the syntax such as "," or "-", so that we are sure they can be searched too by escaping them.

- What would be the default scroll alignment/behavior parameters when the scroll into view is performed? (as a comparison Element.scrollIntoView has block="start", inline="nearest", and behavior="auto")

- Is the CSS scroll-behavior property taken into account to perform smooth scrolling? Which element the CSS property would be read from? (I guess document.body in quirks mode? root element otherwise?)

- The test relies on BroadcastChannel which is not implemented in all browsers :-( Is it a requirement for the feature? If not, would it possible not to rely on BroadcastChannel for testing this feature?

- Can test_cases have a human-readable description, used in addition to the fragment in the test description? That would make things easier to understand and to better see test coverage.

- Similarly, <link rel="help"> tag would help to identify the relevant sections in the spec.

- Would it be possible to use template_literals? I personally find it easier to read than string concatenation.

Hope that helps,

-- 
Frédéric Wang

[David Bokan]

On Fri, Oct 25, 2019 at 11:44 PM Frédéric Wang <fw...@igalia.com> wrote:

However, I think rego's point is that 15 test cases is probably still a small amount compared to the specification size. Do you agree? (see more below)

 Yes, point taken. The tests were ported from Blink's web tests so they make assumptions (e.g. if multiple matches work in one case they'll work in others) but I agree for WPT it makes sense (and shouldn't be hard) to make fewer assumptions like this.

- The test relies on BroadcastChannel which is not implemented in all browsers :-( Is it a requirement for the feature? If not, would it possible not to rely on BroadcastChannel for testing this feature?

Thanks, I didn't know it's not implemented across all browsers. nburris@ might know better what the requirement is. One of the tricky factors here the security restrictions make it difficult to test programmatically (e.g. navigating the top-level window), I suspect that may be related to working around that.

Hope that helps,

Thank you! All these points are all very helpful!

[Nick Burris]

Yes, using BroadcastChannel is not an ideal solution but was the only solution I could find that works with the security restrictions, which are meant to specifically guard against a window being able to programmatically perform a scroll-to-text navigation and observe the result. Thanks for the feedback on the web platform tests! I'll expand on these cases and explore alternatives to using BroadcastChannel.

[Chris Wilson]

On Thu, Oct 24, 2019 at 6:35 PM Maciej Stachowiak <m...@apple.com> wrote:

So on the whole, I don’t think Chrome engineers do as good a job as they could of actively soliciting signals. Members of the WebKit team at Apple are usually happy to provide an opinion if asked, or at least point to someone who can give an informed opinion. We also make sure to sync internally on things like this, to be able to give relatively official opinions.

Seconding Yoav's question - what would be the best way for us to write into the Blink process to do this?  I think "quote any member of the Webkit team you can get to make a statement in public" has multiple failure modes, so I want to make sure we're pointing to (as you put it) relatively official opinions.

 

It’s possible that this is a Blink process problem, and that maybe “no signals” should be accompanied by a record of the lack of signal and/or attempt to solicit one, to remind Blinkers to actively ask. Assuming that’s the intention of the signals section.

We just had a conversation on precisely this topic, and I expressed the concern that embedding a record of our attempts to solicit opinions might also be taken as shaming, which isn't our intent either.

I think I'm hearing:

1. Blink needs to be more explicit about asking for signals.  It would be good to have those as repeatable channels at the various other platform implementation organizations.
2. Blink needs to be more intentional about notifying when features are tracking to land, to put appropriate pressure on getting those signals (positive or negative). 

It’s especially concerning that WICG does not require either multiple implementation experience (like W3C WGs do) or multiple implementor support (like WHATWG does). As a result, single-implementation specifications with no track to multi-engine implementation look exactly the same as incubation projects with multi-implementor support.

I have to disagree with your concern, at least as an entry point.  The whole point of starting incubations is that they may not have multiple implementers interested in prototyping -but an incubation is not the end point.  Certainly, as specs graduate from WICG incubations into an appropriate WG (or the WHATWG) - their exit point from incubation - I would expect multiple implementers to support and to be working on implementations.

"No track to multi-engine implementation" can be only a matter of time and priority, also.  I'm not against declaring more directly/publicly what implementers are "supporting" (in quotes because there's not a precise definition here) any given incubation, if we can come up with a way to do so; would that help?

sometimes we end up with specs using the WICG “Community Group Draft Report” logo while in an individual’s personal repo rather than in WICG.

As Yoav said, I think this is a bug - much like putting the W3C editor draft logo on a spec in a personal repo.  Misleading, at best.

 

I think these are process problems with WICG.

I am strongly against making a higher bar than "multiple independent parties are interested" in order to start an incubation - because a bar such as "must have multiple implementers supporting" would mean the vast majority of incubations would be done effectively outside the community, in personal or corporate repos, with no early contribution IP commitment or outside engagement.

That said, I'm happy to talk about process improvements we can do in the WICG - for example, I proposed above that we enable implementers to tag their support in WICG repos.  Would that help?  Is there something else we should change?

-Chris

(WICG co-chair, among other roles)

[Ryosuke Niwa]

> On Oct 25, 2019, at 10:34 AM, Chris Wilson <cwi...@google.com> wrote:
>
> On Thu, Oct 24, 2019 at 6:35 PM Maciej Stachowiak <m...@apple.com> wrote:
>
>> So on the whole, I don’t think Chrome engineers do as good a job as they
>> could of actively soliciting signals. Members of the WebKit team at Apple
>> are usually happy to provide an opinion if asked, or at least point to
>> someone who can give an informed opinion. We also make sure to sync
>> internally on things like this, to be able to give relatively official
>> opinions.
>>
>
> Seconding Yoav's question - what would be the best way for us to write into
> the Blink process to do this? I think "quote any member of the Webkit team
> you can get to make a statement in public" has multiple failure modes, so I
> want to make sure we're pointing to (as you put it) relatively official
> opinions.
>
>
>> It’s possible that this is a Blink process problem, and that maybe “no
>> signals” should be accompanied by a record of the lack of signal and/or
>> attempt to solicit one, to remind Blinkers to actively ask. Assuming that’s
>> the intention of the signals section.
>>
>
> We just had a conversation on precisely this topic, and I expressed the
> concern that embedding a record of our attempts to solicit opinions might
> also be taken as shaming, which isn't our intent either.
>
> I think I'm hearing:
>

> 1. Blink needs to be more explicit about asking for signals. It would

> be good to have those as repeatable channels at the various other platform
> implementation organizations.

> 2. Blink needs to be more intentional about notifying when features are

> tracking to land, to put appropriate pressure on getting those signals
> (positive or negative).
>
> It’s especially concerning that WICG does not require either multiple
>> implementation experience (like W3C WGs do) or multiple implementor support
>> (like WHATWG does). As a result, single-implementation specifications with
>> no track to multi-engine implementation look exactly the same as incubation
>> projects with multi-implementor support.
>
> I have to disagree with your concern, at least as an entry point. The
> whole point of starting incubations is that they may not have multiple
> implementers interested in prototyping -but an incubation is not the end
> point. Certainly, as specs graduate from WICG incubations into an
> appropriate WG (or the WHATWG) - their exit point from incubation - I would
> expect multiple implementers to support and to be working on
> implementations.

What’s lacking here is the clear indication between the two. For example, how does one supposed to figure out this intent to ship email was based on a feature not being reviewed by Mozilla or Apple? There should have been a clear indication that this is a single vendor feature in the spec itself.

I get that there needs to be some avenue to share ideas. But that avenue can’t be simultaneously something browser vendors use to claim that it’s a well accepted standard API.

[Maciej Stachowiak]

On Oct 25, 2019, at 6:08 AM, Yoav Weiss <yo...@yoav.ws> wrote:

On Fri, Oct 25, 2019 at 4:04 AM 'Maciej Stachowiak' via blink-dev <blin...@chromium.org> wrote:

> On Oct 24, 2019, at 1:49 PM, fantasai <fantasa...@inkedblade.net> wrote:
> 
> On 10/9/19 8:10 PM, Nick Burris wrote:
>> Summary
>> Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow deep-linking references to information.
> 
> So, like, this sounds conceptually like a great feature to have for the Web.
> But this
> 
>> Edge: No signals
>> Firefox: No signals <https://github.com/mozilla/standards-positions/issues/194>
>> Safari: No signals
> 
> makes it seem like you really haven't put much effort into figuring out where the other browser vendors stand on the issue. Given this is an Intent to Ship, I interpret not having figured out where the other vendors stand even at the coarse level of “excited to have spec, plan to implement”, “supportive but not prioritizing; will accept patches”, or “opposed to the feature in its current state” as not really caring what they think. You have contacts into these organizations; I am sure you could solicit such answers where there aren't any if you thought it was necessary.
> 
> Google engineers keep asserting that, no, we really care about standardization and moving the Web forward together with the other browser vendors. Look at the processes we made to help us do that! But Web standardization efforts have always tried to move forward on the basis of consensus. Meanwhile the attitude here seems to be ”There was a template for the positions of other browsers, a blank answer could be provided in the template, nobody reviewing it cares that there was a blank answer, so let's just ship the thing we (Google) want.”
> 
> If this was a blank code review in your template, I imagine you would try harder to get the reviewer's answer, and give a good explanation of your attempts and their failure if indeed you could not solicit a response, before asking for lgtm.

I don’t think anyone at Apple was asked to provide a position. It’s true this spec has been out there for a while, but there’s so many specs these days that it’s hard to predict which will be up for an Intent to Ship next.

I often see links to an Intent to Ship or Intent to Implement where Safari is noted as “no public signals” or “no signals” but no one actually asked us. Sometimes I even see this stated when we clearly said somewhere (perhaps in an issue comment) that we think the feature is a bad idea, at least as proposed.

So on the whole, I don’t think Chrome engineers do as good a job as they could of actively soliciting signals. Members of the WebKit team at Apple are usually happy to provide an opinion if asked, or at least point to someone who can give an informed opinion. We also make sure to sync internally on things like this, to be able to give relatively official opinions.

What would be the best way to solicit such feedback in a scalable way? No all engineers sending intents personally know someone on the WebKit team to ask for their opinion.

Would opening an issue on WebKit's bugzilla be the right way to get such an opinion?

Ping one or more relevant people on a GitHub issue, or email webki...@webkit.org. Our general way of providing public feedback is to comment on an issue or file a new issue, which is why pinging on GitHub is convenient. I’ll privately send a list of more specific contacts once I confirm with people that they are ok with being pinged for feedback on GitHub.

[Frédéric Wang]

On 25/10/2019 17:56, 'David Bokan' via blink-dev wrote:

On Fri, Oct 25, 2019 at 11:44 PM Frédéric Wang <fw...@igalia.com> wrote:

However, I think rego's point is that 15 test cases is probably still a small amount compared to the specification size. Do you agree? (see more below)

 Yes, point taken. The tests were ported from Blink's web tests so they make assumptions (e.g. if multiple matches work in one case they'll work in others) but I agree for WPT it makes sense (and shouldn't be hard) to make fewer assumptions like this.

One can even be picky and ask tests for repeated content, content in display none, generated content, horizontal scroll, shadow DOM, etc. However, this may be avoided if you rely on an existing well-specified and well-tested web API. I checked again your spec, and the key part seems to be

https://wicg.github.io/ScrollToTextFragment/#navigating-to-text-fragment

which defers to the HTML5 spec in order to

navigate to a fragment https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-fragid which performs

traverse the history https://html.spec.whatwg.org/multipage/browsing-the-web.html#traverse-the-history

scroll to fragment https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier

and finally defers to the CSSOMView specification. In particular this answers my previous question regarding behavior/alignment: behavior set to "auto", block set to "start", and inline set to "nearest"

HOWEVER, this is only defined for scrolling an Element into view while your "Find a target text" function returns a Range. Unless I'm missing something, it seems to me that the specification should indicate how to scroll to a Range. Or rather, this should be defined in the CSSOMView specification...

The specification also mentions a UA-defined indication of the match (which is a potential non-interoperable aspect):

https://wicg.github.io/ScrollToTextFragment/#indicating-the-text-match

So I imagine what you are thinking is something similar to the "find text & highlight" feature. There are JS APIs like window.find or document.execCommand("FindString", ...) to try to expose that but AFAIK these are non-standard.

Edit: OK, I just found https://github.com/mozilla/standards-positions/issues/194#issuecomment-546254785 so I basically agree with Anne regarding defining/clarifying the window.find and highlight APIs.

- The test relies on BroadcastChannel which is not implemented in all browsers :-( Is it a requirement for the feature? If not, would it possible not to rely on BroadcastChannel for testing this feature?

Thanks, I didn't know it's not implemented across all browsers. nburris@ might know better what the requirement is. One of the tricky factors here the security restrictions make it difficult to test programmatically (e.g. navigating the top-level window), I suspect that may be related to working around that.

What about MessageChannel? I think this has better interoperability.

-- 
Frédéric Wang

[Yoav Weiss]

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 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.
• 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.

Beyond that, and separate from the shipping discussion, seems like once we'd have stated support from Mozilla or Apple, we'd be able to integrate this spec's processing directly in the HTML spec.

Nick/David - can you confirm that this is the case? 

[Nick Burris]

On Wednesday, October 30, 2019 at 10:52:50 AM UTC-4, 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 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.

Agreed - just want to note that David opened #64 to work out exactly how we should address this in the spec.

• 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.
• 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.

I'm working on a patch expanding our WPTs, and I'll see if using MessageChannel is feasible so we can have better interoperability here. Agreed, if we can specifically note important missing test cases I'll ensure those are added.

 

Beyond that, and separate from the shipping discussion, seems like once we'd have stated support from Mozilla or Apple, we'd be able to integrate this spec's processing directly in the HTML spec.

Nick/David - can you confirm that this is the case? 

 Confirmed! We've structured the WICG draft spec in sections that append to various HTML spec sections, so we are ready to integrate into the HTML spec once we have support (and address the noted issues).

Thanks all for the feedback!

Nick

[Frédéric Wang]

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 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.
• 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
    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.

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.

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

[Nick Burris]

Thanks so much for the detailed feedback! Here's a specific list of blockers, with some comments inline.

Specification issues

• #64 - Prevent invocation from popup
• #66 - Clarify how scroll to fragment is performed

Web platform test cases

• Security restrictions
• Setting window.location.fragmentDirective has no effect
• All combinations of optional parameters in text directive
• Matching TextMatchChars and PercentEncodedChars (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 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, I believe the security and privacy 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 and spec).

 

    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 seems like a viable option.

[Frédéric Wang]

On 31/10/2019 15:17, Frédéric Wang wrote:
>
> (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).
>

... 

>
> 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.
>

Nick and David clarified this in
https://github.com/WICG/ScrollToTextFragment/pull/67 (thanks!). As I
said in
https://github.com/WICG/ScrollToTextFragment/issues/66#issuecomment-550184375
the behavior now seems well-defined to me. However, that also means more
WPT tests in (3) are probably needed to verify the new text.

--
Frédéric Wang

[Nick Burris]

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! Note that we actually do have feature detectability specified implemented per my reply. My apologies this was not mentioned in the initial intent to ship email, it developed a few emails down the line.

Thanks,

Nick

[Yoav Weiss]

LGTM1

--
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+...@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.

[Chris Harrelson]

LGTM2

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.

[Daniel Bratell]

LGTM3

/Daniel

LGTM2

LGTM1

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.

--
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.

[sligh...@chromium.org]

LGTM4

[Thomas Steiner]

I just wanted to take a short moment to _thank_ everyone for making this happen! It's a web dream come true for me, and I guess many others; and I'm sure my muscle memory will be typing #:~:text= blindly soon. The feature works like a charm, and if you want, help me signal boost the brilliant news: https://twitter.com/tomayac/status/1205484308808568834.

[kai.kil...@waitrose.co.uk]

Will these new URL parameters be indexed by Google?

On Wednesday, 9 October 2019 19:10:24 UTC+1, Nick Burris wrote:

Contact emails

nbu...@chromium.org, bo...@chromium.org, bmcq...@chromium.org

Explainer

https://github.com/WICG/ScrollToTextFragment

Spec

WICG draft spec: https://wicg.github.io/ScrollToTextFragment/

TAG review: https://github.com/w3ctag/design-reviews/issues/392

Summary

Scroll To Text allows URLs to link to a piece of text in a webpage rather than just linking to an existing element fragment. The motivating use cases are to enable user sharing of specific content and allow deep-linking references to information.

Link to “Intent to Implement” blink-dev discussion

Intent to implement: https://groups.google.com/a/chromium.org/d/msg/blink-dev/aKI6doxffgQ/7dzrVvo4CAAJ

Intent to experiment: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/NySZyk6UMEs

Link to Origin Trial feedback summary

We requested feedback in the form of Github issues: https://github.com/WICG/ScrollToTextFragment/issues

We did not get specific feedback from origins other than Google Search, who used the origin trial to link featured snippets to the text fragment in the page that they are quoting. Google Search provided the following feedback:

“We experimented with Scroll To Text on Featured Snippets on Google Search, where it scrolls to and highlights the same passage on the source page upon opening. We see improvements in the search experience as a result of this feature. By allowing users to jump to the content that is most relevant to their queries, we observe that users consume content on the source page more effectively. Additionally, users end up consuming content from a wider range of search results. There are already two other similar launches within Google Search on small fraction of traffic. This feature will help greatly expand the coverage.”

This feedback provides a strong signal that the feature improves user engagement and helps surface information on the web.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

With the feature enabled (in latest canary with --enable-blink-features=TextFragmentIdentifiers)

https://en.wikipedia.org/wiki/Cat#Characteristics:~:text=Claws-,Like%20almost,the%20Felidae%2C,-cats

Risks

Interoperability and Compatibility   

There is some small compatibility risk due to the fragment directive behavior. This was added to minimize compatibility risk on pages that use the fragment for state. Because we now strip the section of the fragment after the delimiter, links that contain that delimiter :~: will be mutated. We’ve analyzed the Google search crawler’s database of “seen links” in the last 5 years and didn’t get any hits. We’ve also added Blink UseCounters to track how often we see :~: in the URL fragment unrelated to this feature without any hits yet (will get stable data with M78). Biggest risk here is corporate intranets where we have little visibility.

The usual interop risk of other browsers not implementing this feature applies. However, the risk should be low since links using this syntax will be interpreted as a regular fragment in UAs not implementing it; the page will still load but without intended scrolling/highlighting. This seems like a low-severity fallback with users unlikely to even notice. Similar rationale applies in the event we’d need to unship this feature.

One point worth highlighting relates to the fragment directive behavior mentioned above. Some existing pages break when any fragment is specified at all (due to page script using the fragment). E.g. (https://www.webmd.com/pain-management/knee-pain/picture-of-the-knee). Adding any fragment to this link will cause the page to load in a broken state. The fragment directive works around this. However, a UA that doesn’t implement it and loads a link like this will see this breakage e.g. (https://www.webmd.com/pain-management/knee-pain/picture-of-the-knee#:~:text=Knee). We expect the number of pages like this is very low; webmd.com is the only one we’ve seen that breaks catastrophically like this but this is a risk as there isn’t a good way to measure it.

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: 

We’ve seen some positive sentiment from twitter users:

Positive: https://twitter.com/brucel/status/1168888603671433222

Positive: https://twitter.com/rem/status/1168864475379916802

Neutral/Informational: https://twitter.com/glenngabe/status/1164850052608774145 

Neutral/Informational: https://twitter.com/brodieseo/status/1172724843302621184

Ergonomics

The default usage of this feature is independent of other platform APIs. When the feature is activated, Chrome must search the page for the target text on page load, however this is followed by a user-visible scroll and highlight assuming the target text is found. We observed a median latency of 26 milliseconds from the time we start processing the text fragment directive until the end of the scroll.

Activation

The feature is easy to use as-is; simply append :~:text=example to the URL fragment (i.e. append #:~:text=example to a URL with no fragment) to activate the feature.

The feature would benefit from a reference implementation for determining what the optimal text directive parameters are for a given text fragment on a page. We are working on a Chrome extension that generates scroll to text links, and plan to open source this extension on https://github.com/GoogleChromeLabs to serve as a reference.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://wpt.fyi/results/scroll-to-text-fragment/scroll-to-text-fragment.html

All tests pass on the Chromium implementation when the feature is enabled (wpt expectations are set to “not run” for Chromium as the feature is disabled by default).

Entry on the feature dashboard

https://chromestatus.com/feature/4733392803332096

**********************************************************************
This email is confidential and may contain copyright material of the John Lewis Partnership.
If you are not the intended recipient, please notify us immediately and delete all copies of this message.
(Please note that it is your responsibility to scan this message for viruses). Email to and from the
John Lewis Partnership is automatically monitored for operational and lawful business reasons.
**********************************************************************

John Lewis plc
Registered in England 233462
Registered office 171 Victoria Street London SW1E 5NN

Websites: https://www.johnlewis.com
http://www.waitrose.com
https://www.johnlewisfinance.com
http://www.johnlewispartnership.co.uk

**********************************************************************

[bo...@google.com]

I'm not sure what the behavior of Google Search or other search engines would be. Without any specific changes though I would imagine they'll treat these exactly like they do fragments today.

[Charles Surett]

In chrome 84 is there now no way to disable this?

[David Bokan]

The chrome://flag for this expired in M84 - these are meant to be for experimental purposes and are never intended to be indefinite so its removal is intentional.

Page *authors* can opt their pages out of this behavior using the ForceLoadAtTop policy (1047900) which is currently being origin trialed.

The highlight can be dismissed with a tap/click anywhere; based on similar feedback, we've also made it so that it also disappears when the user scrolls starting in M85.

We don't have any plans right now to have this be user configurable - Chrome in general avoids configuration options in most cases. We will continue to iterate on the design to make it work well for the majority of users though so suggestions on improvements are welcome.

[adam.se...@gmail.com]

How can this feature be disabled? I find it to be very distracting.

[Adam Semenenko]

Hi Charles - yes this can be disabled with policies. 

MacOS, run this in terminal and restart Chrome: defaults write com.google.Chrome ScrollToTextFragmentEnabled -bool false

Windows: Edit the registry (I haven't done this yet) https://support.google.com/chrome/a/answer/9131254?hl=en

I found this solution here: https://www.reddit.com/r/chrome/comments/hucpkh/can_scroll_to_text_fragment_be_disabled/

[Thomas Steiner]

FYI: I have amended the disabling info to the article. Find it here: https://web.dev/text-fragments/#disabling-text-fragments. 

[Javran Cheng]

Yes this feature can be disabled through enterprise policy, but I'd say this is more of a hack than a solution: individual users have to have admin acl (or something equivalent) to disable this setting, for linux, it's /etc/opt/chrome or /etc/chromium, and I don't think there's an easy way to disable this feature on android since 84.

This feature might be useful to some users, but I find it disrespectful as I've never ever wanted my browser or search engine to tell me where to look at, and I can't help but to think that this feature is forced upon users by making the option to disable it even more inaccessible.

Also, if this is an experiment, is there any statistic on how many user liked or disliked this feature to justify moving forward? Yes, there is https://github.com/WICG/scroll-to-text-fragment/issues, but it sounds to me like an assumption is already made that every user wants this feature and it's just a matter of behaviour-related details and the only one asking how to disable it is closed as "out of scope" (https://github.com/WICG/scroll-to-text-fragment/issues/122).

And I don't think flag expiry holds much water for speed and complexity concerns - is having an option in chrome://flags somewhat less efficient or more complex than reading enterprise policy, which has to be done in an OS-dependent way?

[Grant Wang]

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 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

[Guokai Han]

I also use this feature as a workaround to scroll to "chrome://extensions/shortcuts#:~:text=MyExtension" for a feature request.

[Terence Eden]

Thanks Grant, that's really interesting. Please can you publish the raw data behind these findings?  For example the results of user surveys, data from A/B tests, etc.

It might also be helpful to understand where users haven't found this helpful.

Thanks

Terence

[Grant Wang]

It's unlikely that we'll be able to share any of the raw data around the application in Google Search, as that's internal and proprietary.

There are indeed cases where users haven't found the use of Scroll To Text Fragment urls in Google Search to be helpful.  In particular, users will often copy and paste urls to share them, and Scroll To Text Fragment urls tend to be long.  Additionally, even if the highlighted text was useful to them for their search, it may not be useful for people they share with.

Cheers,

Grant

[Terence Eden]

Hi Grant,

Would you perhaps be able to share detailed results of the experiment?  Specifically, whether it met the usability goals stated in https://github.com/WICG/scroll-to-text-fragment#usability-goals

It isn't that I don't trust you. But, at the moment, you're asking the web community to accept Google's word that the results were great without providing any evidence. I'm not sure that new web standards should be developed that way.

Thanks

Terence

[Yoav Weiss]

Hey Terence!

On Thu, Apr 29, 2021 at 5:39 PM Terence Eden <terenc...@gmail.com> wrote:

Hi Grant,

Would you perhaps be able to share detailed results of the experiment?  Specifically, whether it met the usability goals stated in https://github.com/WICG/scroll-to-text-fragment#usability-goals

It isn't that I don't trust you. But, at the moment, you're asking the web community to accept Google's word that the results were great without providing any evidence. I'm not sure that new web standards should be developed that way.

I don't think that Grant is asking the web community for anything. He's simply providing results from an experiment he ran with this feature.

If he can provide more details, that would be great! At the same time, I don't think he owes us anything on that front.

If you distrusts his report, you can always run a similar experiment/UX-research with your users and, if possible, publish a more detailed report.

To unsubscribe from this group and stop receiving emails from it, 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/41b096a4-d48f-4b14-995b-dfd60c364bfdn%40chromium.org.

[David Bokan]

Not Grant so this wouldn't be specific to Search, but I can try to add some details around the usability goals

Specifically, whether it met the usability goals stated in https://github.com/WICG/scroll-to-text-fragment#usability-goals

The usability goals there are specific to abilities the feature provides which we can evaluate based on the syntax/functionality rather than user data (spoiler: the feature meets all these goals).

However, I think you might mean how often the use cases are encountered/needed in practice (and how well the feature works in those cases)? I can share some related data based on our UMA that may be helpful (can't share absolute numbers though). If you have more specific questions I can try and find the data if we have it.

A small disclaimer: since search drives so much traffic these stats are biased towards search use cases and the algorithm that Google/Bing uses to generate text-fragments. We're seeing about 3-5% of text-fragment links visited are referred by a non-well-known search engine.

multiple, non-contiguous passages (i.e. specifying multiple highlights): 

About 78% of text-fragments have just one selector

About 20% have 2 selectors

The rest have 3 or more

 

The user may wish to specify text that spans multiple paragraphs, list items, table entries, and other structures.

This is satisfied by allowing range matches which can cross DOM boundaries like <li> and <td> and <p>. Some stats

About 6% of text fragments include text in a table cell

About 7% of text fragment include text in a list item

About 29% or range-based text-fragments include text that crosses block boundaries (i.e. the start and end are in different block-level elements)

The text the user wishes to target may not be unique on the page

About 2.5% of text fragments are ambiguous (i.e. if we continue searching, we find a second match.). Note however, this isn't ambiguous targeted text, so if "foo" appears twice on a page but only in one instance is followed by "bar", a text-fragment "foo,-bar" (specifying a suffix "bar") will not report an ambiguous match in this metric.

Such links should be creatable for arbitrary pages across the web

About 13% of text fragments fail to find any matches on the page. It's difficult to tell in an automated metric, but when we did small scale analysis by hand I believe we found high single digit percent of pages would fail to match due to a page changing since the link was created.

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/CAL5BFfWm2mZqQFiRMkt3Cs1CxPmyMGDwGs4pcHa4pvAtHvFOPw%40mail.gmail.com.

[Ben Mathwig]

Hi folks,

I wanted to express Microsoft's support for shipping scroll-to-text-fragment as well as becoming a new web standard. We've used this feature in non-search contexts such as the Collections feature of Microsoft Edge, which has greatly enhanced our users experience when saving content to Collections.

Of course Bing has also been a consumer of this feature and has found similar results to what Grant mentioned above with regards to experience and engagement.

[Adam Semenenko]

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

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.

[PhistucK]

I guess you could create an extension that rewrites the URL via the chrome.webNavigation API (desktop only, probably no way on mobile).

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, 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/CAAyoetTvp1B1oxDeL_T9wVebU0kkr58FxL7U4rwg1RB1G9F95A%40mail.gmail.com.

[Thomas Steiner]

I cover disabling the feature in my article: 

https://web.dev/text-fragments/#disabling-text-fragments. Hope this helps!

Cheers,

Tom

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_Jb6OO_UHh47ea9hNRGZNiR%3DGr%3DsUxqxcj%2Bfw3w04wm7g%40mail.gmail.com.

--

Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com, https://twitter.com/tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1.23 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.hTtPs://xKcd.cOm/1181/
-----END PGP SIGNATURE-----

[Adam Semenenko]

Hi all,

Is there a way to remove this option yet? The usability is getting worse for me. Now the ugly highlighting is sticking around for longer.

I don't need Chrome to randomly highlight an arbitrary sentence of some websites in a different colour. It's distracting and annoying. I'd like to turn it off.

Kind regards, 

Adam 

[PhistucK]

You can right click on it and select "Remove highlight" or something like that.

I agree that it is not a nice experience, it is annoying that it is left highlighted. Maybe the original duration was too short, but this is too long/permanent.

Around five seconds might make sense and an option to double click on it to remove it, which would work for most texts.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, 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/CAAyoetRLA%3Da5WScarBrGJnBOpiR9A7eBNJ6nt%3DR4CXDB7czLCg%40mail.gmail.com.

[Adam Semenenko]

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. 

[Anton Bershanskyi]

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" 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.

[Thomas Steiner]

See https://web.dev/text-fragments/#disabling-text-fragments for disabling the feature.

To unsubscribe from this group and stop receiving emails from it, 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/6969a528-2a88-40ab-8b07-9aa9e522946an%40chromium.org.

--

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 -----

[Adam Semenenko]

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.) 

[K. Moon]

If your complaint is about the URLs (and the resulting behavior), isn't that a site authoring issue, not a Chrome issue?

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.

[K. Moon]

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.se...@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

[K. Moon]

(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

[K. Moon]

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.se...@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 

[Adam Semenenko]

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:

[Adam Semenenko]

Thanks for the explanation. But I don't like the scroll to text fragments. They're annoying, and have never been useful. 

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. 

[Adam Semenenko]

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:

[Thomas Steiner]

(On Android, some Chromium-based browsers support extensions, for example, Kiwi browser. It says it supports "most Chrome desktop extensions", but I haven't tested the extension in question.)

[Mike Taylor]

Hi Adam,

crbug.com/new is a better place to file a feature request to disable this feature on Chrome for Android (and a more user-friendly option on Desktop).

thanks,
Mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetRKLi4P4uL-mRSbRmyMfc6p6LHHcP%2BMGRhj%3DV%3DoM7ouGQ%40mail.gmail.com.

[K. Moon]

Chromium is the basis for Chrome, including on Android. If you want to file a request for Chrome only, you probably should direct that request to Google, not here.

Mike suggested using crbug.com/new to file your feature request. This thread is an intent-to-ship for Blink, it's not the place for making feature requests in Chromium/Chrome.

On Fri, Oct 6, 2023, 11:48 PM Adam Semenenko <adam.se...@gmail.com> wrote:

Thanks Mike but I don't use Chromium. Is that even available on Android? 

[Adam Semenenko]

Thanks Mike but I don't use Chromium. Is that even available on Android? 

On Sat, 7 Oct 2023, 03:27 Mike Taylor, <mike...@chromium.org> wrote:

[Adam Semenenko]

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. 

[PhistucK]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetScKktfiiNQOSLNutEOaBboSeh7%2BnhZguTMT2A6OK97wQ%40mail.gmail.com.

[PhistucK]

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.se...@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. 

[Adam Semenenko]

Here's another example of useless and distracting highlighting. What is it about the first two sentences that need highlighting? Is their position not significant enough? 

[Adam Semenenko]

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, <phis...@gmail.com> wrote:

[K. Moon]

Please stop posting this kind of feedback to this thread; you've been informed multiple times by multiple individuals that this is not the right forum for Chrome product feedback.

Continuing to persist in doing so may lead to intervention, like blocking your ability to post entirely.

To unsubscribe from this group and stop receiving emails from it, 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/CAAyoetTc9x1UFboXG0KpRvp9t3CScyYjYNpiX839XX7p8gWCKQ%40mail.gmail.com.

[Adam Semenenko]

Unfortunately the opt-out feature no longer seems to work, and now Chrome is randomly highlighting text and scrolling halfway through a page even when no highlighting was requested.

The colours are getting even more garish over time too.

Is there any other way to disable the highlighting?

On Wed, 25 Oct 2023 at 09:53, Adam Semenenko <adam.se...@gmail.com> wrote:

Sorry, this is just an email isn't it? The thread was closed. I've heard many things from different people, but I'm still experiencing the problem. I'm not sure who any of you are either, is there some sort of guide for who's in charge of who I can email? It'd be nice if the OP was could reply to their thread, instead of just cherry picking praise and running away with an idea that could be improved. 

It's not a Chrome product feedback by the way, as I understand there's the same problem in other browsers. 

[Mike Taylor]

If you believe you've found a bug, please file a new issue at crbug.com/new. This is not a support forum.

thanks,
Mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyoetQCRN2yCPu6j5xSK3odOhX3VNvWbjsHgUiM-PpWLXCCbw%40mail.gmail.com.

[B. Blank]

• ok... So to chime in here. Not sure the best way to reach the folks who created this functionality. There needs to be a way to turn this feature off. It's been distracting and annoying for a couple of years now, and any flag or setting to turn it off is gone. Why isn't there a way to disable this highlighting of text? Come on. Really? 

Sorry. 

Please!

[Daniel Bratell]

I see what you mean since I've also ended up with highlighted text that is very unhelpful, but I think that you are directing your annoyance at the wrong party. 

Scroll To Text Fragment is a web feature that can be used to make a useful experience, or a not so useful experience. Like animations or funny fonts. That the feature can be used badly is not in itself a reason to remove it (and few people want to support badly tested customization flags). 

Instead I think that you should try to reach the people the use it in a bad way. If we're talking Google Search, I know that can be hard, but maybe you can find a way.

Alternatively, if you have a suggestion for how to make it better (turning it off doesn't make the feature better but good try), I think there are places to voice those ideas in connection to Blink. In specification forums or as feature requests.

There also seems to be at least one browser extension that claims that it does something: "Disable Google Search Text Highlights". Maybe it works.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a57474d0-4c51-4649-8afb-7446cd7fdfd3n%40chromium.org.

[Adam Semenenko]

> Scroll To Text Fragment is a web feature that can be used to make a useful experience, or a not so useful experience. Like animations or funny fonts. That the feature can be used badly is not in itself a reason to remove it (and few people want to support badly tested customization flags). 

But there are flags to disable features that interfere with accessibility. Animations can be disabled, https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion, and colour schemes can be modified https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme.

I don't think "bad websites exist, so that means bad browser features are okay" is a convincing argument.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1281ace1-4282-4591-83bf-20f8b43eb5a4%40gmail.com.