> 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! 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
