On Fri, 2 Feb 1996, Brian Behlendorf wrote:
> On Fri, 2 Feb 1996, Terry Allen wrote:
> > Marc Hedlund:
> > | I would be interested in hearing whether the group would like to consider
> > | some variety of conditional HTML system, as has been recently discussed
> > | on www-talk (messages from Brian Behlendorf and myself).
> > There is such a system already in use on the Internet. It's called SGML.
> Terry, we went around this issue before, with "Marked Sections". Check
> out the discussion that starts with a message from Glenn Adams, at
> The idea was to define entities corresponding to feature sets, then
> switching between sections. While the syntax is kind of ugly, I could
> live with that. Is this acceptible to the SGML gurus out there? I got
> the feeling it was greeted with all the enthusiasm of a traffic accident,
> thus the desire to look for solutions outside of SGML (hence using
> Now, Murray Altheim did say the following, in
> > Unfortunately, the SGML spec states that in the event that a status
> > keyword is undefined, the section will be _included_. This is the one
> > place where marked sections alone may create a difficulty. Netscape's "be
> > liberal in what you accept philosophy" (basically dump everything to the
> > screen) fits right here. Any undefined sections would be included. What
> > would be required to solve this problem I believe would be required of
> > any content negotiation scheme: the document must specify what features it
> > contains. Then, the converse NOT sections could properly be defined
> > "IGNORE".
In that same thread, Glenn Adams (if my memory is correct)
suggested proccessing instructions as an alternative to the <IF>
approach originally proposed after I raised similar concerns about the
limitations of marked sections. It seemed like his idea (combined
with some name space definition discussion we had) had real merit.
The discussion fizzled. As you note, a content negotiation
support feature would be required to identify this new level of
HTML. Once we have that content negotiation and conditional HTML,
the whole issue of backward compatibity has a uniform solution.
>From that point forward it would not be necessary to choose
element syntax such that old browsers could ignore the undesirable
I believe we also acknowledged that servers could also pre-process
the conditional markup if the client was known to not support
conditional markup directly.