Fragment directive reserved for proprietary use

[0xdevwrite]

Since the URI fragment is meant to be used as a client-side processing directive, it would be nice for authors to have a namespace that is reserved for proprietary use and is guaranteed to not clash with future standardized directives. For instance, if instead of searching the page for text, an author did indeed want to support using CSS selectors for referencing a part of the page (as has been previously proposed), then they could implement a custom processing instruction within a proprietary-use directive.

In the abstract, it would look something like this: #:~:<proprietary_use_directive>=<processing_instruction>. More concretely using CSS selectors as an example: #:~:proprietary=css(body > p:first-child).

If I were to use a custom directive now, then I would use the domain name of the resource as the token for a proprietary directive (e.g. for example.com something like #:~:example.com=<proprietary_instruction>). This way I would be sure there would be no conflicting directive in the future. While that is good enough for now, I think it would make sense to use a standardized token to represent this proprietary-use namespace.

[bokand]

The primary inspiration for the fragment directive and stripping it from the Document's URL is to avoid clashing with client-side processing. Is there any reason why you couldn't add your custom processing instruction as part of the fragment? e.g. #proprietary=css(...):~:text=...

[0xdevwrite]

Is there any reason why you couldn't add your custom processing instruction as part of the fragment?

I think for the same reason that the text directive uses the fragmentDirective delimiter—in order to not clash with the existing semantics (i.e. reference an element by its ID), and furthermore the processing, of the document fragment.

From my understanding, the fragment in a URI is subject to interpretation as defined by each MIME type individually and for the text/html type, the fragment is meant to reference an element with a particular ID—and now with the introduction of the fragmentDirective to also allow arbitrary processing instructions (although only text for now).

So since the fragmentDirective has now been introduced, I think it could be useful to piggyback off of that so authors could use it to implement their own custom client-side processing, outside of what the user agent does, and without the implication that the fragment is referring to an element by ID.

e.g. #proprietary=css(...):~:text=...

This fragment above could technically refer to an element with this particular ID, whereas #:~:proprietary=css(...) decidedly does not refer to an element by that ID (for supporting user agents) thanks to the introduction of the fragmentDirective and its effect on the semantics of the fragment for the text/html MIME type.

[bokand]

Closing out old issues.

I think any kinds of changes to this behavior are out of scope for this repo. I'm actively working to upstream this into HTML. Any enhancements or proposals should be taken up in that venue.