[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-11 19:39:36
Message-ID: 0B603E5A-2494-41CE-BC92-13E02A7257CE () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi David,
Apple folks have discussed this internally. In general, we think this is useful \
functionality to expose. Some points of feedback (let me know if any of these should \
be filed as an issue against the spec):
(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?
(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.
(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 would frame these more as points of concern than opposition to the whole idea, but \
it seems wise to address them before shipping.
Regards,
Maciej
> On Dec 2, 2019, at 12:22 PM, David Bokan <bokan@chromium.org> wrote:
>
> Hello webkit-dev,
>
> I'd like to solicit feedback as well as an official position from Webkit on our \
> proposal for the text fragment directive: \
> https://github.com/WICG/ScrollToTextFragment \
> <https://github.com/WICG/ScrollToTextFragment>.
> In summary: this is a feature that allows authors and users to craft URLs to pages \
> and specify a snippet of text on the page as a subresource (visually highlighting \
> it and scrolling it into view). Analogous to element-id based fragment anchors but \
> for text.
> You can try this out today in Chrome Beta by enabling \
> chrome://flags/#enable-text-fragment-anchor. Here's an example link: <>
> https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view \
> <https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view>
>
> Relevant Links:
>
> <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md>
> Explainer <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md>
> Spec <https://wicg.github.io/ScrollToTextFragment/>
> TAG Review <https://github.com/w3ctag/design-reviews/issues/392>
> (Currently Suspended) Blink Intent Thread \
> <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/NLbg84m0EAAJ>
> Issue on Mozilla standards-positions \
> <https://github.com/mozilla/standards-positions/issues/194>
> We've been using the GitHub repo for issue tracking but happy to take feedback \
> (official or otherwise) in any form.
> Thank you!
> David
> _______________________________________________
> 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=""><div class=""><br class=""></div>Hi \
David,<div class=""><br class=""></div><div class="">Apple folks have discussed this \
internally. In general, we think this is useful functionality to expose. Some points \
of feedback (let me know if any of these should be filed as an issue against the \
spec):</div><div class=""><br class=""></div><div class="">(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:</div><div class=""><span class="Apple-tab-span" \
style="white-space:pre"> </span>- 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.</div><div class=""><span \
class="Apple-tab-span" style="white-space:pre"> </span>- 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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">(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.</div><div class=""><br class=""></div><div class="">(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.</div><div class=""><br class=""></div><div class="">We would frame \
these more as points of concern than opposition to the whole idea, but it seems wise \
to address them before shipping.</div><div class=""><br class=""></div><div \
class="">Regards,</div><div class="">Maciej</div><div class=""><br class=""><div><br \
class=""><blockquote type="cite" class=""><div class="">On Dec 2, 2019, at 12:22 PM, \
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="">Hello \
webkit-dev,<div class=""><br class=""></div><div class="">I'd like to solicit \
feedback as well as an official position from Webkit on our proposal for the text \
fragment directive: <a href="https://github.com/WICG/ScrollToTextFragment" \
target="_blank" class="">https://github.com/WICG/ScrollToTextFragment</a>.</div><div \
class=""><br class=""></div><div class="">In summary: this is a feature that allows \
authors and users to craft URLs to pages and specify a snippet of text on the page as \
a subresource (visually highlighting it and scrolling it into view). Analogous to \
element-id based fragment anchors but for text.</div><div class=""><br \
class=""></div><div class="">You can try this out today in Chrome Beta by \
enabling <a class="">chrome://flags/#enable-text-fragment-anchor. Here's an \
example link:</a></div><div class=""><br class=""></div><div class=""><a \
href="https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view" \
class="">https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view</a><br \
class=""></div><div class=""><br class=""></div><div class="">Relevant \
Links:</div><div class=""><a \
href="https://github.com/WICG/ScrollToTextFragment/blob/master/README.md" \
class=""><br class=""></a></div><div class=""><a \
href="https://github.com/WICG/ScrollToTextFragment/blob/master/README.md" \
class="">Explainer</a></div><div class=""><a \
href="https://wicg.github.io/ScrollToTextFragment/" class="">Spec</a></div><div \
class=""><a href="https://github.com/w3ctag/design-reviews/issues/392" class="">TAG \
Review</a></div><div class="">(Currently Suspended) <a \
href="https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/NLbg84m0EAAJ" \
class="">Blink Intent Thread</a></div><div class=""><a \
href="https://github.com/mozilla/standards-positions/issues/194" class="">Issue on \
Mozilla standards-positions</a></div><div class=""><br class=""></div><div \
class="">We've been using the GitHub repo for issue tracking but happy to take \
feedback (official or otherwise) in any form.</div><div class=""><br \
class=""></div><div class="">Thank you!</div><div class="">David</div></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=""></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