Best way to do italic and bold

[KevinH]

The goal of adding semantic meaning is laudable. And epub3 has taken this a real step forward by allowing epub:type attributes to be attached to provide semantic meaning in many places (just not in guide/landmarks).

But I truly wonder if any accessibility software ever takes advantage of any of it. Many screen based text to speech routines never see the actual code and instead simply grab the text from the screen buffer meaning that none of the semantic meaning of the code will ever be seen let alone used.

And has anyone read all of the different web pages that try to explain the difference between i and em and b and strong? They seem to need actual translators themselves and end up being more confusing that actually helpful. The printed page had italics and bold and at one time these made sense and everyone understood them. Now we as ebook authors have to intuit the authors meaning by using these which is never 100% clear no matter what approach is used.

I would prefer we reverted to the i and b tags and then added an attribute to them (either an aria-role or epub:type or a special class name) that indicates how the author meant it to be used semantically and stop adding long span tags that simply end up cluttering the code.

Of course I am older and grumpy and don't like change! ;-)

[bookman156]

Well, if we continue to use <i> and <b> then we should do so in the knowledge that we are only designing books to be read on a screen with eyes all the way into the future, and are taking no account of any re-purposing of this information.

Of course, all markup is arbitrary, and we could in future designate <i> not as meaning 'italic' but as meaning something else, perhaps it might come to mean 'indefinite' and then we can define it how we like in the CSS. Then everyone will be happy.

[bookman156]

Say at some point you felt it would be a good idea to have your emphasised words no longer in italic but in red and roman, you'd be faced with the awkward moment of defining the <i> tag as roman in your stylesheet. No such problem with <em>.

Basically, if we want to design with italic we should be making print books, not ebooks. To regard an ebook as an e-equivalent of a print book is just a short period in history when we couldn't see too far ahead.

[JSWolf]

Originally Posted by 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>.

That would have to be sometime before the H2O was released. I've never had a problem with <em> with my H2O. I did have a problem with whatever version RMDSk was used on a 650 when the encoding of the files (not in the files, but the files themselves) was incorrect. I'd end up with mostly bolded text.

[KevinH]

I guess you missed the part about adding an attribute to the tag that indicated its semantic meaning, not by adding new not well defined tags.

;-)

Originally Posted by bookman156

Well, if we continue to use <i> and <b> then we should do so in the knowledge that we are only designing books to be read on a screen with eyes all the way into the future, and are taking no account of any re-purposing of this information.

Of course, all markup is arbitrary, and we could in future designate <i> not as meaning 'italic' but as meaning something else, perhaps it might come to mean 'indefinite' and then we can define it how we like in the CSS. Then everyone will be happy.

[bookman156]

Originally Posted by KevinH

I guess you missed the part about adding an attribute to the tag that indicated its semantic meaning, not by adding new not well defined tags.

;-)

You understand that much better than I do, and maybe you're right, but it seems a bit like fixing my glasses with electrical tape instead of getting a new pair (something I am willing to do for a while). As I say, it's all arbitrary and only depends on what people are willing to agree to into the future. If I no longer think of <i> as meaning italic I can define it in the CSS as anything I like without any sense of creating nonsense. All language is in essence nonsense that we delude ourselves means something.

[bookman156]

Surely this is what is important: 'You should not use b and i tags if there is a more descriptive and relevant tag available.'

From: http://www.w3.org/International/ques...a-b-and-i-tags

[bookman156]

Of course, people will inevitably fall back into the lazy use of the <em> tag, thinking of it as a better italic tag, and so using <em> to get italic for book titles when they should be using <cite>. No-one's perfect. But head-in-the-sandness never helps.

[KevinH]

Or based on my reading of your link, it is summarized at the end as:

It may help to think of b or i elements as essentially a span element with an automatic fallback styling. Just like a span element, these elements usually benefit from class names if they are to be useful.

They are effectively using an attribute ("class" in this case) to confer a semantic meaning. The problem is the class name need not actually indicate anything and it might be better to had attributes with specific recognized vocabularies meant to capture semantic meaning instead of free form class names that may or may not be recognized.

KevinH

[bookman156]

But the idea of a span tag with an automatic fallback position is only an historical legacy. Defining classes for them seems to me a bit of a fudge. May as well just have an actual span class than get involved in that kind of short-termism.

[Pablo]

Originally Posted by bookman156

Say at some point you felt it would be a good idea to have your emphasised words no longer in italic but in red and roman, you'd be faced with the awkward moment of defining the <i> tag as roman in your stylesheet. No such problem with <em>.

Basically, if we want to design with italic we should be making print books, not ebooks. To regard an ebook as an e-equivalent of a print book is just a short period in history when we couldn't see too far ahead.

Hint: if you are already in your ebook editing software changing your CSS, a simple S&R will save you from that awkward situation.

An ebook is not carved in stone, you can always go back and change it.

[bookman156]

Originally Posted by KevinH

They are effectively using an attribute ("class" in this case) to confer a semantic meaning. The problem is the class name need not actually indicate anything and it might be better to had attributes with specific recognized vocabularies meant to capture semantic meaning instead of free form class names that may or may not be recognized.

I don't quite understand what you mean. In itself a class name would mean nothing, but what it meant would be defined in the stylesheet and so recognised there.

[bookman156]

Originally Posted by Pablo

Hint: if you are already in your ebook editing software changing your CSS, a simple S&R will save you from that awkward situation.

Yes, quite true. But if I had used <em> and <cite> instead of a ubiquitous <i> I would have even more control.

[KevinH]

If you read the entire article at the link you posted it recommended using "i" with a class name of "foreignwords" to effectively convey the semantic meaning of why that class is used.

To me that approach is better than nothing but heavily prone to error. It would be much better to have an attribute similar to epub:type or aria:role that has a controlled vocabulary one of which whose terms means "just indicating a foreign word here" officially.

Then you would use an "i" tag but with an extra epub:type attribute set to the universally agreed upon and official term for "foreign word" and let any class attribute be anything you want it to be.

This is the whole idea behind using controlled vocabularies for things like "Add Semantics" as used in the guide/landmarks. In epub 3 there is a much larger controlled vocabulary that can already be used by adding an epub:type attribute to any tag, and the proposed epub3.1 is going to allow full aria:role markup by attribute as well.

Using this approach you do not need both "i" and "em" or both "b" and "strong". The tag itself provides the fall back styling, and class defines the active styling, and the epub:type or aria attribute defines the semantic meaning possibly independent of tag with a controlled vocabulary instead of free-form langauge dependent interpretation.

KevinH

Originally Posted by bookman156

I don't quite understand what you mean. In itself a class name would mean nothing, but what it meant would be defined in the stylesheet and so recognised there.

[bookman156]

Originally Posted by KevinH

If you read the entire article at the link you posted it recommended using "i" with a class name of "foreignwords" to effectively convey the semantic meaning of why that class is used.

To me that approach is better than nothing but heavily prone to error. It would be much better to have an attribute similar to epub:type or aria:role that has a controlled vocabulary one of which whose terms means "just indicating a foreign word here" officially.

I don't know much about epub:type or aria:role to say one way or the other, I bow to your superior knowledge on that. But I don't see why using a class would ever be heavily prone to error, because the class is defined in the stylesheet, so where would the error come from? Am I missing something?