Re: HTML 3.2 PR: Miscellaneous + typos -Reply

Eric Holstege (
Mon, 18 Nov 1996 05:09:45 -0800

Date: Mon, 18 Nov 1996 05:09:45 -0800
Message-ID: <>
From: (Eric Holstege)
Subject: Re: HTML 3.2 PR: Miscellaneous + typos -Reply

Supporting the naming of colors is a waste of disk space and programmer time. 
If every browser has a table of (say) a hundred colors, at (say) 20 bytes per, 
you've added 2K of disk space to 50+ million user machines. That's a hundred 
gigabytes. What have you gained by that. You've made it easier for people who: 
hand write HTML AND speak English AND aren't able to convert decimal to hex. As 
time goes on the vast majority of HTML will be generated with editing tools 
that have color pickers in them. For people who must hand tune HTML (still a 
sizeable population), a tool to convert RGB values to hex, or even a piece of 
paper with the hex codes for common colors, is a preferable economic solution 
to burdening 50 million users with a larger disk space requirement. Sure, 2K is 
not much, but iterate over hundreds of similar decisions in hundreds of 
products and you have a partial explanation for code bloat.

I saw an argument to the effect that gamma correction was a reason to abstract 
away from the specific RGB value and use a color name instead. This seems 
unlikely, because the browser must be prepared to deal with and gamma correct a 
hex RGB value anyway. The most likely implementation is to take the color name, 
convert it into RGB,  and then do the gamma correction of the RGB before 
displaying. The gamma correction must be applied at the last moment becaue it 
is different for display and for printing. This is how paint programs like 
PhotoShop do it.

______________________________ Reply Separator _________________________________
Subject: HTML 3.2 PR: Miscellaneous + typos -Reply
Author:  Charles Peyton Taylor <> at Internet
Date:    11/18/96 11:47 AM

I agree with nearly everything Galactus said.  A few exceptions:

>>> Arnoud Galactus Engelfriet <> 11/17/96 12:03pm >>> 
>In the section on the BODY element, the text states that the 16 color names 
>are widely understood. It is my experience that not all user agents which 
>understand body colors also understand the color names, and those that do do 
>always use the same color values. I would suggest that the specification at 
>recommends the use of color codes instead of  color names.

Well, some browsers understand colors for backgrounds without understanding 
colors for text or links.  It's been my experience that these (like, say, 
NCSA mosaic) don't understand color names.  

If you use "background=#000000 
text=#ffffff" on these browsers, you'll get black text on a black background 
(which "Hitchhiker's Guide to the Universe" book had the black car with the 
black trim and the really really black piping?) If you use "background=black 
text=white" you'll get black text on a grey background, which still isn't what 
you wanted, but it's legible.

>The section on BLOCKQUOTE notes that block quotations are often rendered as 
>indented text. Is such a note necessary? It often leads to confusion about the 
>purpose of this element -- on Usenet, I see daily claims that
><BLOCKQUOTE> is the "indent tag".



>In the section on IMG it should be noted that currently only GIF, JPEG and 
>PNG images can be inlined. 

What about "sometimes PNG".  Do the latest MSIE and NS Nav. support PNG yet?


>In the section on APPLET:
>   [on the contents of this element]
>   browsers ignore this extra HTML code. You can use it to show a
>   snapshot of the applet running, with text explaining what the applet 
>   does. Other possibilities for this area are a link to a page that is 
>   more useful for the Java-ignorant browser, or text that taunts the
>   user for not having a Java-compatible browser. 
>While I agree with the concept of encouraging people to use the contents of 
>to provide an alternative, something like "Click here to download a 
>browser" should never be recommended in a specification. What if the user _has_
>Java-compatible browser (or OS) but has turned this off for security reasons?

Or because it keeps crashing his system and/or corrupting his 

>The term "Java-ignorant" suggests that having Java support is somehow better 
>not having it. Would something like 
>   Other possibilities for this area are a link to a document that 
>   presents the content of the document without the requirement
>   for Java support.

Or an image map, as in the case of webmonkey (


>Galactus who will now update his reference to adhere to the latest version :-) 
>- --  E-mail: .................... PGP Key: 512/63B0E665 
>Maintainer of WDG's HTML reference: <>