Re: Concerns about backwards compatibility of media fragments

On Sun, May 8, 2011 at 10:45 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/7/11 7:02 PM, Silvia Pfeiffer wrote:
>>>
>>> I'm not sure what exactly you tried or in which Firefox version...  If
>>> you
>>> take the SVGs snippet I sent and load it as an SVG file, it shows a 100px
>>> by
>>> 100px green rectangle, in at least Firefox 4, Opera 11, Chrome 11, Safari
>>> 5.
>>
>> Yes, it does that. What I am concerned about is the URL with the
>> fragment, since that is what we are talking about.
>
> Right.  I'm particularly concerned about the use of such a URL as a fill
> value in SVG.
>
>> This URL used in a browser:
>> http://example.org/svg_ex.svg#xywh=10,30,60,20 where the SVG file has
>> an element with an id="xywh=10,30,60,20".
>
> I'm not so much interested in what happens when this URL is used in the url
> bar at the moment.  Maybe that's the confusion.  I'm interested in what the
> fill should be.
>
>> What is it that the browser does with this URL that makes it conflict
>> with what it will do when the browser supports the media fragment
>> scheme?
>
> When used in the fill value, right now browsers resolve that url to a
> pattern element and use that pattern.  With the media fragment thing the
> browser would presumably need to resolve the url to a rectangle cut out of
> the overall SVG image and use that as the pattern, which is a behavior
> change, no?
>
>>>> I certainly can confirm that
>>>> http://example.com/svg_ex.svg#svgView(viewBox(0,20,10,10)) doesn't do
>>>> anything in Firefox.
>>>
>>> Does it do anything in any other UA?
>>
>> Oh yeah, wow - it does in Chrome (probably all Webkit). It will indeed
>> change the viewBox. Thus, the problem that you are concerned about
>> already exists.
>
> Interesting.  Looks like WebKit is just inconsistent in how it treats url
> references.  That's just really bizarre behavior....  Try this testcase:
>
> <svg xmlns="http://www.w3.org/2000/svg">
> <defs>
>  <pattern id="svgView(viewBox(0,20,10,10))" width="1" height="1">
>    <rect width="100" height="100" fill="green"/>
>  </pattern>
> </defs>
> <rect width="500" height="500" fill="url('#svgView(viewBox(0,20,10,10))')"/>
> </svg>
>
> I can't think of a sane way to think of how WebKit handles that given their
> url bar behavior.  And thing get even worse in this situation, when you have
> two files:
>
> test.svg:
> <svg xmlns="http://www.w3.org/2000/svg">
> <rect width="500" height="500"
> fill="url('test2.svg#svgView(viewBox(0,20,10,10))')"/>
> </svg>
>
> test2.svg:
> <svg xmlns="http://www.w3.org/2000/svg">
> <defs>
>  <pattern id="svgView(viewBox(0,20,10,10))" width="1" height="1">
>    <rect width="100" height="100" fill="green"/>
>  </pattern>
> </defs>
> </svg>
>
> This should have the same rendering as the example above, whatever that
> rendering is (and this is the case in Presto and Gecko), but in WebKit it
> doesn't because it doesn't actually support pattern references in SVG
> (including resource documents) correctly.
>
>> Introducing a xywh scheme won't make a difference to that.
>
> It will to the case I care about, which is the fill value.
>
>> You seem to misunderstand how URI fragments are defined in the URI
>> standard (http://www.ietf.org/rfc/rfc3986.txt): a fragment on a URI is
>> resolved by the UA.
>
> Yes, I understand that.
>
>> If it doesn't resolve or handle it, it simply displays the full resource.
>
> Yes, I understand that too.
>
>> Thus, nothing will break when providing a
>> broken fragment: the full resource will simply be displayed. And
>> that's exactly the effect I am seeing.
>
> See testcases above.  Again, it seems like the behavior of fill in my
> original testcase in this thread will change.
>
>>>  But as far as I can tell they simply don't enforce the "must be an
>>> XML Name" syntax restriction from SVG 1.1.
>>
>> That's only when you are looking at how this is dealt with within the
>> SVG image.
>
> Yes, that's the case I'm interested in for the moment.  But note that SVG
> allows cross-document pattern references, so it's not "within" in any sense.
>  It's just a URI.
>
>> It seems different to me what the browsers do in the URL
>> bar than what they do within the resource when interpreting relative
>> links to other objects in the SVG file. That is not really a concern
>> of ours.
>
> That's not the issue I'm concerned with.
>
>> Can we do some kind of analysis?
>
> That would be ideal, yes.
>
> -Boris
>

Are you part of the SVG working group? If not, this is probably a good
time to start talking to somebody involved in the SVG WG to find out
what their plans are for conformance on these urls etc. and start some
analysis.

Silvia.

Received on Sunday, 8 May 2011 04:48:47 UTC