W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2011

Re: Concerns about backwards compatibility of media fragments

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 7 May 2011 18:43:20 +1000
Message-ID: <BANLkTi=i0d_xqtnLgRNSh9Ce1ZEA9GrrNg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-media-fragment@w3.org
On Sat, May 7, 2011 at 11:36 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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 tried your example in Firefox and I didn't seem to do anything - it
definitely didn't make the image a 1x1. So, I wonder what makes you
think that browsers do something with the fragment.


>> I think that would be an acceptable extension to the SVG spec.
>
> Yes, but one that is incompatible with existing UAs, unfortunately.

Can you show how? I wasn't able to reproduce any incompatibility.


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

I certainly can confirm that
http://example.com/svg_ex.svg#svgView(viewBox(0,20,10,10)) doesn't do
anything in Firefox.

Would that not just mean that this feature has not been implemented in
browsers yet? That browsers for SVG simply ignore fragments and that
therefore we have to make sure the spec makes sense, talk with the
browsers, and get the schemes implemented?


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

Where have you seen such content?


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

Ok, good to know. So that's not a problem then.

Cheers,
Silvia.
Received on Saturday, 7 May 2011 08:44:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC