- From: Shadow2531 <shadow2531@gmail.com>
- Date: Tue, 11 Jul 2006 01:18:17 -0400
- 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 <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 05:18:36 UTC