W3C home > Mailing lists > Public > www-style@w3.org > July 2006

Re: Elements styled with width:value% inside a table with width="auto"

From: Shadow2531 <shadow2531@gmail.com>
Date: Tue, 11 Jul 2006 01:18:17 -0400
Message-ID: <6b9c91b20607102218o5ebd21dbhda1c7a22dbbc3ed9@mail.gmail.com>
To: www-style@w3.org

On 7/10/06, Mike Bremford <mike-css@bfo.co.uk> wrote:
> My understanding is it's undefined: from http://www.w3.org/TR/CSS21/
> visudet.html#propdef-width

Thanks Mike.  I'll just go over what I got out of your post.

For the Textarea situation in first post:

6.4.4 Precedence of non-CSS presentational hints

That says:

1. cols is a presentational attribute.
2. If the UA decides to use it, it should be translated to a css width
with a specificity equal to 0 and act as if it was inserted at the
beginning of the first stylesheet.
3. If a css width for the textarea is defined, it will therefore
override the previous css width that was generated from the cols

So, right there, that says if you define a css width, it *overrides*
the width generated by the cols attribute.
Then, because of the following, the behavior is undefined.

10.2 Content width: the 'width' property

Specifies a percentage width. The percentage is calculated with
respect to the width of the generated box's containing block. If the
containing block's width depends on this element's width, then the
resulting layout is undefined in CSS 2.1."

For the Image situation in first post:

10.2 Content width: the 'width' property
"The width of a replaced element's box is intrinsic and may be scaled
by the user agent if the value of this property is different than

10.3.2 Inline, replaced elements

"Percentage intrinsic widths are first evaluated with respect to the
containing block's width, if that width doesn't itself depend on the
replaced element's width. If it does, then a percentage intrinsic
width on that element can't be resolved and the element is assumed to
have no intrinsic width."

So, according to that, since a percentage of the intrinsic width
cannot be resolved, the UA should assume that there's no intrinsic
width, and if there's no assumed intrinsic width, there's no intrinsic
width to fall back on in the case of undefined behavior mentioned for
percentages in 10.2

So, since none of that helps there are:
17.5.2 Table width algorithms: the 'table-layout' property

and Automatic table layout

The last part of says:

"A percentage value for a column width is relative to the table width.
If the table has 'width: auto', a percentage represents a constraint
on the column's width, which a UA should try to satisfy."

Also, there's mention of min and max width in that section.

Also, there's this:

"Note. In this algorithm, rows (and row groups) and columns (and
column groups) both constrain and are constrained by the dimensions of
the cells they contain. Setting the width of a column may indirectly
influence the height of a row, and vice versa."

Section rings a bell and kind of describes what Gecko and
KHTML do. When they "try to satisfy" for the undefined percentage
situation, they use the intrinsic width of the image and the cols
attribute of the textarea to do it. When they do that, they break the
css rules listed above, but only after correclty following the rules
leads to undefined behavior.

So, it looks like this is up to the UA then to do whatever.

Did I get all that right?


Received on Tuesday, 11 July 2006 05:18:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:46 GMT