- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 06 May 2011 21:36:51 -0400
- To: public-media-fragment@w3.org
On 5/6/11 6:46 PM, Silvia Pfeiffer wrote:
> I'm actually struggling to see what that is supposed to do even when I
> created it and loaded it into my browser.
> Is it meant to create a 500x500 rectangle and fill 100x100 pixels of that green?
Yes.
> What is supposed to happen in these cases?
> http://example.org/svg_ex.svg
> Is this supposed to be an image of size 100x100 or 500x500?
This particular SVG doesn't actually have a size defined; its size is
100% by 100%. Or something. I could have specified a size on the <svg>
itself as well.
> http://example.org/svg_ex.svg#xywh=10,30,60,20
> Assuming that it is not using media fragment syntax, but referring
> to your pattern.
> Is this supposed to be an image of size 100x100 or 500x500?
In this case, sort of 1x1 I believe (that's the width and height of the
pattern). But I'm not sure it necessarily makes sense to call it an
"image". It's a pattern. See
http://www.w3.org/TR/SVG/pservers.html#Patterns
> After some looking around, I found this specification for SVG:
> http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers .
>
> This clearly has some very specific expectations of how SVG URLs
> should be formulated.
Yes, but in practice UAs implement something different.
> I think that would be an acceptable extension to the SVG spec.
Yes, but one that is incompatible with existing UAs, unfortunately.
> As for your concern about ambiguity: SVG URI parsers already have to
> make sure they don't mistakenly interpret
> #svgView(viewBox(0,200,1000,1000)) as a bare name
I believe many UAs in practice simply don't implement that svgView syntax.
> If they did, it would be against the spec and such authors
> need to expect that their content may not work going forward.
That's easy to say, but that doesn't mean that there is no such content
and that UAs will be willing to break it if it's present.
> background-image: url('swirl.png'); /* old UAs */
> background-image: image('sprites.png#xywh=10,30,60,20'); /* new UAs */
>
> The idea in the spec seems to be that the parsing of the second image
> url will fail in old UAs and thus the UA will fall back to the first.
The idea there is that the image() construct is a new construct being
introduced just now, so old UAs won't parse that second declaration
because they have no idea what image() is.
This does rely on UAs not implementing image() before they implement the
#xywh thing, of course.
-Boris
Received on Saturday, 7 May 2011 01:37:20 UTC