There is an ocean of CSS that mimic off the shelf LaTeX or journal-specific layouts. They're almost entirely one-off attempts depend on a particular HTML structure to have the CSS work. Introducing new CSS layouts to work on the same HTML generally doesn't work well.
In https://dokie.li/ , HTML is key - semantic and sufficiently "flexible". CSS is secondary. That is why we can generally throw different CSS at it without touching the underlying HTML pattern. Examples:
You can dynamically switch the CSS view from the dokieli menu (top-right) or from your browser's native controls eg. view the ACM authoring guidelines using the LNCS CSS and vice-versa.
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.
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.
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:
In https://dokie.li/ , HTML is key - semantic and sufficiently "flexible". CSS is secondary. That is why we can generally throw different CSS at it without touching the underlying HTML pattern. Examples:
* https://dokie.li/acm-sigproc-sp (ACM - authoring guidelines)
* https://dokie.li/lncs-splnproc (LNCS - authoring guidelines)
* https://csarven.ca/linked-research-decentralised-web
* https://csarven.ca/dokieli-rww
* https://linkedresearch.org/ldn/
* ...
You can dynamically switch the CSS view from the dokieli menu (top-right) or from your browser's native controls eg. view the ACM authoring guidelines using the LNCS CSS and vice-versa.