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?

edit: dear downvoter, explain yourself :)

> Are there any guidelines for chromium development?

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.

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?

Good luck!

Explanation:

> ... and make half the world use it.

vs.

> 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.

Sure, but that won't stay to be the case since otherwise no needle-moving group would start to use it, so what would step 2 be?

"Integration with W3C Web Annotations" https://github.com/bokand/ScrollToTextFragment/issues/4

> 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?

I'm so glad that google just sometimes ignores W3C's horrible design-by-committe nonsense. Its the same reason XHTML failed.

    #selector(type=TextQuoteSelector,exact=foo)

vs.

    #targetText=foo

/edited to be a more fair comparison

I urge you to dig a little deeper and see why things like `prefix`, `exact`, `suffix` exists in that particular example:

https://www.w3.org/TR/selectors-states/#TextQuoteSelector_de...

Please note that you've actually changed the example!

If you just want to include `exact` or "targetText", you can still do:

http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto...

or equivalent:

http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto...

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:

http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto...

I hope that clarifies.

This is just tip of the iceberg! Let's stick to fair comparison and consider extensibility.

Even with that in mind, the W3C spec adds unnecessarily verbose syntax fluff.

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.

Yeah.. I remember Microsoft once thought it would be great to not follow standards. What we got is Internet Explorer.

W3C takes into consideration any platform where a browser might run, instead of which OSes are supported by Chrome.

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.

The bottom one looks prettier, yes. Does it also take into account all the problems the first one does?

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:

https://github.com/NYTimes/Emphasis

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!