Re: HTML4.0 draft: comments re: inclusion of frames (fwd)

Arnoud (
Wed, 10 Sep 1997 19:48:54 +0200

From: (Arnoud "Galactus" Engelfriet)
Date: Wed, 10 Sep 1997 19:48:54 +0200
Message-ID: <>
Subject: Re: HTML4.0 draft: comments re: inclusion of frames (fwd)

In article <>,
MegaZone <> wrote:
> Once upon a time Arnoud "Galactus" Engelfriet shaped the electrons to say...
> >The problem here is that "reality" mostly means "Whatever Netscape
> >comes up with", as far as new HTML extensions are concerned. Given
> >their history of strange extensions, that's not really a good way
> >to work on a new standard.
> OBJECT is NS?  CSS support is NS?  Navigation hotkeys is NS?
> Internationalization is NS?  The full tables support is NS?

Is any of that *implemented* in Netscape right now? 

It's true that the HTML 4.0 draft has some new stuff, but a *lot*
that is in there is copied almost literally from how NS (and IE)
do it. Look at the huge number of JS-related attributes. Surely
there are better ways of doing that? 

And to get back to the subject at hand, what the **** are NS's
frames doing in there? That implementation (meaning the elements
and the approach) is just plain bad. It breaks non-supporting clients,
there is no alternative presentation if you can't display the frames
in the indicated order, there is no way to assign a logical meaning 
to the framesets[0], the "one URL, one document" model no longer holds,
and so on.

[0] By that I mean something like the LINK-method of indicating 
related documents, perhaps with a link to a stylesheet or something
to suggest a specific visual presentation of the various documents.

> I think people really need to stop beating up NS and MS just because it
> is easy, and step back and take a better look at HTML 4.0.

I'm not beating up NS because it's easy. What I'm doing is trying to
argue that the inclusion of the above-mentioned things in HTML 4.0,
because I feel they have no place in there. 

And *if* the extensions proposed by NS and MS are really so easy to
criticize, then doesn't that perhaps suggest that including them
in a standard without modifications may be a bad idea?

E-mail: .................... PGP Key: 512/63B0E665
Maintainer of WDG's HTML reference: <>