HTML question about italics and bold

[ElMiko]

Talk about shutting the barn door after the horse has left... but I'm wondering if the deprecation of the <i> and <b> elements has any practical consequences in ebook design? Is using <span> elements (with appropriate css) in their place best practice in a belt-and-suspenders sense of extreme caution, or is there a reasonable expectation that using <i/b> elements will actually foul up the final ebook?

[KevinH]

Both the i and b tags are valid in html5 and are no longer deprecated. Their use versus spans depends more in their semantic meanings and functional purpose. Using the tags for the right reasons improves Accessibility.

There are a large number of threads here on MR that help people decide which of s, em, b, i, or spans to use and why.

So no worries about support for those tags going away.

[ElMiko]

Thanks, KevinH. I'd never really understood what was meant by "semantic" vs "presentational" from normal websearches. Leave it to MR to finally make the difference click!

As a follow-up, in the context of text-to-speech accessibility, does it matter where the punctuation is relative to the <em> tags (i.e. inside or outside)? I tried the following samples in calibre and couldn't tell the difference between any of them:

"He said <em>what?</em>"

"He said <em>what</em>?"

"He said <i>what</i>?"

[JSWolf]

Originally Posted by KevinH

Both the i and b tags are valid in html5 and are no longer deprecated. Their use versus spans depends more in their semantic meanings and functional purpose. Using the tags for the right reasons improves Accessibility.

There are a large number of threads here on MR that help people decide which of s, em, b, i, or spans to use and why.

So no worries about support for those tags going away.

s should be strong.

[JSWolf]

And there are eBooks that use a span such as...

<p>This is an <span class=italic>italicized</span word.</p>

With the CSS being something like....

.italic {
font-style: italic;
}

However, there are times when an italic is used in a class when the entire paragraph is italicized. and <i> when not.

So if you are of the type that believes in <em> (I don't). Then you have have to edit all of this manually.

[ElMiko]

@JSWolf — yeah... using <span>s just for italics just feels really cumbersome to me and visually confusing while I'm editing. This is, obviously, merely a "me" problem, so I get it that others are happy to take this approach. but for me the decision tree is simply to <i> or to <em> at this point.

I'm inclined to err on the side of accessibility (especially since a word that's been erroneously emphasized aurally is less bothersome to me than one that's erroneously de-emphasized). However, I'm also struggling to see the <em> effect in practice with the—admitedly simple—text-to-speech programs I've tested. So... until I get more clarity I'm sticking with <i>. Praise regex, going back and switching to <em> should be trivially easy.

In that case, though, I'm also wondering: is it best practice is to include a css feature that specifies the appearance of <em>? e.g.:

em {
font-style: italics;
}

[Karellen]

You won't see a difference between <i> and <em> in ereaders, unless you have specifically styled them differently in the CSS.

My understanding is that it is helpful for accessibility coding. ie for Read Aloud software. If you want to emphasize certain words in a sentence, you would use <em>, but if you just need italics, say for the name of a ship (USS Enterprise) then you would use <i> because you don't want the voice reader to emphasize the name of the ship.

I would never use <span>s for bold or italic.

In my css I use

em, i, .italic {
font-style: italic;
}

b, strong, .bold {
font-weight: bold;
}

[ElMiko]

Originally Posted by Karellen

You won't see a difference between <i> and <em> in ereaders, unless you have specifically styled them differently in the CSS.

My understanding is that it is helpful for accessibility coding. ie for Read Aloud software. If you want to emphasize certain words in a sentence, you would use <em>, but if you just need italics, say for the name of a ship (USS Enterprise) then you would use <i> because you don't want the voice reader to emphasize the name of the ship.

I would never use <span>s for bold or italic.

In my css I use

em, i, .italic {
font-style: italic;
}

b, strong, .bold {
font-weight: bold;
}

Yup, I understand that the visuals wouldn't change (in most systems). In post #3 I was referring particularly to text-to-speech. That is, aurally, all three examples were rendered the same way. And I'm wondering a) why no difference (aurally) between <i>, <em>, and plain text, and b) for TTS, does it matter if the punctuation is inside the tags or outside them (eg. <em>"what?"</em> vs. "<em>what</em>?")

[DNSB]

Originally Posted by ElMiko

Thanks, KevinH. I'd never really understood what was meant by "semantic" vs "presentational" from normal websearches. Leave it to MR to finally make the difference click!

As a follow-up, in the context of text-to-speech accessibility, does it matter where the punctuation is relative to the <em> tags (i.e. inside or outside)? I tried the following samples in calibre and couldn't tell the difference between any of them:

The only time I notice a difference between <i> and <em> is when I am using voice output.

<p>The <i>Titanic</i> sank after hitting an iceberg</p>. will have Titanic said in the normal voice.

<p>The woman screamed <em>"Help! Help!"</em></p> would have the help help spoken in an emphasized voice (in the software I was playing with, a slightly louder voice).

Ditto for bold vs strong.

Basically, <em> is for stress emphasis of its contents while <i> is for text to be set off from the surrounding text (in the example above, the ship's name)

If you are not worried about accessibility, you can use either but I prefer to try to make ebooks that I work on more accessible.

As for punctuation? I personally prefer to keep it outside the tags but that dates back a lot of years to when my original ereader had some oddities in the font when displaying italic or bold punctuation marks. The voice output I was playing with didn't seem to care.

[JSWolf]

Originally Posted by ElMiko

@JSWolf — yeah... using <span>s just for italics just feels really cumbersome to me and visually confusing while I'm editing. This is, obviously, merely a "me" problem, so I get it that others are happy to take this approach. but for me the decision tree is simply to <i> or to <em> at this point.

I look for classes to see what's being used where. A class that does italic or bold is a pain. So I change them to <i> and <b>.

[/quote]I'm inclined to err on the side of accessibility (especially since a word that's been erroneously emphasized aurally is less bothersome to me than one that's erroneously de-emphasized). However, I'm also struggling to see the <em> effect in practice with the—admitedly simple—text-to-speech programs I've tested. So... until I get more clarity I'm sticking with <i>. Praise regex, going back and switching to <em> should be trivially easy.[/quote]

There is no visual difference between <i> and <em>. Also, nobody has been able to say what TTS reads <i> and <em> differently. So I too stick with <i>. However, if the class that's being used specifies italic, I leave it be.

In that case, though, I'm also wondering: is it best practice is to include a css feature that specifies the appearance of <em>? e.g.:

em {
font-style: italics;
}

There's no need to do so as <em> is italic by default. I've seen some CSS define <i> and <b> to be italic and bold when is also not needed.

[JSWolf]

Originally Posted by Karellen

You won't see a difference between <i> and <em> in ereaders, unless you have specifically styled them differently in the CSS.

My understanding is that it is helpful for accessibility coding. ie for Read Aloud software. If you want to emphasize certain words in a sentence, you would use <em>, but if you just need italics, say for the name of a ship (USS Enterprise) then you would use <i> because you don't want the voice reader to emphasize the name of the ship.

I would never use <span>s for bold or italic.

In my css I use

em, i, .italic {
font-style: italic;
}

b, strong, .bold {
font-weight: bold;
}

You don't need that CSS for i, em, b, strong.

Can you point out a TTS that reads <em> differently then <i>? Nobody has been able to name one when I've asked.

[ElMiko]

Originally Posted by DNSB

The only time I notice a difference between <i> and <em> is when I am using voice output.

Yep, this is what I'm getting at with the question. But as I said (and JSWolf appears to second, and third!), I am not hearing any difference between the two tags, nor am I hearing any difference between punctuation inside/outside the <em> tags. Now, that may be because I'm using fairly simple text to speech (Calibre and whatever the default is for my PC) to test it. So I'm wondering if this appeal to semantic emphasis is actually realized in any common text-to-speech programs (particularly those related to ebooks) or if this is a strictly theoretical distinction.

[Turtle91]

You can change how emphasized words are spoken using css assuming the device supports the standards... you can also change how emphasized words are displayed with css.

The defaults of <i>/<em> and <b>/<strong> are the same (italics and bold respectively) but they can be changed. So Wolfe's assertion that there is no difference is a little misleading. There is a semantic difference. <i> is for a visual only presentation (however you want it to look), while <em> is whether the word is supposed to be emphasized (typically when read aloud, but even when you are visually reading the word - I can assign an emphatic voice in my mind while reading...) DNSB gave a good example in #9.

Whether or not anyone has used a device that sufficiently differentiates the semantic coding does not invalidate the difference in coding...

I also choose to code my books with the assumption that meeting accessibility standards, as well as proper use of semantic tags, will just make the books better as/when devices improve their support... I also won't have to go fix the books if a major portion of the world passes laws requiring book producers to follow accessibility standards (like the EU did)....

[ElMiko]

Thanks for those thoughts, @Turtle91.

I think that part of the reason I'm trying to confirm if <em> is actually implemented semantically in current/mass-market TTS is that if it isn't, I'd expect their eventual implementation to also allow users to select semantic preferences based on nominally visual tags (e.g. <i> and <b>). Given the existing catalogue of reflowable ebooks that do not use the semantic tags , it would be surprising if these programs didn't account for that possibility. "A gajillion ebooks use <i> (or spans) instead of <em>. I've decided I'm finally going to incorporate semantic rendering into my TTS program. But I'm not going to offer users the option to apply semantic rendering to anything but <strong> and <em> despite knowing that these have not been consistently implemented." Perhaps (no, DEFINITELY) I've been too spoiled by developers like those of Sigil and Calibre who are constantly adding almost insanely granular modifications to their programs to accomodate users' idiosyncracies, but there you have it.

If however, the majority—or a significant plurality—of these TTS programs (particularly those used in ebook platforms) already incorporate semantic differentiation, then a standard has already been practically established for those kinds programs that doesn't accomodated semantic recognition of visual coding. It would then make a lot more sense to change my workflow and to modify past projects.

In either case, I fully grant that your point about the possibility of EU-like regulation is a strong argument in favor of preemtively switching to <em> where appropriate, though.

[DNSB]

The ePub reader used by one of my neighbours who is legally blind is a Victor (??) Reader Stream device supplied by the CNIB. It does handle quite a bit of semantic content and I used them to test some of accessible ePubs I created.

For me, it was more or less that it took little effort for me to make my ePubs more accessible and I liked the idea of doing so.