Re: The (new, enhanced) viewbox property

Brian Birtles:

> Issue 4: Does the viewbox keep changing if the content moves around or
> its bbox changes?
> Proposal: Yes.
...
>No feedback about this issue.

Maybe it was not obvious, under which circumstances the viewBox should
change at all, respectively what are the use cases for this.
I think, similar things were already discussed in relation to transforms etc.
If it is the purpose of a document to show an object moving on a specific
trajectory, it will contraproductive to change the viewBox. In the worst case
the object will not move at all in the presentation.
To be able to provide characteristic snapshottimes to determine a
boundingBox including all times and to use this as a static viewBox could 
be useful and not always trivial for authors to do.

Something like this and the suggested viewBox value auto can be 
problematic as well with the current usual approach for SVG 1.1 to use
some large element as background color replacement - surely SVG 2
should have the viewport-fill property for this as SVG tiny 1.2 has, but
one has to take into account, that common practice will remain, already
for older viewers, that do not interprete yet new SVG tiny 1.2 features.
Therefore it could be desirable to exclude as well some elements
from such a calculation of the viewBox. 


> Issue 5: The syntax.
> Proposal: viewbox: none | auto | <length>{4}
> - Units are allowed on lengths (including when used as an attribute value)
> - Units may also be omitted as per usual SVG parsing

>No feedback on this issue.

Currently it is a list of numbers or 'none' in SVG tiny 1.2.
Why to introduce the complexity of units here?
In general it is a better approach to follow in general the
tiny profile to restrict units to the width and height attributes
of the root svg element.  
Taking into account, that CSS units typically do not work properly,
as already discussed ;o), one should not add them to
already working features of SVG.

> Issue 7: Can <calc> be used?
> Proposal: Yes, in place of each of the individual <length> arguments.
> Rationale: Why not?

>No feedback here.

Could be interesting, if an SVG fragment or document is embedded into
other content, but one might need to use the suggested SVG parameter
mechanism to make good use of this - would be nice to see examples,
how this could work together.

But of course, one has to take into account, that current viewers will
ignore the complete attribute, because they do not understand values
like 'auto', length units or calc constructs. The addition of only
'none' in SVG tiny 1.2 was not a big problem, because this describes
only the behaviour, what happens anyway, if a viewer discovers an
unknown value.  But if this new syntax is used in the attribute, it will
cause problems with current viewers, interpreting new syntax as 'none'.
Maybe one should add a non normative hint for authors,
that they always should use new CSS syntax only together with 
the viewBox attribute with old syntax to ensure backwards compatibility
as far as possible.


Olaf

Received on Thursday, 9 January 2014 11:09:26 UTC