Re: Conditional HTML Alternatives

Paul Prescod (
Fri, 22 Mar 1996 16:01:52 -0500

Date: Fri, 22 Mar 1996 16:01:52 -0500
Message-Id: <>
To: "David W. Morris" <>
From: Paul Prescod <>
Subject: Re: Conditional HTML Alternatives
Cc: Paul Prescod <>,

At 01:17 AM 3/21/96 -0800, David W. Morris wrote:
>These proposals break because they demand that there be a DTD which
>which describes all possible combinations as opposed to having two
>DTDs which are applied conditionally. 

Websoft has always maintained such a DTD as have others (InContext, for
example). Is there any reason to expect that they would stop?

>THe CPP and MARKED section
>approachs don't require:
>  1.  COntent providers to be DTD lawyers

They don't have to be DTD lawyers. They just have to download the latest
experimental DTD from W3C, WebSoft or someone else?

>  2.  Every UA to be capable of groking every arbitrary DTD and mapping
>      it against the UA's capabilities.

No they don't. If you don't recognize an element name, you look around for
the NO.XXX element. You don't have to be able to read a DTD to do that!

>In addition, there are UA characteristics which are not ever likely to
>be represented in a DTD. For example, hardware characteristics of the
>UA's execution environment. 

We are talking about a platform for experimentation, right? I didn't mean to
suggest that my convention would replace marked sections _everywhere_. HTML
already supports marked sections. I'm saying that the existing marked
section mechanism is not the best tool to use for experimental feature
support. It is too hard to validate and (subsequently) edit.

>THe <ALT> proposals, the <NO*> proposals etc. all become rather quickly
>embroiled in discussion of how to order things what the content model
>might have to be, what the restrictions are  on extensions to make it
>work, etc.

Discussion isn't bad. Sure, the proposals seem more complicated, but they
are complications for the UA vendors and DTD writers instead of
complications for authors.

>We need and will continue to need a solution which transcends those
>concerns. Lets create an extensiblity environment where we can devote
>our energies to design of the functionality not how to retrofit it
>to the existing world.

The whole point of this discussion is about how to retrofit functionality
into the existing world! How can we ignore that issue???

>Don't presume that a situation has a single alternative. Don't require
>any understanding, including access to new DTDs, on the part of 
>already deployed UAs for the new features/markup to be tolerated

My proposal used several redundant conventions so that UAs would _not_ need
to get new DTDs. That was a major concern of the proposal. My solution is no
more or less dependant on new DTDs than is any marked section-based proposal.

 Paul Prescod