W3C home > Mailing lists > Public > public-css-testsuite@w3.org > December 2014

Re: 54 new tests submitted in section 3.1

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Sat, 27 Dec 2014 14:45:11 -0500
To: 塩澤 元 (Shiozawa, Hajime) <hajime.shiozawa@gmail.com>
Cc: Public CSS test suite mailing list <public-css-testsuite@w3.org>, Koji Ishii <kojiishi@gluesoft.co.jp>, "Elika J. Etemad" <fantasai@inkedblade.net>
Message-ID: <9ed0617601fca4d321ebbe0b8803cada@gtalbot.org>
Le 2014-12-25 10:27, 塩澤 元 a écrit :
> Hi Gérard,
> 
> I have reviewed the following test.
>  - block-flow-direction-001.xht ~ block-flow-direction-022.xht
>  - line-box-direction-001.xht ~ line-box-direction-020.xht
> 
> Here is comments for these test.
> 
> 1.
> Some test-cases specify another specification's ref-file
> (/css-multicol-1/multicol-count-002-ref.xht) as its ref-file.
> I think that it is better to make a new ref-file (or copy) in
> css-writing-modes-3 directory.

Hajime,

We discussed this in
http://lists.w3.org/Archives/Public/public-css-testsuite/2014Nov/0039.html

I think we eventually should filename-rename
multicol-count-002-ref.xht
as
ref-yellow-PASS-on-black.xht
or some filename like that and then move that file into
http://test.csswg.org/source/css21/reference/
with other frequently reused reference files.

> 2.
> All test-case uses 'yellow' and 'black' color.
> I think that it is better to use 'green' and 'blue' because these makes
> positive impression.

Ideally, you want to use green color and restrict using green color if 
and only if red indicates failure. Green color should be restricted in 
tests where failures will be indicated by red color.

"
Green

In the absence of any red, green indicates success.
"
http://testthewebforward.org/docs/test-style-guidelines.html#color

"
There is no need to list common incidental features like the color green 
if it is being used to validate the test unless the case is specifically 
testing the color green
"
http://testthewebforward.org/docs/css-metadata.html#specification-links

"
Since green-with-no-red is often used to indicate success, it's best to 
also avoid green unless using the presence of red to indicate failures.
"
https://wiki.csswg.org/test/format#design-requirements (old 
documentation)

This is what I did in

http://test.csswg.org/suites/css-multicol-1_dev/nightly-unstable/html4/multicol-rule-percent-001.htm

and in

http://test.csswg.org/suites/css-multicol-1_dev/nightly-unstable/html4/multicol-containing-002.htm

with

http://test.csswg.org/suites/css-multicol-1_dev/nightly-unstable/html4/reference/multicol-containing-002-ref.htm


Also, if some layout test renders the word "PASS", then you want to use 
a light color along with a dark color. Green and blue are both rather 
dark colors.


With more thinking about this issue, now I think I could have created a 
black "PASS" rendered layout instead...

Anything that simplifies the task of testers (people taking the tests) 
is, as a general rule, welcomed, better, more desirable: so, 1 color is 
better than 2 colors.


> 3.
> I think that it is better to add information to title in some 
> test-case.
> 
> - block-flow-direction-005.xht, block-flow-direction-006.xht
> before: CSS Writing Modes Test: float and 'vertical-rl' - block flow
> direction of block-level boxes
> after: CSS Writing Modes Test: float*-left* and 'vertical-rl' - block 
> flow
> direction of block-level boxes
> 
> - block-flow-direction-007.xht, block-flow-direction-007.xht
> before: CSS Writing Modes Test: float and 'vertical-lr' - block flow
> direction of block-level boxes
> after: CSS Writing Modes Test: float*-right* and 'vertical-lr' - block 
> flow
> direction of block-level boxes
> 
> - line-box-direction-005.xht, line-box-direction-006.xht
> before: CSS Writing Modes Test: float and 'vertical-rl' - ordering
> direction of line boxes
> after: CSS Writing Modes Test: float*-left* and 'vertical-rl' - 
> ordering
> direction of line boxes
> 
> - line-box-direction-007.xht, line-box-direction-008.xht
> before: CSS Writing Modes Test: float and 'vertical-lr' - ordering
> direction of line boxes
> after: CSS Writing Modes Test: float*-right* and 'vertical-lr' - 
> ordering
> direction of line boxes

I am not sure why specifying the float value is or would be important in 
the title. The float value is specified in the assert text and in the 
code. Normally, we want title text to be as short as possible while at 
the same time to be descriptive.

"
The title is descriptive but not too wordy.
"
http://testthewebforward.org/docs/review-checklist.html#reftests-only

"
The title appears in the generated index, so make sure it is concise, 
unique and descriptive. The role of the title is to identify what 
specific detail of a feature or combination of features is being tested, 
so that someone looking through an index can see quickly what's tested 
in which file. In most cases, this description should not require more 
than 5 or 6 words. There is no need to provide the chapter or section in 
the title.
"
https://wiki.csswg.org/test/format#title-element


By the way, I use 'float: left' with 'vertical-rl' and 'float: right' 
with 'vertical-lr'; in order to make a test suite coverage more complete 
and thorough, we probably should test both float values for each 
vertical writing-mode values ...

Anyway, I will add the float value in the title, as you suggested.

> 4.
> There is not line-box-direction-*004*.xht. Why is this missing?

In my mind, when testing 'writing-mode', I would do all and each 
'writing-mode' values in the order they are listed in the spec: 
horizontal-tb, vertical-rl, vertical-lr, (default or initial) and 
inherit. Now, testing 'writing-mode: horizontal-tb' does not make much 
sense. IE5 and NS4 could and would pass those tests, you see. And 
testing default or initial values is impossible to test. Many 
(otherwise, all) tests we did in CSS2.1 about initial and default 
property values were not useful. So, there is no 
line-box-direction-*004*.xht because there is no test about default, 
initial 'writing-mode' value. I could remove
block-flow-direction-004.xht
for the same reasons given here. I could also remove
line-box-direction-001.xht
and
block-flow-direction-001.xht
because bad browsers, old browsers, buggy browsers are most likely going 
to pass these tests. Those tests by themselves are not really helpful, 
not really necessary; they most certainly will not be useful to browser 
(and CSS rendering engine) manufacturers.

A test that never fails, that never can fail, that is passed by old 
browsers or buggy browsers is not an useful test, is not a worthy test.

-------

"
In addition to the property-specific values listed in their definitions, 
all properties defined in this specification also accept the inherit 
keyword as their property value.
"
http://www.w3.org/TR/css-writing-modes-3/#values

"
Name:	writing-mode
(...)
Inherited:	yes
"
http://www.w3.org/TR/css-writing-modes-3/#propdef-writing-mode

The same reasoning could and should also apply to properties that are 
inherited by default and properties with the inherit reserved keyword 
value. If a property value is inherited by default, then how is it 
useful or worthy to test that same property with the 'inherit' keyword 
as its value? It is not useful, not relevant. 'inherit' as a reserved 
keyword value is worth testing and must be tested when a property value 
is not inherited by default.


---------

One thing (there is another which I need to explain into a specific, 
dedicated email) worth modifying in 12 inline-block-related tests:

http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/block-flow-direction-01[1-6].htm

http://test.csswg.org/suites/css-writing-modes-3_dev/nightly-unstable/html/line-box-direction-01[1-6].htm

background-color should apply to the inline-block in all those 12 tests; 
that way, I can often remove 1 declaration from the code; the 
border-bottom declaration on the span can be safely removed.

Also, the inline-block in line-box-direction-011 should be wrapped into 
a block container, just like block-flow-direction-011.

Gérard


> During this weekend, I will review other test-case which you submitted.
> 
> Hajime.
> 
> 
> 2014-12-19 15:31 GMT+09:00 Gérard Talbot <css21testsuite@gtalbot.org>:
> 
>> Le 2014-12-17 08:38, Koji Ishii a écrit :
>> 
>>  How long do you think it’ll take until you submit?
>>> 
>> 
>> Done.
>> 
>> committed changeset 6935:a4b95a324593 22 tests (18 new tests)
>> committed changeset 6936:65afcff4b06b
>> committed changeset 6937:912ef3c7b408 (block-flow-direction-023)
>> committed changeset 6938:ca6495d8b9df 29 tests
>> committed changeset 6939:65b6d0358772 7 tests and 7 images
>> committed changeset 6940:81f6362c4cb7 1 test and 3 images
>> 
>> They are all here, submitted on december 18th:
>> 
>> http://test.csswg.org/source/css-writing-modes-3/?C=M;O=D
>> 
>> --------
>> 
>> I have added 2 last-minute tests:
>> 
>> http://test.csswg.org/source/css-writing-modes-3/block-
>> flow-direction-023.xht
>> 
>> which is a minor variant of block-flow-direction-003
>> 
>> and
>> 
>> http://test.csswg.org/source/css-writing-modes-3/form-
>> controls-vert-rl-005.xht
>> 
>> I now think that maybe I should create a block-flow-direction-024 
>> which
>> would be a minor variant of block-flow-direction-002 to balance 
>> things...
>> 
>> --------
>> 
>> One last thing I need to check with Peter Linss.
>> 
>> Shepherd is able to detect that the link target in the Public spec has
>> been changed in the Editor’s Draft. So, that means
>> 
>> http://www.w3.org/TR/css-writing-modes-3/#writing-mode
>> is pointing to section 3.1 but, in the Editors' draft, it is now
>> http://dev.w3.org/csswg/css-writing-modes-3/#block-flow
>> 
>> I think Shepherd is only notifying me, informing me of such thing .... 
>> I
>> do not think I need to change the actual, current
>> <link rel="help" 
>> href="http://www.w3.org/TR/css-writing-modes-3/#writing-
>> mode" title="3.1 Block Flow Direction: the writing-mode property" />
>> 
>> ---------
>> 
>> 
>>  I have not managed
>>> yet but probably either Elika, Hajime, and/or I are the best
>>> candidates to review them. Should we wait for the submission and
>>> review on Shepherd, or would it help you if we review earlier on your
>>> site?
>>> 
>> 
>> Please wait that the tonight (00:00 Pacific Day Time) build process 
>> works
>> and does not break!
>> 
>> You can review those 58 tests after that in emails in the Public CSS 
>> Test
>> suite mailing list or in Shepherd.
>> 
>> My site is acting like an /incoming folder, like a transitory place 
>> where
>> draft tests are standing by. So, those tests may not be ready.
>> 
>> Gérard
>> --
>> 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
>> 
>> Test Review Checklist
>> http://testthewebforward.org/docs/review-checklist.html
>> 
>> CSS Metadata
>> http://testthewebforward.org/docs/css-metadata.html
>> 

-- 
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

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

CSS Metadata
http://testthewebforward.org/docs/css-metadata.html
Received on Saturday, 27 December 2014 19:45:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:27 UTC