[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: David Bokan <bokan () chromium ! org>
Date: 2020-09-18 14:35:37
Message-ID: CANMmsAs-BBT2dEkLdNSncBoqHKXkE61-=MhM1bwHo0AQrsQyuQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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> 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@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@apple.com> wrote:
>>
>>> On Aug 31, 2020, at 9:33 AM, David Bokan <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 (text/html)]
<div dir="ltr">Friendly ping to get an answer here.<div><br></div><div>Do my answers \
above address those points or is there anything else I can \
clarify?</div><div><br></div><div>Thanks,</div><div>David</div></div><br><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">bokan@chromium.org</a>> \
wrote:<br></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"><div>[sending (again, sorry) from correct e-mail]</div><div><br></div>I \
think <a href="https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html" \
target="_blank">Nick's replies</a> mostly still apply, some updated answers to \
those questions.<span style="color:rgb(80,0,80)"><div><br></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">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>- 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>- 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></blockquote><div><br></div></span><div>We do have a <a \
href="https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis" \
target="_blank">feature detection</a> mechanism for \
this.</div><div><br></div><div>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)"><div> </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></blockquote><div><br></div></span><div>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)"><div> </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></blockquote><div><br></div></span><div>This was discussed in more detail \
in <a href="https://github.com/WICG/scroll-to-text-fragment/issues/75" \
target="_blank">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">TextQuoteSelector</a> specified in WebAnnotations which I think may \
have benefits for interaction with annotation applications.</div></div><br><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">bokan@google.com</a>> wrote:<br></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">I think <a \
href="https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html" \
target="_blank">Nick's replies</a> mostly still apply, some updated answers to \
those questions.<div><br></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">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> - 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> - 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></blockquote><div><br></div><div>We do have a <a \
href="https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis" \
target="_blank">feature detection</a> mechanism for this.</div><div><br></div><div>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> </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></blockquote><div><br></div><div>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> \
</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></blockquote><div><br></div><div>This was discussed in more detail in <a \
href="https://github.com/WICG/scroll-to-text-fragment/issues/75" \
target="_blank">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">TextQuoteSelector</a> specified in WebAnnotations which I think may \
have benefits for interaction with annotation applications.</div></div><br><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">darin@apple.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div>On Aug 31, \
2020, at 9:33 AM, David Bokan <<a href="mailto:bokan@chromium.org" \
target="_blank">bokan@chromium.org</a>> wrote:</div><br><div><div \
dir="ltr"><div>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">standards-position</a>.</div></div></div></blockquote><br></div><div>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><br></div><div>— Darin</div></div></blockquote></div> \
</blockquote></div> </blockquote></div>
_______________________________________________
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