Re: Thoughts on a new charter for HTML

Dave Raggett wrote (3:24 PM +0100 5/21/98):

" I notice that pretty much every wysiwyg document editor supports
" bold and italic buttons on the toolbar. I think we will have a hard
" time of it convincing users that <B> and <I> should be dropped.

You don't have to drop bold and italics. You just move them to the style
language (where they belong, and are already). Use a span if it's really
just decorative, and give it class="pres" id="23" (not inline style) so it
can be ignored, stripped out, or otherwise flagged in a re-use scenario.

I'd say that HTML 5.0 should be designed such that no WYSIWYG document
editor can touch it unless it's also a CSS editor. Existing WYSIWYG editors
are suited to generating HTML 3.2 or 4.0 Transitional, and I agree with you
that a great many authors will continue to use these versions (or, more
likely, something vaguely resembling them) for a long time yet. That's
fine. I thought this was about improving upon HTML 4.0 Strict, rather than
stretching out the transition to stylesheets for style.

" The
" accessibility argument doesn't apply to these elements, since its
" easy to apply styles for aural browsing etc. as has been so ably
" demonstrated by T.V. Raman. I don't see how generating <EM> for the
" Italic button and <STRONG> for the bold button changes things.

It would be wrong to do this anyway. Some stylesheets (such as, um, the
Core Styles) render <em> as bold, and <strong> as bold italic. Any
questions? STRONG and EM together typically transform to BOLD UPPERCASE. If
you think keeping B and I as elements are clear and natural and harmonious
with other W3C initiatives, try explaining this to a newcomer: <b
style="font-weight: normal">.

" At the workshop, I very much appreciated the sentiment that forms
" should be more declarative, with a strong separation of structure
" from presentation. This would seem to place the burden on CSS to
" cover form fields in a future revision, e.g. the choice of
" rendering for a range input field as a slider, spin control or dial.

Agreed. But hard to support. X-platform widgets are tough (or so I hear

" The tough issue for me is how do deal with tabular information.
" One idea is to treat tables as presentation markup. Provided
" authors express the data model directly, you can then use style
" sheets to map the data into tables for windows browsers and
" nested lists (for example) for browsers that have small displays.
" CSS2 includes the support needed to map a <P> element (say)
" into a table cell, but lacks flexibility. A scriptable style
" sheet using as Spice or XSL is easily powerful enough though.
" This sounds good, until you realise that most users won't get it.
" I believe that most users think of tables as a presentation device
" and are very happy to author that way.

Such users can continue doing what they do! Let 'em! What do they need a
new DTD for? They've never paid attention to the old ones. Anyway I think
you confuse desire with necessity. Saying that authors like to use tables
for presentation because they all seem to do it is like saying that
prisoners really like prison because they seem not to have escaped. I work
all day long with designers for whom the design/performance constraints
imposed by HTML as a layout/style language are utterly execrable. Same
thing for the production people, same thing for the client who has to
maintain it all. This is mostly because CSS1 isn't implemented *anywhere*
yet, much less everywhere (as are tables).

That's why we and our peers continue to design in Photoshop. We accept
fixed-resolution, image-heavy design as the cost of escaping these mutually
inadequate "HTML/CSS flow objects" as design elements. "DHTML" is sometimes
enticing in a sheepish "Is that PowerPoint, or Excel on steroids?" sort of
way. But without an aspect-independent paged rendering model, better
control of flows and fonts and anti-aliasing algorithms, we'll continue to
accept bitmap-based design, with tables to nail things into place, as a
*necessary evil*. This paradigm is not worth improving. It is worth
abandoning in place as soon as the escape route is cleared of its many
implementation traps.

David Siegel/Verso didn't invent GIF-and-table based design, but we did
write the best-selling book about how to do it. 13 languages now. I'm here
for penance; Dave's off doing non-Web things. I always had reservations
about this stuff, but I justified it to myself as "mocking up the future".
I never believed that people would confuse and adopt the mockup for the
future thing it modelled. I was wrong.

" How do we convince them to
" take the extra trouble to express their data declaratively?

It's no extra trouble! It's unfamiliar, certainly. So is using <h2></h2>
instead of <br><br><font ... ></font><br> . If the benefits of the former
approach are not apparent for a given application, no amount of
"convincing" and spec-brandishing will help. Hint: Only 1 CSS browser today
will help you make the case for the former markup, and the other one will
cancel out the argument. The font markup will continue to win in the market
until this changes. This group's work cannot speed this transition up, but
it can slow it down if it endorses any CSS-redundant markup.

" How
" would you map Excel spreadsheet data to a form that works well for
" cell phones?

You proposed lists. Works for me! So you're toying with the idea of losing
table markup in 5? Splendid! This way, 4.0 Strict will require a CSS1
implementation, while 5.0 will require CSS2.

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 Thursday, 21 May 1998 16:54:49 UTC