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

[Ryosuke Niwa]

On Fri, Sep 18, 2020 at 7:35 AM David Bokan <bokan at chromium.org> wrote:

> Friendly ping to get an answer here.
>
> Do my answers above address those points or is there anything else I can
> clarify?
>
> Thanks,
> David
>
> On Mon, Aug 31, 2020 at 1:42 PM David Bokan <bokan at chromium.org> wrote:
>
>> [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.
>>
>
We're continued to be concerned about this backwards compatibility issue.

(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.
>>
>
This will limit the utility of this feature. For something as board
impacting as a URL format change, it seems rather short sighted.

Also, Web Annotations Data Model allows other kinds of annotations:
https://www.w3.org/TR/2017/REC-annotation-model-20170223/#selectors

Is there any reason this particular matching algorithm was picked and only
picked with no possibility of the future extensibility?

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200923/c9fa5471/attachment.htm>