search

w3c / svgwg

SVG Working Group specifications
Other
699 stars 132 forks source link

Quoted FuncIRI resolving #781

Open RazrFalcon opened 4 years ago

RazrFalcon commented 4 years ago

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:

<svg viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg">
    <linearGradient id="lg">
        <stop offset="1" stop-color="green"/>
    </linearGradient>

    <linearGradient id=" lg">
        <stop offset="1" stop-color="yellow"/>
    </linearGradient>

    <linearGradient id="lg ">
        <stop offset="1" stop-color="blue"/>
    </linearGradient>

    <!-- first column -->
    <rect id="rect1"  x="70"  y="10"  width="20" height="20" fill="url('#lg')"/>
    <rect id="rect2"  x="70"  y="40"  width="20" height="20" fill='url("#lg")'/>
    <rect id="rect3"  x="70"  y="70"  width="20" height="20" fill="url('#lg ')"/>
    <rect id="rect4"  x="70"  y="100" width="20" height="20" fill="url(' #lg')"/>
    <rect id="rect5"  x="70"  y="130" width="20" height="20" fill="url(' #lg ')"/>
    <rect id="rect6"  x="70"  y="160" width="20" height="20" fill="url(' # lg ')"/>

    <!-- second column -->
    <rect id="rect7"  x="100" y="10"  width="20" height="20" fill="url('#lg  ')"/>
    <rect id="rect8"  x="100" y="40"  width="20" height="20" fill="url('#  lg')"/>
    <rect id="rect9"  x="100" y="70"  width="20" height="20" fill="url('# lg ')"/>

    <!-- image frame -->
    <rect id="frame" x="1" y="1" width="198" height="198" fill="none" stroke="black"/>
</svg>

And here are results:

e-svg-037

If we assume that Chrome and Firefox are correct, then why rect7 and rect9 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?

fsoder commented 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.

RazrFalcon commented 4 years ago

So rect3 should be green?

JoKalliauer commented 4 years ago

@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: func.svg

fsoder commented 4 years ago

So rect3 should be green?

Yes, AFAICT.

RazrFalcon commented 4 years ago

@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>

e-use-001

(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>

e-use-002

I don’t even know what to think.

JoKalliauer commented 4 years ago

@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

fsoder commented 4 years ago

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.

RazrFalcon commented 3 years ago

The up to date results:

e-svg-037