Best way to do italic and bold

[bookman156]

In the EPUB I am editing from a publisher they have used span classes for all italic and bold, which seems crazy to me, but not worth altering now. Is there any reason anyone can think of when span classes would be good for that? Or is it perhaps a PDF-to-EPUB conversion thing (I believe they made the EPUB from a scan of the book).

In Sigil I notice <i> tags are used instead of <em>, and <b> instead of <strong>. The tags <i> and <b> seem very old-fashioned to me, in terms of web design, but is it an EPUB thing? If I were making an EPUB from scratch myself I'd like to use <em> and <strong>. Is that allowed?

[DiapDealer]

Originally Posted by bookman156

If I were making an EPUB from scratch myself I'd like to use <em> and <strong>. Is that allowed?

Certainly. That's typically the way i do it too. I don't really use any of Sigil's write-some-html-for-me buttons.

There's no way for me to say this without sounding like I'm tooting my own horn, so I'll just say it: you should check out my TagMechanic plugin if you've got a lot of spans to be converted to other elements. It makes it pretty painless. It's especially handy if you've got nested spans where a simple search and replace might unwittingly break things.

[bookman156]

Great, thanks.

Be interesting to hear how people generally approach making an EPUB from scratch. I suppose if you have an InDesign file already you'd make one from that, but if I wanted to kinda write the book itself from scratch into an EPUB? Maybe it would seem natural to write it as webpages in Dreamweaver, as I'm quite used to that and it uses the tags I prefer. Or perhaps it would be better to design it in InDesign. Do people create EPUBs from scratch in Sigil?

[bookman156]

Originally Posted by DiapDealer

you should check out my TagMechanic plugin if you've got a lot of spans to be converted to other elements. It makes it pretty painless. It's especially handy if you've got nested spans where a simple search and replace might unwittingly break things.

Ah, that sounds useful, I'll look it out. I am quite worried about breaking things through replace and am doing so very cautiously at present.

Any idea why a big publisher might use spans for italic? I am trying not to think of them as incompetent, despite the fact that my proofreading errors sheet runs to 22 pages so far without even considering the coding.

[DiapDealer]

Originally Posted by bookman156

Any idea why a big publisher might use spans for italic? I am trying not to think of them as incompetent, despite the fact that my proofreading errors sheet runs to 22 pages so far without even considering the coding.

To be honest; I really don't know. Part of me wants to believe it's because of a desire for widespread device support, but then I simply can't think of a device/app that would display an <i> tag incorrectly, but I could be wrong. There's some weird, wacky device/app quirks out there that I have the luxury of not having to worry about accounting for. Others may have better answers for you.

[Ripplinger]

Kobo readers would display bold instead of italic when <em> was used in the past. I can't remember now if it was for just specific fonts or even if it still happens or was fixed by now. But that got me in the habit of using <i> and <b> just for the reason DiapDealer said... it works on everything, including the then buggy Kobo firmware. I also figured <i> and <b> are shorter (yes, I'm lazy, less typing is always good ), and as long they both did the same thing and both generally supported, I didn't see a reason to change to <em> and <strong>.

[bookman156]

But you would define <em> as italic in the CSS, along with <cite> (which I know I should use but am often lazy). Would Kobo still ignore that? While you may get italic for <i> it won't make much sense when ebooks are read out for blind people.

[Toxaris]

That is part of my issue with <em> and <strong>. It is up to the parser to interpret it. The fact that they usually depict it as italic and bold does not mean they have to. That is why I rather use a CSS style or just <i> and <b>.

[DiapDealer]

I don't give parsers any choice in the matter. I use <em> and <strong> semantically, and then use CSS to determine what they look like stylistically. Any parser that screws that up isn't one that I'm going to worry about.

(I do realize commercial ebook producers don't always have that same luxury)

[HarryT]

Originally Posted by Toxaris

That is part of my issue with <em> and <strong>. It is up to the parser to interpret it. The fact that they usually depict it as italic and bold does not mean they have to. That is why I rather use a CSS style or just <i> and <b>.

But your book is not always being displayed visually; it might be being read out loud by a TTS system, for example. The whole point of semantic markup as opposed to stylistic markup is that it permits the parser to make the appropriate decisions for the display medium.

[jackie_w]

Originally Posted by HarryT

But your book is not always being displayed visually; it might be being read out loud by a TTS system, for example.

Out of interest, have you come across any TTS apps which currently do actually emphasise the words differently when wrapped in <em> or <strong> tags? I don't think any of my Android reading apps do, nor does my TextAloud Windows application.

I don't think any of them, so far, will speak the contents of <img alt="your description here" ...>, either, which is a bit of a shame. In fact, much as I like TTS, I'm a bit disappointed with the lack of any major leaps forward since I first started using it on a PC in 2006 and a smartphone in 2012.

[HarryT]

Originally Posted by jackie_w

Out of interest, have you come across any TTS apps which currently do actually emphasise the words differently when wrapped in <em> or <strong> tags? I don't think any of my Android reading apps do, nor does my TextAloud Windows application.

I'm afraid my experience of TTS is extremely limited, so it's not really something I can comment on. Of course, what an application could (or perhaps even should) do, and what it actually does do are not always the same thing. There's certainly no reason that TTS couldn't respond to these tags - that is, after all, why they're there.

[jackie_w]

Originally Posted by HarryT

I'm afraid my experience of TTS is extremely limited, so it's not really something I can comment on. Of course, what an application could (or perhaps even should) do, and what it actually does do are not always the same thing. There's certainly no reason that TTS couldn't respond to these tags - that is, after all, why they're there.

Pity. I was hoping you could recommend some superior apps

[HarryT]

Originally Posted by jackie_w

Pity. I was hoping you could recommend some superior apps

Unfortunately not, but if anyone else does know, it's something I'd very much like to know myself!

[bookman156]

Originally Posted by DiapDealer

I don't give parsers any choice in the matter. I use <em> and <strong> semantically, and then use CSS to determine what they look like stylistically.

I think this really is the essence of the issue, and the reason web designers embraced <em> and <strong> against the seeming preference for <i> and <b>. Once the idea was pointed out to them, it made perfect sense to web designers who liked to think about what they were trying to achieve with tableless design and CSS. The ebook business seems to be in this same stage of infancy at the moment that web design was ten years ago, in regards to not really understanding what is semantic markup and what is stylistic markup. The point is to remove the decision from the xhtml and place it in the CSS. In the future, perhaps we will be able to deliver sound stylesheets that specify exactly the kind of emphasis of voice that should be applied, and not be faced with stretching an <i> tag to cover voice, which is why <i> really is bad practice.