HTML Italic and Bold Elements as regards Web Standards

I find minutiae arguments daft. The W3C HTML WG has plenty. HTML5 WG, too.

The last argument I found interesting but daft was regarding the allowance of  and  in the HTML5 UA requirements for backwards compatibility as defined by W3C Technical Architecture Group (TAG).

Cleaning House [May 2, 2007] began this argument. It veered into The Semantic Debate [May 7, 2007] which veered into Why bother? (was Re: The Semantic Debate) [May 7, 2007]. The arguments against their inclusion was continued and future abuse by authors. [Note: [WSG] Legitimate uses of  and  [January 16, 2007] on the Web Standards Group mailing list has a concise thread.] It is difficult for me to understand the arguments against inclusion of these HTML presentational elements, when the arguments are based on assumptions of continued abuse, given that most sites which will continue to use them will use them regardless of a lack of HTML5 compliance (or, validation). It’s not as though a single, non-validating site has failed due solely to its use of italics or bold HTML elements.

Semantic arguments are intriguing: authoring semantics versus machine-readable semantics are often blurred in these arguments. Further, most arguments are based on assumptions rather than use cases. Or—Even—simple, fundamental research.

Let’s take eBay as a simple, fundamental example.

eBay Text Editor-Before

That becomes this,

eBay Text Editor-After

eBay did not use an HTML presentation element; it rendered spans with in-line CSS. That’s odd. One of the world's largest Content Management System (CMS) engaging Web Standards. The italic and bold buttons are universally known, aren’t they. Most eBay users do not care if the text is italics or emphasis, bold or strong; it looks the same. It may have semantic significance but semantic significance has no significance with general web users. How many other world-class CMS utilize Web Standards and didn’t advertise it?

[Elementary aside: I’m certain that some would argue against such deception.]

TinyMCE does that common-understood buttons trick but renders its styling as HTML presentational elements,  and .

How many other text editors and web development programs have done something similar?

I’ll confess that some arguments are beyond me. If Web Standards proposes that all presentational HTML elements are deprecated and to be replaced by style sheets, why are  and  allowed? but not  or .

The Web Standards argument I understand and—Seemingly—so does eBay and TinyMCE.

Sean Fraser posted this on May 20, 2007 02:49 PM.

Comments

Ben Buchanan wrote this at May 20, 2007 07:41 PM

People get worked up over the principle behind the argument, not because they specifically care about B and I. It's a common misconception that standardistas are somehow particularly enamoured with emphasised text ;)

"If Web Standards proposes that all presentational HTML elements are deprecated and to be replaced by style sheets why are strong and em allowed? but not i or b."

...because STRONG and EM have specific, defined semantic meanings; whereas B and I do not. STRONG and EM are not presentational, regardless of their default rendering. Mind you, of all the issues out there it's pretty low impact since the de facto semantics are pretty strong.

HTML5 allowing B and I is essentially trying to retrospectively excuse people for not understanding semantics. The same lack of understanding becomes really problematic when people use FONT instead of headings.

The problem is that it's perpetuating the mistakes of past specs. HTML5 could just as easily have deprecated B and I. It would make no difference to the people who created bad code out of ignorance - they still won't get it right. Why excuse them?

"One of the world's largest Content Management System (CMS) engaging Web Standards."

That's not ebay engaging web standards, that's crap code pure and simple. No spec ever recommended adding semantics using inline style. Engaging with standards would be using STRONG and EM, not to mention H1-H6 instead of FONT tags.

Even B and I would have been better than inline styles, although STRONG and EM would have actually been *correct* :)

Anne van Kesteren wrote this at May 21, 2007 05:04 AM: I think what eBay does depends on the browser you use. Firefox for instance emits span elements in designMode where other browsers might emit the b or strong element.

Anne van Kesteren wrote this at May 21, 2007 05:07 AM: Using em and strong for what eBay does is most definitely not correct. That would be silly. The user could have made it italic for very different reasons not known to the editor. i and b are definitely the way to go there.

Sean Fraser wrote this at May 21, 2007 07:09 PM

Ben Buchanan:

I believe eBay (and others for which I am unaware) should be commended. They - Seemingly - are trying to meet Web Standards. I do not know that to be factual but it is encouraging nevertheless. I find myself optimistic about Web Standards progressing. Personally, I do not care if they use <spans> or not with inline CSS:

“HTML5 allowing B and I is essentially trying to retrospectively excuse people for not understanding semantics. ”

I disagree. The HTML5 specification includes  and  for browsers, not authors. And, since most of the general public uses some sort of CMS, I would fault CMS developers. And, excusing - Retrospectively - people who used HTML elements before Web Developer Semantics was invented, must be done.

“The same lack of understanding becomes really problematic when people use FONT instead of headings.”

I agree. However, but perhaps with their next version, eBay (and others) will begin using header elements; and, move their inline CSS to an external style sheet. Maybe not. It could very well be cost-prohibitive.

Principles are interesting, aren't they.

I remain optimistic.

Anne:

I looked at eBay with Safari and Firefox/Mac where each rendered  elements. I seem to remember IE doing that, too.

Silly or not, I’m - Still - optimistic.

Boicozine wrote this at January 7, 2008 02:54 AM: As a bit of a pleb when it comes to web design (even though I've been building websites for a number of years, they're usually just for me) I get constantly frustrated by the fact that 'em' and 'strong' end up looking like words inside the copy I am trying to mark up. 'b' and 'i' were much less intrusive. I understand that it's good to spell things out so it's easy for anyone to understand but how many editors and designers really understand 'strong' and 'emphasis' compared to age old standards like 'bold' and 'italic'. Add that to the fact that fonts don't come in 'strong' and 'emphasis' versions and it all starts looking a little like change for change's sake.

Edward wrote this at February 4, 2008 10:24 AM: I get annoyed by the web standards crowd seeming ignorance of the vast array of circumstances under which a document might be rendered in HTML. If I am the actual author of the content, I understand the argument that it makes more sense for me to markup based on semantics. However, as someone who is involved in publishing court opinions of which I have no control of the content, I have to be concerned that if a judge wants something bold it needs to always be presented as bold. Giving up control of presentation is not an option, therefore, em and strong are often useless to me because I need to code presentation (however wrong someone thinks it is). This issue comes up in a lot of web standards where there is this hidden assumption that the person deciding on markup is the author or at least has some freedom concerning presentation.

Comments are closed.

The Elementary Standards: A Compendium of Web Standards, CSS, Linguistics and Search Engine Optimization methodology Copyright ©2005-2008 Sean Fraser. All work is published under a Creative Commons License. All Rights Reserved.