W3C Reference Note on Selectors and States:
It is part of the suite of specs that came through the W3C Web Annotation Working Group:
More examples in W3C Note Embedding Web Annotations in HTML:
Different kinds of Web resources can combine multiple selectors and states. Here is a simple one using `TextQuoteSelector` handled by the https://dokie.li/ clientside application:
Regarding URL hash abuse elsewhere: this current development in Chromium is different from front-end frameworks and specific websites doing it because SomeSite can't break OtherSite while both having a different way to handle the hash.
Now Chromium randomly claims part of the hash which others now need a workaround for? Are these devs serious?
edit: dear downvoter, explain yourself :)
Absolutely! Launching a change to the web platform is a long, arduous process. This feature is currently taking the very early first steps.
For more details, see https://www.chromium.org/blink/launching-features.
Having some feature like this for the web would in itself be good, just claiming a key in the hash part just for this would (and I know that hash doesn't really have a format so "it's not a key" etc, but it does gets used that way).
A proposition: instead of using plain 'targetText' how about having some prefix for all Chromium's claims in the hash part so that the front-end (framework) developers can filter these out without needing to keep a list?
> ... and make half the world use it.
> Add about:flag for Scroll-To-Text
> Adding chrome://flag to allow users (particularly on Mobile) to easily enable and test the feature.
(Commit message via https://chromium-review.googlesource.com/c/chromium/src/+/14...)
So nobody will use the feature unless they explicitly choose to.
> It would be great to be able to comment on the linked resource text fragment. W3C Web Annotations [implementations] don't recognize the targetText parameter, so AFAIU comments are then added to the document#fragment and not the specified text fragment. [...]
> Is there a simplified mapping of W3C Web Annotations to URI fragment parameters?
Please note that you've actually changed the example!
If you just want to include `exact` or "targetText", you can still do:
but that selects all instances of the text "annotation" in the document. Which is precisely why we need `prefix` and `suffix` to be able to identify the actual selection that the user made.
So, here is the equivalent of your example:
I hope that clarifies.
This is just tip of the iceberg! Let's stick to fair comparison and consider extensibility.
Please have a closer into why we should be mindful of different use cases here, especially those pertaining to different resource representations, ways to "select", and factor in the state of the resource/representation at the time of the selection. It is there for use. It doesn't mean that all possible options needs to make its way into the identifier. This is important because people are going to use these identifiers in documents, and preserving context matters. Like I said earlier, the W3C Note has considered these, as well as permitting the use of different (RFC) selectors for different media. Let's reuse instead of NIH-FUD.
There then remains the question of cross-compatibility: do all relevant tools implement the same techniques? That is a legitimate concern, but it’s well-enough specced that it shouldn’t be a problem.
Also as noted, various tools out there already use this format. The Chrome team ignoring that and using their own, functionally inferior format is hostile.
There is a reason nobody implemented the W3C proposal, If I have the choice between a simple working solution that anyone can describe in a single sentence specification and a hundred page specification with tons of unneeded features that nobody is going to implement ever, I choose the former. I wonder how much hate Mozilla would've gotten for the same feature, probably none.
Well, I started writing this and read your answer. This is not a problem specific to html/the web, for example I regularly encounter this when referencing things in pdfs. Will definitely have a look at this!