W3C home > Mailing lists > Public > html-tidy@w3.org > October to December 2001

Re: CheckColor default

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sun, 04 Nov 2001 14:31:56 +0100
To: Klaus Johannes Rusch <KlausRusch@atmedia.net>
Cc: html-tidy@w3.org
Message-ID: <migautgds932fv2iqseb9fge4kflds8lu3@4ax.com>
* Klaus Johannes Rusch wrote:
>In <jgaautg3267nbnq1e5qsth3k4rnfqvobrq@4ax.com>, Bjoern Hoehrmann <derhoermi@gmx.net> writes:
>> No, the behaivour is intended, Tidy should IMO always transform the case
>> of hex digits and replace those 16 colors with their corresponding color
>> names.
>There are at least two good reasons:
>* Color names are supported by MOST browsers but there are some, admittedly 
>  historic, browsers which only understand color values.

Please name them. Color names were included in all HTML versions, user
agents that do not support them are simply non-conforming. There may be
many that do not support e.g. color=orange, since orange is no valid
color keyword.

>* tidy should change what needs to be changed, but not mess with code that is
>  already valid. The author of a document may have had a good reason, or just
>  a personal preference, for choosing a color value instead of a color name.

Tidy generates a canonical version of the document. What this includes
is not specified.

>> >The option probably should allow conversions in both directions, i.e.
>> >
>> >        ColorAttributes: symbolic|hexadecimal|asis
>> I don't see any good reason why one wants Tidy to turn readable color
>> names to unreadable color codes.
>I do not see a benefit in making tidy unusable for folks who need to or 
>want to use color values.

I don't argue about an option to prevent the change the color values, I
argue about conversions in both directions.
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/
Received on Sunday, 4 November 2001 08:32:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:38:51 UTC