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

Tab Atkins Jr.:
>Media Fragments were designed for arbitrary media. It wouldn't make
>much sense to use something named "svgView()" on a PNG, after all.
>^_^  Even if it duplicates existing specced functionality in SVG, it
>would be nice if MF syntax worked on SVG as well as raster images.

I did no test here, if we assume, that available viewers indicate problems
with fragment identifiers like id="xywh=" or id="t=..." anyway, 
no author will have used such structures, allowed or not. 
And even if some viewers might accept 'wrong' values for id (I think, some
do), the probability that someone used such values will be low, is my
guess. Therefore indeed, it might not cause any/relevant backwards 
incompatibility problems, if such an addition to indicate another view
of the document in SVG2 is defined respectively referenced.
Obviously for SVG 1.0, 1.1 and tiny 1.2 this is still wrong and
authors nevertheless have to use for example
sprites.svg#svgView(viewBox(40,0,20,20))
to get the intended effect.
Therefore it is still a good idea to modify the example in
http://dev.w3.org/csswg/css3-images/#image-fragments
in such a way, that one example uses something like
background-image: image('sprites.png#xywh=40,0,20,20')
and another example, that is correct for current SVG documents, 
(similar to example 4 in the draft):
background-image: image('sprites.svg#svgView(viewBox(40,0,20,20)))
This can avoid further confusion (and disappointments for authors with older 
and current SVG viewers, resulting in long discussions in tutorials and
forums, why one should not use the SVG example in this CSS draft for
best practice).

I think, the behaviour of the MF syntax is more or less defined, if applied to
SVG documents, including some advice to ignore it, if it does not
fit, for example a pixel-unit notation for a document with percentage width
or height. For other combinations like document size in units like mm, em, ex
the problem will not be larger than already now, due to the known problems
of viewers to determine the size of such documents correctly.
But this looks like an area, that requires tests to ensure, that viewers do
something useful, if the size of the document is not given in pixel ;o) -
obviously, those are important use cases for SVG documents for sprites etc,
scaling in good quality.

Olaf

Received on Thursday, 5 July 2012 11:08:07 UTC