Re: Concerns about backwards compatibility of media fragments

Hi Boris,

Wow, I wasn't even aware that there is a media fragment example in the
CSS spec: http://dev.w3.org/csswg/css3-images/#url .
It's great news that the spatial media fragments are actually being
considered in CSS now and this will indeed create questions about
things that we may not have considered yet.

In particular the section that you're pointing to in our spec also says:
"..the intention of this document is to propose a specification to all
media type owners in the audio/*, image/*, and video/* branches for a
structured approach to URI fragments and for specification of commonly
agreed dimensions to address media fragments (i.e. subparts of a media
resource) through URI fragments. We recommend media type owners to
harmonize their existing schemes with the ones proposed in this
document and update or add the fragment semantics specification to
their media type registration. "

It's great to see that we are looking at this now for image/svg+xml.
We have previously tried to analyse SVG also in
http://www.w3.org/2008/WebVideo/Fragments/wiki/Existing_Technologies_Survey

I actually think there are two problems that we need to sort through.
So, let me start with the one you've raised.

1. SVG URLs with fragments:

You provided the following example:
<svg xmlns="http://www.w3.org/2000/svg">
   <defs>
     <pattern id="xywh=10,30,60,20" width="1" height="1">
       <rect width="100" height="100" fill="green"/>
     </pattern>
   </defs>
   <rect width="500" height="500" fill="url(#xywh=10,30,60,20)"/>
   </svg>

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?

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?

   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?

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.

It seems to indicate that "bare name" addressing as in #randomstring
is regarded as equivalent to xpointer addressing, e.g.,
MyDrawing.svg#MyView or MyDrawing.svg#xpointer(id('MyView')).

However, "xywh=10,30,60,20" is not a bare name, since it doesn't
quality as an XML name.

The only other addressing that SVG URL fragments define is a function
called svgView, e.g. MyDrawing.svg#svgView(viewBox(0,200,1000,1000))
which seems to restrict the rendering box.

Nothing else is defined.

It seems to that we need to work with the SVG working group on
extending the specifications for image/svg+xml fragment URIs.

Firstly, we would need to ask them to allow structured fragments as in
use by media fragments: http://example.com/svg_ex.svg#param1&param2 .

Secondly, we would need to ask them to extend the allowed
SVGFragmentIdentifier from
   SVGFragmentIdentifier ::= BareName | SVGViewSpec
to something like
   SVGFragmentIdentifier ::= BareName | SVGViewSpec | xwyhFragment

This would make it possible to have URIs such as
http://example.com/MyDrawing.svg#xywh=10,30,60,20&svgView(viewBox(0,200,1000,1000))
, which would render a splice of the svg image into the given viewBox.

I think that would be an acceptable extension to the SVG spec.

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, so any current
implementation should not allow doing #xywh=10,30,60,20 as an
xpointer. If they did, it would be against the spec and such authors
need to expect that their content may not work going forward.


2. Old UAs interpretation inconsistency:

Now to the second problem that I read out of the spec.

I read this example in the CSS spec at http://dev.w3.org/csswg/css3-images/#url:

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.

I think that may be a problem, because if a UA doesn't understand a
fragment, as per URI spec they would still download the full resource
and not raise an error. I think you may need to come up with a better
solution to the problem of old UA/new UA.

Cheers,
Silvia.



On Sat, May 7, 2011 at 4:39 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Section 2.2.1 of http://www.w3.org/TR/2011/WD-media-frags-20110317/ says:
>
>  An analysis of all media type registrations showed that there is
>  not a single media type registration in the audio/*, image/*, video/*
>  branches that is currently defining fragments or fragment semantics.
>
> I'm not sure how this analysis was conducted, but image/svg+xml is defined
> to be SVG and SVG does in fact define fragment semantics.
>
> This means that applying media fragments to SVG images, at the very least,
> would cause behavior changes in current UAs.
>
> For an example, see the simple SVG testcase in
> http://lists.w3.org/Archives/Public/www-style/2011May/0114.html
>
> I'm not quite sure what to do about this problem, honestly.
>
> -Boris
>
>

Received on Friday, 6 May 2011 22:47:19 UTC