intrinsicRatio and the CSS min/max algorithm

On Aug 8, 2013, at 6:26 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:

> It's specced for <img> at http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width and http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height and the interaction with min-width and max-width is specced at http://www.w3.org/TR/CSS21/visudet.html#min-max-widths (see the part starting "for replaced elements with an intrinsic ratio and both 'width' and 'height' specified as 'auto', the algorithm is as follows").

Thanks Boris for the reference. Yes, the third link with the table of "constraint violation" "resolved width, "resolved height" based on intrinsic ratio is what I would like inline SVG be able to reference. But since inline svg isn't replaced content, as I understand it none of this technically currently applies?

> So anything that's got a CSS box and an intrinsic ratio should get this behavior automatically.  Note that this setup doesn't need an intrinsic width and intrinsic height; just a ratio is enough.  This is why <svg> with percentage intrinsic dimensions in an HTML page behaves sanely: the percentages don't give you an intrinsic width and height but they do give you an intrinsic ratio.

Well, in SVG1.1 using a percentage value for either height and or width on a rootmost svg is supposed to tell the browser to ignore that very percentage value (!) and instead to look at the viewBox dimensions to derive a ratio.

http://www.w3.org/TR/SVG/coords.html#IntrinsicSizing

I will admit that the spec makes strictly logical sense on this point, but it's never been usable cross browser. For one thing, the CSS min/max algorithm as it stands doesn't actually do anything with this intrinsic ratio. So what's it good for? More to the point, using percentage units as the Big Red Switch is just wildly, brainfreezingly counterintuitive. Where else in any modern API does declaring a numeric value tell a program to go out of its way to ignore that very same value?! Totally… freaking... insane….

I actually see this as one of the major obstacles to integrating SVG and CSS. The sizing models are discrepant at the very top level. The spec says: "Note: the ‘width’ and ‘height’ attributes are not the same as the CSS width and height properties." My point is that they should be. There's a whole forest of long-standing layout bugs here that will probably never be resolved until both specs budge a little, and there should be no compatibility worries about changing it to fix things. IMHO this part of SVG1.1 needs to be thrown out completely.

> Your constrainedProportion suggestion seems to be a way to explicitly specify an intrinsic ration as input to this algorithm, right? It seems like even for things that aren't CSS boxes it should be possible to reference this algorithm...

Exactly, yes. The algorithm structure is all there already, and it works perfectly. There just needs to be a lucid way to pass intrinsic ratio information from svg, while leaving the individual dimension attributes set to "auto". Replaced <img> elements typically get this sizing info from image file metadata. Svg has no such resource, so it needs to be spelled out somewhere. SUMMARY: "auto" should be the lacuna value for SVG width and height, "constrainedProportion" or perhaps "intrinsicRatio" should be separated out into its own property, and the CSS visual formatting min/max algorithm should explicitly apply to svg-in-html.

-Ben

Received on Friday, 9 August 2013 17:59:30 UTC