W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [CSS21] Issue 142: the term "ancestor box"

From: Peter Moulder <peter.moulder@monash.edu>
Date: Sun, 03 Apr 2011 19:50:25 +1000
To: W3C style mailing list <www-style@w3.org>
Message-id: <20110403095025.GB9285@bowman.infotech.monash.edu.au>
On Fri, Apr 01, 2011 at 02:43:58PM -0700, fantasai wrote:

> [...] Can you take a look and let me know whether there's anything
> remaining ambiguous?
>
> http://www.w3.org/Style/css2-updates/draft-PR-CSS21-201103XX/visudet.html#containing-block-details

It's interesting that this still contains the "ancestor box" wording
that was the start of this issue.  I would guess that Bert would still
consider the new text to mean unambiguously the box of the ancestor
element (because the subject of the sentence is still an element, and
an element can't have a box ancestor), and I would guess that whoever
would have interpreted it in the previous text as meaning ancestor in
the box tree would similarly take that interpretation with the new text
(particularly given that the new "block container" qualifier is a
hyperlink to a definition of "block container box", with no mention of
elements).

Even without run-in, this still makes a difference.

I believe anonymous block boxes make two things clear:

  - That "containing block" needs to be defined for anonymous block
    boxes, so that the coordinates of the anonymous block box are
    defined.

    Whereas the text in the above (201103XX) only defines the
    containing block for elements.  Anonymous boxes by definition don't
    have an associated element.

  - That the inlines in the anonymous block box need their containing
    block to be the anonymous block box, so that because inlines are
    laid out beginning at the top of a containing block and are flowed
    into line boxes that in absence of floats have the width of their
    containing block.

    Note that the anonymous block box isn't the box of any ancestor
    element (or any element), so the existing 201103XX text would be
    wrong if interpreted as "box of the ancestor element".

Another consideration for how 10.1 should be worded is inside list
markers.  Inside list marker boxes "[are] placed as the first inline
box in the principal block box [generated by the list-item element]".
If "ancestor box" in 10.1 were to be interpreted as "box of the
ancestor element" [and if the list-item element in question isn't the
root element], then the list marker's containing block would be
established by some ancestor of the list-item element, whereas all user
agents I've tested agree that the list marker is placed with reference
to the principle block box generated by the list-item element (or, if
the list-item element's first child is block-level, a descendant of
that principle block box), never an ancestor of the list-item.


It seems that

  http://lists.w3.org/Archives/Public/www-style/2010Oct/0540.html

was missed in the scan of the mailing lists for issues.
It raises a number of issues concerning the then-current text for 10.1,
most of which still apply to the 201103XX text.

Some steps have been taken to resolve the issue it raises for item 4,
but I believe some issues remain: The "In CSS 2.1, ... split ... is
undefined" sentence was intended to address the
abspos-child-of-relpos-inline-element cases, but I don't think it goes
far enough:

  - It changes an uncertainty between A and B into an uncertainty
    between A and undefined, still leaving an uncertainty as to whether
    it's defined.

  - If the inline element is split due to bidi instead of line breaking
    then it would still be an uncertainty between A and B.  In the
    appended test case, Gecko goes by box ancestry and the containing
    box is just one of the two boxes generated by the inline, while the
    Konqueror family go by element ancestry and make the containing
    block surround both halves of the element.  (Can someone test
    Opera?  The ancient version that I tested did something weird.)

    (I suspect that the intention was for the Konqueror family
    behaviour, though I suspect that the Gecko behaviour is a bit
    easier to specify and implement.)

(Test case also available at
http://bowman.infotech.monash.edu.au/~pmoulder/html-tests/10.1-inline-relpos-cb.html
.)

The reply by Anton Prowse
(http://lists.w3.org/Archives/Public/www-style/2010Oct/0651.html)
is another message that I think should have had an issue created for
it, because it identifies several places in the spec that seem
inconsistent with section 10.1's definition of the containing block as
merely a rectangle (particularly considering the case of the initial
containing block).  (The resulting issue might be seen as having low
importance, though it might be considered easy enough to address
anyway.)

pjrm.


<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Test of containing block for abspos child of relpos inline element</title>
</head>
<body>
<div>
<span style="position:relative; top:2em; text-decoration:underline;">hello 
 <span style="position:absolute; left:0; right:0; top:0; bottom:0; width:auto; height:auto; background:yellow; z-index:-5;">--</span>
ויקיפדיה</span> ברוכים הבאים
</div>
</body>
</html>
Received on Sunday, 3 April 2011 09:51:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:39 GMT