[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Feedback on Blink's text fragment directive proposal
From: Maciej Stachowiak <mjs () apple ! com>
Date: 2020-09-24 9:08:42
Message-ID: 79725A09-1193-4FB2-AD54-F130B603EDBB () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@chromium.org \
> <mailto:bokan@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@google.com \
> <mailto:bokan@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@apple.com \
> <mailto:darin@apple.com>> wrote:
> > On Aug 31, 2020, at 9:33 AM, David Bokan <bokan@chromium.org \
> > <mailto:bokan@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
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><div class=""><br class=""></div>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?<div class=""><br \
class=""></div><div class=""> - Maciej<br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On Sep 18, 2020, at 7:35 AM, David Bokan <<a \
href="mailto:bokan@chromium.org" class="">bokan@chromium.org</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Friendly ping \
to get an answer here.<div class=""><br class=""></div><div class="">Do my answers \
above address those points or is there anything else I can clarify?</div><div \
class=""><br class=""></div><div class="">Thanks,</div><div \
class="">David</div></div><br class=""><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Mon, Aug 31, 2020 at 1:42 PM David Bokan <<a \
href="mailto:bokan@chromium.org" class="">bokan@chromium.org</a>> wrote:<br \
class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" \
class=""><div class="">[sending (again, sorry) from correct e-mail]</div><div \
class=""><br class=""></div>I think <a \
href="https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html" \
target="_blank" class="">Nick's replies</a> mostly still apply, some updated \
answers to those questions.<span style="color:rgb(80,0,80)" class=""><div \
class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(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 (<a \
href="http://webmd.com/" target="_blank" class="">webmd.com</a>) 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:<br class="">- 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.<br \
class="">- 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.<br class=""></blockquote><div class=""><br \
class=""></div></span><div class="">We do have a <a \
href="https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis" \
target="_blank" class="">feature detection</a> mechanism for this.</div><div \
class=""><br class=""></div><div class="">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.</div><span style="color:rgb(80,0,80)" class=""><div \
class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(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.<br \
class=""></blockquote><div class=""><br class=""></div></span><div class="">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.</div><span style="color:rgb(80,0,80)" class=""><div \
class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(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.<br class=""></blockquote><div class=""><br \
class=""></div></span><div class="">This was discussed in more detail in <a \
href="https://github.com/WICG/scroll-to-text-fragment/issues/75" target="_blank" \
class="">issue#75</a>; 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 <a \
href="https://www.w3.org/TR/annotation-model/#text-quote-selector" target="_blank" \
class="">TextQuoteSelector</a> specified in WebAnnotations which I think may \
have benefits for interaction with annotation applications.</div></div><br \
class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, \
2020 at 1:31 PM David Bokan <<a href="mailto:bokan@google.com" target="_blank" \
class="">bokan@google.com</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">I think <a \
href="https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html" \
target="_blank" class="">Nick's replies</a> mostly still apply, some updated answers \
to those questions.<div class=""><br class=""></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">(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 (<a href="http://webmd.com/" target="_blank" \
class="">webmd.com</a>) 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:<br class=""> - 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.<br class=""> - 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.<br \
class=""></blockquote><div class=""><br class=""></div><div class="">We do have a <a \
href="https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis" \
target="_blank" class="">feature detection</a> mechanism for this.</div><div \
class=""><br class=""></div><div class="">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.</div><div class=""> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">(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.<br class=""></blockquote><div \
class=""><br class=""></div><div class="">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.</div><div class=""> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">(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.<br \
class=""></blockquote><div class=""><br class=""></div><div class="">This was \
discussed in more detail in <a \
href="https://github.com/WICG/scroll-to-text-fragment/issues/75" target="_blank" \
class="">issue#75</a>; 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 <a \
href="https://www.w3.org/TR/annotation-model/#text-quote-selector" target="_blank" \
class="">TextQuoteSelector</a> specified in WebAnnotations which I think may have \
benefits for interaction with annotation applications.</div></div><br class=""><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 12:42 \
PM Darin Adler <<a href="mailto:darin@apple.com" target="_blank" \
class="">darin@apple.com</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><blockquote \
type="cite" class=""><div class="">On Aug 31, 2020, at 9:33 AM, David Bokan <<a \
href="mailto:bokan@chromium.org" target="_blank" class="">bokan@chromium.org</a>> \
wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="">We've \
made lots of improvements to the spec, notably around issues raised in \
Mozilla's <a href="https://github.com/mozilla/standards-positions/issues/194" \
target="_blank" class="">standards-position</a>.</div></div></div></blockquote><br \
class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">— \
Darin</div></div></blockquote></div> </blockquote></div>
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic