I would like to urge the browser developers/makers to adopt existing proposals which came through open consensus which do precisely cover the same use cases (and more!)
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:
Are there any guidelines for chromium development? It seems like one can just commit a feature to it and make half the world use it.
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?
Thank you for the link and I may have come off a bit harsh with that last sentence.
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?
> 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?
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.
We can only compare what's on the table, ie. arbitrary text selection. The targetText proposal doesn't necessarily result in a unique identifier that deterministically corresponds to user's original selection. So, I'm not sure if there is any point in discussing the syntactical differences on specificity further at this point. Having said that, at the end of the day, it is going to be the application that generates and uses the identifier.
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.
It's not like (un)necessarily verbose syntax is that uncommon in URLs. Or rather that's exactly where you'd expect an excrutiatingly verbose description of what you're linking to.
Such fragments don’t need to be particularly human-readable, only machine-readable. Given that, greater flexibility is generally a virtue: different matching strategies will work better in different contexts, and different tools can benefit from it. Consider the increased scope of the annotations feature—it’s designed for things like more robust referencing, bookmarking with annotations and other things like that.
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.
it adds a huge amount of unnecessary complexity for such a simple feature
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.
No, Mozilla would've gotten plenty of hate for potentially breaking sites, and adding features without discussing things with other vendors and Internet bodies. The thing is, we all know that Mozilla can't get away with that, but Google can, given Blink's market dominance.
But various tools have implemented the W3C proposal; just not browsers yet, probably mostly because getting the UI right is tricky, and the risk of breaking things higher. The problem is not in the particular syntax, but the feature as a whole.
The W3C design seems to be extensible for future use cases with a consistent syntax while keeping everything under one keyword. Something like this could also be applied to other types of documents, not only to text. Let's say to quickly draw a highlight on an image or specify a page in a PDF document. While "#targetText=" is simple, it is not a generic solution.
Isn't it that Google don't have to care about breaking millions of websites but W3C do? At this point every web developer is used to bending to Google's will, W3C have similar power but need to get consensus first.
Not saying its the best one but I built a system we used on the NYTimes web site for awhile that was fault tolerant and adjusted to changes in the page:
Typical GOOG move. Add some code, break the web outside the Google way. Why can't those guys write an RFC "Content sublocator-protocol for diverse media"...
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!
W3C Reference Note on Selectors and States: https://www.w3.org/TR/selectors-states/
It is part of the suite of specs that came through the W3C Web Annotation Working Group: https://www.w3.org/annotation/
More examples in W3C Note Embedding Web Annotations in HTML: https://www.w3.org/TR/annotation-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:
http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto...
A screenshot/how-to: https://twitter.com/csarven/status/981924087843950595