Re: Scrollbars, olive color, maximum viewport width

>> 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  
>> that 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.
>
> What other scrolling mechanism should we assume (or expect) can be  
> tested by the CSS 2.1 test suite?
I don't think we need to consider a particular mechanism when  
standardizing this sort of terminology. The assumption is that all  
mechanisms incorporate an adequate means of providing scrolling  
dependent on overflow direction.
> And how can we test this?
I'd say the 'overflow' spec is broad enough in it's definition to  
allow all values to adopt consistent behavior across different  
scrolling mechanisms.
> The CSS 2.1 test suite mentions "panner" as a possible scroll  
> mechanism

Hmm, I've never come across a 'panner' before :)
>>>> 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?
>
> If the test includes "scroll" as a requirement flag, the scrolling  
> mechanism can be invisible but if the test specify scrollbars, why  
> or how could scrollbars be invisible and still part of a test?
>
> E.g.: Let's say scrollbars are not visible, not rendered but the  
> user can still access overflowed (clipped) content by rolling the  
> mousewheel.

This would be my concern, too. I think we need to make a distinction  
between the visibility of scrolling mechanisms, and the ability to  
control the function of the scrollbar mechanism itself - with the  
latter being out of the scope of CSS (note, the prose for 'overflow'  
value definitions: "This value *indicates* that content..."). With  
this in mind, we can only test the visibility of scrolling mechanisms  
and how those mechanisms are invoked. Having said that, the 'auto'  
value is ambiguous in the sense that if the content of an element  
clips only one axis - thus invoking a scrolling mechanism - the  
scrolling mechanism could be propagated to both axis, differing from  
currently consistent implementations.

> Then "scroll" as a requirement flag should be in the list of  
> flags ... but not scrollbars.

On a slightly separate issue, the 'scroll' and 'interact' flags seem  
to mutually inclusive. Shouldn't we remove the example in the  
'interact' flag definition, as 'scroll' seems more appropriate for  
flagging scrolling mechanisms.