Re: [css-ui] border-image with an SVG resource that has no intrinsic size

fantasai:
...

>[none]         -> no intrinsic size
>viewBox        -> intrinsic aspect ratio
>width          -> intrinsic width
>height         -> intrinsic height only
>width+height   -> intrinsic width, intrinsic height, and (derived) intrinsic 
aspect ratio
>width+viewBox  -> intrinsic width, (derived) intrinsic height, intrinsic 
aspect ratio
>height+veiwBox -> (derived) intrinsic width, intrinsic height, intrinsic 
aspect ratio
>width+height+viewbox -> intrinsic width, intrinsic height, intrinsic aspect 
ratio

>I'm not really sure what happens when the aspect ratio conflicts with the
>width/height ratio, but in any case, all of this should be specified clearly
>by the SVG spec, and if it's not, it needs to be specified there. The CSS
>specs (Images and Backgrounds) are already very explicit about what happens
>with all combinations of intrinsic {aspect ratio, width, height}.

The viewBox is mainly intended for internal aspects of the
SVG document, the user coordinate system in use.
SVG 1.1.2 does not mention it at all for the determination of the initial
viewport:
http://www.w3.org/TR/2011/REC-SVG11-20110816/coords.html#ViewportSpace
SVG tiny 1.2 or the current draft for SVG 2 do not mention viewBox for the 
determination of the initial viewport either.

In general always and only width and height determine the size 
(if not provided, they are 100% of the viewport, the SVG should 
be rendered in, what implicates, that if there is an element with a CSS box 
with some known size around it, the SVG viewport aligns with this. 
Additionally preserveAspectRatio specifies, how to scale the viewBox into the 
available viewport, this implicates, that the initial viewport is already 
known, before viewBox is considered.
The viewBox itself does not imply any information about the aspect ratio
of the initial viewport for the SVG content. Especially if preserveAspectRatio
is set to 'none', obviously there is no such relation intended by the author
to be meaningful.
This scaling of the viewBox into the initial viewport can implicate, that 
parts of the SVG outside the viewBox are visible on the viewport as well 
or not all of the content inside the viewBox becomes visible in the viewport.
To resume, the viewBox is not related to the size of the SVG.
If noted, it only determines some area of the canvas, that needs
to be transformed to be visible in the initial viewport for the SVG
content.

I think, some viewers use own rules, if the size of the viewport for the SVG 
content is not known either (what effectively means, it is not known, how an 
intrinsic size of 100% for width and height has to be presented), in such a 
case the viewBox might be desireable to determine somehow the aspect ratio or 
even the size of the displayed SVG, if not specified by the embedding format.
Typically for authors and users it could be useful, to take into account 
preserveAspectRatio (if not set to none) and viewBox in case the size 
of the viewport for the SVG is not known. 
For example, typically an author would assume, that if the aspect ratio is 
conserved and the viewBox is present, that the arbitrarily created
viewport at least aligns with the viewBox instead of creating a viewport of
arbitrary aspect ratio, not related to the available information with the
the consequence, that typically the SVG document is unneccesarily scaled
down to fit the viewBox with defined aspect ratio into the created viewport
with arbitrary aspect ratio.
But currently such a situation with unknown size of the viewport for the
SVG is problemantic/unspecified, if not specified already by the embedding
format, therefore in doubt authors need to avoid this.

My observation with common viewers is, that they even display problematic
things, if the viewport size is completely defined by CSS,
Assume for example an element xhtml:figure with the following styling:
figure {display: block; width: 20em; height: 20em; flow: left}
The content of the figure is an SVG, width and height are 100%, 
viewBox="0 0 400 800", implicated preserveAspectRatio 'xMidYMid'.
Unfortunately several common viewers seem to ignore the height of 100%
and present the viewBox area with a width of 20em and a height of
40em (this is 200%, not 100%), 
with the result of an overlap with other content.
Correct would be obviously a height of 20em and the width
of the viewBox area is scaled to 10em.
But if there is content in the SVG on the left or right of the
viewBox, this can be visible, because the viewport of the SVG
aligns here with the box of the CSS styled xhtml:figure element with 
a width of 20em and a height of 20em.
Therefore even such simple situations, pretty relevant for authors,
are worth to be tested carefully to ensure, that future versions of
viewers do something meaningful here for such common use cases
to size different SVGs within a text with the same stylesheet dependent
on units like em to get 'responsive design/styling'.
Not sure, whether such testing is more a task for CSS or SVG, maybe
more for SVG, because the viewer determine a wrong scaling from the
size of the initial viewport and the viewBox. On the other hand, such a test
requires CSS interpretation and embedding within another format.

Olaf

Received on Thursday, 18 June 2015 12:05:49 UTC