Re: deprecated tags in Wilbur & Cougar -Reply -Reply

> I cannot agree with this. If you are writing a filter from FrameMaker,
> then it is a straighforward matter to avoid name clashes, for example,
> by using a prefix string. I intended the CLASS attribute to be used to
> support the ability to differentiate different roles for the same tag
> and to avoid the need for browsers to add new tags. The alternative
> is to define you own DTD and use DSSSL to specify the rendering, but
> this is a major delta in complexity.

There is a step inbetween were users can define DTDs that are a superset of
HTML and use CSS (or CSS 2) to define presentation. This is certainly more
complex for authors who write HTML by hand, but seems to be a more robust
solution. It seems to me that classes will become just as complex, if you
start doing things like checking to see if people use certain classes in the
proper contexts. Or will classes be limited to the content models of the
elements that are attached to?

With a DTD we could do something like the following:
         <LOCALNUMBER2> 5345 <LOCALNUMBER2> 

With HTML and classes you could do
         <SPAN CLASS="LOCALNUMBER2"> 5345 </SPAN>

If you want to express in a formal document that a phonenumber must have
a LOCALNUMBER1 and a LOCALNUMBER2 (in that order), then you will need 
something like a DTD.

I guess the questions, is do we want to require and/or allow explicit 
content models or not? With classes we have to either disallow content model
specification, or invent a whole new way of doing it.

I agree that we want a way for the man on the street to create new
presentation classes without having to learn how to read and write a DTD.

Our point of disagreement is, do we want to allow UA authors to create
new presentation classes without writing a DTD (or at least a DTD fragment). I
think UA authors should be able to step up to the plate and create DTDs for
their UAs and understand DTDs that others create.

Received on Wednesday, 7 August 1996 17:26:41 UTC