[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: 2019-12-13 17:23:02
Message-ID: A489BDB9-BCF4-4D3D-8CE5-2B480A179980 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Dec 11, 2019, at 12:48 PM, Nick Burris <nburris@chromium.org> wrote:
>
> Hi Maciej,
> Thanks for the reply! David's away this week, my responses are inline:
> (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.
> It seems like the spec doesn't provide a solution for this. We think some form of \
> feature detection would slightly improve the situation. Other than that, We're not \
> sure how to avoid potential breakage. Maybe evangelize WebMD if that's the only \
> major site that breaks on unexpected fragments?
> There is a feature detection mechanism that we have \
> [specified](https://wicg.github.io/ScrollToTextFragment/#feature-detectability \
> <https://wicg.github.io/ScrollToTextFragment/#feature-detectability>) and \
> implemented, see [#19](https://github.com/WICG/ScrollToTextFragment/issues/19 \
> <https://github.com/WICG/ScrollToTextFragment/issues/19>). Feature detection can be \
> done by checking `typeof(window.location.fragmentDirective) == 'object'`. Indeed, \
> there is still a compat concern as described in the intent to ship, since these \
> links will exist in the wild. Since WebMD is the only broken site we've come \
> across, I agree it would be good to make sure they're aware of this. I'll reach \
> out.
Great. (Why only add it to the Location interface and not also URL?
>
> (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.
> Agreed - we're wrapping up on some smaller remaining issues and our next step is to \
> turn this into PRs.
Glad to hear it.
>
> (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.
> We wanted to keep this simple to ensure links are robust (generally they will be \
> generated algorithmically, where one can ensure the text directive is unique in the \
> page). If we add the dimension of relying on starting at a fragment, that fragment \
> or the text could move in the page and break the link, even if the desired text is \
> still present on the page. Feel free to open a Github issue if you think this is \
> worth discussing more!
https://github.com/WICG/ScrollToTextFragment/issues/75
>
> Thanks,
> Nick
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
[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=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On Dec 11, 2019, at 12:48 PM, Nick Burris <<a \
href="mailto:nburris@chromium.org" class="">nburris@chromium.org</a>> \
wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" \
class=""><pre style="white-space: pre-wrap;" class="">Hi Maciej,</pre><pre \
style="white-space: pre-wrap;" class="">Thanks for the reply! David's away this week, \
my responses are inline:</pre><pre style="white-space: pre-wrap;" \
class=""><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/" 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.<span style="font-family:Arial,Helvetica,sans-serif" \
class=""> </span></blockquote><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span \
style="font-family:Arial,Helvetica,sans-serif" \
class=""> </span></blockquote><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It seems like \
the spec doesn't provide a solution for this. We think some form of feature detection \
would slightly improve the situation. Other than that, We're not sure how to avoid \
potential breakage. Maybe evangelize WebMD if that's the only major site that breaks \
on unexpected fragments?</blockquote><div class=""><br class=""></div><div \
class="">There is a feature detection mechanism that we have [specified](<a \
href="https://wicg.github.io/ScrollToTextFragment/#feature-detectability" style="" \
class="">https://wicg.github.io/ScrollToTextFragment/#feature-detectability</a>) and \
implemented, see [#19](<a \
href="https://github.com/WICG/ScrollToTextFragment/issues/19" style="" \
class="">https://github.com/WICG/ScrollToTextFragment/issues/19</a>). Feature \
detection can be done by checking `typeof(window.location.fragmentDirective) == \
'object'`. Indeed, there is still a compat concern as described in the intent to \
ship, since these links will exist in the wild. Since WebMD is the only broken site \
we've come across, I agree it would be good to make sure they're aware of \
this. I'll reach out.</div></pre></div></div></blockquote><div><br \
class=""></div>Great. (Why only add it to the Location interface and not also URL?<br \
class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><pre \
style="white-space: pre-wrap;" 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">(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.</blockquote><div class=""><br \
class=""></div><div class="">Agreed - we're wrapping up on some smaller remaining \
issues and our next step is to turn this into \
PRs.</div></pre></div></div></blockquote><div><br class=""></div>Glad to hear it.<br \
class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><pre \
style="white-space: pre-wrap;" class=""> <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.</blockquote><div class=""><br class=""></div><div class="">We wanted to keep \
this simple to ensure links are robust (generally they will be generated \
algorithmically, where one can ensure the text directive is unique in the page). If \
we add the dimension of relying on starting at a fragment, that fragment or the text \
could move in the page and break the link, even if the desired text is still present \
on the page. Feel free to open a Github issue if you think this is worth discussing \
more!</div></pre></div></div></blockquote><div><a \
href="https://github.com/WICG/ScrollToTextFragment/issues/75" \
class="">https://github.com/WICG/ScrollToTextFragment/issues/75</a></div><div><br \
class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div \
dir="ltr" class=""><pre style="white-space: pre-wrap;" class=""><div class=""><br \
class=""></div><div class="">Thanks,</div><div class="">Nick</div></pre></div> \
_______________________________________________<br class="">webkit-dev mailing \
list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" \
class="">webkit-dev@lists.webkit.org</a><br \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br \
class=""></div></blockquote></div><br class=""></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