Re: 54 new tests submitted in section 3.1

Le 2014-12-31 02:11, 塩澤 元 a écrit :
> 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.
> 


The plan to create a top-level reference files folder and to put all the 
"ref-*" references files in it is not something that I can do right now. 
It involves re-writing accordingly the href value of the <link 
rel="match"> of all tests referencing those with a massive "search and 
replace" in an advanced text editor. And it's risky because if the href 
value of the reftest is incorrect, then the build system fails. I have 
already way too much on my hands already.

Also, some very frequently reused reference files may not have been 
hg-copy-ed but just moved. I do not know how to figure this out; 
Shepherd does not indicate this.

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

I do not intend to re-number the whole set of tests. It would be lot of 
work for little. I might as well just create that 004 test instead.

I do not intend to test properties (writing-mode, text-orientation and 
text-combine-upright) with the reserved keyword inherit because those 3 
properties already inherit by default.

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

Received on Sunday, 4 January 2015 00:57:14 UTC