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

> So, it looks like this is up to the UA then to do whatever.
>
> Did I get all that right?
>

Probably :-) CSS gives plenty of wiggle room in some areas.

The idea behind 17.5.2.2 is that you can do something like this:

<html>
  <head>
   <style>td { background-color:gray; font-size:10pt }</style>
  </head>
  <body>
   <table><tr><td style="width:10%">Big</td><td style="width:90%">!</ 
td></tr></table>
   <table><tr><td style="width:10%">Bigger</td><td style="width:90%">! 
</td></tr></table>
  </body>
</html>

and the UA will try and size the first column to be four times the  
width of the second (however wide that may be). In practice, the UAs  
we've tested appear to determine the minimum width each column has to  
be to display it's content and then attempt to expand each column to  
meet this requirement, as you can see with that example. That's only  
for sizing the columns however - the content is still governed by the  
other rules, which kick in once the column has been sized.


Cheers... Mike


On 11 Jul 2006, at 06:18, Shadow2531 wrote:

>
> 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
> <http://www.w3.org/TR/CSS21/cascade.html#q13>
>
> 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
> attribute.
>
> 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
> <http://www.w3.org/TR/CSS21/visudet.html#the-width-property>
>
> "<percentage>
> 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
> 'auto'."
>
> 10.3.2 Inline, replaced elements
> <http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width>
>
> "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
> <http://www.w3.org/TR/CSS21/tables.html#width-layout>
>
> and
>
> 17.5.2.2 Automatic table layout
> <http://www.w3.org/TR/CSS21/tables.html#auto-table-layout>
>
> The last part of 17.5.2.2 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 17.5.2.2 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?
>
> Thanks
>
> -- 
> burnout426
>

Received on Tuesday, 11 July 2006 11:02:49 UTC