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
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.)
--
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.
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
--
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.
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.
typeof(window.location.fragmentDirective) != 'undefined'
--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
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.
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.
--
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.
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.
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
--
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.
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.
> 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.
> 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?
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.
> 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.
>
> 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.
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.
- 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
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)
- 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?
Hope that helps,
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.
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.
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.
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?
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
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?
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
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.
--
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.
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.
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.
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).
**********************************************************************
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
**********************************************************************
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-goalsIt 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.
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.
Specifically, whether it met the usability goals stated in https://github.com/WICG/scroll-to-text-fragment#usability-goals
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.
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.
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.
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.
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.
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.