4 ms·

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

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

raimue 8y ago
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.
csarven 8y ago
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_def 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=TextQuoteSelector,prefix=,exact=annotation,suffix=) http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto... or equivalent: http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelector,exact=annotation) 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=TextQuoteSelector,exact=browser-based%20authoring%20and%20annotation%20platform%20with%20built-in%20support) 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.
- crehn 8y ago
  Even with that in mind, the W3C spec adds unnecessarily verbose syntax fluff.
  - contravariant 8y ago
    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.
  - csarven 8y ago
    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.
chrismorgan 8y ago
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.
- ru999gol 8y ago
  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.
  - giornogiovanna 8y ago
    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.
  - chrismorgan 8y ago
    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.
pjmlp 8y ago
W3C takes into consideration any platform where a browser might run, instead of which OSes are supported by Chrome.
Kovah 8y ago
Yeah.. I remember Microsoft once thought it would be great to not follow standards. What we got is Internet Explorer.
xg15 8y ago
The bottom one looks prettier, yes. Does it also take into account all the problems the first one does?
pbhjpbhj 8y ago
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.

raimue 8y ago

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.

csarven 8y ago

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_def 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=TextQuoteSelector,prefix=,exact=annotation,suffix=) http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto... or equivalent: http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelector,exact=annotation) 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=TextQuoteSelector,exact=browser-based%20authoring%20and%20annotation%20platform%20with%20built-in%20support) 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.

crehn 8y ago
Even with that in mind, the W3C spec adds unnecessarily verbose syntax fluff.
- contravariant 8y ago
  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.
- csarven 8y ago
  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.

chrismorgan 8y ago

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.

ru999gol 8y ago
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.
- giornogiovanna 8y ago
  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.
- chrismorgan 8y ago
  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.

pjmlp 8y ago

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

Kovah 8y ago

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

xg15 8y ago

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

pbhjpbhj 8y ago

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.