- From: Todd Fahrner <fahrner@pobox.com>
- Date: Wed, 20 May 1998 16:17:55 -0700
- 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 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 mailto:todd@lowbrow.com http://www.verso.com/agitprop/ 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