Re: [CSS21] Width of an absolutely positioned table.

(12/05/11 22:44), Simon Sapin wrote:
> I can’t find anything in the spec on tables with 'position: absolute'.
> In particular, there are two different algorithms that could apply to
> determine their width:
> 
> 10.3.7 Absolutely positioned, non-replaced elements
> 17.5.2 Table width algorithms: the 'table-layout' property (and
> sub-sections)
> 
> I think that a reasonable way to resolve the conflict is to take the
> used width (the result) from 10.3.7 and pretend it is the computed width
> (one of the "input") for the purpose of 17.5.2, and keep *that* used value.
> 
> The only problem is that I made it up. Did I miss something in the spec?

Spec-wise, the beginning of 17.5.2 has this paragraph

  # Note that this section overrides the rules that apply to
  # calculating widths as described in section 10.3. In particular, if
  # the margins of a table are set to '0' and the width to 'auto', the
  # table will not automatically size to fill its containing block.
  # However, once the calculated value of 'width' for the table is
  # found (using the algorithms given below or, when appropriate, some
  # other UA dependent algorithm) then the other parts of section 10.3
  # do apply. Therefore a table can be centered using left and right
  # 'auto' margins, for instance.

so it's reasonable to *guess* that a UA should use 17.5.2 instead of
10.3.7. However, I do think that, the spec should explicitly mention in
the beginning of 10.3 that the section only partially applies to
'table'/'inline-table'.

One reason to support this reading is that, if 10.3.7 is applied before
17.5.2, the whole flow of the algorithm would be quite messy since the
shrink-to-fit width, as required to finish 10.3.7, for 'table' is
essentially 17.5.2.

In terms of existing implemention, I'd note that the difference can be
tested by examining this part of the spec in 17.5.2:

  # 2. If the 'table' or 'inline-table' element has 'width: auto', the
  # used width is the greater of the table's containing block width,
  # CAPMIN, and MIN. However, if either CAPMIN or the maximum width
  # required by the columns plus cell spacing or borders (MAX) is less
  # than that of the containing block, use max(MAX, CAPMIN).

. Note that it says "table's containing block width" instead of "table's
available width", which would be shorter for a abs-pos 'table' when one
of 'left' or 'right' isn't 'auto'.

Testing with[1] gives:

IE8 mode, IE 9, Chrome 21: table's containing block width
Firefox 14, Operal 12 internal: table's available width

(I got interested in this because I was quite shocked to realize that
the "available width" for an 'inline-block' doesn't get shrunk in the
presence of other things in the same line. That's something I would
count as what's weird about CSS 2.1 but I don't think this can still be
changed. The abs-pos 'table' case here seems to share some similarity,
and I guess we can reexamine this for 'width: fill-available' if we
really want to.)

[1]
http://lists.w3.org/Archives/Public/www-archive/2012Aug/att-0014/abs-pos-table-available-width

(12/06/16 21:01), Anton Prowse wrote:
> (Note that the same issue applies to other layout models such as
> flexbox.)

Right. We need to pick either "containing block width" or "available
width" here too.


Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/

Received on Tuesday, 14 August 2012 15:48:16 UTC