Why, Sigil, Why? And can I change you?
 

Does anyone know why Sigil uses <b> for bold/strong and <i> for italics/emphasis?

<b> is identical to <strong> and <i> is identical to <em>, and everything I read indicates that <strong> and <em> are the preferred way to do it. And so, I try to be consistent with the recommended way.

Why does Sigil do it the older, original way? Or are all the HTML publishing guides wrong and we should use <b> and <i> instead of the longer variants? (and if it DOESN"T matter, why are all the style guides wrong?)

And lastly, if I wanted to, can I modify Sigil to use <strong> and <em> when I bold or italicize text?

P.S. Granted, with all the posts here on the forum, I suppose it's possible to look through them all, or search them all, but I didn't find anything addressing this issue. (Sorry if I missed an existing question about this!)

Frank
~~~~~~~~~~~~~~~~~~~~~~~~
Using Win10 Pro and Samsung Note20

Semantic meaning is what differentiates when to use one or the other of them and it has waffled back and forth repeatedly given changes in the living html spec. Some tags like u have even gone away and then brought back.

Since Sigil can not guess what semantic you want it defaults to the more generic tags.
Sigil will not be changing the tags based on current "fashion" once again.

You can do either of:

- Use Find and replace to swap those tags to anything you want

- Set up Clips to create the tags you prefer and assign them to clip icons so they can used just as easily as italic and bold icons now.

Why, oh why, do people who don't want to bother writing their own html code get so overly dramatic about the way valid html code gets generated for them?

And to answer your second question: of course you can change it. You're welcome to write your own html with whatever tags you prefer.

Because we are the Dog being wagged by the HTML spec writers? :rofl:

How about all the render engines that choose to ignore one way or another? Why o Why

All browser based versions handle both so what render engine/e-reader requires strong and does not recognize b?

Do I have the topic for you:

2020: "<i>, <em> or <span> for italics ?"

Especially see my Posts #67+.

<i> vs. <em> + <strong> vs. <b> was discussed to death, with detailed examples.

You can easily swap between <span class="italics">/<i>/<em> + <b>/<strong> using Diap's "TagMechanic" Sigil plugin (or "Diap's Editing Toolbag" if Calibre).

Again, see 2020: "How do I change italic <i> shortcut to use <em> instead?" where I give instructions how.

Well, I thank you all for the quick response. Because I create my own eBooks, I want them to be as compatible and consistent as possible. (as if that's even possible). For that reason, (as I mentioned before), since I keep hearing about using <em> instead of <i> and <strong> instead of <b>, I had (mistakenly) thought that SIGIL would go with what was the presumed standard (if it really even is a standard).

With regards to "can I change it", I was referring to the way that SIGIL responds when you choose to BOLD, ITALICS, or UNDERLINE with just a click of the mouse or a keypress of CTRL-B or CTRL-I or CTRL-U. Granted, if I was a programmer I'm sure I could edit the source code, and generate my own custom version of SIGIL, but sadly, I can't and I'm guessing the source code isn't available even if I could.

So, I'll keep using SIGIL as I have been, (and wishing...)

Again, thank you all for your help!

;-)

Frank
~~~~~~~~~~~~~~~~~~~~~~~~
Using Win10 Pro and Samsung Note20

Or do as I said and create an "em" and "strong" clips, view the clips toolbar and highlight what you want have one click set them.

Try reading the clips.xhtml chapter of the latest Sigil User Guide which will show you how to create them.

As KevinH has already mentioned, you could easily change the behavior of CTRL+B and CTRL+I by creating two clips. This'll take less than 5 minutes.

1. Right-click the toolbar and check Clip Bar, if it isn't already checked.
2. In the Clip Editor, create two clips with the following contents
<strong>\1</strong>
<em>\1</em>
(They must be the first two clips.)

https://i.imgur.com/kaZ9ztF.png

3. Change the keyboard shortcuts for clips 1 & 2 to CTRL+B and CTRL+I

https://i.imgur.com/ruF21MJ.png

<em> is a logical tag, so it can be used with foreign scripts to make text bold, or smaller, or add a line or accent dots.

Thanks, Doitsu. I've used Clips the older way (right-click, choose CLIPS, and choose my desired Clip), but I wasn't aware you could associate them with a hotkey. That might do the trick for me.

Perfect answer!

<em> and <i> is something completly different. <i> sets the fontstyle to italic. <em> is emphasized is a semantic thing. Most browserstylesheet are displaying the emphasized text in italics, but thats just a usual representation.
<em> is neither better. nor more modern, nor more compatible than <i>. Exactly the same with <b> and <strong>.

True - as the thread linked by Tex mentions, there are many reasons why you might want <em> instead of <i>. Aside from the visual styling, because you can use identical css with either tag to make the look the same, the <em> is used by accessibility programs to treat the word/phrase differently - eg. different stress on a word in tts.

So… if you only need a visual italic (like in a list of references) then <i> works fine. But if it is supposed to mean something then you want the semantically correct <em>.

<em> is no more “logical” than <i>.
You can redefine either or both to be expressed however you like in css.
Anyway, I don’t see <i> or <b> not working anytime soon, so I will keep using them. One of the first things I do when I check over a book is convert em and strong to i and b. I hate longwinded code that clutters up text. The same reason we use figures to do maths and not words. Simpler notation makes for more clarity.

When I use <i> it’s because I want italics. So <i>is more logical for me. If someone wants to convert that to flashing green or whatever, that’s fine. They can add a line to the css.

Sorry, I thought I had linked to the Accessibility Publishing Database website in my previous post. Here it is for anyone who cares.

They have a nice explanation on what the differences are between i/b/em/strong and when each should be used...they also talk about the html5 specs briefly.

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

Right, but I thought they were also for making text bold? :D

Now i have a catchy tune :rolleyes:

... in English.

That's another reason why <em> was introduced:

English (and most Latin-alphabets) tend to use italics for emphasis.

But Asian languages don't have such a thing as italics. They emphasize using dots (and other symbols).

As the internet spread across the world, there were more and more cases where <i> and <b> failed.

Side Note #1: For emphasis, along with italics, there's been lots of different display types:

• bold
• letter-spacing
• highlight
• colors
• [...]

For a little more info, see Wikipedia: "Emphasis (Typography)".

But you can clearly see how E M P H A S I S is a distinct category from plain old italics.

Side Note #2: A lot of the multi-lingual stuff was being discussed at the end of the very last thread:

"<i>, <em> or <span> for italics ?" (Post #151+)

There was a TUG talk given in 2020: "Typographical expression of emotions in a variety of alphabet systems"... I should re-contact them and see if they ever posted the lecture online. Sadly, I signed up for the conference, but missed the livestream of that talk.

<em> is not ambiguous.

But I agree, HTML5's explanation of <strong> is a little... ehhhh...

Again, multi-lingual.

See the fantastic article me+Toxaris (and others) always point to:

Wikipedia: "Quotation mark" > Summary Table

Around the world, there's every single combination under the sun for quote marks.

Just so happens to be, in English, the "apostrophe" + "right single quote" (single "close quote") settled on using the same-looking symbol.

Just like it just so happens to be, in English, emphasis settled on italics. :D

Not necessarily. The academic + scientific market is pretty huge. Minority, yes, but large nonetheless.

And it's an example where lots of proper markup is used. Just because you haven't seen it, doesn't mean it's not out there (and should be strived towards).

And when their crappily-designed, not-following-the-standards, "I just care about the looks" ebook breaks a few years down the line? You'll be back to cleaning it up. :D

A lot of my work is cleaning up 10+-year old EPUBs that were poorly converted, bringing them up to date + following the latest standards.

Another large chunk is compilations—taking chapters from multiple books, combine into a single book. (When you combine books, you typically have to normalize the texts so they are consistent within themselves. [Like all UK spelling/quotes -> US spelling/quotes.])

Or releasing a single, larger chapter as a standalone.

(My latest 3 projects were 1 in each of these categories!)

Well, that's your issue. I've successfully converted quite a few authors into Styles after teaching them how much better it is.

(Seriously, it only takes ~30 minutes to watch a few of those Styles videos... and it'll save any author TONS of time.)

Yes, you'll still have 99% of the crowd mindlessly clicking the BOLD + CENTER + FONT SIZE buttons (hundreds of times)... but once you unleash the power of Styles, wow.

See my most recent Styles post on Reddit:

• /r/writers: "Paragraph Formatting shortcuts?"

and my Styles posts in 2019/2020:

• 2019: "MS Word vs. Open Office Word"
• 2020: "eBook Formatting in Sigil", especially Posts #46 + #50 + #52

If it's people who will be working with me over the years... Styles just saved them+me hundreds of hours of work. And the more they plan on writing, the more and more time Styles will save. :)

There's absolutely no reason NOT to use Styles!

And if I can take it down from 99% to 98% people, wow... take one down, pass it around, 98% who don't use Styles on the wall! :D

And another aim of proper markup is progressive enhancement.

For example, I always converted all tables into actual <table>, but I had no idea about <thead> until recently.

<thead> allows long tables (or tables that get split across pages) to carry headings over + allows the computer to understand main headings (instead of trying to guess).

Accessibility Ranking

So, let's say we were going from worst -> best.

An image of a table is worst:

Adding an alt tag is better:

Converting to <table> is much better:

and this is best:

If we use a % Accessibility score, you might have:

• 0%: <img>
  
  • A blind person (and/or search engine) will have zero clue what this image is.
• 25%: <img> with alt
  
  • At least they know: "Hey, there's an image of 'Table 1' here."
    
  • And if the image is ever lost/missing, there's placeholder text.
    
  • And a more descriptive alt would be even better!
• 90%: <table>
  
  • Text-to-Speech can actually read all the data.
    
  • A blind reader can navigate all the data, going forward/back if needed.
    
  • You can make the font as large as you need.
• 100%: <table> with <thead> + scope
  
  • Everything will be read out loud correctly (like a human would)
    
  • + it works across split pages (very common on small cellphone screens)!

So, if we look at the ebook as a whole, that little list I gave in Post #21 are the major fixes, and probably gets you 75% of the way there:

• Headings allow users to easily jump around the book
• Tables allow all data to be read
• lang allows spelling/dictionary-lookup/hyphenation/text-to-speech to be correct.
• [...]

Then each of those little Accessibility/markup enhancements slowly add up... taking care of edge cases + alternate ways of reading.

The code in the ebook is much more than just surface visuals.

:thumbsup::thumbsup:

Nope. A heading in fiction is a block of several paragraphs. A heading in HTML is a single paragraph. They just don't mix.

The only possible use is creating a fake H# element with a manually generated title. (Yes, in fiction, you cannot derive the TOC text from the header automatically).

That's an epigraph or epigram. And there's no law that says a heading in HTML has to be a single line or paragraph, either.

That's ridiculous. Of course you can. WHAT are you talking about? What is this about "a heading in fiction is a block of several paragraphs" stuff? What fiction are you talking about?

Hitch

Block model says so. H# elements can only contain runs, not paragraphs or other blocks.

A heading in fiction has several block parts forming an indivisible unit: the chapter text (without a final punctuation), like "Chapter VII", the chapter illustration, the chapter name (with the final punctuation in some languages), and the chapter synopsis (which can sometimes be present in the TOC). The TOC text is different from the actual header: it can be a simple list (like in The Lord of the Rings), or the numbering/name may be different, the punctuation will usually be present, and the chapter name punctuation will be absent.

The text editors or macrolanguages like Latex can handle that easily, but not HTML, a dumb language for technical documentation.

Sigil can generate different TOC text:

Ahh yes, that "dumb language" that controls the entire interwebs... but not Fiction books though! :rofl:

I agree on all points, but the example above is not a good one. The alt text should contain something meaningful when the image is not displayed, which is the case with text-to-speech. Here a good software would use the alt-text, and "Table 1" is now as meaningless as nothing. In the last case you can always see that there is something, but that's it.

You can see it especially well in initials, where the first letter of the chapter is represented by a picture. I have seen it many times: the alt text then reads "Letter A" (assuming the image shows letter A). This is nonsense. The correct alt text is "A", not "Letter A" or "Initial A" or anything else. If I have the publisher's logo on the cover, then the correct alt text is "Raqndom House", "Penguin Books" or whatever the publisher is called, but neither the name of the image "publisher-logo.png" or "logo" or anything like that makes sense.

In your case "The e-book creator did not care about disabled people" should be in the title attribute or further hints in the longdesc attribute, where in the longdesc attribute only URIs may occur. EReaders certainly don't evaluate this, whether reading software does it I don't know.

For descriptive content the alt-attribute is the wrong place.

The USER can generate different TOC text. H# elements do not help here.
This page, for example, contains exactly 0 H# elements, which says lots about its usefulness.

Mistakes made by others are no excuse for your own mistakes. Bad examples are not arguments for one's own opinion. References to the mistakes of others are distracting whataboutism.