> On Dec 11, 2019, at 12:48 PM, Nick Burris <nbur...@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!

> Thanks,
> Nick
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

webkit-dev mailing list

Reply via email to