Re: [css3-images] Image Fragments and SVG URIs

Dirk Schulze:
>
> There is no problem if media fragments extends SVG 1.1. The backward
> compatibility needs to be  considered. And as discussed during the last SVG
> WG telcon yesterday, the syntax is a bit different, so that URI is not
> necessarily affected. URI needs XML names, while the introduced fragments
> on media fragments need equal signs (which can not be used for XML names
> IIRC). Therefore there is a way to differ between predefined fragments and
> ids #xywh and #t.
>
> Dirk

If we have a look into this:
http://www.w3.org/TR/2011/REC-SVG11-20110816/linking.html#SVGFragmentIdentifiers

[
An SVG fragment identifier can come in two forms:
* Shorthand bare name form of addressing (e.g., MyDrawing.svg#MyView). This 
form of addressing, which allows addressing an SVG element by its ID, is 
compatible with the fragment addressing mechanism for older versions of HTML.
* SVG view specification (e.g., 
MyDrawing.svg#svgView(viewBox(0,200,1000,1000))). This form of addressing 
specifies the desired view of the document (e.g., the region of the document 
to view, the initial zoom level) completely within the SVG fragment 
specification. The contents of the SVG view specification are the five 
parameter specifications, viewBox(...), preserveAspectRatio(...), 
transform(...), zoomAndPan(...) and viewTarget(...), whose parameters have 
the same meaning as the corresponding attributes on a ‘view’ element, or, in 
the case of transform(...), the same meaning as the corresponding attribute 
has on a ‘g’ element).
]

This explictly says, there are only two ways, not three or more.
If '#xywh=...' or ' #t=...' do not reference an SVG element by its ID, as
you already noted, and it does obviously not represent an SVG view
either, it is not applicable for the interpretation of SVG documents similar
to '#17'. Even if authors and viewers ignore the ID/'name' restrictions and
the document does not contain an element with the id '#xywh=...' or ' 
#t=...' , there is no meaningful interpretation.
For authors (including CSS draft authors) this simply means, chose
between the two given options (or wait for a new SVG version with more
options).
I think, up to now we found no problems in extending views SVG 2.0 with this
new syntax - simply do it and this can be used for future SVG 2.0 documents.

About '#t=...' by the way - I think, in typical viewers something like this 
does not even work in the already well defined option to reference an 
animation element ID like animate or set to start an animation with something
like MyDrawing.svg#MyAnimation, if this is not noted within the SVG document 
itself (only bugs or gaps in viewers here, not a conceptual problem).
The problem with '#t=...' and SVG is obviously similar to the problem already
discussed in SMIL about complex time dependent media, resulting in the fact,
that something like dur="media" is not meaningful, therefore we can forget
too simple approaches like '#t=...' for SVG or SMIL documents anyway.


Olaf

Received on Friday, 6 July 2012 12:40:18 UTC