regression: SVG url(#xxx) xml:base incorrect when HTML head injected with base tag

[danielweck]

This seems to be a known issue with most browsers :(

Note: I tried to "force" the xml:base on the SVG element, to no avail.

Test EPUB: https://readiumfoundation.box.com/s/lv024fngot7eg3unnw50
(e.g. svg-007.xhtml)

Regression introduced by:
#76

iframe loader code:
https://github.com/readium/readium-shared-js/blob/develop/js/views/iframe_loader.js#L166

[danielweck]

I tried combining html>head>base@href with html@xml:base, but although the former is needed for image resources (HTML img@src), it breaks SVG url(#xxx) references (even with the latter applied at top-level, or deeper in the markup structure (e.g. on the actual SVG elements)).

[danielweck]

There's a bugfix for Firefox (develop branch):
df67671

Chrome Safari and Opera (all WebKit-based), are not rendering SVG clipping paths and gradients, because they are somewhat not able to resolve the url(#fragmentID), despite the use of both "html>head>base@href" and "svg@xml:base" (the latter is really only useful for xlink, not so much for resolving other resources).

[jccr]

Looks like we might have to find all url(#xxx) and change them to url({absolute uri}#xxx)

http://stackoverflow.com/questions/18259032/using-base-tag-on-a-page-that-contains-svg-marker-elements-fails-to-render-marke

[jccr]

Or find something that lets us no longer have to use the base tag.

[danielweck]

I tried setting the url(xxx#yyy) manually in the HTML/SVG...to no avail.

[jccr]

@danielweck

I tried url(blob-url:#yyy) and it looks like it works for the clipping paths. Haven't gotten the gradients to appear though.

Example: url(blob:chrome-extension%3A//mihipnppbjnahamjfilmpfogchcejkmc/44a2a54e-b6a5-456c-a47b-b6f7072c1ee1#SVGID_2_CX)

Edit: the gradients work too

[danielweck]

That's good to know, thanks!
Although, if we can find a solution that does not involve pre-processing (parsing) every possible syntax occurence of url(#xxx) and other URI-dependent constructs in SVG markup...I'd be happier :)
(this could be a viable solution for the cloud reader though, just to patch this particular shortcoming, whilst the chrome extension and native apps use a more robust pre-processor strategy)

[jccr]

Yea I agree this solution is not going to be robust, even for the cloud reader.

We'd have to also account for CSS style attributes on SVG elements that can be used with the URL reference as well.

[jccr]

I found a workaround that matched the iframe src (not the blob url, the real src url) and base url while swapping the html element with our bootstrapped html: the SVG works but Javascript does not get executed...

[rkwright]

This issue is now moot since we have abandoned attempts to create a generic iFrame Loader. It does not appear it can be done without significant drawbacks (such as this issue). Therefore we have gone to platform/browser-specific Loaders. So am closing this issue