Color: auto, or colour fallbacks

A few weeks ago, I turned off author colours in my office IE (to 
view a mobile phone operator's site where detail text was in white
on white (presumably controlled by scripting).  I've kept it that 
way because it makes most sites easier to read, and, particularly,
because it re-enables the visited link function in the browser, which
authors often frustrate.

Given that authors still seem to want to control colours and in
particular link colours, it occurs to me that a facility, primarily
for user styles sheets, to let the browser choose a colour that maintains
a distinction between pseudo-classes, background and foreground, would
allow some compromise between user needs and author wishes.

The initial thought were:

color: auto
background-color: auto

which would cause the browser to choose a colour for maximum contrast
with the background colour and any of the other possible foreground colour
states of the element.  However more control might be possible if there
were a choice list of colours, with auto as a possible last choice.

The algorithm for auto colours really also needs to be under user as well
as browser control.  A browser may know the characteristics of the display
hardware, but doesn't know whether the user has colour vision defects.

Getting more complicated would be a facility to specify the degree of 
contrast before the auto mode stepped in.  E.g. with the white on white case,
there is no contrast, so an auto color for the non-pseudo classed element
ought to kick in and turn this to black on white (a problem for some keyword
stuffing techniques!), but, where there was some contrast, the user could
choose how far the browser would go in respecting the author colours.

I think that there ought to be a MAY clause allowing user agent to take
account of the page as a whole when choosing an auto colour.  auto should
inherit as though it were a computed value, although the user agent
may/should remember the computed value of the actual colour used, so that,
for example, small shifts in background colour don't cause a change in 
foreground colour unless the contrast is degraded too far.  (The suggested
MAY clause would allow the user agent to use the first auto colour when
it found the second background colour, not as a descendant, either by
treating it as a descendant for that decision, e.g. if it had not seen
the background as a real descendant, or remembering that it had made the
same compromise when it was a real descendant.  Whilst the MAY clause 
also allows a global solution, with fixups, it could cause a useful
improvement even with once only incremental rendering.)

A weakness of this approach is that it doesn't allow a user to force all
links to contrast, but have the same colour in visited and active pseudo
classes, as simply overriding the authors equal colours for all of them
would force all the colours to be distinct.  I don't think that the following,
as a way of requesting that, would be really in the spirit of CSS:

:link, :visited, :active  { color: auto; } /* not suggested */

This, I think, represents, in part, an awkwardness in these pseudo classes. 
This example would work better if :link were really a[href] and :active and
:visited where treated as inheriting from that, so that color: inherit could
cancel the author styling.  However the milk is already spilt.

To be useful, except where authors underspecify colours and create a
poor contrast with a browser default, this will almost always have an
!important qualifier.  Also, being a user style sheet, there need not be
a physical style sheet to edit; it might be implemented by other means in
the browser HCI.  However specifying in style sheet terms still creates
a model of behaviour that may encourage implementation.

Received on Saturday, 5 July 2003 07:19:09 UTC