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