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

Re: Concerns about backwards compatibility of media fragments

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 07 May 2011 20:45:35 -0400
Message-ID: <4DC5E7AF.1020309@mit.edu>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: public-media-fragment@w3.org
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">
   <pattern id="svgView(viewBox(0,20,10,10))" width="1" height="1">
     <rect width="100" height="100" fill="green"/>
<rect width="500" height="500" fill="url('#svgView(viewBox(0,20,10,10))')"/>

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:

<svg xmlns="http://www.w3.org/2000/svg">
<rect width="500" height="500" 

<svg xmlns="http://www.w3.org/2000/svg">
   <pattern id="svgView(viewBox(0,20,10,10))" width="1" height="1">
     <rect width="100" height="100" fill="green"/>

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.

Received on Sunday, 8 May 2011 00:46:05 UTC

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