W3C home > Mailing lists > Public > www-svg@w3.org > January 2014

Re: The (new, enhanced) viewbox property

From: Tavmjong Bah <tav.w3c@gmail.com>
Date: Thu, 09 Jan 2014 15:48:55 +0100
Message-ID: <1389278935.2794.14.camel@localhost.localdomain>
To: Erik Dahlström <ed@opera.com>
Cc: 'www-svg' <www-svg@w3.org>, Brian Birtles <bbirtles@mozilla.com>
On Thu, 2014-01-09 at 13:46 +0100, Erik Dahlström wrote:
> On Thu, 09 Jan 2014 03:37:41 +0100, Brian Birtles <bbirtles@mozilla.com>  
> wrote:
> ...
> >> Issue 3: What bounding box to use for (b)?
> >> Proposal: The stroke bounding box as defined in SVG2[2] (which, by the
> >> way, includes markers).
> >> Rationale: It's nearly always more desirable than the geometric bounding
> >> box, at least for simple use cases which is what (b) is aimed at.
> >
> > Alex Bell agrees to using stroke bounding box.[2] No other feedback yet.
> Note: "(b)" refers to "SVG fragment identifiers" when an svg is referenced  
>  from somewhere.
> I would prefer this to be taking into account all possible things that  
> extend the rendered shapes, and I'm not sure the stroke bounding box  
> considers anti-aliasing. I would not expect that to be clipped away  
> because then things at the edges could potentially look bad. Using the  
> stroke bounding box will just give us the same issue later on, and there's  
> also clipping, masking and filters that can affect the resulting "rendered  
> bbox".

I think at least the option to use the 'geometric' bounding box should
be offered. Think of a a triangle with a moving dash pattern on the
stroke, as the dashes move, the 'stroke' bounding box changes. See the
animation at the bottom of:  http://tavmjong.free.fr/blog/?p=821

> An alternative might be to add support for overflowing the svg viewport,  
> though this may only provide the desired result in some cases. Svg used as  
> a tiled css background-image is one example where it might be problematic,  
> or when there's overlapping content and you need the svg to be fully  
> contained.

I would support this alternative.

Received on Thursday, 9 January 2014 14:49:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:50 UTC