I want to bring up some points.
Some screen readers may use a different inflection when they come across this tag to communicate the emphasis.
None that I know of. Similarly, they all (at least the big names) seem to ignore aural stylesheets entirely. When the specs were written, there was hope that strong and em would be pronounced differently, but if you give a good listen to speech synthesizers, they mostly suck already. You're lucky to get them to bring the tone down at the end of a sentence (mine do it in the middle of a sentence if it's the end of a line!) or speak capital letters out in a higher pitch... getting them to speak like a human with emphasis is just asking too much. Except from VoiceOver, that synth is pretty good and would be the first one I'd expect to even try making strong and em sound differently. At least for English. The Dutch is... hilarious to say the least. Feeeerfox and weeeebdesigners, lawlz.
Not only that I have actually found that when you use <b> for your text, each browser renders that differently because it is not using a specially designed alternate bold typeface as in the print industry. You are leaving the browser to interpret bold with it's own trickery. It's actually faux bold.
This isn't true for any of my browsers, but I could believe this to be true on a Mac. Specifically Safari was one of the few browsers who actually understood the different font-weights (100, 400, 700, etc) and Macs were possibly the only OSes equipped with actually different weights of at least some fonts.
What my (Linux) browsers do: if the font they are rendering has a bold version, they just throw that in there. Nothing more. Once I downloaded a "free" Tahoma (somehow it was supposedly around the licensing restrictions???) for Linux. It did not come with a bold or an italic or an oblique, only "normal". B and strong tags were not rendered bold when this font was applied, because I simply did not have it.
Italics, however... IE especially was known for making faux italics by tilting the letters, which I believe lead to the overflow bug known in IE6. I'm sure IE wasn't the only browser to tilt letters instead of using the italic version of the chosen font. Also explains why it looked like pants. : )
However, in this context, I was looking at the W3C meaning. In the HTML4 specs, <b> and <i> are regarded as styling elements and therefore presentational. But "The HTML5 specification redefines b and i elements to have some semantic function, rather than being purely presentational", says the HTML5 resource.
Yeah the HTML5 guys have been trying to figure out how to make non-semantic (typographic) tags mean something.
Guess what they did with the u tags? Yeah, they're back. Specifically for Chinese proper nouns though. And of course WYSIWYGs; unfortunate that the HTML5 spec considers real-world use, even if terrible, to be reason enough to state that's how we should do things. Bleh.
I was taught at school that, grammatically, book titles and the like should be contained in inverted commas.
I was taught in school that ship names, the first time a name of an interviewee was presented in an article, and bibliographies needed to be bold. I was taught that book/magazine/article titles were to be underlined. However, in practice, we underlined everything (or, that was allowed) because most of us didn't have computers with word processors, but electric typewriters. Bold was possible (go back every letter and re-hit it several times) but underlining was just easier to do and easier to see. This is partially why some styleguides say bold and others say underline for the same thing: only a typesetter could do bold or italic, while regular people were stuck with underlining.
That's why when you set up your styles in CSS, you have "font-weight" with available values like: 300, 400, 600, and ...... bold!
You have "bold" because not all fonts (I'd maybe dare say MOST fonts) don't have all those weights at all. Bold == anything 400 and up. However some of the older font absolutely have a 100 weight, a 400 weight, a 600 weight... so CSS was designed to deal with that, but in the real world, means little. But you type one less character so I'm all for it.
Personally I set
in my stylesheets most of the time because, as you've noted, it's not a hard and fast rule how they are rendered, just that most user agents currently tend to display those tags that way.
But since no machines can see the difference, the semantics I write with strong and em are just for kicks, shts, giggles, and to stroke my ego as "semantics warrior". I kinda believe something can't be "semantic" (have meaning) if nobody actually bothers to read the meaning into the tag. HTML5 is like that currently: there are all these supposed future benefits of "semantic tags" but they don't mean zip to any machine or program out there. <article> == <div> in current user agents, including screen readers (who are one of the big reasons championed for more semantic tags really).
In the glorious future, though, they will have meaning and we'll finally get our damned flying cars. Only been waitin 50 years for those...