Re: CSS 3 color module and deprecation of "system" colors

Patrick H. Lauke wrote:
> Bert Bos wrote:
>>The reason we have system colors and the 'appearance' property is in 
>>fact the opposite: to allow designers to style form controls 
>>*differently* from the system defaults.
> 
> That assumes that I'm only interested in styling form controls, when in 
> fact I'm thinking more along the lines of *any* element that can be 
> assigned some form of colour.

   Very true. For instance, someone may create a custom DHTML control
that uses an <input type="hidden"> element to submit and no other form
controls. That means all the visible elements are non-form elements.
Clearly, you'd need system to make such a custom widget look anything
like a native widget.

   (Side question: Does "appearance" change the input type? If I take an
<input type="text"> and assign it the property "appearance: checkbox",
will the textbox be converted to a checkbox?)

>>Accessibility doesn't play any role here. The accessibility of a site 
>>doesn't depend on the style chosen by the author. The Web would be 
>>pretty inaccessible if that were the case. Instead, CSS allows the 
>>author to choose whatever colors he wants and it allows the user to 
>>ignore them.
> 
> That is an all or nothing scenario: either the user accepts the evil 
> designer's choice, or completely ignores them. However, I'd suggest that 
> with something like system colours (as imperfect as they may be in CSS 
> 2.1's specification), you can create a third scenario where author and 
> end user can meet half way.

   At the very least, system colors that are shown to have wide OS
support should not be deprecated. There's no reason to throw the baby
out with the bath water. If certain system color keywords don't apply
that often, just get rid of those specific keywords.

> Accessibility may not play a role in your view, and I'm not saying that 
> style is a prerequisite of accessibility (as you say, otherwise the web 
> would be in a sorry state from an accessibility point of view). What I 
> *am* suggesting is that adequate styling that can, to a certain extent, 
> take into consideration the user's existing OS settings can work towards 
> *increasing* accessibility (thinking of alternate style sheets, evolving 
> from the current "zoom layout" idea of offering single column 
> alternatives for multi-column sites, which can still maintain a modicum 
> of style rather than taking the all or nothing route).

   Not sure these are the best example for keeping system colors. I
think custom UI is the best example of where you'd need system colors.

> Then again, I may be the only one who holds that particular point of 
> view then...

  No, I think the decision to remove system colors was too hasty. When
developing UI for windows, I'd often use system colors for custom
widgets that weren't in the development platform by default. The removal
of system colors undermines a web author's ability to create widgets
that resemble local OS widgets. It will also slow the adoption of XBL2
in some areas.

Received on Wednesday, 7 September 2005 00:48:43 UTC