csarven

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:

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

Right on. Different fragment selectors can be used depending on the media type of a representation: https://www.w3.org/TR/selectors-states/#selector

Expanded here: https://news.ycombinator.com/item?id=19169582

XPointer is one of options for a fragment selector in W3C Reference Note on Selectors and States: https://www.w3.org/TR/selectors-states/

See also https://news.ycombinator.com/item?id=19169582

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.

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.

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!)

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

Laconica is theme-able see http://laconi.ca/trac/wiki/ListOfServers for some examples. It can also integrate custom Plugins which allows you to do a good range of stuff. http://army.twit.tv http://bleeper.de http://todaysmama.com/connect are few of the larger laconica communities that have custom themes and plugins implemented.