[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: Nick Burris <nburris () chromium ! org>
Date: 2019-12-11 20:48:22
Message-ID: CADvKJHOrOGtSB2ONrROL5J-3HSTWNH1hYGSXtgKtKU7ViscCiA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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) 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)
and implemented, see
[#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.
(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.
> (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!
Thanks,
Nick
[Attachment #5 (text/html)]
<div dir="ltr"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Hi \
Maciej,</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Thanks for the reply! \
David's away this week, my responses are inline:</pre><pre \
style="white-space:pre-wrap;color:rgb(0,0,0)"><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">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.<span \
style="font-family:Arial,Helvetica,sans-serif"> </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"> </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><br></div><div>There is a feature detection mechanism \
that we have [specified](<a \
href="https://wicg.github.io/ScrollToTextFragment/#feature-detectability" \
style="">https://wicg.github.io/ScrollToTextFragment/#feature-detectability</a>) and \
implemented, see [#19](<a \
href="https://github.com/WICG/ScrollToTextFragment/issues/19" \
style="">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><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">(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><br></div><div>Agreed - we're wrapping up on some smaller \
remaining issues and our next step is to turn this into PRs.</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.</blockquote><div><br></div><div>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><div><br></div><div>Thanks,</div><div>Nick</div></pre></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