W3C home > Mailing lists > Public > www-validator-css@w3.org > May 2008

Re: http://jigsaw.w3.org/css-validator/validator results legibility

From: Felix Miata <mrmazda@ij.net>
Date: Thu, 01 May 2008 10:26:40 -0400
Message-ID: <4819D320.6030409@ij.net>
To: www-validator-css@w3.org

On 2008/05/01 19:39 (GMT+0900) olivier Thereaux apparently typed:

[Re: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5592 ]

> I have followed parts of your patch very closely (e.g font size),  
> others I respectfully disagree with (making the text color stronger  
> than the rest of the text on the results page, for instance) and  
> therefore settled for a compromise patch that I hope you will find  
> acceptable.

I don't find your proposed colors fully acceptable. They are a definite
improvement. They do technically pass the brightness and contrast tests.
However I find those brightness and contrast tests to be too liberal.

I'm of the opinion that the widespread concern among web designers that #000
on #FFF is too bright and/or contrasty was instigated and is perpetuated by
people with (generally large) brand new or newish displays that have never
had proper brightness and contrast control adjustments, and remain as shipped
from their factories with those both those adjustments set to 100% or nearly so.

Setting to 100% at the factory makes them look good to the uninitiated
sitting on brightly lit store shelves, but is a detriment to the displays
themselves. Leaving them thus set accelerates their aging. Those aware of
this, and those otherwise enlightened, properly adjust their brightness and
contrast to levels suitable for their local environments and/or conserving
the life of the display. As aging deteriorates the device's performance, the
controls can be readjusted to compensate only if they aren't already up to 100%.

Older displays that for whatever reason don't have normal contrast and/or
brightness capability any more can do just fine if maximum contrast and
brightness are used on a web page, but make reading difficult when authors
use #FFF backgrounds with text more than a little lighter than #000. The
effect is similar when light non-white backgrounds are used. In those cases,
the foreground should only rarely be anything other than #000.

I find on a display with correctly adjusted brightness and contrast that the
difference on a #FFF background between #222 and #333 is the difference
between acceptable (#222) and uncomfortable (#333). In every case, I find
darker than #222 noticeably better still.

The whole subject of brightness and contrast above is similar to the
pervasive problem with undersized web page text, undersized because web
authors think something less than 100% of the browser default can somehow be
better. They only sit in front of their own displays. Their data is wholly
insufficient to determine what is better in environments other than their
own, whether for text size, or text brightness and contrast.

> The style patch can be tested at:
> http://qa-dev.w3.org:8001/css-validator/

> It would be great if this change to the results page could be tested  
> on a variety of browsers. Indeed, reports on any style bug currently  
> showing would be much welcome.

On WinXP I looked with IE7, Safari 3.1.1, Opera 9.27 & FF 2.0.0.14. On OS/2 I
looked in Firefox 3.0b5 and 2.0.0.14. On Linux I looked at FF 2.0.0.14, FF
trunk, IE6 and Konqueror 3.5.5. I saw no apparent differences among
Konqueror, IE7, Safari & Opera.

In IE6, the badgeSnippet left border runs through the right side of the
images that the other browsers all display as intended to the left. I don't
find this to be a problem, but merely a noticeable difference.

In FF2, the example badgeSnippets are pushed right as if there were two
inline-badges to their left instead of one.

In FF 3.0b5 on OS/2 behavior seems pretty much the same as all other browsers
except FF2.

In FF trunk on Linux, I tried 1856x1392 full screen and smaller windows.
Regardless of window size, the upper example badgeSnippet remains to the
right of its inline-badge, while the lower example badgeSnippet is always
pushed below its inline-badge (the same as the other browsers do when the
window is sufficiently narrowed).

Since the rest of the text on the page is #1F2126, I recommend
pre.badgeSnippet either use exactly the same, or a color with similar
brightness & contrast, such as #222. Better yet, do as I proposed, and use
#000 on a slightly darker than #FFF background.

FWIW, the brightness/contrast problem on many W3 pages is so noticeable that
I was forced to create a site-specific user stylesheet ruleset to compensate
for most of its non-black text.
-- 
". . . . in everything, do to others what you would
have them do to you . . . ."       Matthew 7:12 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
Received on Thursday, 1 May 2008 14:26:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 June 2012 00:14:20 GMT