Re: [CSS21] 17.5.2.1 Fixed table layout and percentages

Le Jeu 17 novembre 2011 5:33, Simon Sapin a écrit :
> Thanks Gérard for the many clarifications.
>
> Le 17/11/2011 00:14, "Gérard Talbot" a écrit :
>> This reference (algorithm of 10.3.3 for blocks) of the spec (recourse of
>> algorithm of 10.3.3) is not implemented in any browser I know of.
>
> So as the spec says, when the width is auto, the automatic layout should
> be used instead. However the automatic layout is not specified and UAs
> can do anything the want … including the fixed layout. I’ll do that at
> first until I implement some kind of automatic layout.
>
>> [snip]
>
> Ok for containing blocks and what percentages refer to.
>
>> " (...) percentage is calculated with respect to the height|width of
>> the generated box's containing block. If the height|width of the
>> containing block is not specified explicitly (i.e., it depends on
>> content height|width), then the value computes to 'auto'. " or a
>> sentence typically similar.
>
> The width of a table always depend on its content.


No, not always. The width of a table does not depend on its content when
'table-layout: fixed' is declared and when it can apply.
With 'width: auto' declared on a table, the resulting width of a table
will depend on its content; with 'width: 400px' declared on a table and a
"reasonable" width set on a cell in first row or on a column, then the
resulting width of such table does not depend on its content.


"
With this (fast) algorithm, the horizontal layout of the table does not
depend on the contents of the cells; it only depends on the table's width,
the width of the columns, and borders or cell spacing.
"
17.5.2.1 Fixed table layout
http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout

'table-layout: fixed' is for *speed* of rendering a table

'table-layout: auto' is for *precision* and imply that tables are not
rendered incrementally. The whole table is rendered only once all
table-rows and their content have been processed. That's the main
difference with the 'table-layout: fixed' rendering mode. The
'table-layout: fixed' rendering mode only need a few values for the table
element and at least one value that applies to the first row and then it
can render the rest of the table.

(Even a non-auto
> width property is actually a minimum.) Does that mean that percentage
> widths on columns or cells can never be used?
>


Setting a percentage width on column can be done, I'm sure.

Setting percentage on cells, right now, I don't know.

>>> The remaining space is then divided for columns that do not have a
>>> width
>>> yet. The remaining space is the tentative width minus everything else.
>> Everything else being: table borders and column borders and cell borders
>> and border-spacing.

I was wrong up here: cell borders should not be excluded from column
width; they are part of column in the border-collapse: separate model and
half of them are in the border-collapse: collapse model.

>
> Paddings are not listed here.

"
1.    A column element with a value other than 'auto' for the 'width'
property sets the width for that column.
2.    Otherwise, a cell in the first row with a value other than 'auto'
for the 'width' property determines the width for that column. If the cell
spans more than one column, the width is divided over the columns.
3.    Any remaining columns equally divide the remaining horizontal table
space (minus borders or cell spacing).
"
http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout

What it means is that the remaining space is equally divided among columns
and columns are made of border cells, cell padding and cell content.


> I guess that the used width of a cell is
> the column width minus the left and right cell padding? So the `width`
> property on cells (of the first row) represents the content width plus
> paddings, unlike other boxes where it is just the content box?
>
>>> (The used width is still not known.) Now what happens if this result is
>>> negative or zero? Is the width of the remaining columns zero or some
>>> other arbitrary value?
>> I assume here that your questions refer to column(s) being set to a
>> percentage value.
>>
>> If it's zero, then remaining columns get zero width. If it's negative,
>> then it's resulting layout is undefined. It's like a situation where a
>> column width would be set to be 110% of table box width.
>
> It can happen without percentages. Example: a 3-column table with
>
> table { width: 300px }
> #first_column, #second_column { width: 200px }
> /* No specified width for the third column */

Here, (assuming such example declared 'table-layout: fixed'),
the resulting layout is undefined.

First column would get 200px, second column gets 200px. Then, when executing
"3. Any remaining columns equally divide the remaining horizontal table
space (minus borders or cell spacing). "
it would imply that 3rd column gets 300px minus (200px plus 200px) which
can not be rendered. This situation is not covered by the spec; such
mathematically impossible situation then could lead (just a possibility)
the rendering engine to trigger the automatic table layout rendering
mode...

>
> Or even with percentages that sum under 100%:
>
> table { width: 300px }
> #first_column { width: 200px }
> #second_column { width: 50% }
> /* No specified width for the third column */

Here, (assuming this example declared 'table-layout: fixed'),
first column would get 200px, second column gets 150px.
"3. Any remaining columns equally divide the remaining horizontal table
space (minus borders or cell spacing). "
it would imply that 3rd column gets 300px minus (200px plus 150px) which
can not be rendered. So, same probable outcome: the resulting layout is
not ocovered by the spec and is undefined according to spec.

>
> What is the width of the third column?


>
> If such cases are undefined,

According to section 17, such cases are undefined. So anything can happen
or is "okay" with the spec.

> can UAs do whatever they want?

Yes. Exactly. They do what they want; they can not follow the spec since
such situations is not covered. So, chances are some browsers will just
choose the automatic table layout when they see that the maths lead to a
negative value for 3rd column. This would be worth testing.

> I’d say the
> most sensible thing to do give a zero width to remaining columns.

It's up to the specification writers to decide, otherwise browser
developers. As far as I understand such situations, there is no
predictable resulting layout and there is no specified resulting layout
according to spec. So, any resulting layout is "okay" with the spec.

>
>> [snip]
>> What your post does not mention - and this can be a real headache - is
>> that 'table-layout: fixed' can apply to 4 types of tables:
>> 1- HTML<table>  with border-collapse set to separate
>> 2- HTML<table>  with border-collapse set to collapse
>> 3- CSS table with border-collapse set to separate
>> 4- CSS table with border-collapse set to collapse
>>
>> and table-layout: fixed covers several possibilities itself: when table
>> has an absolute width (eg: table {width: 300px;}), when table has a
>> relative width (eg: table {width: 40%;}), when table has an auto width.
>> When table has an auto width, then there are sub-categories of
>> possibilities too: if one column has a set width (with relative or
>> absolute width) or if one table cell in first row has a set width
>> (non-auto absolute width), etc... The whole thing can get quite long and
>> complex to test.
>
> Does it matter if a table is made of HTML table elements or not as long
> as the elements have the right table-* values for `display`? (Apart from
> span/colspan/rowspan attributes.)

It can matter if the spec specifically indicate a difference.

Eg.
"
The width of the table is the distance from the left inner padding edge to
the right inner padding edge (including the border spacing but excluding
padding and border).

However, in HTML and XHTML1, the width of the <table> element is the
distance from the left border edge to the right border edge.
"
17.6.1 The separated borders model
http://www.w3.org/TR/CSS21/tables.html#separated-borders

Gérard
-- 
CSS 2.1 Test suite RC6, March 23rd 2011
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Thursday, 17 November 2011 18:18:01 UTC