- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Mon, 05 Sep 2005 19:01:21 -0500
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- 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):
ActiveBorder
Active window border.
InactiveBorder
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.
-Boris
Received on Tuesday, 6 September 2005 00:01:40 UTC