Re: [CSS21] (Appendix E) Are inline-blocks "block equivalent"?

On 18/07/2012 09:48, Anton Prowse wrote:
> On 15/07/2012 00:38, Anton Prowse wrote:
>> On 15/05/2012 00:05, Anton Prowse wrote:
>>> On 11/05/2012 16:07, Simon Sapin wrote:
>>>> Appendix E uses this sentence twice:
>>>> "If the element is a block, list-item, or other block equivalent"
>>>>
>>>> What is a "block equivalent"? Do inline-blocks fall in that category?
>>>>
>>>> I’m trying to figure out how to make sure that inline-blocks (that may
>>>> or may not be positioned, with z-index that may or may not be 'auto')
>>>> get their background and borders painted exactly once...
>>>
>>> Yes, this does seem a bit muddled, doesn't it.
>>
>> This issue is now filed at
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17778
>>
>>> I think Step 2 should in fact be talking about block containers.

>>> On a related note,  the second list of Step 2 which purportedly applies
>>> to stacking contexts which are block-level tables is nonsensical: the
>>> list is clearly talking about the table box, yet in CSS21 a table box
>>> cannot be a stacking context (since the 'position' property affects the
>>> table wrapper box instead).  This is a left-over from the days when
>>> there was confusion between the table wrapper box (which may be
>>> block-level or inline-level) and the (always block-level) table box.

>> [...] we need to wait until Step 4 to paint the table box (since
>> the table caption box might have a negative stack level and thus
>> need to be painted in Step 3 underneath the table box; see
>> practical confirmation below) [...] Step 4 is written in terms of
>> descendant elements of the table element in question and is thus
>> not immediately suitable for subsidiary /boxes/ of the element
>> itself.

(This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=17782 )

> [...] the term "element" is defined specially
> in E.1 to include certain boxes. It would assist the proposals for both
> the issues with E.2 described above, and particularly the latter one, if
> we were to widen that definition slightly to include the table box
> generated by a table element - which seems likely to have been the
> author's intention anyhow.  (Similarly, the definition doesn't seem to
> include the marker box of a list item, and yet a subsequent sentence
> explicitly uses it as an example, so we can take the opportunity to
> clarify that at the same time.)  Note that this is effectively what my
> proposed extra wording for Step 2 was doing independently, in the
> proposal above.

[Snip Proposal C, which didn't correctly handle the propagation of the 
background of a table box of a root table or inline-table element to the 
canvas.]

The following proposal has a dependency on the proposal in [2], filed as 
[3], which sets up the wording of the introductory paragraphs of E.2 in 
such a way that we can easily extend to handle the case of table box 
background propagation.

Proposal D:

(a) Adopt Proposal A for [3] (or any subsequent proposal for that issue 
which maintains the editorial device of discussing background 
propagation prior to the painting order algorithm and leaves the 
algorithm written in a manner which focuses the more typical general case).

(b) Modify said proposal in the following manner:

In E.2, prepend to the following existing prose:

   # The painting order for the descendants of an element generating a
   # stacking context (see the 'z-index' property) is:
   #
   # 1. If the element is a root element:
   #    1. background color of element over the entire canvas.
   #    2. background image of element, over the entire canvas, anchored
   #       at the origin that would be used if it was painted for the
   #       root element.

the following additional prose:

   | The background color and image of a child element of a root
   | element is sometimes painted over the entire canvas instead of that
   | of the root element itself.  This happens <ins>in the case of a
   | table box associated with a root table wrapper box, and</ins> _in
   | some situations with HTML and XHTML documents_<link to 14.2>.  When
   | this happens, no background is painted for that child element.  User
   | agents must apply these rules instead of the ones below whenever
   | the latter concern the elements and backgrounds in question.

(c) In 9.2.1 (Block-level elements and block boxes), replace:

   # [...] Some block-level elements may generate additional boxes in
   # addition to the principal box: 'list-item' elements. [...]

with:

   | [...] Some block-level elements may generate additional boxes in
   | addition to the principal box: 'list-item' elements may generate a
   | marker box, and table elements generate a _table box_<link to
   | 17.4>. [...]

(d) In E.1 (Definitions), replace:

   # Element
   #   In this description, "element" refers to actual elements,
   #   pseudo-elements, and anonymous boxes. Pseudo-elements and
   #   anonymous boxes are treated as descendants in the appropriate
   #   places. For example, an outside list marker comes before an
   #   adjoining ':before' box in the line box, which comes before the
   #   content of the box, and so forth.

with:

   | Element
   |   In this description, "element" refers to actual elements,
   |   pseudo-elements, marker boxes and table boxes _additionally
   |   generated_<link to 9.2.1> by list items and by block- and
   |   inline-level table elements respectively, and anonymous boxes.
   |   Pseudo-elements, additionally generated boxes and anonymous
   |   boxes are treated as descendants in the appropriate places.
   |   For example, a table box precedes a table caption, whilst
   |   an outside list marker comes before an adjoining ':before' box
   |   in the line box, which comes before the content of the box,
   |   and so forth.

(e) In E.4 Step 2, replace:

   # If the element is a block, list-item, or other block equivalent:
   #   [...]

with:

   | If the element is a block container or block-level replaced
   | element:
   |   [...]

and delete:

   # Otherwise, if the element is a block level table:
   #   1. table backgrounds (color then image) unless it is the root
   #      element.
   #   [...]
   #   7. all table borders (in tree order for separated borders).

(f) In E.2 Step 4, replace:

   # For all its in-flow, non-positioned, block-level descendants in
   # tree order: If the element is a block, list-item, or other block
   # equivalent:
   #
   #   [...]
   #
   # Otherwise, the element is a table:

with:

   | For all its in-flow, non-positioned, block-level descendants in
   | tree order:
   |
   | If the element is a block container or replaced element:
   |
   |   [...]
   |
   | Otherwise, the element is a table box:


> Note 1: the change to 9.2.1 links to 17.4 for table box because it would
> probably be naively assumed by the reader unfamiliar with tables that
> the table box is the principal box of a table element (which is false of
> course).  Note also that 9.2.1 is nominally about block-level tables,
> and so I haven't explicitly said that an inline-table element similarly
> generates an extra box; but I think it can be inferred, and of course my
> proposed change to E.1 indicates so explicitly by linking back to this
> section.  Ideally, my suggestion in [1] to define "block container
> element" and "principal box" of block container elements would be used
> to solve that problem completely, since then 9.2.1 would be saying that
> /block container elements/ may generate additional boxes, and we could
> call out inline tables alongside block-level tables.

> Note 3: "the element is a table box" sounds weird, but given the special
> definition of element in E.1 it's actually correct.  It also serves to
> remind the reader that, in Appendix E at least, "element" isn't quite
> what it appears.
>
>
> [1] http://lists.w3.org/Archives/Public/www-style/2012Jul/0338.html
   [2] http://lists.w3.org/Archives/Public/www-style/2012Jul/0478.html
   [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18344

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Friday, 20 July 2012 16:35:35 UTC