- 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