> It's a shame that folks compromise the structural integrity of their
> documents to convince Mosaic to display documents the way they'd like.
> It discourages folks from, for example, developing tools to build a
> table of contents out of the <Hn> tags in HTML documents, since those
> tags are used for font changes, rather than to mark headers.
(First, excuse me if I rehash old argument, but I just joined this list)
It is indeed a shame, but one can argue that is was extremely
foreseeable.
HTML (in all its flavours) is a lobotomized SGML. It (like RTF)
sits on the fence, being neither purely a formatting description
language (like raw troff), nor purely a high-level document
description language (like SGML).
You've got elements of both, and most people don't know how to
make the distinction.
I know the argument that "we can't build a full-fledged DTD
interpreter into Mosaic, etc...." -- can't we? Why not?
If I visit a home page on Katherine the Great's library of
Voltaire's books in St. Peterburg, how is my viewer supposed
to know to display in Cyrillic and not Latin1?
Another thing: there is no mechanism for displaying mathematical
and scientific notations. What if I wanted to cut and paste a
formula from Mosaic to a Latex document that I was editing?
A properly done application should be able to do the conversion
from one syntax to another, but only if it retains all the *semantic*
information necessary.
Otherwise it's like trying to regenerate EQN source from the troff
output...
> But presentation _is_ important.
>
> And even when (not if) some sort of stylesheet mechanism gets deployed,
Damn right it will. It has to be.
> do you think somebody's going to:
>
> * give an element an ID and construct a stylesheet that gives
> the element with that Id a little more space, and maintain
> the association between the document and the stylesheet
> or
> * add a <p> tag before the element
>
> Yup. Thought so.
>
> So what if we gave folks an option that's as simple as adding a <p>
> tag, but doesn't affect the structure of their document at all?
No, no, no. That's a band-aid. For each quick-and-dirty fix you
can come up with like that, I can find you ten more problems...
> What if we support little bits of DSSSL inside processing instructions,
> ala:
>
> <ul>
> <? (space-before: 12pt) >
> <li> xlkjdlfkj
> <li> ablkjasdf
> </ul>
>
> <dl>
> <? (font-weight: 'bold font-size: 14pt)> <!-- get the right font -->
> <dt>Slug
> <dd> explanation
> </dl>
No. Because I might want to cut and paste that list into another
document, which might be in another font, another size, etc. This
is a hack.
Don't Mix Logical And Physical Elements. Period.
> This has the following features:
>
> * It's simple to maintain
> * It's independent of the DTD. You could use it in HTML, HTML+,
> DocBook, etc.
But we don't *want* it to be independent of the DTD. All this shit
should be in the DTD in the first place.
> * The semantics can be defined in terms of DSSSL, a (draft)
> international standard with zillions of person-years of
> work behind it
> (if a different stylesheet mechanism gets deployed, the same
> sort of thing should work. But DSSSL-Lite seems as good
> as any right now.)
> * It doesn't affect the structure of the document
(Doesn't it? Are you sure?)
> When you get to the point that there are so many processing
> instructions in there that it ceases to be "simple to maintain," you
> have the option of creating a suitable stylesheet.
Even before then. Why are people so scared of stylesheets?
> The only tricky thing is to decide what the scope of a given
> processing instruction is. I propose that processing instructions go
> right before start tags, and their scope of influence is the element
> that the tag starts. In other words,
(stuff deleted)
> Well, there might be some kinks to work out, but you get the idea.
Again, for cutting and pasting, it isn't easy to "backtrack" and
find prefix directives that might affect the current selection...
> Does this seem like a good idea?
Honestly? No.
-Philip