W3C home > Mailing lists > Public > www-style@w3.org > March 2012

Re: [CSS21] 10.1 Containing block: when "the ancestor is an inline element": editorial improvements

From: Gérard Talbot <www-style@gtalbot.org>
Date: Fri, 9 Mar 2012 13:49:06 -0500
Message-ID: <346b90417f2b448c090e1ae09f2e6c21.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Alan Gresley" <alan@css-class.com>
Cc: "W3C www-style mailing list" <www-style@w3.org>

Le Jeu 8 mars 2012 23:59, Alan Gresley a écrit :
> On 8/03/2012 4:10 PM, "Gérard Talbot" wrote:
>> Hello,
>>
>> Section 10.1, bullet 4 (with sub-bullets 1 and 2)
>> http://www.w3.org/TR/CSS21/visudet.html#containing-block-details
>>
>> Current text is:
>>
>> {
>> 4. If the element has 'position: absolute', the containing block is
>> established by the nearest ancestor with a 'position' of 'absolute',
>> 'relative' or 'fixed', in the following way:
>>
>>    1.  In the case that the ancestor is an inline element, the
>> containing
>> block is the bounding box around the padding boxes of the first and the
>> last inline boxes generated for that element. In CSS 2.1, if the inline
>> element is split across multiple lines, the containing block is
>> undefined.
>>    2.  Otherwise, the containing block is formed by the padding edge of
>> the
>> ancestor.
>> }
>>
>>
>> Proposed replacement (the pairs of ** indicate where editorial changes
>> would be):
>>
>> {
>> 4. If the element has 'position: absolute', the containing block is
>> established by the nearest ancestor with a 'position' of 'absolute',
>> 'relative' or 'fixed', in the following way:
>>
>>    1. *In case such nearest positioned ancestor is an inline element,
>> then*
>> the containing block is the bounding box around the padding boxes of
>> the first and the last inline boxes generated for that element. In CSS
>> 2.1, if the inline element is split across multiple lines, the
>> containing
>> block is undefined.
>>
>>    2. *In case such nearest positioned ancestor is a block container,
>> then*
>> the containing block is formed by the padding edge of such block
>> container.
>> }
>>
>>
>> What can definitely create confusion and misinterpretation is this
>> proposition:
>> "In the case that the ancestor is an inline element (...)"
>> when the proposition should at least explicitly identify such ancestor
>> as
>> "the nearest positioned ancestor".
>>
>> Gérard
>
> Gérard, there is confusion in that part of the testsuite (test that are
> not testing what they purport to test) and section 10.1.

Alan,

I totally agree with you. containing-block-011 to 021

http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-011.htm

http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-013.htm

http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-015.htm

http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-017.htm

http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-018.htm

http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-019.htm

http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-020.htm

http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-021.htm

have issues, meta text assert confusion, difficulties. I am reviewing
those tests these days.

[RC6] containing-block-011, 013, 015 incorrect
http://lists.w3.org/Archives/Public/public-css-testsuite/2012Mar/0007.html

And we already discussed/met such difficulties in 2 threads in dec. 2010
and january 2011:

[RC3] containing-block-017 and containing-block-003 not testing what they
are supposed to test
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Dec/0202.html

and

[RC4] and [RC5beta] containing-block-017 and other containing-block-01*:
section 10.1 (inline versus block)
http://lists.w3.org/Archives/Public/public-css-testsuite/2011Jan/0013.html

> That part of
> the spec (with point 4.1) and the assert for containing-block-011.htm is
> better suited for this test.


For containing-block-011.htm test, please read

http://lists.w3.org/Archives/Public/public-css-testsuite/2012Mar/0007.html

containing-block-011, 013, 015 are *not* testing (current) bullet 4.1 .
containing-block-011, 013, 015 are incorrect as far as testing bullet 4.1
is involved.


>
> http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-017.htm


Some tests may be good but the meta assert text is (still) confused or
confusing.

Several tests implicitly use and rely on 'top: auto' and 'left: auto' for
containing-block-011 to 021 tests: I do not think this is best or
suitable. At the very least, I would explicitly declare 'top: auto' and
'left: auto' in those tests.


>
>    (IE9, Safari 5.1.2 and Opera 11.61 pass)
>
>
> To follow what that test is testing, examine a simpler test.
>
>    (IE9, Safari 5.1.2 and Opera 11.61 pass ltr)
>    (IE9 and Safari 5.1.2 pass rtl)
>
> http://css-class.com/test/temp/containing-block-inline.htm

.. and

http://css-class.com/test/temp/containing-block-inline2.htm


>
>
> Or this one by Bruno.
>
>    (IE9, Safari 5.1.2 and Opera 11.61 pass)
>
> http://www.brunildo.org/test/inline-cb.html
>

Bruno and I created
http://test.csswg.org/suites/css2.1/20110323/html4/containing-block-031.htm
from such original test.

>
> Note how the wording of section 10.1, point 4.1 has changed:
>
> Current:
>
>    | In the case that the ancestor is an inline element,
>    | the containing block is the bounding box around the
>    | padding boxes of the first and the last inline boxes
>    | generated for that element. In CSS 2.1, if the inline
>    | element is split across multiple lines, the
>    | containing block is undefined.
>
> Previous:
>
> http://www.w3.org/TR/2010/WD-CSS2-20101207/visudet.html#containing-block-details
>
>    (note that this is point 4.1.1)
>
>    | If the 'direction' is 'ltr', the top and left of the
>    | containing block are the top and left padding edges
>    | of the first box generated by the ancestor, and the
>    | bottom and right are the bottom and right padding
>    | edges of the last box of the ancestor.
>
>    | Note: This may cause the containing block's width
>    | to be negative.
>
>
> Some history on these test and the testsuite regarding 10.1.
>
> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Dec/0203.html
>
> And a familiar looking test below which is identical to
> containing-block-011.htm apart from the assert.
>
> http://test.csswg.org/suites/css2.1/20101027/html4/containing-block-017.htm



Alan, we really should be discussing spec in www-style mailing list and
tests of test suite in public-css-testsuite. Unless of course a test
demonstrate a spec issue or has some incidence on the spec.

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 Friday, 9 March 2012 18:49:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:48:51 GMT