Well, I think yu'vr actually done a fairly good job of pointing out the
real issue: should the content be emphasised or not.
>On the one hand, I'm sure they exist. On the other, after watching
Well, I think Novell might be an example, but there are many others
>I have studied this issue at some length, and it appears to me that
>keeping presentation separate from content is cost-effective for
>long-lived documents: technical documentation, law, etc. Most SGML
Yes. This is quite correct, though I would tend to say that any
textual information where content is considered important can benefit.
>But for advertising, journalism, creative art, and many other equally
>noble persuits, there is no motivation to separate presentation from
>the content.
Well, advertising and creative are emphasise art, not the written
word...
>(or "layout language"), but because it captures the communications
>idioms of a large community: everybody communicates using paragraphs,
>lists, and headings.
Albeit in a simple-minded manner. Witness <h1> et al.
>Hyperlinking is a powerful idiom that's evidently
Hyperlinking is at least as old as writing itself.
>That's why I'm so big on s-expression syntax, especially for
>stylesheets. s-expressions are EASY to implement. (Go grab the code
As am I. In fact, I think SGML could have benefited greatly from
them...
>The SGML community has a reputation for being... well... eletist.
Sure, but elitism doesn't equal being wrong either. As I noted, one of
the fundamental concepts of SGML, and an idea presenting
itself in HTML as well, was ignored. Separation of presentation and
information. Device and application independence. This was justified
by ignoring the concepts and talking about the language....
>A kludge should be argued down
Precisely what I was doing.
>As far as I can see, allowing
>
> <body font.family="helvetica">
>
>doesn't _prevent_ folks from separating content from presentation,
>as long as we agree that browsers will support
>
> <body class="techreport">
>
>with stylesheets keyed on class/id as well.
Which one should browser writers' support? Aren't we trying to find a
single, reasonable, *standard* solution to this problem.
>The one thing that style attributes does is break down modularity
>between HTML and stylesheet languages, which is something I'd like to
This is what I've been saying! Put it somewhere else where it doesn't
pollute the data. It makes HTML development *and* stylesheet notation
development easier, and buys device, and application independence into
the bargain. That is the basic tenet.