Re: Scrollbars, olive color, maximum viewport width

Hello all,

I've been unable to reply to emails for about a week. I'm slowly
returning back now..

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


Good enough then. I will add such PREREQUISITE in/for each and all tests
requiring it.


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


Well then why not

<meta name="prerequisite" content="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.">

or

even add "scrollbars" as another possible token in the set of
"Requirement Flags"
http://wiki.csswg.org/test/css2.1/format#requirement-flags

<meta name="assumption" content="..."> is another possibility and is ok
with me.


>From the start, I assumed that uncommon assumptions were making the
inclusion of the quoted PREREQUISITE text unnecessary.


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



What other scrolling mechanism should we assume (or expect) can be
tested by the CSS 2.1 test suite? And how can we test this? The CSS 2.1
test suite mentions "panner" [1] as a possible scrolling mechanism.



>>> 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.
Then "scroll" as a requirement flag should be in the list of flags ...
but not scrollbars.

regards, Gérard
--
[1]:
"(...) if the user agent uses a scrolling mechanism that is visible on
the screen (such as a scroll bar or a panner) (...)"
http://www.w3.org/TR/CSS21/visufx.html#overflow

Received on Friday, 18 December 2009 23:00:57 UTC