Re: Scrollbars, olive color, maximum viewport width

> Gérard Talbot wrote:
>> Hello all,
>> 1- Scrollbar(s) versus scrolling mechanism
>> In test
>> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_11/overflow-scrollbar-001.xht
>> it is written:
>> "
>> PREREQUISITE: User agent needs to support scrollbars as the scrolling
>> mechanism. If it does not then this test case does not apply to this
>> user agent.
>> "
>> but in CSS 2.1 Conformance Test Suite
>> Uncommon Assumptions
>> http://www.w3.org/Style/CSS/Test/CSS2.1/current/#uncommon
>> it is written:
>> "
>> The device is interactive and uses scroll bars.
>> "
>> so the PREREQUISITE text can be removed.
>
> Ideally, the tests should not rely on the Uncommon Assumptions, and  
> if they
> do, that should be indicated in the test.

As I've mentioned before, I strongly believe an established mechanism  
should exist for including Uncommon Assumptions and prerequisites in  
tests, especially if the long-term aim is to remove the majority of  
the current Uncommon Assumptions from http://www.w3.org/Style/CSS/Test/CSS2.1/current/ 
. The main advantage as I see it, would be that it provides a clear,  
readable way of quickly highlighting any test dependancies to the  
reviewer (more so than placing the assumption in the assert field),  
whilst removing the possibility of bloating the assert field with a  
convoluted assumption.

However, in either case, I believe we should introduce an explicit  
format for describing assumptions/prerequisites. My suggestion would  
be to include the exact line in the specification that describes the  
assumption that the test relies on, followed by a link to that  
reference. For example:-

<meta name="assumption" content="The width of a replaced element's box  
is intrinsic and may be scaled by the user agent if the value of this  
property is different than 'auto' [http://www.w3.org/TR/CSS21/visudet.html#the-width-property 
]" />

or
<meta name="assert" content="[The width of a replaced element's box is  
intrinsic and may be scaled by the user agent if the value of this  
property is different than 'auto' -http://www.w3.org/TR/CSS21/visudet.html#the-width-property 
] [ASSERT]">
In the second example, the aim of the square brackets encapsulating  
the assumption is to separate the assumption from the assert itself.

> They are stated up front mainly
> because we have a number of old tests that rely on these assumptions  
> and
> do not identify the assumptions they make in the test itself.  
> Otherwise,
> I would like to get rid of as many Uncommon Assumptions as we can.

See above.

>
>> Some other tests (eg
>> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_11/overflow-ancestors-001.xht
>> ) mention "active scrolling mechanism" instead of scrollbar.
>> I am working on tests which involve overflow, scrolling, scrollbars,
>> etc. and I wonder if we should not standardize the wording regarding
>> scrolling.
>
> That's probably a good idea. Do you have some recommendations?

I second this. I would suggest standardizing the term, 'scrolling  
mechanism' as I believe it describes in a concise manner, the  
mechanism that is being described, and I also believe it's a term what  
would be clearly understood by reviewers. This term is also flexible  
enough to allow it to be extended to cover axis-specific scrolling,  
and active/inactive mechanisms; for example, "active scrolling  
mechanism along the x-axis", "inactive scrolling mechanism along the y- 
axis", etc.

>> Active and inactive: should we use such distinction? I think so. At
>> least, when the test may involve scrollbar and/or scrolling and is  
>> being
>> tested.
>> Speaking of visible scrollbar is not useful since its opposite
>> (invisible scrollbar) is not useful in a test.
>
> Some UAs might have a scrolling mechanism that is not visible.

But that's a UA-specific option, and it is surely out-of-scope of a  
CSS test? How can we test for a scrolling mechanism that isn't visible?

Received on Sunday, 13 December 2009 21:07:45 UTC