Re: The (new, enhanced) viewbox property

David Vest:
...
>As you know, 100% is the default value
>for width and height and the sizes will be the be the following:
>
>#1: 100% x 100%
>#2: 100% x 100%
>#3: 50% x 50%
>#4: 0.01% x 0.01%
>
>Then all these are resolved using the document viewport size. So why is
>that?

Alex's test seems to be not accessible (I can only see something not
related to SVG in the reference).
Just looking at the numbers:
As a first approach one should take into account, that the viewport has
a known size, for example for an SVG document directly rendered into
the viewport, this means, an svg element is the root element of the
document.
If we assume that the available viewport is for example 1600px x 1000 px 
(device pixels),
it is simple to calculate width and height:
#1, #2: 1600px x 1000 px
#3: 800px x 500 px
#4: because this results in something below one device pixel, no need to 
display this at all.

It is definitely the task of SVG to define the behaviour, if the svg element
is the root element of a document, but I think, this is already available in 
SVG 1.1 and SVG 1.2, therefore no need to change this.
Authors should be allowed to use the overflow property to determine, whether
something outside the viewBox is displayed or not, this may result in some
display for #4 outside the viewBox. Unfortunately currently it is defined, 
that this is ignored for the root svg element. Because for example SVG 1.1
has no viewport-fill as SVG 1.2, this can result in ugly effects annoying for
authors and the audience, because some element representing the 
background-color is limited to the viewBox now.

If something is embedded into another document, for example in XHTML,
it is quite useful, that the aspect ratio together with the viewBox is used to
determine the size. This should cause no specific problems, if 
preserveAspectRatio is not none and a viewBox is given.
The situation is more complex, if  preserveAspectRatio is none or  viewBox
is not given. This needs to be defined in an understandable way in the
embedding language, here XHTML, respectively if CSS is used, there as
well. Additionally SVG may define the behaviour for all languages, that do
not define such a behaviour.

Jelle Mulder:
>Maybe the whole viewBox issue could have been prevented if there hadn't  
>been a choice of setting 90DPI as the standard resolution for SVG.

This is not the case for SVG. For SVG 1.1 clearly CSS2.0 applies, only
CSS 2.1 has the confusing definition:
1px is equal to 0.75pt.
1pt is equal to 1/72nd of 1in.
1in is equal to 2.54cm.
cm  fortunately is defined as an international standard precisely by
scientific authorities beyond the competence of the CSS working group,
inches are derived from this as well, but this fits to the 2.54cm mentioned
in CSS 2.1.

I haven't seen, that this definition of a pixel is defined in any viewer.
Usually another misleading section of CSS 2.1 is implemented, that
promotes to intentionally break international standards of lengths to 
mislead people about the correct size. This needs to be fixed in CSS 2.1,
but is currently not applicable for SVG 1.1 - therefore viewers having
such a behaviour have a bug.

Indeed this is a bigger problem, that effectively results in wrong presented
absolute units, but this is a bug of viewers, not something that is done 
wrong in SVG.

In the past, I think some viewers had the problem to get it right if one
uses units like em or ex for width and height - but I did not test yet,
whether this is fixed.

Currently I think, we have the situation, that other units than percentages
for width and height often result in a wrong presentation in most viewers due
to bugs in viewers, not due to problems of SVG itself.

My suggestion would be to: 
1) fix bugs/confusing sections in CSS 2.1
2) define behaviour for embedded graphics, if there size cannot be
determined from the graphics itself in (X)HTML and CSS.
3) define behaviour in SVG, if no viewBox is given or preserveAspectRatio is 
none for languages, that do not define themselves a behaviour how to
determine the size of embedded graphics.

4) if 1) remains unfixed and 2) does not happen, add a hint for authors
about these open issues in the SVG 2 draft as none normative text to indicate
at least the origins of annoyances with these issues ;o) this may result in 
the hint for authors not to rely on units, only to use units for width and 
height of the root svg element and always to provide a viewBox or
if preserveAspectRatio is none to explictly set width and height to some 
none percentage value and not to rely on a specific presentation in 
this situation, if the SVG document is embedded in
other documents.


Olaf

Received on Monday, 6 January 2014 12:19:38 UTC