Re: <NEWHTML>???

>>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.<<

    My experience is that its quite easy to make them look OK on old
browsers, it is the different implementations of the CSS rules on the
browsers that DO support them that is making my life a misery!!

Frank

-----Original Message-----
From: Alex Fabrikant <afabrikant@smtpgtwy.ausd.k12.ca.us>
To: afabrikant@smtpgtwy.ausd.k12.ca.us <afabrikant@smtpgtwy.ausd.k12.ca.us>;
www-html@w3.org <www-html@w3.org>
Date: Thursday, March 05, 1998 8:06 PM
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
>
>

Received on Friday, 6 March 1998 15:41:45 UTC