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

Thu Sep 24 02:08:42 PDT 2020

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 <mailto: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 <http://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 <mailto: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 <http://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 <mailto:darin at apple.com>> wrote:
>> On Aug 31, 2020, at 9:33 AM, David Bokan <bokan at chromium.org <mailto: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/a3b733f8/attachment.htm>