Created attachment 244675 [details]
STEPS TO REPRODUCE:
View attached testcase.
(which is a slightly tweaked version of https://bug1121708.bugzilla.mozilla.org/attachment.cgi?id=8549260 )
One blue rect.
Two blue rects.
Please use labels and text to provide additional information.
The second blue rect is from a <use> element, with xlink:href="#original-rect". The problem is, there's a <base> element, which is supposed to set the base URL to be used when resolving relative URLs in attributes in the document (including this xlink:href attribute), as described at https://html.spec.whatwg.org/multipage/semantics.html#the-base-element
So, the xlink:href="#original-rect" URL *should* be interpreted as "/foo#original-rect", which doesn't resolve to anything (in this case), so nothing should show up.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1121708 for a discussion of how this works in Firefox. I'm filing this bug here in the hopes of getting interoperability on this.
NOTE: I filed this on Blink here: https://code.google.com/p/chromium/issues/detail?id=449027
WebKit version tested: Midori version 0.4.3, which reports itself as using "WebKitGTK+" version "1.10.1 (2.4.6)" (in about:version)
I also tested Safari 8 on OS X Yosemite. Same results in each. (and in Chrome)
Firefox matches my EXPECTED RESULTS.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1121708 for discussion on Firefox's behavior.
Blink bug was fixed and now the pages with <base> work interoperably in Edge, Chrome (canary) and Firefox, but not Safari/WebKit
This was resolved last August during Paris face to face SVG WG meeting - https://www.w3.org/2015/08/25-svg-minutes.html#item08
This behavior was changed via https://github.com/w3c/svgwg/issues/61. CSS Values now has <https://drafts.csswg.org/css-values/#local-urls>:
"When matching a url() with the local url flag set, ignore everything but the URL’s fragment, and resolve that fragment against the current document that relative URLs are resolved against."