Re: bounding box of inline SVG

Hi Olaf,

thanks for the feedback!. This is clearly a complex issue.
I understand that there is a need for fixed size SVG as well as SVG that
scales with the viewport.

My hope is that the browser will treat SVG elements to same as their HTML
siblings by the browser (with the same overflow rules, transforms, transform
points, etc). I think this will put a lot of power in the hands of
designers.

Rik

2011/9/14 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

> 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
>
>
>