Re: bounding box of inline SVG

Rik Cabanier:
...
> >
> > As already mentioned, current viewers do not manage absolute units
> > like cm, mm properly and some do not manage em or ex either for width and
> > height, therefore no good idea to use them.
>
> true. However, the coordinates in SVG correspond with 'px' in CSS.
>

For XHTML I typically use em or ex, just because I do not know the 
relation between the preferred font-size of the user and px, therefore
I think, in most cases authors of stylesheets use px units wrong -
could be ok however for raster images (but with the current CSS2.1 there
is no need for viewers to map CSS px to device pixels for raster images,
therefore the use cases for px are limited even more).

In SVG px maps to local units, how much this is on the viewport depends
strongly on transformations (initiated by the user, transform attributes,
viewBox etc) - this is for some authors a problem, if they want to embed
a raster image in SVG without scaling ;o)

> > In the few cases of SVG used in XHTML, I think I used a div container
> > styled
> > and sized with CSS to embed the SVG content. Either it is sized relative
> > to the available viewport or - what is typically suboptimal within an
> > XHTML environment - in px units - here one practically has to separate
> > XHTML text from inline graphics again to manage the coexistence in
> > viewports of different sizes somehow.
>
> OK. So a DIV container with sizing took the place of width/height. So, if
> you change an SVG element, you would have to update the styling of this
> DIV.

Typically I do not want to have a change of the size of the presentation
of the svg element due to changes within it, because this would be 
contraproductive for understanding the content - the rules, why things
changes for example or the aesthetic impression in case of art work.
For example if you have a rectangle rotation around the center of the
viewBox, if bounding box would matter, it would not rotate anymore in
the display of the viewer, if the  bounding box would be updated.
Typically this is not what the author intended - a rotating rectangle ;o)

...
>
> the viewBox is updated every time there is a change to your SVG DOM.
> There is no need to calculate a maximum.
>

Sure, there is, if you want to have the size static, from my point of view
this is the typical use case. I'm not interested in additional scaling,
translation or distortions from the viewer with no relation to my intends.
If I need it, I provide such changes within the SVG...

If you have calculated with some effort including keyTimes and keySplines
an animation of a harmonic oscillator, moving horizontally in the viewBox, 
obviously you do not want a viewBox to oscillate with the inverse
motion to compensate the intended motion resulting in no motion in the
display at all ;o) 


...

>
> Again, just mapping the SVG coordinates to straight 'px' would resolve
> this.
>

Not really, if you want to have it as big as possible for the available
viewport, a fixed size is no solution. 
Or if you have an aperiodic pattern (penrose pattern) done with
a finite number of use elements and the need to limit the displayed area
to a rectangle, that is completely covered by the use elements - depending
on the aspect ratio, there will be only the smallest rectangle displayed, that
is completely covered by the viewport, many things will be outside to be
able to cover quite different aspect ratios. The available viewport determines
size and clipping.


...

> >
> > I think, these models are so different, that there is no or no trivial
> > solution to have both in one document. If you start with XHTML,
> > you will always need some kind of somehow sized box to put the
> > graphics in and the text can flow around or before and after in a
> > flexible way.
>
> I don't see why they are different.
> I agree that things used to be different in HTML, but with the introduction
> of CSS transforms, that is no longer the case.

Well, transforms like rotation for XHTML text with unkown font-size and
unkown viewport size will be quite a lot of fun for authors. 
Because I think, I have no viewer at all that has implemented this
feature already, I do not know, what viewers do - rearrange the text
all the time with different line breaks to keep everything in the viewable
range?
I think, for larger amounts of text in XHTML this is of pretty limited use -
or due to suboptimal stylesheets (font-size in px and width/height in px)
the readability of text gets problematic for users, therefore they use
a minimal font-size in the browser preferences to avoid this (as I do for
many years) and all the px-assumptions of the author get wrong
with the result, that users have to switch off CSS interpretation for
such a web page to get something readable ;o)

> HTML with 'display:block' and CSS transform is almost the same as SVG
> transforms.

You typically do not know the relation of the size of the viewport to the
size of the block in XHTML, therefore you cannot guess the consequences
of transforms properly. With SVG with a given viewBox you always know
the consequences of transforms and using different values of 
preserveAspectRatio you can control, what it means, if the viewBox does
not fit to the viewport. In XHTML you typically have scrollbars, if something
does not fit - and typically you want to avoid horizontal scroll bars to get
better readability.

>
> I'm not proposing of getting rid of the box model. An SVG circle will still
> create a rectangular knockout region.

This can depend von transforms and preserveAspectRatio ;o)

>
> > Starting with SVG, you need always a somehow positioned
> > box (for XHTML or textArea in tiny 1.2) to contain text with
> > automatic arrangements with less relevant importance of graphical
> > appearance - and you have to take into account problems with
> > suboptimal readability of such texts, dependent on magnification.
>
> Yes, text and SVG is a problem.
> I personally think that reflowable text is better done in HTML...
>

If you have both in one document, it is a challenge, or if you
have the need to present for example a poem in a specific
graphical way. For some text use cases it is better to use SVG+RDFa,
for most clearly XHTML+RDFa is the better choice.
Typically for poems there is no advantage in using XHTML,
because it has not markup for poetry at all as SVG,
but for less structured larger amounts of prose of course
SVG gets a nightmare, even with tiny 1.2 textArea ;o) 


A combination of XHTML+SVG is always more complex.
Problems depend on the root element of course, they are
quite different for html than for svg, because they have so
quite different approaches how to align and position the content.
And in some viewers the implementation of XHTML in SVG is
still not worth to discuss of course ;o)
Currently for example in my photo gallery I use PHP scripts
to determine dynamically, whether the output is generated as XHTML
or SVG, but not both in one output. For a combination XHTML+SVG
I have just a few examples with relatively simple layout to 
avoid complications - would be interesting of course to see
more interesting examples with more complex layout, that really work.

>
> I agree that there are many cases where you want your content to scale with
> the browser's page size.
> An author could do this by calculating a matrix that is applied to the SVG
> or we can introduce a new keyword...
>

This already exists, you just have to remove width and height from the root
svg or set them to 100% or 63.2% if you prefer this ;o)
As far as I understand the current situation, it is more problematic for
SVG embedded in XHTML+CSS to say, you want 100% (or 59.3%) 
of the available viewport (or the embedding parent element) 
for the width and calculate the height due to the aspect ratio of the 
viewBox automatically. I think, this is currently not really defined,
but an important use case
(I anybody has seen such a definition or attribute or property combination,
please provide an URI).


Olaf

Received on Wednesday, 14 September 2011 10:12:09 UTC