W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: [CSS21] Issue 283 - undefining size of replaced elements with intrinsic ratio only

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 22 Mar 2011 18:46:37 -0700
Message-ID: <4D8950FD.4040503@inkedblade.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: "www-style@w3.org" <www-style@w3.org>
On 03/22/2011 04:13 PM, Tab Atkins Jr. wrote:
> On Tue, Mar 22, 2011 at 3:24 PM, fantasai<fantasai.lists@inkedblade.net>  wrote:
>> Proposal:
>> In 10.3.2
>>   # If 'height' and 'width' both have computed values of 'auto' and the
>> element
>>   # has an intrinsic ratio but no intrinsic height or width and the
>> containing
>>   # block's width does not itself depend on the replaced element's width,
>> then
>>   # the used value of 'width' is calculated from the constraint equation used
>>   # for block-level, non-replaced elements in normal flow.
>> Replace "is calculated" with
>>   | is undefined. However it is suggested that it be calculated.
> This describes the behavior of Opera and FF, but Chrome and IE instead
> just default to the standard 300x150 rectangle.  (Well, Chrome does
> for<object>.  For<img>  it does something crazier, where it
> calculates both the width *and* the height to fill available space.)
> I prefer the Chrome/IE behavior, given that we're calculating the size
> of an inline replaced element.  I wouldn't want it to act like a block
> by default and get all huge, automatically dropping down to the next
> line of text.

The resolution was to make it undefined because, due to the misinterpretation
of SVG's percentage widths and heights as intrinsic widths and heights, we
have no implementations. It does not override the previous resolutions we had
that this is the correct and desired behavior.

300x150 is useless for SVG. If you want it, you can get it by specifying
explicitly. But if you want to insert a pretty picture or a graph, the
behavior currently in the spec is much more useful, and not something you
can get otherwise.

Received on Wednesday, 23 March 2011 01:47:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:57 UTC