Skin-deep semantics

Somewhere along the way web developers learned that bold and italics tags (don’t even mention underline) were verboten, careless mingling presentation with semantics and structure, but that emphasis and strong emphasis were cool. Heck, even Dreamweaver and related products now automatically insert em and strong tags in wysiswyg mode when the user clicks buttons labeled I and B.
There’s a problem with this, though. In some ways it’s the equivalent of the CSS-styled span tags Word now inserts to apply font (typeface) choices just exactly the way it used to littler HTML output iwith font tags. So, what’s the problem?
The problem is, for example, that italics does not always mean emphasis. The semantics behind the typesetter’s choice to use italics can mean a number of things. Yes, it can signify emphasis. It can also mean the title of a book or record. It can mean that the word in question comes from another language.
Mindlessly applying em to a French word is semantically as useless as applying an i tag. In fact, I’d say it’s worse. At least italics are traditionally associated with foreign words. Emphasis is not. It’s more like a homonym – it looks the same but it means something entirely different.
So what’s a standards-conscious, POSH, separation-of-semantics-and-presentation web developer to do? It seems that the workaround would be to (as usual) choose the best tag (I like cite for titles, which happens to render in italics in most browsers) and then define classes for the semantic meanings involved.
By all means, continue to use em and strong when dealing with emphasis, but come up with some for word-from-another-language, and then apply it.
Creators of wysiwyg tools might want to trap clicks of those I and B buttons (note I used the i and b tags here because I am literally talking about italics and bold, not emphasis and strong emphasis!), and ask the author which of the several meanings traditionally associated with italics or bold they have in mind. Then create or apply the appropriate markup.
Problem solved.
UPDATE: Noticed that Zeldman praises the new Apple Store’s standards-adherence and encourages his readers to view the source. I couldn’t help noticing the site’s use of strong to produce bold inline headings. I guess a case to be made (tortured) to say that an inline heading is a phrase you wish to emphasize, but isn’t it really a heading that just happens to be bold? Strong is the new bold.