This is partly true; if NetScape had released powerful authoring tools
that generated HTML that worked properly on the web as opposed only in
NetScape, it would have made the damage less painfull. It would have
solved the problem of the damage they've done even if you ignore the
extensions(*). It would have done so because:
> It's those extensions -- not
> publicly specified stuff like <FONT>
If there's a public spec for the netscape extensions that sufficient
to implement from, I'd love to know where it is. NetScape doesn't
answer my questions, and I refuse to use "try it and see" as a
guideline. The lack of specifics has led to interesting situations;
one of my clients went through and did a nice white-on-black page.
Load it in emacs-w3 - which implements the netscape extensions - and
get an offwhite on white page. Why? Because NetScape accepts spaces in
the color value, but doesn't document this anywhere.
<mike
(*) Anneli was absolutely fuming at NetScape, with comments on "making
fortunes helping millions of clueless people do the wrong thing." A
magazine she likes had recently bragged about their web pages. Turns
out they aren't navigable in anything but NetScape because of
NetScapes broken attribute parsing. The response from the magazine was
that 25% (their estimate) of their market wasn't worth spending a few
minutes fixing the problem, or even doing it right next time.