W3C home > Mailing lists > Public > public-css-testsuite@w3.org > September 2010

Review Report on sections 9.1.x to 9.2.3 ~= 78 testcases

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Tue, 31 Aug 2010 19:21:30 -0700
Message-ID: <828fb59418c7bd31bc0f5bb650aa2f23.squirrel@cp3.shieldhost.com>
To: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Cc: "Arron Eicholz" <arron.eicholz@microsoft.com>, "Boris Zbarsky" <bzbarsky@mit.edu>
Hello,

This report is mostly for Fantasai, Arron Eicholz and Boris Zbarsky

Summary
*******

1- Many of these Ian Hickson testcases from
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-001.htm
to
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-020.htm
need to be redone to better indicate
should be redone to indicate
- better, more correct <link rel="help" href="...">
- <meta name="flags" content="...">
- <meta name="assert" content="...">
- add an alt attribute if required
- remove the <p class="ahem"> since ahem should be listed as a meta-flag
- and most important, what the testcase is actually testing.

2- everywhere <script> occurs should be <script type="text/javascript">

3- Section 9.2.3 on run-in is underdefined

4- I have approved many testcases which, nevertheless, still require
some minor corrections.



Section 9.1.x and 9.2 (partial) review report
=============================================

**************************
Section 9.1.1 The viewport
**************************

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/root-canvas-001.htm

I do not think this is a good test because if there was presence of red,
it would not verify what the testcase was about, was aiming at testing
to begin with: "what size is the viewport on the object element." And
such question is answered in section 10.3.10 -> 10.3.2.
http://www.w3.org/TR/CSS21/visudet.html#inlineblock-replaced-width

The red (leading to, causing test failure) would have to come from
padding on the wrapping div or because the object has a margin and/or
padding or if the embedded document
http://test.csswg.org/suites/css2.1/20100815/html4/support/root-canvas-001a.html
does not apply the margin or padding rules for root and body elements.

Rejected

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/viewport-001.htm

Reviewed and approved

{Note to self: A testcase based on
http://www.css-lab.com/bug-test/opera10-ap-bug.html
could be done: #fixed's height (and/or bottom: 80px) is not recalculated
(and does not have to according to spec) and is not redrawn (and does
not have to according to spec) in the viewport, due to viewport
resized.}

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/viewport-002.htm

<meta name="assert" content="Scrolling mechanism should be available
when canvas is larger than viewport.">

Shouldn't "large" and "larger" be for width and "tall" and "taller" be
for height?

Proposed adjustment:
<meta name="assert" content="Scrolling mechanism should be available
when canvas is taller than viewport height.">

Rejected

{Note to self: A testcase where viewport is narrower than document box
width could be created.}

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/viewport-003.htm

<meta name="assert" content="Scrolling mechanism should be available
when canvas is larger than viewport even when page is set to
right-to-left.">


Shouldn't "large" and "larger" be for width and "tall" and "taller" be
for height?

Proposed adjustment:

<meta name="assert" content="Scrolling mechanism should be available
when canvas is taller than viewport height even when page is set to
right-to-left.">

Rejected

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/viewport-004.htm

I have created+submitted a bug report on that testcase:

Bug 10459 -  Frame start tag unexpectedly not recognized
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10459

Reviewed and approved


*******************************
Section 9.1.2 Containing blocks
*******************************


Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/containing-block-026.htm
http://test.csswg.org/suites/css2.1/20100815/html4/containing-block-027.htm

Reviewed and approved

----------------------


**************************************************
Section 9.2.1 Block-level elements and block boxes
**************************************************


Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/box-generation-001.htm

            #span1
            {
                background: orange;
                width: 1in;
            }

"The 'width' property does not apply."
10.3 Calculating widths and margins, 10.3.1 Inline, non-replaced elements
http://www.w3.org/TR/CSS21/visudet.html#inline-width

<meta name="assert" content="Block boxes can reside within a principal
block box established by a block-level element; inline boxes are outside
of the principal block box.">

The assert is providing 2 statements as if these 2 statements were
independent from each other: a semi-colon ";" acts as a syntaxical
separator ... when, in fact, the second statement should be understood
and presented as a consequence of the first statement. When block boxes
reside in a principal block box, then there can not be inline boxes
inside of it too: "(...) a principal block box (...) contains either
only block boxes or only inline boxes.".

I am not sure that the testcase is actually testing what the assert text
is saying. I am not sure that a testcase can actually test whether a
principal block box (generated by a block-level element) can only
contain either only block boxes or (mutually exclusive or) only inline
boxes. So, this one will have to be reviewed by someone who knows
more/better.

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/box-generation-002.htm

          span
          {
              background: blue;
              width: 1in;
          }

"The 'width' property does not apply."
10.3 Calculating widths and margins, 10.3.1 Inline, non-replaced elements
http://www.w3.org/TR/CSS21/visudet.html#inline-width

<meta name="assert" content="Inline boxes can reside within a principal
block box established by a block-level element; block boxes are outside
of the principal block box.">

The assert is providing 2 statements as if these 2 statements were
independent from each other: a semi-colon ";" acts as a syntaxical
separator ... when, in fact, the second statement should be understood
and presented as a consequence of the first statement. When inline boxes
reside in a principal block box, then there can not be block boxes
inside of it too: "(...) a principal block box (...) contains either
only block boxes or only inline boxes.".

I am not sure that the testcase is actually testing what the assert text
is trying to say. I am not sure that a testcase can actually test
whether a principal block box (generated by a block-level element) can
only contain either only block boxes or (mutually exclusive or) only
inline boxes. So, this one will have to be reviewed by someone who knows
more/better.

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/box-generation-003.htm

Although this is more a "section 12.5" testcase where we can read: "The
background properties apply to the principal box only; an 'outside'
marker box is transparent."
http://www.w3.org/TR/CSS21/generate.html#lists

Reviewed and approved

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/containing-block-028.htm
http://test.csswg.org/suites/css2.1/20100815/html4/containing-block-029.htm

Reviewed and approved

----------------------

*************************************
Section 9.2.1.1 Anonymous block boxes
*************************************


Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/anonymous-box-generation-001.htm

Personally, I believe that this test
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/anonymous-box-generation-001.htm
is more correct because the formatting affecting the anonymous block box
should be the same as the one id-ed as "non-anonymous-block-box". It
also meets, embrases the comments in the thread
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Mar/0020.html

Nevertheless,

Reviewed and approved

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/anonymous-box-generation-002.htm

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/anonymous-boxes-001.htm

I do not see why there is
<link rel="help"
href="http://www.w3.org/TR/CSS21/visudet.html#block-root-margin">

Why isn't there a
<link rel="help"
href="http://www.w3.org/TR/CSS21/visudet.html#the-height-property">
for that testcase?

The testcase should be declaring a transitional DTD to avoid validation
markup errors.

Rejected

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/anonymous-boxes-inheritance-001.htm

One important word is missing in the assert: "enclosing"

Proposed replacement:
<meta name="assert" content="Anonymous boxes inherit property values
from their enclosing non-anonymous box.">

Reviewed and approved

----------------------

Author: Boris Zbarsky

From
http://test.csswg.org/suites/css2.1/20100815/html4/block-in-inline-append-001.htm
to
http://test.csswg.org/suites/css2.1/20100815/html4/block-in-inline-whitespace-001b.htm
(60 testcases)
and
http://test.csswg.org/suites/css2.1/20100815/html4/table-in-inline-001.htm

have not been reviewed for several reasons:
- absence of expected results, clear pass/fail conditions
- validation markup errors
- &ndash; in the <title>
- etc.

Not reviewed

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/inline-box-001.htm
http://test.csswg.org/suites/css2.1/20100815/html4/inline-box-002.htm

Reviewed and approved

----------------------

****************************************************
Section 9.2.2 Inline-level elements and inline boxes
****************************************************

All of the testcases from
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-001.htm
to
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-020.htm
should be redone to indicate
- better, more correct <link rel="help" href="...">
- <meta name="flags" content="...">
- <meta name="assert" content="...">
- add an alt attribute if required
- remove the <p class="ahem"> since ahem should be listed as a meta-flag
- and most important, what the testcase is actually testing.

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-001.htm

The test should state that there should be no red... obviously.

Proposed replacement:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/inlines-001.htm

Rejected

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-002.htm

I spent a lot of time on this apparently simple testcase, reading E.2
painting order. The test is about in-flow, non-positioned, inline box
children painting along the z-axis over the parent. The green border is
not even required for the test. I think this test should be removed.
The inline parent <span> has no content and no padding; so the whole
<strong> element should display.

Rejected

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-003.htm
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-004.htm
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-005.htm
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-006.htm
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-007.htm

Reviewed and approved

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-009.htm
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-010.htm

I agree with these testcases... although I'm sure not everyone does...
and, it seems, there is no normative rule on how replaced element should
be displayed.

{
How a replaced element's content is rendered is not defined by this
specification. Rendered content may also be alternate text for an
element (e.g., the value of the XHTML "alt" attribute)
}
http://www.w3.org/TR/CSS21/conform.html#defs

Maybe the testcase should have the "may" flag

Undefined

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-011.htm

I am sure this test should not be about section 9.2.2
<link rel="help"
href="http://www.w3.org/TR/CSS21/visuren.html#inline-boxes">
Images sit on the baseline and background-color will paint the descent
area.

Proposed replacement:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/inlines-011.htm

Reviewed and approved

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-012.htm

Same thing here: this test should not be in section 9.2.2

Proposed replacement:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/inlines-012.htm

Reviewed and approved

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-013.htm

<img src="support/1x1-white.png"> is missing the alt.

<link rel="help" title="9.5.1 Positioning the float: the 'float'
property" href="http://www.w3.org/TR/CSS21/visuren.html#float-position">
should be added

Rejected because of that

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-014.htm
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-015.htm

alt attribute missing

Both rejected

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-016.htm

<link rel="help" title="16.6.1 The 'white-space' processing model"
href="http://www.w3.org/TR/CSS21/text.html#white-space-model">
<meta name="flags" content="ahem">
<meta name="assert" content="If a space (U+0020) at the beginning of a
line has 'white-space' set to 'normal', then it is removed.">

should be added to that testcase and

<link rel="help"
href="http://www.w3.org/TR/CSS21/visuren.html#inline-boxes">
<p
class="ahem">Ahem_font_required_for_this_test._See_directory_listing_for_details.</p>

should be removed.

Rejected

----------------------

Author: Ian Hickson

http://test.csswg.org/suites/css2.1/20100815/html4/inlines-017.htm
http://test.csswg.org/suites/css2.1/20100815/html4/inlines-020.htm

Reviewed and approved

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/anonymous-inline-whitespace-001.htm

Reviewed and approved

----------------------

**************************
Section 9.2.3 Run-in boxes
**************************

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-001.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-002.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-003.htm

Reviewed and approved

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-004.htm

If the first span is styled as an inline box, then the abs. pos. 2nd
span can still have its left: auto and top: auto resolved to next line
at document body's left edge anyway.

Rejected

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-005.htm

I would change

<meta name="assert" content="Run-in boxes cannot run-in with another box
that already starts with a run-in.">

into

<meta name="assert" content="Run-in boxes cannot run into another box
that is itself a run-in.">

because the <span>Filler Text</span> is a run-in.

Reviewed and approved

----------------------

Author: Microsoft

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-006.htm

<meta name="assert" content="Run-in boxes are converted to block boxes
when the run-in box runs into a table box.">

I don't know about this one. The spec says "If a sibling block box (that
does not float and is not absolutely positioned) follows the run-in box,
the run-in box becomes the first inline box of the block box." and this,
it seems, is the case here. So, how is #span1 going to become the first
inline box of the table box? How can #span1 become the first inline box
of the table box? Assuming anonymous (corresponding) table elements
(tbody, tr, td) are generated for #span2, then the first XX pair should
precede the second XX pair. That would not create a square but rather a
1em tall by 4em large rectangle.

Rejected

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-abspos-between-001.htm

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-abspos-between-002.htm

<script> should be <script type="text/javascript">

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-abspos-between-003.htm

<script> should be <script type="text/javascript">

<span id="r" class="abspos">Some text.</span>

would require to be adjusted to pass validation. More work would be
required here.

Rejected

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-001.htm

The assert text says:
"There must be no nodes in the DOM between the run-in and the following
block.">

but section 9.2.3 says

"
If *a* sibling block box (that does not float and is not absolutely
positioned) follows the run-in box (...)
"

so, it seems like it does not have to be the very first following block:
it could be another.

The assert text should be corrected.

Rejected

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-002.htm

The assert text says:
"There must be                  whitespace in the DOM between the run-in
and the following                  block."

but I think it should be saying

"There can be whitespace in the DOM between the run-in and a following 
block."

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-003.htm

The assert text says
"Tests that run-ins actually run in if there are comments               
  between the run-in and the following block.  There must be            
     whitespace and comments in the DOM between the run-in and the      
           following block."

but I think it should be saying

"Tests that run-ins actually run in if there are comments between the
run-in and the following block. There can be whitespace and comments in
the DOM between the run-in and the following block."

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-004.htm

<script> should be <script type="text/javascript">

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-005.htm

The spec says:
"A run-in cannot run in to a block that already starts with a run-in"
and this is exactly what happens in the testcase. The spec does not
continue with an "... otherwise...". So, why should the run-in header be
inside the bordered #target? It seems to me that run-in is underdefined,
underdevelopped in the spec., at least on this precise issue.

Undefined

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-006.htm

[there should be no space between the word "header" and the word "Start".]

IMO, there should be a bullet list-marker between the word "header" and
the word "Start".

Rejected

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-007.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-008.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-009.htm

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-010.htm

   <script>document.body.offsetHeight; /* flush layout here on purpose
*/</script>

should be

   <script type="text/javascript">document.body.offsetHeight; /* flush
layout here on purpose */</script>

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-011.htm

<script>
should be
<script type="text/javascript">

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-012.htm

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-013.htm

<script>
should be
<script type="text/javascript">

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-014.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-015.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-016.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-017.htm

<script>
should be
<script type="text/javascript">

The spec is underdefined. Why a single preserved (non-breaking) white
space should prevent a run-in from running into a block?

No idea here.

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-basic-018.htm

<script>
should be
<script type="text/javascript">

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-block-between-001.htm

  <meta name="assert" content="Tests that run-ins don't run in if
there's a block between                  them and the block.">

How about saying instead/rather

  <meta name="assert" content="Tests that run-ins run in with the first
(closest) sibling block that follows the run-in box.">

Isn't that what happens in that testcase?

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-block-between-002.htm

<script>
should be
<script type="text/javascript">

  <meta name="assert" content="Tests that run-ins don't run in if
there's a dynamically                  inserted block between them and
the block.">

How about saying instead/rather

  <meta name="assert" content="Tests that run-ins run in with the first
(closest) sibling block that follows the run-in box, even if/when
dynamically inserted.">

Isn't that what happens in that testcase?

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-block-between-003.htm

<script>
should be
<script type="text/javascript">

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-breaking-001.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-breaking-002.htm

<span class="run-in">Run-in<br>header</span>
should be
<div class="run-in">Run-in<br>header</div>

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-contains-abspos-001.htm
http://test.csswg.org/suites/css2.1/20100815/html4/run-in-contains-block-001.htm

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-contains-block-002.htm

<script>
should be
<script type="text/javascript">

Reviewed and approved

----------------------

Author: Boris Zbarsky

http://test.csswg.org/suites/css2.1/20100815/html4/run-in-text-ref.htm

    <div class="run-in">Run-in header</div>

    Some text.

should be

    <div class="run-in">Run-in header</div>

    <div>Some text.</div>


Reviewed and approved

regards, Gérard
-- 
Contributions to the CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

CSS 2.1 test suite (beta 3; August 15th 2010):
http://test.csswg.org/suites/css2.1/20100815/html4/toc.html

CSS 2.1 test suite contributors:
http://test.csswg.org/source/contributors/
Received on Wednesday, 1 September 2010 02:22:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 September 2010 17:52:03 GMT