- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Tue, 31 Aug 2010 19:21:30 -0700
- 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
- – 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 UTC