Re: <NEWHTML>???

Alex Fabrikant (afabrikant@smtpgtwy.ausd.k12.ca.us)
Thu, 05 Mar 1998 20:05:40 -0800


Message-Id: <s4ff05b1.023@smtpgtwy.ausd.k12.ca.us>
Date: Thu, 05 Mar 1998 20:05:40 -0800
From: Alex Fabrikant <afabrikant@smtpgtwy.ausd.k12.ca.us>
To: afabrikant@smtpgtwy.ausd.k12.ca.us, www-html@w3.org
Subject: Re: <NEWHTML>???

>As for new features of HTML, complexity shouldn't run that high
>and new elements are designed to be backward 
>compatible. The HTML4.0 strict model is a super-HTML2.0 that 
>kicks out the mess done by adding zillions of ill defined elements. 
Yes, indeed, the new HTML models must, by definition, be backward
compatible. However, implementing some elements as such is becoming
an increasing problem. For example, to create a site based on cascading
style sheets that still looks normal on older browsers requires a lot
of effort -- more than it should, in my opinion. 


>There is the NOSCRIPT element for 
>browsers that do not show scripts, and also mechanisms like OBJECT 
>or IFRAME seem adequette for most cases.
>Putting both new and old version in the same document 
>(as NEWHTML and  NOSCRIPT do) reduces downloading time.
>The user always will download data he doesn't get anyway!
>That is an advantage of OBJECT, the old browsers don't download 
>what they can't understand. (but new browsers may load everything)  

Yes, some minor equivalents have been created -- but if for each major
new tag you have to create a new <NO...> tag, an unnecessarily large
number of tags will be created. NOSCRIPT, NOFRAME, and NOLAYER exist
already [not sure on the standard re. NOLAYER, but still] -- and each
time a new feature is introduced, another replacement will need to be
made. Introducing a universal "alternate content for new elements" tag
should save a lot of redundancy.


>The NEWHTML proposal is more related I think to XML or the HTML-Math 
>working group. The question there is how to embed
>MathML (or other XML) in HTML documents.
>I think that one proposed solution is to use a MATH element
>that is similar to the NEWHTML element.

I'm not familiar with the solution decided upon for MathML, but this,
again, seems to be an unnecessary special case of what should be covered
by a NEWHTML tag. To expand on the old example:

<NEWHTML>
<!--
parameter="mathml"; version=1.0; end="EndOfMathML"
[MathML lines]
EndOfMathML

parameter="XML"; version=2.03; end="</XML>"
[XML tags]
</XML>
-->
<OLDVER>[alt. text sans MathML and XML]</OLDVER>
</NEWHTML>

Actually, come to think of it, the name NEWHTML would then be somewhat
inappropriate -- but that, again, is minutia.


On a side note--
I can see that, over time, the excessive use of this syntax can bring down
download speeds. BUT. a. The hardware speeds are still growing. AND b. If
this does become widespread, why not implement a corresponding extension
to the HTTP Accept header line, and have the server parse the code, pulling
up only the parts of NEWHTML fragments which the browser would understand.


--
Alex Fabrikant
afabrikant@ausd.k12.ca.us