[Standards-JIG] XHTML-IM clarification

trejkaz at xaoza.net trejkaz at xaoza.net
Tue Sep 14 06:33:13 UTC 2004

Section 8.6.1 Recommended Style Properties:
> The property is unnecessary since it can be emulated via user input or recommended XHTML
> stuctural elements (e.g., the "text-transform" property can be emulated by the user's
> keystrokes or use of the caps lock key, and the "white-space" property can be emulated
> by judicious use of the <br/> element).

This should say "judicious use of the <br/> element *and non-breaking spaces*"... the CSS
"white-space: preserve" would cause horizontal whitespace as well as vertical whitespace
to be preserved (such as in a <pre/> block.)

Actually, when it comes to instant messaging, you could say that whitespace preservation
is a given.  Users generally won't press space 8 times unless they want an indent.
Whitespace is already preserved for the <body/> of plain text messages in every client
I've ever used, so why don't we just recommend that user agents preserve whitespace by
default for XHTML message bodies, and save all those extra <br/> elements which would need
to be performed otherwise?

I'm also curious as to why we use our own namespace for the <html/> but XHTML's namespace
for the body.  There don't seem to be any attributes on that <body/>, and our <html/>
already performs the job of a container, so couldn't the contents go directly inside our
<html/> element?


'Every sufficiently advanced technology is indistinguishable from magic' - Arthur C Clarke
'Every sufficiently advanced magic is indistinguishable from technology' - Tom Graves

             Email: Trejkaz Xaoza <trejkaz at xaoza.net>
          Web site: http://xaoza.net/trejkaz/
         Jabber ID: trejkaz at jabber.xaoza.net
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20040914/7dbf479d/attachment.sig>

More information about the Standards mailing list