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

Re: 54 new tests submitted in section 3.1

From: Shiozawa, Hajime <hajime.shiozawa@gmail.com>
Date: Wed, 31 Dec 2014 16:11:55 +0900
Message-ID: <CAHSwuKPtNEPpHOOkVL3esRTzAcq+n0Zve5nvaNFcEsPi3s=QfQ@mail.gmail.com>
To: Gérard Talbot <css21testsuite@gtalbot.org>
Cc: fantasai <fantasai.lists@inkedblade.net>, Public CSS test suite mailing list <public-css-testsuite@w3.org>, Koji Ishii <kojiishi@gluesoft.co.jp>
Hi Gérard,

1. About ref file
> Le 2014-12-29 22:29, fantasai a e'crit :
> > On 12/27/2014 11:45 AM, Ge'rard Talbot wrote:
> > 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.
>
> I agree with Hajime on this one, I don't think it's good to reference
> a reference file inside a different test suite.  But I also agree with
> Ge'rard, it would be good to have this as a common test reference. In
> that case, however, I think it would go in a top-level reference folder,
> like the common support files are in a top-level support folder.

I agree with this plan.

2. About color choice

> 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.
>>>
>>
>> This is true, and I think Hixie tended to use the color-combination of
>> blue and yellow for such cases. Black is, I agree, a bit too intense
>> here. :) We also tend to use black for descriptive text, so it's good
>> to have a different color than black for the actual test rendering.
>>
>
> I will do a "search and replace" black -> blue edition for the tests using
> a big yellow PASS word then.
>

Thank you for your good explanation.
Now I think that a choice of color (blue and yellow) is right way.

3. About test case title

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

When I reviewed your test, I guessed that the combination of opposite side
('float-*left*' with 'veritcal-*rl*' and 'float-*right* with
veritcal-*lr*') is important for test. So I thought that it is better to
add its value in test case title.
If there are 'float: *right*' with 'vertical-*rl*' (and 'float: *left*'
with 'vertical-*lr*') in tests, I will feel that the absence of float value
in title is not strange.

4. About missing test case
> 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.

OK, I understand what you said.
However I think that a lack of number makes tester (or developer) feel
strange.
Will you do re-numbering these test case to remove a lack of number?

Hajime.

-- 
# 塩澤 元 (Shiozawa, Hajime)
# mail: hajime.shiozawa@gmail.com
Received on Wednesday, 31 December 2014 07:12:22 UTC

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