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
> ( rather than in email,
> because it'll likely get lost over time otherwise.


Then what should be the purpose of this mailing list?

> On Sat, Mar 25, 2017 at 9:13 PM, Gérard Talbot <> 
> wrote:
>> Geoffrey,
>> 1-
>> Reference File
>> "All metadata is removed."
>> 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.


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 
Requirements flags in reference files

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


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
>> "
>> 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
>> Also:
>> "the two files render pixel-for-pixel identically within a 600x600 
>> window
>> including scroll-bars if present;"
>> "The device has a viewport width of at least 800px."
>> 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. "
> 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, 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.)


The 600px by 600px decision was (more or less) made in
Reftest Maximum Viewport Size thread:

Writing Tests

General Test Guidelines

Test Review Checklist

Test Templates

Writing Reftests

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