On Fri, Sep 18, 2020 at 7:35 AM David Bokan <bo...@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 <bo...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev