Re: color: NCSA Mosaic, Netscape, and HTML3

kitblake (kitblake@gig.nl)
Mon, 24 Jul 1995 12:50:31 +0100


Message-Id: <9507241049.AA22250@waterloo.gig.nl>
Date: Mon, 24 Jul 1995 12:50:31 +0100
To: www-html@www10.w3.org
From: kitblake@gig.nl (kitblake)
Subject: Re: color: NCSA Mosaic, Netscape, and HTML3

<mike wrote:

>> For instance, since the background tile is apparently already part of the
>> 3.0 DTD, I think Lou (a la Netscape) has sufficiently proven that it is
>> neccessary to change the text colors (blue anchors disappearing into a blue
>> background, etc). Accept it. Announce colors in HTML 3.
>
>So why don't you do it?  Write up something that is rigorous enough to
>be considered an internet draft, and send it to the working group
>(which makes you de-facto part of the working group).
>
>The real question is: why hasn't NetScape done this?

Yes, that is THE question, and I'm sure it hooks in with a market
mentality. But from my newbie position, I am trying to formulate
alternatives to the present solution process, which generates a lot of
problems, as evidenced by the negative feelings and Netscape bashing one
sees on this list.

I believe this problem will cycle. As soon as 3.0 is finalized, some will
begin "improving" it. Deja vu. 

Perhaps the answer lies in the following snip, from Brandon Gillespie's post:

>Because in the HTML 3 draft it states that backgrounds are really *ONLY*
>inteded for clients which do not support style sheets.  Style sheets
>should give you the ability to change colors/backgrounds/whatever.
>Netscape should (for once) try following a standard (of sorts) and USE
>STYLE SHEETS INSTEAD.

Wouldn't it be possible to formulate the DTDs with the evolution of
browsers in mind? Becuase we know they cycle faster than the Internet draft
process? Above, there is a feature supported, but only for/until a browser
catches up with code implementation. In this way, both browser makers and
HTML users are aware that they are employing "not-final tags", which will
be retired in the future, but give them the desired result now.

This would be a resilient solution, as opposed to the present absolute
process. Ideas - good ideas - which will in the future operate outside of
HTML, can still be part of a standard which everyone had better follow.
This would allow important developments like:

> Netscape's table markups do not conform to the HTML v3 DTD.  Nowhere in
> the DTD does it indicate that the border attribute may take a value for
> thickness, or anything else, for example.

IMHO, the border attribute is a good idea. But it is presentational, and
thus should not be in (absolute) HTML, but in style sheets. Until style
sheets are viable, "resilient HTML" could carry such features. (In a sense,
"resilient HTML" could also function as a beta test. Until features are put
into practice, it's very difficult to predict how they will integrate. So
"resilient HTML" would allow flexibility, and unforeseen problems to be
corrected. New tags  could even have a probationary condition until they
are fully tested.)

This might be a way for the standards process to keep pace with the
breakneck innovation on the Web. The HTML Working Group should spend its
energies on development, not damage control. Perhaps the same solution
could also work for style sheet development.

kitblake


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 kitblake@gig.nl                                                  Amstel 222
 ELECTROGIG Europe                                        1017 AJ  Amsterdam
 http://www.gig.nl/                                          The Netherlands
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~