Selector JSON to IRI/URI Mapping: supporting compound fragments so that SPAs work

[westurner]

https://www.w3.org/TR/2017/NOTE-selectors-states-20170223/#frags says:

Note that this representation is valid only if the IRI for the Source does not contain a fragment identifier of its own (an IRI may contain at most one fragment identification).

https://github.com/bokand/ScrollToTextFragment/issues/4#issuecomment-464036000

Is there a way to handle multiple attributes in the fragment e.g. so that SPAs can just drop the e.g. &selector=... attribute when doing client side routing?

Maybe something like:

#!route/two&selector=(...)

!route/two#selector=(...)

!route/two;;selector=(...)

... from https://github.com/bokand/ScrollToTextFragment/issues/4#issuecomment-464485999 .

Can we make `selector(...)` a value of a keyed attribute?
Other than https://w3c.github.io/web-annotation/selector-note/converter/ , which tools support this note?

> The values should be percent encoded [rfc3986]; the encoding is a must for characters that may make the fragment ambiguous, namely: [ =,#]

> Applying percent encoding method for entire IRI string might also cause unnecessary troubles.

With ``#!route/two#selector=(...)``, AFAIU a URL parsing library should return the part after the first `#` (regardless of percent encoding). This form would be easiest for client side SPA URI routing because the (nonconforming?) app could just drop the data after the second `#` (which should *technically* be percent-encoded AFAIU)

[azaroth42]

This would be a change of functionality requiring a new version, rather than an error in the current spec. Tagging postpone (e.g. defer for future version)

[westurner]

Fixing this sooner rather than later would reduce the costs of implementing the breaking changes later in all implementations.

Is there an e.g. "future breaking changes" milestone or just label as "postpone" for now?