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

[David Bokan]

>
> Can you clarify what question you’re looking to have answered? Are you
> asking for a new standards position in light of the replies below?
>

 There are two specific points:

 - As I understand it, HTML requires multi-vendor interest to merge changes
to specs. Is Apple's position sufficient to start that process? I'd be
happy to start turning the spec into PRs but I interpreted the earlier
position in this thread more as "not-opposed" rather than support (is that
a fair reading?)

 - Would Apple accept contributions to WebKit implementing this feature?

Google Search uses this on supporting UAs - user surveys have found this
improves the user experience. A recently published extension
<https://chrome.google.com/webstore/detail/link-to-text-fragment/pbcodcjpfjdpcineamnnmbkkmkdpajjg?hl=en>
to generate links to text already has over 50,000 users. This is clearly
useful to users but would really be helped if we can make it interoperable
across browsers.

Thanks,
David

On Thu, Sep 24, 2020 at 5:08 AM Maciej Stachowiak <mjs at apple.com> wrote:

>
> Can you clarify what question you’re looking to have answered? Are you
> asking for a new standards position in light of the replies below?
>
>  - Maciej
>
> On 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.
>>
>>
>>> (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/20200924/c98e3baa/attachment.htm>