Re: Some updates to do in documentation files, or discussions/clarifications to have

Le 2017-04-03 15:08, Geoffrey Sneddon a écrit :
> FWIW, this probably more lives in issues on the GitHub repository
> (https://github.com/w3c/web-platform-tests) rather than in email,
> because it'll likely get lost over time otherwise.

Geoffrey,

Then what should be the purpose of this mailing list?

> 
> On Sat, Mar 25, 2017 at 9:13 PM, Gérard Talbot <www-style@gtalbot.org> 
> wrote:
>> Geoffrey,
>> 
>> 1-
>> Reference File
>> "All metadata is removed."
>> http://web-platform-tests.org/writing-tests/reftests.html#reference-file
>> 
>> Actually, that is usually true but sometimes not true. If a reference 
>> file
>> uses some flag(s), then a <meta name="flags" content=""> will be 
>> required.
> 
> AFAIK, nothing has ever done anything with those flags. As far as I'm
> aware, they've practically always been required to be on the test
> itself.

[snipped]



We have discussed this before:

"
It's perfectly valid for a reference file to have flags, and they should 
be present as needed, but they should only reflect requirements of the 
reference
(...)
"
Requirements flags in reference files
https://lists.w3.org/Archives/Public/public-css-testsuite/2013Jun/0025.html


>> 4-
>> Ahem usage
>> http://web-platform-tests.org/writing-tests/ahem.html#usage
>> 
>> "as such, the font shorthand should normally be used." "doesn't use 
>> font
>> shorthand;": font shorthand should not be recommended. I think it 
>> should be
>> neutral: not encouraged, not discouraged. When I create a test that 
>> uses
>> font shorthand, then I can not easily and quickly examine 
>> subproperties with
>> web inspection tools. Also, font shorthand is more "sensitive", 
>> demanding:
>> if only 1 subproperty is invalid, then the shorthand is rejected, 
>> ignored
>> while declaring subproperties in individual declarations will only 
>> affect
>> the invalid declarations and not the other valid subproperty 
>> declarations.
> 
> The reason why the shorthand is recommended is it avoids any risk of
> accidentally inheriting non-default property values, which would
> likely result in Ahem not rendering as expected.

[snipped]


I have read several times your sentence and I do not understand it. The 
documentation even warns "Other font properties should make sure they 
have their default values".

> As far as I'm aware, all web development tools provide ways to see
> both defined and computed values; the latter should show the
> individual properties.

But not the former.

> I don't think anyone should be using any font
> value for Ahem that isn't valid CSS1, hence I don't think we should be
> concerned about the shorthand being rejected.

Shorthand form (not just for font) is more demanding than longhand form.



>> 6-
>> Be short
>> http://web-platform-tests.org/writing-tests/general-guidelines.html#be-short
>> "
>> For reftests in particular scrollbars at 800×600px window size must be
>> avoided unless scrolling behavior is specifically being tested.
>> "
>> This, I believe, was changed to 600px by 600px. Thread starts here:
>> Reftest Maximum Viewport Size
>> https://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0020.html
>> 
>> Also:
>> "the two files render pixel-for-pixel identically within a 600x600 
>> window
>> including scroll-bars if present;"
>> http://web-platform-tests.org/writing-tests/reftests.html#components-of-a-reftest
>> 
>> "The device has a viewport width of at least 800px."
>> http://web-platform-tests.org/writing-tests/assumptions.html
>> If pixel comparison involves only 600px, then why should we require a
>> minimum of 800?
>> 
>> I am wondering if the documentation is consistently coherent with 
>> regards to
>> viewport width and presence of scrollbars.
>> 
>> "The test renders within a 600x600 viewport, only displaying 
>> scrollbars if
>> their presence is being tested. "
>> http://web-platform-tests.org/reviewing-tests/checklist.html
> 
> We have total disagreement about this, some documentation saying
> 800x600, some saying 600x600, some implementations doing one, some the
> other… It's a complete and utter mess. :\
> 
> This was a pre-existing issue with the old documentation for the CSS
> testsuite (at testthewebforward.org), hence I didn't consider it a
> priority to fix with the cleanup recently. This needs buy-in from
> implementors, hence is more than a documentation issue, really. (For
> reference, the old wiki documentation didn't define any resolution, or
> even a minimum, so who knows how you were meant to run them.)

[snipped]

The 600px by 600px decision was (more or less) made in
Reftest Maximum Viewport Size thread:
https://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0024.html

Gérard
-- 
Writing Tests
http://web-platform-tests.org/writing-tests/index.html

General Test Guidelines
http://web-platform-tests.org/writing-tests/general-guidelines.html

Test Review Checklist
http://web-platform-tests.org/reviewing-tests/checklist.html

Test Templates
http://web-platform-tests.org/appendix/test-templates.html

Writing Reftests
http://web-platform-tests.org/writing-tests/reftests.html

Received on Monday, 3 April 2017 21:14:51 UTC