Re: Conditional HTML Alternatives

At 10:01 AM 3/18/96 -0600, Scott E. Preece wrote:
>Unless I'm missing something, this only helps if there's a single spec
>for the given element.  That is, a TABLE/NOTABLE distinction doesn't
>help if there are Netscape 1.2 tables and Netscape 2 tables and HTML 2+
>tables and HTML 3 tables and...  WIth marked sections you don't have to
>depend on distinguishable element tags, but can have a richer set of
>feature test names.

That's a good point. But element names can be more meaningful that "TABLE".
For instance NSTABLE or TABLE.SOFTQUAD. Maybe it's a good idea to force
elements with different behaviour into different element names. When a
standard for a particular feature arises, the proprietary names could be
deprecated and collapsed into the standardized version.

Most often, 

 * one browser introduces a feature that a competitor doesn't have at all, or 
 * one browser tries to clone a competitor's behaviour, (and therefore uses
the same element name, and a backwards compatible content-model), or
 * several browsers introduce similar features under different names
(applet, embed, fig) so there is no conflict.

I guess what I'm trying to say is that I am willing to risk element name
conflicts because I think (as you seem to) that this situation is going to
occur less and less as the Web evolves. The number of times in the past
where this would have been a problem are few. Nobody wants to introduce a
backwards-incompatibility (even with a competitor's proprietary tags)
because existing pages will look "wrong" in their browser.

 Paul Prescod

Received on Monday, 18 March 1996 11:32:02 UTC