Re: Color: auto, or colour fallbacks

> 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. 

I rather want to believe in each Web developer's responsibility to create
valid, usable and accessible Web pages (although that ain't likely, I know)
than to force all layouts being 'raped'. So I don't agree, and I guess all
developers work is obsolete when every user-agent overrides site layout.

Second, if you begin allowing not only maximum contrast (I guess you mean
black text on white background) but even alternative and still readible
alternatives, you'll IMO get a definition problem -- what is 'enough' contrast? #000
on #EEE? Or #036 on #9CF, is this okay, since user-agents have to calculate
acceptable values for maybe 'color: auto'?

Only some thoughts.


Best regards,
 Jens Meiert.



> 
> 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.
> 



-- 
Jens Meiert

Steubenstr. 28
D-26123 Oldenburg

Mobil +49 (0)175 78 4146 5
Telefon +49 (0)441 99 86 147
Telefax +49 (0)89 1488 2325 91

Mail <jens@meiert.com>
Internet <http://meiert.com>

Received on Saturday, 5 July 2003 11:46:55 UTC