Hacker News Reader

Comment by ru999gol | Hacker News Reader

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

View on HN

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.

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.

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.

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?

Reply on news.ycombinator.com