[Standards-JIG] XHTML further simplification

Rachel Blackman rcb at ceruleanstudios.com
Tue Sep 21 22:41:27 UTC 2004

>> It's lovely to discuss the ideal semantics, the proper way to do
>> design.  From the standpoint of purely a discussion of XHTML1 grammar,
>> many of these points are good ones.  Is Joe Q. User going to care 
>> about
>> this?  All they're going to want is that if they paste in text to 
>> their
>> input window -- yes, even if it has two line breaks between a bit of
>> text -- that it gets sent.

First, mea culpa, I explained this wrong.

> If the text comes from some other program, that's probably fine.  But I
> thought the use of XHTML-IM was for simple formatting, not for pasting
> quantities of text from other applications into the Jabber client.  
> Either
> way, if the other program had two line breaks, then the other program 
> is the
> one with the broken semantics... so it's not really our problem at that
> point.

Okay, 'pasting in' was a bad word choice, especially since I was the 
one against the argument about pasting in arbitrary HTML needing to 
preserve document layout for clients, thus all HTML should be allowed.  
I grant you this.  But here's an example of what I meant.

Look, ma, I can type.


This is cool!

Notice the two linebreaks between 'Whee!' and 'This is cool!'  I can 
type this in Notepad and save it.  I can type this in an e-mail program 
(obviously) and send it.  I can type this in AIM or MSN in an IM.  In 
none of those does it consume the extra linefeed, is what I'm saying.  
If you do not believe me, copy and paste that text from my e-mail 
message right into any of those programs and try it. ;)

Ah, you say, but that is plain text, and that is different!

Not to the end user, it is not.  Your average end user does not see a 
conceptual difference between 'plain text' and 'marked up' text.  In 
most cases, they don't mystically expect different behavior if they 
send the exact same message, just with one word set bold the second 
time.  If I highlight 'cool' and hit the key for bold, it's XHTML now.  
Further, if you have a default font or color for outgoing messages set 
(as AIM, MSN, etc. allow you to), isn't your plain text really XHTML 
anyway, since you'll be sending it with that markup?

In none of those cases am I convinced that the extra linebreak should 
simply vanish.

And if bolding a word suddenly makes one of the empty lines disappear, 
I will bet you the average end user will not think, 'huh, they apply 
reasonable document layout standards to their internal XHTML variant 
for document markup.  Bravo!'  They will, more likely, think, 'man, 
this is broken.  Where'd my extra line go?'

>> And they likely don't care if it's <br/> or whatnot, behind the 
>> scenes. :)
> They might care about the side effects.  What will be our excuse if a 
> user
> tries to right align just one paragraph in their message and the entire
> message right aligns, due to there only being one semantic paragraph?

Quoting you just above, "But I thought the use of XHTML-IM was for 
simple formatting..."

I can accept the validity of your argument within the contexts of a 
full document, but I consider 'simple formatting' to be bold, italic, 
underline, font size, font face, foreground and background color.  My 
IM chat window input is not a word processor.

I do not dispute that it could be useful to send entire documents, with 
paragraph alignments and whatnot; however, I still feel quite firmly 
that it's beyond the scope of this JEP.  Rendering a full document, 
yes, <br/> doubling is perhaps a little silly in some ways.  But I see 
this as describing not a way to send arbitrary blocks of XHTML, but a 
way to provide supplemental markup on what would otherwise be a snippet 
of plain text.

I'm honestly not trying to be a pain, I just feel this is a bad road to 
go down.  I agree it's useful to have a method for sending enriched 
document-type blocks of data.  Bravo!  I'm all for it.  But I feel 
document layout (indenting, etc.) as opposed to the plainer markup /in 
simple chat messages/ is a bad idea, and here's an example of one 
reason why.

Most IM clients do something like:

[15:35:12] Sparks: This is text!
[15:36:01] Trejkaz: ...your examples are getting really lame, you know.
[15:36:51] Sparks: Hey, I am pulling them out of thin air... cut me 
some slack. :)

Markup like bold, italics, underline, font size, font color, those are 
all easy to do in such an interface.  When text wraps, it wraps.  
Simple enough.

But let's say I put in that CSS border.  How do I render it now?  And 
what about when it wordwraps?  Do I just draw a little line at the 
beginning of each place the line wraps, thus causing the top of the 
border to be offset to the right due to the timestamp-and-name?  Or do 
I need to just do a linefeed-and-indent beneath the name now in order 
to render the block properly?  Indent all the wordwrapped or linebroken 
text as far in as the name is?  What about adding a left margin in the 

And regardless of the choice, aren't I potentially already now causing 
the same side effects you mention above, i.e. unexpected implications 
of layout?

To put it another way, only a few months ago when I brought up that few 
people implement XHTML (as a sideline in an entirely different 
argument), I was told this was because it was 'too complicated' for 
people to want to implement it.  We are not, in general, making it 
simpler right now.  Despite what the subject line of this thread 
claims. :)

Rachel 'Sparks' Blackman -- sysadmin, developer, mad scientist
"If it is not broken, give me five minutes to redesign it!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20040921/b501aa48/attachment.sig>

More information about the Standards mailing list