[webkit-dev] Feedback on Blink's text fragment directive proposal

[David Bokan]

[sending (again, sorry) from correct e-mail]

I think Nick's replies
<https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html>
mostly
still apply, some updated answers to those questions.

(1) We’re concerned about compatibility issues in a world where some
> browsers support this but not all. Aware browsers will strip `:~:`, but
> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
> mentioned that at least one site (webmd.com) totally breaks if any
> fragment ID is exposed to the page. This makes it difficult to create a
> link that uses this feature but which is safe in all browsers:
> - Since there is no feature detection mechanism, it’s hard for a webpage
> to know whether it should issue such a link. It would have to be based on
> UA string checks, which is regrettable.
> - A link meant for a supporting browser can end up in a non-supporting
> browser, at the very least by copy paste from the URL field, and perhaps
> through other features to share a link.
>

We do have a feature detection
<https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis>
mechanism
for this.

On the latter point, this is true but we think implementing fragment
directive stripping (removing the part after and including `:~:`) is
trivial even if the UA doesn't wish to implement the text-fragment feature.
FWIW, we haven't seen or heard of another such example since.


> (2) The portions of this Community Group report that monkey patch other
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
> against those specifications. Monkeypatching other specs is not a good way
> to build specifications for the long term.
>

We still need support from another vendor to start merging the monkey
patches into the real standards - if Apple's supportive I'd be happy to
start on that immediately.


> (3) Text fragment trumping a regular fragment ID seems a bit strange. The
> more natural semantic would be that the text search starts at the fragment,
> so if there are multiple matches it’s possible to scroll to a more specific
> one. It’s not clear why the fragment is instead entirely ignored.
>

This was discussed in more detail in issue#75
<https://github.com/WICG/scroll-to-text-fragment/issues/75>; I agree with
Nick's point that the disambiguation syntax is already specific enough that
starting from a fragment isn't necessary. This also keeps us
mostly-compatible with the TextQuoteSelector
<https://www.w3.org/TR/annotation-model/#text-quote-selector> specified in
WebAnnotations which I think may have benefits for interaction with
annotation applications.

On Mon, Aug 31, 2020 at 1:31 PM David Bokan <bokan at google.com> wrote:

> I think Nick's replies
> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html>
> mostly still apply, some updated answers to those questions.
>
> (1) We’re concerned about compatibility issues in a world where some
>> browsers support this but not all. Aware browsers will strip `:~:`, but
>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>> mentioned that at least one site (webmd.com) totally breaks if any
>> fragment ID is exposed to the page. This makes it difficult to create a
>> link that uses this feature but which is safe in all browsers:
>> - Since there is no feature detection mechanism, it’s hard for a webpage
>> to know whether it should issue such a link. It would have to be based on
>> UA string checks, which is regrettable.
>> - A link meant for a supporting browser can end up in a non-supporting
>> browser, at the very least by copy paste from the URL field, and perhaps
>> through other features to share a link.
>>
>
> We do have a feature detection
> <https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis>
> mechanism for this.
>
> On the latter point, this is true but we think implementing fragment
> directive stripping (removing the part after and including `:~:`) is
> trivial even if the UA doesn't wish to implement the text-fragment feature.
> FWIW, we haven't seen or heard of another such example since.
>
>
>> (2) The portions of this Community Group report that monkey patch other
>> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
>> against those specifications. Monkeypatching other specs is not a good way
>> to build specifications for the long term.
>>
>
> We still need support from another vendor to start merging the monkey
> patches into the real standards - if Apple's supportive I'd be happy to
> start on that immediately.
>
>
>> (3) Text fragment trumping a regular fragment ID seems a bit strange. The
>> more natural semantic would be that the text search starts at the fragment,
>> so if there are multiple matches it’s possible to scroll to a more specific
>> one. It’s not clear why the fragment is instead entirely ignored.
>>
>
> This was discussed in more detail in issue#75
> <https://github.com/WICG/scroll-to-text-fragment/issues/75>; I agree with
> Nick's point that the disambiguation syntax is already specific enough that
> starting from a fragment isn't necessary. This also keeps us
> mostly-compatible with the TextQuoteSelector
> <https://www.w3.org/TR/annotation-model/#text-quote-selector> specified
> in WebAnnotations which I think may have benefits for interaction with
> annotation applications.
>
> On Mon, Aug 31, 2020 at 12:42 PM Darin Adler <darin at apple.com> wrote:
>
>> On Aug 31, 2020, at 9:33 AM, David Bokan <bokan at chromium.org> wrote:
>>
>> We've made lots of improvements to the spec, notably around issues raised
>> in Mozilla's standards-position
>> <https://github.com/mozilla/standards-positions/issues/194>.
>>
>>
>> Do you think those improvements address Maciej’s concerns from last
>> December? Since you didn’t say that explicitly I was wondering what your
>> take on that was.
>>
>> — Darin
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200831/25fafdb3/attachment.htm>