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: Sun, 8 May 2011 09:02:22 +1000
Message-ID: <BANLkTi=5OM-n2NDe0xPvnXS6+Lk+Sy9f_g@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-media-fragment@w3.org
On Sat, May 7, 2011 at 11:53 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 5/7/11 4:43 AM, Silvia Pfeiffer wrote:
>> 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'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.

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

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

>> 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. Introducing a xywh scheme won't make a difference to

>> Would that not just mean that this feature has not been implemented in
>> browsers yet?
> Well... a number of SVG 1.1 features are not only not implemented yet but
> are planned to be removed.  It's worth checking with the SVG working group
> about the status if svgView().  I'm not familiar with the details there.

Yes, I think that's absolutely necessary. We should liaise with that
group to sort out the addition of the xywh scheme to the svg fragment

>> That browsers for SVG simply ignore fragments
> They don't ignore fragments; if they did none of the SVG out there would
> work.

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. If it doesn't resolve or handle it, it simply
displays the full resource. 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.

>  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. 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 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?
> I haven't.  I also haven't seen any clear evidence that there isn't any.
>  It's something that needs to be looked into.

Can we do some kind of analysis?

Received on Saturday, 7 May 2011 23:03:10 UTC

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