Re: The (new, enhanced) viewbox property

Brian Birtles:

...
>Yes, please see my previous reply to Alex where I described such a case.

I could not identify any specific functionality here (maybe due to the script
problem - script interpretation is disabled in my user-agent by default for
unkown resources ;o)

>> If yes and this matters for content, it might be a good idea
>> to provide a mechanism as well to have such a feature for
>> content as well, not just for decoration.

>I'm afraid I don't understand this comment.

CSS properties are about decoration or styling only, this means
is makes no difference for the understanding of the content, if
you remove all styling information. 
If it matters for content, one needs for example
the attribute or another mechanism - similar applies for scripted
parts of documents - if it really matters, this needs to be done
declaratively and scripting is the wrong way.
For SVG most features matter for understanding the content,
therefore the applications for styling or scripting are alternative
views of the content, currently not often done by authors. 
For example with viewBox typically it matters for understanding, 
which fraction of the document one can see, however if the
document contains different alternative views in different areas,
this may matter as well for styling.

Therefore if something can be done only with the property for
styling, one has to think about the question, if this could matter
for content as well.

A typical example is the current problem, that one cannot
animate classes of elements, but one can style
classes of elements. Therefore one should consider to
introduce a feature in SVG 2 to allow the animation of
classes of elements as well, because this is a helpful
use case and such an animation is often relevant for
the interpretation of the content, if present.



About new values for viewBox:
With non numerical values like 'none' introduced already in SVG tiny 1.2
and 'auto' one has to take into account, that this means more complex
implementations for animation - or at least more rules to explain what
to do. If one follows strictly SMIL rules, such possible values mean, 
that there can be only discrete animation.
But we have already specific rules for fill and stroke, resulting typically
in bugs in implementations due to the complexity to get it right to
determine the interpolation method. But this is required, because
often one wants to have continuous animation.
Still one should add some non normative information as a help for
implementors, how to get the interpolation method 
(discrete versus linear/spline/paced) for such complex attributes, 
for example:
'Analyse the values list. If it contains a non interpolable value, chose
calcMode discrete, else use the specified calcMode, respectively the
default linear, if not specified.'
There has to be additional information about additivity for fill and stroke,
that is not applicable for viewBox, because it is not additive anyway.



About width/height:
>That's an interesting idea. If we introduce a new top-level <graphics> 
>element I would be interested in simply removing width/height from its 
>definition for similar reasons.

width and height of the root svg element are quite important for several
use cases, for example for maps with a defined scale, for representing
images of objects in original size or simply if the document contains
raster images and one does not want, that those are scaled up resulting
in a presentation of bad quality.



Tab Atkins Jr.:
>Correct that CSS separates words with dashes, because CSS is ASCII
>case-insensitive for language-defined things.  We traditionally write
>it all lowercase, but you can do whatever casing you want.

>I don't think English has a preference between "viewbox" and "view
>box".  It would likely be just fine for CSS to have a property named
>"viewbox" (which SVG-comfortable authors could write as "viewBox" if
>they chose).

This sounds like a note for such properties would be sufficient/helpful like:
"Note, that the related SVG attribute is 'viewBox', but because property
names are case-insensitive, one can use other representations of 
the property like 'viewbox' as well."


Olaf

Received on Wednesday, 18 December 2013 10:37:50 UTC