From the previous post it can be concluded that everyone defines their own goal slightly differently and based on that also makes a slightly different choice of the available specific resources <i> or <em>. There are also others that say if we can use <em> for Italics, then we can use <i> Tag to display an icon of, say, the font Awesome version 4.7 in an EPUB.

I think in that scenario, it might make some sense to instead use a span for an icon like that. While <i> "only" means italics, it also does specifically mean that. Whereas <span> means basically nothing in particular, so no strong argument against using it for an icon that I can think of.

FWIW, vis: everybody "does their own thing," we had a book that passed 3 different international standard accessibility checks, right?

But did it pass this one college's? Noooooooooooooooooooo, it didn't. I forget now what it was, that they were all up in the high hairy eyeball about,but we had to add something that made NO sense, to pass their internal "accessibility check." It took myriad passes with this custom-designed, in-house tool.

You cannot assume that using Standard A will mean that everybody and their brother will sign off on those particular sets of standards.

@fdwojo: And as far as "since you make your own eBooks," hey, that's what everybody here is doing. Some of us, for other folks, too.

All we can ALL do is muddle along, doing the best we can with inconsistent standards which are then even more inconsistently applied and adopted.

In my humble opinion, i ≠ em and b ≠ strong. When you're having something read aloud to you, they are different.

Offered FWIW.

Hitch

Yes.

So, <i> and <em> for example:

• <i> = Visually italics.
  
  • Like a book title or name of a newspaper.
• <em> = Words that are actually emphasis.
  
  • You're speaking the word "never" differently.

Then take <b> for example. I was just working on a book with an interview:

• <b> = Visually bold.

The "person speaking" is definitely not <strong>, because it's not super important (or emphasized) or anything... it's just a visual decision.

So some books might even use <i> there instead:

Anyway, you can read through the 2 big threads for a ton more details and examples. :)

Complete Side Note: On more easily marking up <i> vs. <em>... there's still the "Italics Lists" idea (which I wrote about a few months ago in "What Features or Tools does Sigil Still Need Yet?" (Post #163)).

If you had a nice, searchable/sortable list of all italics in the book, then you could easily mark which ones should go from <i> -> <em> or <em> -> <i>.

It would be the perfect mashup of Spellcheck Lists + Diap's Toolbag. :)

Thanks for the link.

Exactly.

I'd like to hear more details on this no-sense nonsense!

OK. So e.g. I italicise New York Times but don't emphasise it vocally.

However, I've never seen a commercial book that made that distinction.
Either they use i throughout, or em throughout, for everything: emphasis, book titles, headings, foreign words, etc.
Most of the big corporate ones used em, but if so never used i.

And none of my clients has ever mentioned this distinction to me. Certainly none of the authors have.

And if I was making a text-to-speech app, it would be foolish to expect the text to be coded according to this rule, because hardly any is. It would have to either emphasise all italics, or have an exception list of commonly italicised words.

Anyway, I make books to read and look good on paper or screen.
if someone wants to run it through a TTS engine, good luck to them. They can pay me if they want me to prep the text for that.

This was partially discussed in those 2 previous large threads on the topic.

Yes, most people just go for the easy/quick: all <i> or all <em>... (or you have no-good tools/workflows which force markup fully one way or the other.)

Although much rarer, there are programs/tools/people that generate more semantically correct HTML.

Like Citation Management Systems (Zotero, Mendeley) generate proper <i> + <em> + <b>.

There's also lots of other alternate workflows, like: DOCBook->HTML, LaTeX->HTML, or JATS (an XML format used in journal articles).

Publishers/authors will mark italics/emphasis/bold in their books properly, so they could more easily swap citation styles, mathematical styles, etc.:

• A journal article in a journal may follow a different citation style than republishing it as a chapter in a book.
  
  • Some citation styles use "Vol. 1, No. 2", others may use "<b>1</b>(2)".
• In physics, a vector may be written as a <b>i</b> letter. Other styles may use a "hat" (î).

Doubt they have a clue. But you, as the ebook creator, should be the knowledgable one.

They probably won't know one thing about <blockquote>, <h1>, <table> + <thead>, alt tags, or EPUB3 footnote markup either... but you'd want to mark all this stuff to the best of your ability (and teach them about it) to help future readers/conversions/tools. :)

* * *

Properly marked headings for example.

I've discussed how HTML from my ebooks gets converted/reposted as articles on a website.

After publishing ~100 ebooks, the web admin decided to add a Javascript TOC. Now, because I had all my headings marked properly, poof, a reader on the site can jump through the web-version similar to an EPUB's TOC + the Javascript TOC highlights where you're located in the book.

(Blind/visually-impaired readers using JAWS/NVDA would've already been able to navigate using headings! And now sighted readers can now too! :D)

Because I followed standards + laid the groundwork... the tools/enhancements will come. :D

If you mark the:

• Headings
  
  • using <h1>-><h6>, NOT <p class="heading">.
• Paragraphs
  
  • using <p>, NOT <div class="p">.
• Italics
  
  • using <i> or <em>, NOT <span class="italics">.
• Tables
  
  • using <table>, NOT <img>.
• Proper lang + xml:lang
  
  • Mark the Chinese as Chinese!

then you'll be most of the way there. :D

H tags are useless for headings: they were designed for technical documentation "2.1.1 Blah blah" and not for books.

If you're doing scientific articles in epub, all respect to you, but that's a pretty esoteric market.


I meant, they have never discussed repurposing the text (except from print to ebook, or for webpages, which is trivial) or converting to audio automatically -- for audiobooks, they use a human reader, which is by far the best result.

They just care what it looks like. And I have never, in 30 years, had an author who was able to use Word styles usefully. Trying to educate them about XML is just unthinkable.



Yes, of course.
I learnt HTML back in the 90s, did it for years before I learned any CSS, so I use all those as appropriate. And I much prefer e.g. just <h2> for chapter heads than a p or div class; not least because it more or less works with no CSS and lets me generate a TOC in Sigil.

So, you don't use Sigil's "Generate Table of contents"?

Anyway, chapters I use h2. Parts, h1. Subheads h3.
Works for fiction as well as anything else.
Then click and in 30 seconds I have a presentable TOC.

Hogwash.

Hogwash indeed.

And may I add in my HOGWASH, too? What utter nonsense! "H tags are useless for headings." Sheesh.


Hitch

To me,it's a distinction without a difference. I prefer i and b because they do what they say, while em and strong are ambiguous. Most writers emphasize with italics, and reserve bold for the most minor sort of breakhead.

Lots of html is nutty. For example, the claimed distinction between an apostrophe and a single close-quote. One shrugs one's shoulders and gets on with it.

I would suggest that shows a complete lack of awareness about people with accessibility issues. I was there not too long ago, then I was forced to become aware… and now I care. Don’t feel lonely though - there are a lot of people that are unaware and don’t care.

The distinction is that the reading devices/apps can, and do, treat them (b/i, em/strong) differently. So, as a professional, it would be incumbent upon us to do things the right way, rather than not.

Took the words right out of my mouth. Or, snagged 'em from my fingers, as it were.

H