[Standards-JIG] XHTML-IM Conclusions

Ian Paterson ian.paterson at clientside.co.uk
Thu Sep 2 16:37:13 UTC 2004


Sorry to join in so late. I'm certain many people are fed up of this
conversation. Having worked exclusively with HTML for the last ten years, I
hope I can contribute a useful point of view.

Since most clients render each instant message as a single paragraph in a
scrolling display, this JEP only needs to explain how to _style_ (not
structure) those messages.

Rachel Blackman wrote on 27 August:
> I just don't think that saying 'bold can be done as
> <strong/> and <span style='font-weight: bold'/> and...'
> is a good road to go down

Yes. It will be far more simple once there is only one way to achieve IM
styling. [I also agree with most of what Byron has been saying.]

Peter wrote:
> Perhaps removing the CSS features would make people happier?

No, it needs to be the other way around! W3C has been fighting to separate
style and structure/content for many years now. They have been severly
handicaped by the legacy of HTML. W3C recommends that CSS should be used for
style (while XHTML should be confined to document structure and content).
The use of HTML (or XHTML) for styling has been depricated since 1997! The
various HTML specs are full of quotes to that effect. For example: "The
usage of BLOCKQUOTE to indent text is deprecated in favor of style sheets."

XHTML-IM is currently proposing the use of BLOCKQUOTE, and I imagine it will
only be used to indent text! Perhaps the person at W3C Peter talked to
didn't understand that we want to style IM messages, not structure them?

Peter wrote:
> perhaps people are smarter than protocol geeks, and what they really
> wanted all along was bold and italics, not strong and emphasis...

Yes, let's get real! Few, if any, IM clients are going to provide CODE,
CITE, QUOTE, HEADLINE (1,2,3) buttons. We all know what users want is
italic/bold/red etc... That is even more true for rapid-fire IM than it is
for Web publishing.

CSS properties were designed to specify style. XHTML was not. Why should we
bother with so much XHTML, when in practice it will only ever be used to
duplicate CSS features (something it was not designed for)?

If we cut out as much XHTML as possible, this will make the XHTML more
simple to parse, _validate_ and render. Let's not repeat a ten-year-old
mistake and handicap ourselves with the added complexity of supporting both
XHTML and CSS styling.

IMHO the following tags are _not_ necessary for IM styling: <cite/>,
<code/>, <em/>, <h1/>, <h2/>, <h3/>, <p/>, <q/>, <strong/>, <br/>. The
<blockquote/> tag can also be removed if the JEP allows the 'padding-left'
CSS property for <div/> tags (do we need it?). Finally, clients can use
  to achieve the same effect as <pre/>.

That would leave us with the following XHTML tags and attributes for single
paragraph messages:

<body xml:lang="" style=""/>
<span style=""/>
<a href="" type="" style=""/>

...and the following (optional?) XHTML tags for visually structured messages
and inline images:

<div style=""/>
<ol/>, <ul/>, <li style=""/>
<img src="" alt="" style="" height="" width=""/>


Existing implementations already parse the CSS styles, and they can be
trivially modified to generate, for example, <span style="font-weight:
bold"/> instead of <strong/>.


Tijl Houtbeckers wrote:
> For example, imagine I hook up a text-to-speech generator
> to my XHTML implementation...

That might be a reason to keep <em/> and/or <strong/>. But that is exactly
what the CSS 'stress' property was _designed_ for.

- Ian




More information about the Standards mailing list