Re: The (new, enhanced) viewbox property

Alex,

I tend to use the <svg width="100%" veiwBox="some dimension"  
aspectRatio="something"> a lot to make my designs render at the full width  
or height of the browser screen and make it scale across different  
resolutions. This is an easy way to make sure that the whole graphic  
displays the way you intend. Sometimes I'll even use -20% as to make sure  
resizing and scrolling doesn't create white artifacts.

I would be very sad with having only user units for the defenition. I'd  
rather think the way Opera 9-12 handles it is the way and maybe the  
standard should define it the way it is implemented in that browser. Seems  
a more logical solution to me to clarify how it should be doen.

Browser compatibility? Firefox will not render the offscreen area, unlike  
Opera 9-12, not even when scaled to smaller size. Blink renders off-screen  
fine, but still hasn't fixed the xlink regression bug since Chrome 19, I  
have no clue about Safari and MSIE,.. well.. Might have a look at it some  
time when they stop harassing me with all the dependencies in Whinedo's.

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. It  
would have been nice if the SVG root had something like  
pxPerMeasurementUnit="10" or something like that so you could set how many  
pixels per mm you'd like to define and scale that way.

Now authoring software ends up with insane 3.45etc. px  per mm settings,  
which makes working with mm a real joy. Or allow this setting to be  
included in SVG root and viewBox elements to make scaling a bit more  
enjoyable.

Regards,

Jelle Mulder

On Sat, 21 Dec 2013 10:22:41 +0800, <alex@bellandwhistle.net> wrote:

> On 2013-12-16 19:14, Brian Birtles wrote:
>
>> That's an interesting idea. If we introduce a new top-level <graphics>
>> element I would be interested in simply removing width/height from its
>> definition for similar reasons.
>
>
> Thanks Brian, I initially had the same thought, but on reflection have  
> come to the opposite conclusion: I think the spec should retain width  
> and height attributes in order to calculate intrinsic viewport aspect  
> ratios.
>
> The elephant in the room is that the spec doesn’t distinguish between  
> the intrinsic sizing of an SVG viewport, and the intrinsic sizing of a  
> viewbox. These are actually completely different things, which the spec  
> (written long before the heyday of responsive design, let alone  
> object-fit) confusingly treats as one. (They can of course be  
> numerically equal.) When object-fit has sunk into everyone’s heads a bit  
> more I think this will suddenly become obvious all around. Object-fit  
> doesn’t yet tackle the question of the viewbox. It only concerns the SVG  
> viewport and its container. The SVG spec says for the intrinsic sizing  
> of the viewport to derive from the intrinsic sizing of the viewbox when  
> an dimension attribute value is missing, or supplied in percentage  
> units, but the two aspect ratios are still essentially different, and  
> they ultimately have different use cases in layout. When object-fit asks  
> for the intrinsic ratio of an SVG viewport, it will be tempting but  
> wrong to hopscotch over the viewport ratio and pass the viewbox ratio.  
> That distinction needs to be specc'ed.
>
> I understand the appealing simplicity of throwing out height and width  
> attributes completely for a new element, and punting all rootmost  
> viewport sizing to CSS, but I also don’t think that preserves the  
> meaning of the word “intrinsic” for a rootmost viewport. CSS sizing is  
> arguably never “intrinsic” in the sense of "natural". And it doesn’t  
> preserve the possibility of different aspect ratios for the viewport and  
> the viewbox, which object-fit requires in order to work properly as  
> written.
>
> More generally, I think there needs to be a simultaneous breakthrough in  
> the spec in terms of both viewport sizing and viewbox sizing, and their  
> relationship. They need to be distinguished, but harmonized, without  
> simply pointing at each other in a circular fashion. I’ll try to  
> summarize:
>
> One problem is that numeric percentage values apparently have no  
> semantic meaning for rootmost svg. Is there ever a case according to  
> spec in which rootmost:
>
> <svg width=“100% height=“100%”>
>
> is handled differently from
>
> <svg width=“50% height=“50%”>
>
> or even
>
> <svg width=“0.01% height=“0.01%”>
>
> Because these all have the same intrinsic dimensions (none, no viewbox),  
> CSS specified size (none), and same default object size, the viewports  
> should all render identically. Quick test:
>
> http://jsfiddle.net/CYLjW/
>
> No browser renders the “0.01” case, which I would argue is technically a  
> bug. But besides that, results in current browsers are all over the  
> place:
>
> -Chrome Canary renders the <rect>s all at the same size, but the  
> containing viewports are all different sizes. This is an old,  
> longstanding bug.
> -Firefox Aurora renders the <rect>s in #1, #2, #3 all at different  
> widths (but the same height). Since none of these have a viewBox, and  
> 100% is the lacuna height/width value, shouldn’t the viewports of  
> examples #1 and #2 match?
> -IE11 renders the viewports all overlapping, and very badly broken.
> -Opera 12 renders the width of the second rect in #3 at a different  
> size, but leaves the first the same (?).
>
> In short: zero compatibility. And this is just one example.
>
> I think the problem here is in the spec, not with broken implementations  
> per se. Without going into great detail, there is a circularity[1] where  
> non-percentage dimensions are being defined to specify intrinsic aspect  
> ratios, and intrinsic aspect ratios are referencing dimensions, with  
> neither part of the specification actually yielding what we need: a  
> step-by-step algorithm to determine rootmost viewport dimensions.
>
> As a further complication, since 100% is currently the lacuna value for  
> both height and width, browsers have to consider whether that percentage  
> value is coming from an explicit stated attribute, a UA stylesheet, or  
> some other internal value. This seems another part of the recipe for the  
> existing confusion.
>
> Here are some compromise possibilities to address some of these issues  
> short of a new <graphics> element:
>
> - For rootmost SVG and <graphics>, only accept width and height  
> attribute values in user units. Physical sizing (em,mm,px) can be done  
> in CSS. Disallow percentage values for rootmost element attributes.  
> Percentages don’t yield an independent intrinsic ratio for the viewport.  
> There will be no breakage, because an invalid dimension attribute will  
> simply instruct the browser to derive aspect ratio from the viewBox, if  
> supplied. This would clarify things, and there’s no meaningful current  
> compatibility to break.
>
> - The lacuna value for rootmost svg dimensions could be “auto”, not  
> 100%. This could be further defined in terms compatible with css. We  
> ought to get away from percentages entirely for the rootmost case,  
> because the numbers aren’t defined to be meaningful, and because there  
> is an understandably strong tendency on the part of both browsers  
> (Webkit) and authors to understand them in terms of the containing block.
>
> - A detailed algorithm for generating rootmost viewport dimensions needs  
> to be written, similar to that already existing for replaced content in  
> HTML, that harmonizes with the elegance of object-fit, and specifies SVG  
> default object size.
>
> - nit: standardize on either “outermost” or “rootmost” and use either  
> one or the other consistently across the spec. I'm using rootmost out of  
> habit but don't have a strong preference.
>
> Cheers,
> Alex
>
> [1] https://svgwg.org/svg2-draft/single-page.html#coords-IntrinsicSizing

Received on Saturday, 21 December 2013 06:19:02 UTC