


From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Mon, 05 Sep 2005 19:01:21 -0500
Message-ID: <431CDC51.6070107@mit.edu>
CC: www-style@w3.org

Patrick H. Lauke wrote:
> In my recent testing on Windows browsers, I found them to be fairly well
> supported

While I can't speak as to why system colors were deprecated, I have to say that 
the word Windows there is a key one.  The list of system colors in CSS2 was 
written based on the then-current Windows UI.  That means that they don't map 
well to other user interfaces (eg various versions of MacOS, various Linux 
desktops).  This I can say based on some implementation experience in Gecko

For example, let us consider two system colors quickly (quoting CSS2.1 section 
18.2 here):

       Active window border.
       Inactive window border.

What happens when active/inactive state is not shown by changes in the border? 
Should the two be the same color?  How many web page designers will realize that 
this can even happen if they're developing on Windows?  Similar problems plague 
other system colors -- the very definitions assume that certain classes of 
windows exist, and that each has certain parts.  If windows outside this list of 
classes exist, if parts outside this list exist, or if windows or parts of 
windows in the CSS2 lists do NOT exist, things break down.

 > and would posit that they can have quite a valuable role to
> play in creating accessible style sheets that match the user's set
> colour scheme / preferences (e.g. if a user has set their Windows
> environment to High Contrast, a web page can be styled to follow that
> preference).

But if a user has their non-Windows environment set up for accessibility things 
won't work because the colors that environment _does_ use are not reflected in 
the Windows-centric system color list?  If this is the problem we're trying to 
solve, system colors as present in CSS2.1 are not a good enough solution.

Received on Tuesday, 6 September 2005 00:01:40 GMT
