Intra-publication links

[dauwhe]

These... are a problem. A fragment link within a single document works fine. But linking from iframe to iframe is much, much trickier. You can target the other iframe, but it doesn't work with our :target css, and even if all iframe are visible a UA won't scroll to the "active" one.

I'm hoping I'm missing something obvious.

[BigBlueHat]

What things can CSS "handle" when selecting with :target? As in, what characters can (and more importantly) cannot be used as the id of the thing targeted?

The URL spec(s) don't have any fragment identifier delimiters, but there may be cases where CSSOM and DOM-level lookups do actually fail (currently) if/when they encounter certain characters. If that's indeed the case, then "breaking" on those characters and possibly using whatever remains after the delimiter to target within the contained (i.e. iframed or whatever) document space might get us sub-document-targeting.

[BigBlueHat]

Alternatively, a ServiceWorker could catch any sub-resource requests and present them within the publication's rendering space, but that presents a race condition--navigating to a child will only show the child out of presentational context unless the SW is installed and responding at the time of the visit.

In the Single Page App (SPA) world, this is usually "solved" by breaking the Web and always sending back the same index.html file for every path (i.e. /about/author returns index.html just like / etc).

Doing this essentially leaves the browser (nor caches, etc) very few options to help the developer optimize things, and ultimately it's slower--as any visual processing MUST go through the whole JS run cycle before routing anywhere.

Ideally, instead, one could respond with a content document which referenced it's "shell" (as it's called in SPA land), and that "shell" would be retrieved and used if available--but if that failed, then the child document would be presented on it's own...essentially as if it were not part of a larger thing (publication or app).