[Standards-JIG] Re: JEP-0071 XHTML-IM lack of scope

Peter Saint-Andre stpeter at jabber.org
Wed Sep 1 22:32:28 UTC 2004

In article <4133C19D.2020606 at apnic.net>, Byron Ellacott <bje at apnic.net> 

> the <em/> element is not about italics, it's about emphasis.

Indeed it is:


> Now, the introduction text you've added to the JEP does talk about 
> lightweight formatting being emphasis, but it's also about font information.
> The main reason XHTML seems like a bad fit 

A bad fit for addressing the requirements of lightweight text formatting?

> is you specify a relatively 
> small subset of XHTML to use, and for the things which aren't available 
> in XHTML, you specify a very small subset of CSS to use, which includes 
> font-weight and font-style.  

Is this inconsistent in some way?

> Is it better for a client to generate <em/> 
> or <span style="font-style: italics"/> elements when the user requests 
> italics?  

This is addressed by Business Rule #3:

3. The use of physical tags such as <b/> and <i/> is NOT RECOMMENDED; 
instead, implementations SHOULD use the appropriate logical elements 
(such as <em/> and <strong/>). Implementations MAY use the <span/> 
element with an appropriate 'style' attribute (e.g., <span 
style='font-weight: bold'>this is bold</span>), but they SHOULD use 
logical structures (e.g., <strong/>) rather than physical formatting 
(e.g., <span style='font-weight: bold'/>) wherever possible.

Now, we know that users (and even HTML authors) don't know anything 
about the distinction between logical and physical, because plenty of 
people still mark up their pages with <b> and <i>. But perhaps people 
are smarter than protocol geeks, and what they really wanted all along 
was bold and italics, not strong and emphasis....

> Or, is it irrelevant, since a receiving client will have to 
> handle both anyway.  Or is it valid for a receiving client to have a 
> different default style sheet, in which case <em/> might not be 
> italicised at all?

Certainly a processing application could have its own default style 
sheet. We might have text-to-speech clients that handle emphasis and 
strong in their own ways, or even textual clients that show emphasis and 
strong as different colors (think Lynx, mutt, etc.) rather than as 
italicized and bold text. I don't see any inherent problems with that, 
since it seems to have worked just fine in the world of web browsers and 
email clients.
> In other words, you've had to span (sic) two separate specifications, 
> and introduced a complex layered styling mechanism, for lightweight 
> formatting.

Perhaps removing the CSS features would make people happier?

> One final example:
> <span style="text-style: none !important;">
>    <em>What does this look like now?</em>
> </span>

What does it look like in a web browser? Go here to see:



More information about the Standards mailing list