Best way to do italic and bold

[KevinH]

The semantic meaning in that case is coming from the user's choice of class name. I might choose to call it "foreignword" someone else might call it "latinterm" or someone else might call it "foreignterm". Not everyone will decide to use the exact same class name to indicate the same semantic meaning. That makes interpreting it by screen readers and TTS unreliable. If instead a controlled vocabulary is attached to an attribute specifically chosen to convey semantic meaning, then screen reading and TTS software would understand immediately what you mean by your italic tag regardless of what class name you chose.
KevinH

[bookman156]

But it would be a good idea to have a dedicated tag to indicate that a word was being italicised solely because it was a foreign word and not because it needed emphasising in any way.

[bookman156]

Originally Posted by KevinH

The semantic meaning in that case is coming from the user's choice of class name. I might choose to call it "foreignword" someone else might call it "latinterm" or someone else might call it "foreignterm". Not everyone will decide to use the exact same class name to indicate the same semantic meaning. That makes interpreting it by screen readers and TTS unreliable.
KevinH

Yes, but it doesn't matter what you call it, because you are defining it in your own stylesheet. The universal agreement is ceded to CSS alone.

You can tell the screen-reader or TSS what to do with a particular class in the CSS.

[HarryT]

Sometimes all you want to do is reproduce the appearance of a printed book, and not worry about what the intent of the author was in using bold or italic. I can see no harm in using <b> and <i> tags in such a situation.

[bookman156]

The author of a book published before ebook technology had no intent beyond italic and bold. But then they may not have had an intent that their work should appear in anything other than the print medium. I am finding this out for myself, but it was my fault for not quibbling over the parts of the contract dealing with media type.

[KevinH]

That would be the role of the attribute, not the tag. Otherwise you need lots of tags just to handle semantic meaning. One defined set of possible values for attributes attached to generic tags would make the most sense (and is how they have decided to go in the future).

That way standardized software can read anyone xhtml page and know immediately what the author meant, what structure the document has, and why specific styles (that they may in fact be unable to see) are bing used.

The next release of Sigil will make it possible to easily add even more semantic information using the epub:type attributes (even in BV) so that more of the structure of the document can be recognized automatically and universally by everyone. Right now you choose a term in your own language when you add semantics but in reality there is a controlled vocabulary of terms used in the guide and in landmarks and actually in many other places in epub3. So more semantic attribute marking will be coming for epub3. The reason is to allow readers more information about both the structure of the document and the reason certain tags are being used.

KevinH

[bookman156]

Originally Posted by KevinH

That would be the role of the attribute, not the tag. Otherwise you need lots of tags just to handle semantic meaning.

We do have a lot of tags to handle semantic meaning, but not everyone uses them, preferring plain old <i>, because they're seeking only to reproduce the look of a printed book, which I suppose is fine, even if ignoring blind people whose ebook might be in Braille if there was the technology. I don't know how Braille does italic, do they slant the dots? But whether it is a tag or an attribute, the end meaning will be the same. Are attributes saving any work over a dedicated tag? One still has to think about semantic content and tag it appropriately.

[KevinH]

The same attribute to add a specific semantic meaning can be used on multiple tags and always be interpreted correctly vs a large proliferation of variations of tags that no one knows the difference between. It is simple combinatorics.
Kevin

[bookman156]

I am becoming more Luddite the more I think about it. Perhaps the error was learning to read.

[theducks]

KISS
Don't introduce things that aren't needed
<b>, <i> say use the current font and paragraph attributes, Just those faces. That is it. no CSS or style needed

(I use bold to convey keywords when giving usage guidance here at MR and underline for strong warning Gotcha's

OTOH if you are trying to convey 'voice', then <em> or <strong> might be better

<em>, <strong> tend to inherit their qualities from the render engine designers and need additional style controls (if you care)

[BetterRed]

Originally Posted by bookman156

I am becoming more Luddite the more I think about it. Perhaps the error was learning to read.

Originally Posted by jackie_w

...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.

@jackie_w - it hasn't changed much since I used DecTalk boxes on some sugar mill SCADA systems in the mid 1980's. I believe Steven Hawking still uses a DecTalk box.

BR

[Toxaris]

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

And that is not right either. A title is not the same as a citation, so the use of <cite> would also not be correct and not better than <i>. Here you will use the wrong semantics.
The current standard only knows a limited set of semantic tags. I do agree that it is better to split semantics/structure from layout. However, <i> and <b> can mean so much more than <em> or <strong>. So much, that actually the 'emphasis' or 'strong' would not be suitable at all. To fully replace that by semantics, you would need a whole lot more. So, you would need to resort to stylesheet classes to give the semantic value to the actual text.

[bookman156]

Originally Posted by Toxaris

And that is not right either. A title is not the same as a citation, so the use of <cite> would also not be correct and not better than <i>.

I know a title isn't a citation, but nonetheless this is one of the things <cite> is used for, check the specification:

https://www.w3.org/TR/html5/text-lev...e-cite-element

[Toxaris]

Originally Posted by bookman156

I know a title isn't a citation, but nonetheless this is one of the things <cite> is used for, check the specification:

https://www.w3.org/TR/html5/text-lev...e-cite-element

In that case the title is part of the citation/reference. It is not the title of the book/document itself.

To me it seems they are trying to make HTML more semantic, but they do it only partially and not consistent. Anyway, I don't want to be depending on a renderer to decide who things must look as this is not defined in the standard. If they would specify the standard rendering of a semantic tag, it could be easily used and overruled. It is almost impossible to prevent every possible layout that a renderer could apply to a tag as their standard.

[st_albert]

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.

Seems no one has answered this question, at least directly, so I'll give you my reasons.

In some cases, I create epubs via export from InDesign CS4, which implements character styles with spans. It loves spans so much it even wraps all paragraphs in a "generic span" that has a null definition in the stylesheet, just in case you want to define them later (I suppose). IIRC, later versions of ID will let the user define the HTML used to implement a given style.

In other cases, I create the epub from a (Word .doc, .rtf, etc.) -> LibreOffice .odt via a "Writer2latex" javascript tool. In this case I can define the CSS that corresponds to each LibreOffice paragraph or character style, and I do so in such a way as to make it consistent with the ID4 CSS, just to make my life easier.

In either case, the epubs so obtained require considerable tweaking in Sigil, and I like my saved clips and S/R's to be applicable to epubs from either source, to the extent possible.

If this constitutes incompetence, so be it

Albert