Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

document.fragmentDirective doesn't work for feature detection #257

Open
foolip opened this issue Apr 30, 2024 · 9 comments
Open

document.fragmentDirective doesn't work for feature detection #257

foolip opened this issue Apr 30, 2024 · 9 comments

Comments

@foolip
Copy link
Member

foolip commented Apr 30, 2024

Due to https://webkit.org/b/273466, web developers will not be able to rely on document.fragmentDirective to detect support for text fragments.

The possible paths to interop are WebKit adding document.fragmentDirective or Chromium removing it. Either way makes it impossible to use document.fragmentDirective for feature detection. I don't have an opinion on which way to go.

@tomayac
Copy link
Contributor

tomayac commented Apr 30, 2024

It makes a lot of sense to make the feature detectable. Else, polyfills that emulate the native highlighting, for example, by injecting <mark> tags, might possibly break the page. See GoogleChromeLabs/link-to-text-fragment#102 for a real-world example.

@foolip
Copy link
Member Author

foolip commented Apr 30, 2024

Can the situation be salvaged though? Is it a problem if the feature appears unsupported even though it's supported?

@tomayac
Copy link
Contributor

tomayac commented Apr 30, 2024

In the worst case someone would then inject/load a polyfill despite native support.

@foolip
Copy link
Member Author

foolip commented Apr 30, 2024

I've filed GoogleChromeLabs/text-fragments-polyfill#157 to probe about what will happen with that polyfill.

@bokand
Copy link
Collaborator

bokand commented Apr 30, 2024

Hmm, would the polyfill be an issue if a browser has support but claims not to? In that case it'd strip the :~: part of the fragment off so the polyfill wouldn't see it, I think?

The bigger issue is we added it so that sites could selectively add a text directive to an anchor only for agents that it knows will strip it off, given that there were cases where adding it could break a site when followed - though this is fairly rare and I'm not sure if anyone uses it for that.

I'm curious to hear WebKit's take on https://webkit.org/b/273466 - if they did this intentionally and don't see any issues I suppose it might be a signal we could try unshipping it...

@tomayac
Copy link
Contributor

tomayac commented Apr 30, 2024

Hmm, would the polyfill be an issue if a browser has support but claims not to? In that case it'd strip the :~: part of the fragment off so the polyfill wouldn't see it, I think?

Correct, this is what I found out and documented in GoogleChromeLabs/text-fragments-polyfill#157 (comment).

@zcorpan
Copy link

zcorpan commented Oct 31, 2024

https://bugs.webkit.org/show_bug.cgi?id=273466 has been fixed. I think this issue can be closed.

@annevk
Copy link
Collaborator

annevk commented Nov 4, 2024

Note that it's not enabled by default, though I don't see any reason not to do that.

cc @rniwa @megangardner @sideshowbarker

@sideshowbarker
Copy link
Contributor

Opened WebKit/WebKit#36413

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants