- From: Nikos Andronikos via GitHub <sysbot+gh@w3.org>
- Date: Mon, 08 Aug 2016 10:41:45 +0000
- To: public-svg-issues@w3.org
nikosandronikos has just labeled an issue for https://github.com/w3c/svgwg as "DoC_positiveResponse": == Possible to use `<use xlink:href="#id">` in the presence of an HTML `<base>` element? == Apologies if this is not the right venue for this question, but I'm struggling to understand how the spec defines the URL resolution logic when an HTML `<base>` element exists. Please let me know if there is somewhere else I should ask this question. In the example HTML page below [1], the `<use xlink:href="#MJMAIN-39"` element fails to resolve to the `<path>` element due to the presence of the HTML `<base href="https://example.com">` element. This behavior is visible in Chrome 49 [2] and Firefox [3], but is not present in Safari [4]. However, according to my (extremely non-expert) reading of the SVG2 draft spec and XML Base spec, it would appear that this reference should resolve to the local `<path>` element. In particular, the SVG2 spec says at [5] "If the URL reference is relative, its absolute version must be computed by the method described in XML Base before use [XML-BASE]." The XML Base spec then says at [6] "RFC 3986 defines certain relative URI references, in particular the empty string and those of the form `#fragment`, as _same-document references_. Dereferencing of same-document references is handled specially." Taken together, I interpret these as meaning that despite the HTML `<base>` element, `<use xlink:href="#MJMAIN-39"` should be considered a same-document reference and therefore should resolve to the `<path>` element. Is my reading of the specs correct? If not, could you explain where I've misinterpreted them and whether it's possible to reference an element in the same document despite the presence of the HTML `<base>` element? Thanks! [1] ```html <!DOCTYPE html> <html> <head> <base href="https://example.com"> <meta charset="utf-8"> <title>Math Test</title> </head> <body> <svg xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 -1035.6284324052635 9227.414882379479 1501.846702397534"> <defs> <path id="MJMAIN-39" stroke-width="10" d="M352 287Q304 211 232 211Q154 211 104 270T44 396Q42 412 42 436V444Q42 537 111 606Q171 666 243 666Q245 666 249 666T257 665H261Q273 665 286 663T323 651T370 619T413 560Q456 472 456 334Q456 194 396 97Q361 41 312 10T208 -22Q147 -22 108 7T68 93T121 149Q143 149 158 135T173 96Q173 78 164 65T148 49T135 44L131 43Q131 41 138 37T164 27T206 22H212Q272 22 313 86Q352 142 352 280V287ZM244 248Q292 248 321 297T351 430Q351 508 343 542Q341 552 337 562T323 588T293 615T246 625Q208 625 181 598Q160 576 154 546T147 441Q147 358 152 329T172 282Q197 248 244 248Z"></path> </defs> <g stroke="black" fill="black" stroke-width="0" transform="matrix(1 0 0 -1 0 0)"> <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#MJMAIN-39" x="394" y="0"></use> </g> </svg> </body> </html> ``` [2] https://bugs.chromium.org/p/chromium/issues/detail?id=470608 and bugs that have been closed as duplicates, as well as https://bugs.chromium.org/p/chromium/issues/detail?id=449027 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1121708 and https://bugzilla.mozilla.org/show_bug.cgi?id=652991 [4] https://bugs.webkit.org/show_bug.cgi?id=140488 [5] https://svgwg.org/svg2-draft/linking.html#linkRefAttrs [6] https://www.w3.org/TR/xmlbase/#same-document See https://github.com/w3c/svgwg/issues/61
Received on Monday, 8 August 2016 10:41:56 UTC