W3C home > Mailing lists > Public > www-archive@w3.org > August 2013

[Fwd: System colors]

From: L. David Baron <dbaron@dbaron.org>
Date: Fri, 30 Aug 2013 11:05:46 -0400
To: www-archive@w3.org
Message-ID: <20130830150546.GA1486@crum.dbaron.org>
Forwarding message previously archived in member-only space at


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

attached mail follows:

I'd like to discuss system colors at some telecon in the reasonably
near future.  In particular, I'd like to discuss the errata I proposed
[1] that I would like to include in the CSS2 errata and I would like
to discuss other changes that we could make in the system colors for
CSS3.  (These are both discussed further below.)

First, though, I'd like to explain why I'm bringing these issues up.
The colors in the default skin for Mozilla (although not the default
for Netscape) are almost entirely specified in terms of CSS2 system
colors.  Over the past few months, I've been working intermittently to
make the appearance of this skin in the GTK port (our primary X toolkit
port) more similar to the appearance of other GTK applications.  This
has led me to discover some very strange things in the way Windows
system colors work that make them inadequate for describing system
colors in GTK applications.  (The CSS2 system colors are a straight
copy of the Windows system colors.)  There are two main issues that
I've run into:  first (in the order I ran into them), the duplication
of colors for 3-D borders and their poor descriptions in CSS2, and
second, the way windows specifies colors for dialogs.


In Windows, Buttons are colored with ButtonText text on ThreeDFace
background (henceforth "colored ButtonText on ThreeDFace").  Things
such as textareas are colored WindowText on Window.  However, things
within dialog boxes (labels of controls, radio button and checkbox
text, etc.) are colored WindowText on ThreeDFace.  This is a rather
bizarre Windows-ism that makes it difficult to emulate other platforms
correctly -- when the CSS2 system colors are used "correctly" in
dialogs, it can make the dialogs illegible for GTK themes where
textfields have dark text on a light background and buttons have light
text on a dark background.  (This is the classic point that one should
always specify color and background together.)

I worked around this problem in Mozilla by implementing the Dialog,
DialogText, Field (this was implemented by someone else well before
since the default GTK window background is a gray color that is
inappropriate for textfield backgrounds), and FieldText colors from the
CSS3 UI draft as -moz-Dialog, -moz-DialogText, -moz-Field, and
-moz-FieldText.  I strongly support the existence of these colors in

3-D Borders

Right now we have two different sets of 3-D borders, one set for a
one-part outset border and the other for a two-part outset border, as
described in [1].  At least, that's what we have assuming that the
incomplete descriptions in CSS2 meant to describe the Windows system
colors that they copied.  I'd like to add to the CSS2 errata (see [1])
to describe these colors better so that implementors on other platforms
at least understand how one might implement these colors.

The addition of new system colors in CSS3 creates a problem about how
to handle borders.  We currently have duplicate sets of border system
color values for describing all the borders in a button, yet in Windows
these all map to the same colors.  We could give them different
meanings so that one set could be used for dialogs, and the other (in
expanded form) could be used for buttons.  However, I think a better
solution would be to simply have ButtonBorder, DialogBorder, etc., as
named in the current CSS3 UI draft [2].  *If* we define the computed
value for system colors as the system color keyword itself (which I
have already argued has advantages for gamma correction and
round-tripping in the CSSOM) these BorderColor keywords can translate
into the correct set of border colors when used on a border (and some
other default when used elsewhere).  (Alternatively, we could define
ButtonBorder, DialogBorder, etc. as keywords for the 'border' property
rather than the 'color' property.  This would have the added advantage
of having them specify the width of the border, although it would make
implementation more complicated since the border width would have to be
accounted for during layout.  Thus I think it might be better to leave
them as values of 'color' but say that the 'border-style' is ignored
when they are used for 'border-color' unless 'border-style' is 'none'.
However, I'd be happy to hear a better proposal on this issue.)

Thus for CSS3 I would like to propose / support:

1. deprecating ButtonHighlight, ButtonShadow, ThreeDFace (since it is
   the same as ButtonFace), ThreeDHighlight, ThreeDLightShadow,
   ThreeDShadow, and ThreeDDarkShadow,

2. adding Border color values for all appropriate UI elements as
   described in [2], with the meaning something like what I described
   above, and

3. adding some or all of the colors described in [2].


[1] http://lists.w3.org/Archives/Member/w3c-css-wg/2001JanMar/0265.html
[2] http://www.w3.org/TR/2000/WD-css3-userint-20000216#color

L. David Baron        <URL: http://www.people.fas.harvard.edu/~dbaron/ >
Mozilla Contributor                      <URL: http://www.mozilla.org/ >
Invited Expert, W3C CSS WG          <URL: http://www.w3.org/Style/CSS/ >
Received on Friday, 30 August 2013 15:06:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:22 UTC