Re: CSS Grid Layout tests suite

Le 2014-10-28 10:15, Manuel Rego Casasnovas a écrit :
> Hi again,

Hello Rego,

> It'd be nice if we could find someone else to help us with the review,
> at least during the initial phase.

Okay. I will review your first tests, during initial phase. And it may 
take me a few days before making a review as I expect to be very busy in 
the next few months.

> Otherwise we'll try to follow your advices and do our best :-)
> 
>> A first draft was made public in:
>> 
>> 28 proposals to improve testcase writing guidelines
>> http://lists.w3.org/Archives/Public/public-css-testsuite/2011Dec/0004.html
>> 
>> Since then, I have improved such document; it's more detailed and 
>> lists
>> additional improvements.
> 
> Thanks for the link, it has a good set of really useful rules.
> It'd be great to have that document in a wiki or directly under
> http://testthewebforward.org/docs/.

It's just a set of notes (more or less organized) I took over time. When 
I see or find an issue or problem in someone's test or even in my own 
tests, I write a note about it.

The general idea of those notes is what to do in tests that help

a) testers,
b) reviewers,
c) maintenance of tests and
d) reduce test linkages (therefore server load),

and that reduces condition of mistakes, that speeds or eases their 
tasks. You should pay more attention to 8a- Avoid single cell with 
single row tables, 8b- How to test inline-block) and 29- Unneeded, 
unnecessary, extraneous declarations.

{

8a)-
Avoid single cell with single row tables
****************************************

Mono-cell in mono-table-row table in table layout rendering testcases is 
to be
avoided because those are not very helpful and not very reliable. It may 
lead to false positives. Such are not realistical usages of tables and 
are not typical webpage scenarios either.

eg
http://test.csswg.org/suites/css2.1/20110323/html4/background-position-applies-to-004.htm
is passed by IE9 and Chrome 14 but
http://test.csswg.org/suites/css2.1/20110323/html4/table-backgrounds-bs-row-001.htm
and
http://test.csswg.org/suites/css2.1/20110323/html4/table-backgrounds-bs-row-002.htm
are failed by IE9 and Chrome 14.
Additional testcase: 
http://the-dees.webs.com/iepp1/55-tr-bg-position.html


8b)-
How to test inline-block
************************
best or better, more recommendable testing of inline-block when its
content does not have any block containers.
e.g.
(bad or less good)
<div>
  <span style="display: inline-block;">text sample</span>
</div>

(good or better)
<div>
  <div style="display: inline-block;">
   <span style="display: block;">text sample1</span>
   <span style="display: block;">text sample2</span>
  </div>
</div>

29-
Unneeded, unnecessary, extraneous declarations
**********************************************

width: 0
--------
If an element applies shrink-to-fit width (like a table cell), then 
setting its
width to 0 is unneeded and unnecessary.

http://test.csswg.org/suites/css2.1/20110323/html4/border-right-color-applies-to-001.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-right-color-applies-to-004.htm

An empty cell will not under normal circumstances require that its box 
occupy/creates an horizontal space for its empty content. An empty cell 
that has 'width: auto' will use/occupy/generate a zero width box, a 
content box of 0 width.

table-layout: fixed
-------------------
In order to trigger the fixed table layout algorithm and to get some 
kind of layout effect out of it, some kind of rendering effect out of 
it, the table width or at least one column width or at least one table 
cell width in first row has to be specified.
If none of those 3 is specified, then 'table-layout: fixed' does not and
can not have any useful or meaningful rendering effect.
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-001.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-004.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-006.htm
etc.

margin-left: 1in
----------------
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-001.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-002.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-003.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-004.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-005.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-006.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-007.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-013.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-left-width-applies-to-014.htm

In the 'border-collapse: collapse' model,

"
The left border width of the table is half of the first cell's collapsed
left border, and the right border width of the table is half of the last
cell's collapsed right border. If subsequent rows have larger collapsed
left and right borders, then any excess spills into the margin area of
the table.
"
http://www.w3.org/TR/CSS21/tables.html#collapsing-borders

There is no subsequent rows in those tests, so no possible excess 
spilling. So, I see no reason to set a margin-left to 1in for these 
tests.

Where exactly the left border of a table starts in comparison to where
its content box starts is a distinct and separate issue which does not 
and should not affect where the black border starts being painted in all 
those tests.

http://lists.w3.org/Archives/Public/public-css-testsuite/2012Jun/0000.html


height: 0
---------
http://test.csswg.org/suites/css2.1/20110323/html4/border-bottom-width-061.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-bottom-width-062.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-top-width-061.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-top-width-062.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-width-001.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-width-002.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-width-003.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-width-004.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-width-005.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-width-006.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-width-007.htm

Under normal circumstances, an empty div does not require height: 0. 
Under
normal circumstances, an div with 'height: auto' which does not have any 
content
nor children will occupy/generate a height of 0.

height: 1in
-----------
http://test.csswg.org/suites/css2.1/20110323/html4/border-top-width-092.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-top-width-093.htm
http://test.csswg.org/suites/css2.1/20110323/html4/border-top-width-094.htm

Removed because pointless, irrelevant to the tests.


width: 1in set to an inline non-replaced
----------------------------------------
http://test.csswg.org/suites/css2.1/20110323/html4/box-generation-001.htm
http://test.csswg.org/suites/css2.1/20110323/html4/box-generation-002.htm
Setting a width to an inline non-replaced element has no effect, has no 
rendering or layout effect.

}

Test Format Guidelines
http://testthewebforward.org/docs/test-format-guidelines.html

Test Style Guidelines
http://testthewebforward.org/docs/test-style-guidelines.html

Test Templates
http://testthewebforward.org/docs/test-templates.html

CSS Naming Guidelines
http://testthewebforward.org/docs/css-naming.html
(This document no longer mentions to avoid using underscore character in 
filenames and support files.)

Test Review Checklist
http://testthewebforward.org/docs/review-checklist.html

CSS Metadata
http://testthewebforward.org/docs/css-metadata.html

Gérard
-- 
CSS3 Writing modes section
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/

Received on Wednesday, 29 October 2014 20:17:53 UTC