Open RazrFalcon opened 4 years ago
Since this is URL resolving/parsing it ought to be covered by https://url.spec.whatwg.org/#url-parsing - I believe this says to strip leading and trailing whitespace.
The weird/buggy behavior is probably caused by bugs due to the handling of the "local url flag" (https://drafts.csswg.org/css-values-4/#local-urls).
I filed https://crbug.com/1063694 for Chromium/Blink.
So rect3
should be green?
@RazrFalcon In SVG 1.1 spaces in ids are not allowed? https://validator.w3.org/check?uri=https%3A%2F%2Fgitlab.com%2Finkscape%2Finbox%2Fuploads%2F1ebc0cc8dad3cd4f59cdcc70cb1e5f59%2Ffunc.svg
Image Rendered by your browser:
So
rect3
should be green?
Yes, AFAICT.
@JoKalliauer Good question. Looks like the id
attribute must follow the name token which disallows spaces. Not sure if this is part of the same issue, but here is a test with use
:
<svg viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect id="rect1 " x="20" y="20" width="160" height="70" fill="green"/>
<use id="use1" xlink:href="#rect1 " x="0" y="90"/>
</svg>
(Batik crashed)
So in this case Chrome ignored the IRI, which is strange.
But if we will insert a space inside the id (since trailing spaces are a bit tricky) the picture is different once again:
<svg viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect id="rec t1" x="20" y="20" width="160" height="70" fill="green"/>
<use id="use1" xlink:href="#re ct1 " x="0" y="90"/>
</svg>
I don’t even know what to think.
@RazrFalcon :
Chrome removes trailing spaces in xlink:href=" but not in id
so id="rect1"
with xlink:href="#rect1 "
shows two rect
but if both end with spaces chrome wont render
and id="rec t1"
does not work with xlink:href="#re ct1 "
the middle-space must be at the same pace to get rendered in chrome
Browser UAs don't really care about "valid" in cases like this (and viewers using validating XML parsing is likely quite rare in general). The trailing space in the href
can be URL encoded (%20
) to avoid being stripped in that case.
The up to date results:
Not sure if this is an SVG2 or CSS3 issue, but I'm confused about paint server resolving rules when URL (or FuncIRI in SVG1.1) is quoted.
Here is an SVG in question:
And here are results:
If we assume that Chrome and Firefox are correct, then why
rect7
andrect9
are missing? They do have an extra space, but in some cases it's fine, but in other it's not. Is this algorithm explained somewhere?