RE: A single specification

You will note from my original comment that I have suggested doing exactly 
what you are suggesting by providing levels/modules of the specification 
which add the required extensions to HTML for each module. I am in no way 
implying that a single spec should cover all aspects of the browser 
interface, merely that the base spec should be extensible by module and not 
contain superfluous extensions implemented at the discretion of the browser 
manufacturer's.

If a browser maker support HTML 4.0 then they should support all of it.

>I would like to suggest/propose a unified, modular specification for the
>following languages / specifications / options:
>
>- HTML 4.0
>- CSS1
>- The DOM (Document Object Model)
>- ECMAScript (Formerly JavaScript)
>- DOM / ECMAScript integration rules
>- Other interpreted presentation / application options

Please - NO.

Making it part of one spec is the best way to ruin them all.

Keeping things seperate, but with a common set of interface points, allows
the WGs to do their work well.  It allos developers to change components
as each area changes.  It stops the hold ups when one small thing in one
area is lagging.

Making things monolithic has been proven the worst thing to do countless
times in software and in specifications.

Imagine if all of the PPP RFCs were one monolithic RFC.  That would be
madness.

>The current HTML 4.0 specification provides extensive support for the
>integration of style sheets and scripting but does not include the style
>and script specifications themselves. This could set up conditions where
>browser vendors claim HTML 4.0 support without supporting any of the
>implied style and script extensions.

A browser can support HTML 4.0 without doing DOM - that is legit.  Making
it one monolithic spec will not force anyone to do anything - browser
makes will just ignore it as being unreasonable.  And frankly, I'd agree
with them.  Bluntly I don't expect, nor WANT, all browsers to start adding
scripting or DOM support.  It doesn't make sense for all UAs to do so.

Keeping things seperate is the only sane way to approach standards
development.  Once things become too closely tied, it acts like an anchor
restraining development, and expecially deployment.

-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com
For support requests: support@livingston.com  <http://www.livingston.com/>
Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Received on Wednesday, 20 August 1997 03:36:02 UTC