Conditional HTML Alternatives

David and I were discussing an alternative conditional HTML strategy that
requires application tag conventions like <FRAME><NOFRAME>, <TABLE><NOTABLE>. 

At 06:05 PM 3/17/96 -0800, you wrote:
>I believe the difficulty with this approach  has to do with not 
>knowing whether the unknown tag might have content or not. 

In the long run, this is solved because documents are supposed to have DTDs.
That was one of the major points of Dan's post on conditional features. In
the short run, there are three possible conventions that can clarify this
issue. 

#1.Force the NOXYZ first (that's not so nice, but doable)

#2.Require all new elements to have non-omittable end tags. 

#3.The third solution is actually pretty nice, I think. We can require all
new elements to _contain_ a NOXYZ tag. So if we go back in time and were
recreating HR, it would be

<HR>
<NOHR>
----------------
</NOHR>
</HR>

And IMG would be

<IMG SRC="rover.gif">
<NOIMG>
A picture of my dog.
</NOIMG>
</IMG>

Now if we change the DTD to make the NOING tags ommittable in the DTD, then
we have

<IMG SRC="rover.gif">
A picture of my dog.
</IMG>

Which looks alot like the much lauded (and much grieved) FIG element. One
neat thing about the NOXXX proposal is that element alternates can be
enforced in the DTD the way FIG did it.

This convention is similar to Joe English's ALT proposal, but it creates a
new alternate element for each new feature.  This allows you to customize
the content model of the alternate contents. (the potential for abuse
otherwise is quite high)

>It might work if the <NOxxx> element were first but my
>intuition is that since we need some new mechanism, the marked sections
>or CPP approaches are more general and easier to understand and no 
>harder to implement.

They aren't harder to implement, but they involve a very different paradigm.
The convention I describe is a feature for _conditional display of
elements_. CPP or marked sections are _conditional inclusion of elements_.
It is a level above that which I am proposing. That extra level could add in 

 * boundary problems (esp. with SGML's mystical RS/RE rules), 
 * validation problems (it was valid with _these_ sets of flags), 
 * editing problems (same as the validation problems) etc.

I also wonder what new problems will arise as the Web evolves. When we add
entity management, will there be interactions? 

> >    Since SGML validation utilities wouldn't understand the
> >    features, the whole file including alternative forms would have
> >    to validate as is.
> 
>> This is a good thing, isn't it? I don't think most people want to have to
>> run their validation script 8 times with different flags.
>
>What I was trying to say I think was that to validate new feature XYZ,
>the sgmls-s would require a DTD that represented all features. Furthermore,
>all new features would be constrained to co-exist within a 'single' DTD.

I think that this is a very good thing. An HTML document should validate
according to a single DTD. Rhe conditional inclusion proposals move us away
from that by making it harder to validate, and introducing the concept of a
document that validates to different DTDs depending on what flags you use.
Imagine people faced with a WebTech validator that returns: "This document
fails to validate when TABLES are turned off, FRAMES are turned on and
SCRIPT is turned off." I think any new validation burden should be avoided.

It is better to just make a superset DTD. 

Opinions?

 Paul Prescod

Received on Monday, 18 March 1996 10:37:06 UTC