> I suspect that you will receive a very negative reaction to your
> suggestion. HTML was designed to be a flexible language that can be
> adapted for many display purposes. The typical response to your sort of
> goals is "Go use PDF". There are several of us commercial implementors
> who tend to communicate and at least in theory try to give some sort of a
> consistant representation to documents, mostly on the basis of our
> customers expressing just the sort of opinions that you did.
Well, so far I've recieved more positive comments than negative. You might
be partially misinterpreting my desires, because of the somewhat widespread
desires of web authors to have explicit control over the layout of their
pages. I don't advocate that position, and in fact shudder at it, even
though I'm intimately involved in the commercial publishing field,
as one of the editors of a magazine which makes a big deal about its
graphic design and layout (and we paid a pretty penny for our last
redesign to somone who is now working for Ziff, too). But the whole point
of design and layout on paper is to make it easy and inviting for the
reader. Duplicating that exactly in phosphors accomplishes neither goal. I
desire no such fine control over what the HTML standards produce in the
browsers.
I think it is imperiative though, that a document produce meaningfull, and
consistent (in terms of content, and usefullness) interpretation by all
browsers. If I specify that a word is surrounded by <b><i>bold and
italics</b></i>, I'd like to know that the meaning is carried over through
every browser, and not that some browsers randomly decide to apply only one
of the two styles to the text. I don't care if Netscape shows it as bold
and italic, and that Lynx displays it as underlined and brighter (if that
terminal supports it), or underlined and surrounded *by asterisks*, or
_*like this*_. Or, at the very least, a browser should indicate to the
user that there were aspects of the markup it couldn't handle, because of
system or configuration related issues.
Some of this is clearly in the domain of the specs the WG produces, but
I'm concerned that the charter not be worded (or interpreted) from
preventing us from specifying small, but important details like this.
I also think that we need to make the *intent* of how these standards were
designed clear, to aid the interpretation of what they mean. A DTD only
tells you so much.
And it is imperative that someone create an accurate, useful document
(online, published book, whatever) that consisely details how to write
correct HTML, according to the final standard. The wide variety of editors
that don't quite follow the standard needleslly complicates understanding
of the correct syntax, and we need to counter that.
******************************************************************************
* Peter K. Sheerin Technical Editor, | Work : psheerin@mfi.com *
* CADENCE Magazine & AutoCAD Tech Journal | CompuServe: 71621,3173 *
* 600 Harrison Street, San Francisco, CA | Personal : psheerin@best.com *
* *
* <URL:http://www.mfi.com/cadence/> <URL:http://www.best.com/~psheerin/> *
* <URL:http://www.mfi.com/atj/> *
******************************************************************************