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 <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 > <mailto: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 <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 <bo...@google.com > <mailto:bo...@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 <da...@apple.com > <mailto:da...@apple.com>> wrote: >> On Aug 31, 2020, at 9:33 AM, David Bokan <bo...@chromium.org >> <mailto:bo...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
