[Standards-JIG] Re: JEP-0071 XHTML-IM lack of scope
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
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
> In other words, you've had to span (sic) two separate specifications,
> and introduced a complex layered styling mechanism, for lightweight
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>
What does it look like in a web browser? Go here to see:
More information about the Standards