W3C home > Mailing lists > Public > html-future@w3.org > May 1998

Re: Thoughts on a new charter for HTML

From: Todd Fahrner <fahrner@pobox.com>
Date: Wed, 20 May 1998 16:17:55 -0700
Message-Id: <v03102805b1867472743f@[]>
To: "Daniel B. Austin" <daniela@cnet.com>, Dan Connolly <connolly@w3.org>
Cc: html-future@w3.org
Daniel B. Austin wrote (4:00 PM -0700 5/18/98):
" Overarching concepts of this proposal:
" * using the right tool for the right job (HTML for layout, CSS for style,
" acronymML for authoring...)

I can't see any distinction between layout and style - never have. I think
HTML is a hopelessly poor basis for anything related to rendering. That's
the mess we're in: HTML, with a ton of prayer, imagination, and patience,
has been made barely good enough for Web display in the absence of any
better alternative (or competing browser), and now too many people have
decided that it's actually sensible. <sarcasm>Look: it "works".
Frankenstein *can* dance. Look out Excel! Edward Tufte, David Carson:
behold your new working quarters!</sarcasm>

But supposing I were to agree with you that HTML has a place in the
formatting equation: I think you've got it backwards. I assume that by
"style" you mean phrasal, text-level style, like bolding. This stuff is
usually tied to tag boundaries (e.g., <strong>), so inlining it (e.g., <b>)
makes limited sense. But layout - whitespace, columnar arrangement,
placement and scaling of figures - this stuff is properly independent of
tag boundaries. All browsers execute some aspects of layout (like line
wrapping and letter spacing) today without the need for inline cues. This
stuff, IMO, is best handled by stylesheet languages which can be
parameterized with rendering environment variables.

Style languages are developing to handle all aspects of rendering. Even
CSS1, if implemented, will replace the need for the most common abuses of
HTML tables (float). Similarly, CSS2 can largely replace frames. CSS's
media-specificity can smooth over many of HTML's most frequently cited
scalability problems, too, though a transformation language (XSL?) is
undoubtedly handy here too.

People are going to keep using "anything goes" HTML for display purposes
for a long time. I don't believe this application is perfectible, nor even
worth trying to improve. It's hamburger already: no amount of chewing will
render it any more healthful. The effort should go into improving the
design and implementation of style languages.

What is worth trying to create, IMO, is a markup language for
general-purpose structured hypertext. HTML 4.0 Strict is not bad, though
its SGML (rather than XML) profile makes it hard to support as designed,
particularly in view of HTML's current use as a hand-hacked display format,
which effectively forbids real parsing. (Already some "web designers" are
using HTML 4.0 Strict doctypes, thinking this will somehow provide better
pixel control in "4.0" browsers.)

HTML 5's namespace should build on HTML 4.0 Strict's, but deprecate BR, HR,
IMG, B, I, BIG, SMALL, and PRE in favor of stylesheet and OBJECT support.
It should not permit pcdata, empty, or "inline" elements in BODY. DIV and
SPAN should require a class and id attribute. The style attribute should be
deprecated in favor of external or head stylesheets, which will be
mandatory. The behavior of &nbsp; should be clarified to forbid rendering
as content or noncollapsible whitespace (unless the stylesheet specifies),
but only as indication of an impermissible word break.

True sectioning would be great (DIV?). Forms are tough - external entities?
I don't understand XML linking, but I hear it's quite different.

New elements should be chosen for their likely usefulness following
deprecation of BR, for greater rhetorical articulation in running text, and
above all for coincidence with emerging XML namespaces and RDF vocabularies.

Todd Fahrner

The printed page transcends space and time. The printed page, the
infinitude of books, must be transcended. THE ELECTRO-LIBRARY.
	- El Lissitzky, 1923
Received on Wednesday, 20 May 1998 19:10:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 20:16:36 UTC