Underlining

[Hitch]

Originally Posted by DiapDealer

True. But the button is there because there was a wysiwyg cry for such a thing. And making the button underline text in a spec-compliant AND sane method would be nothing but trouble: do we create inline styles; do we create a new class in the css file for each occurrance (do we create/link a css file if one doesn't already exist)? Do we parse existing css (both inline and external) to see if a suitable class to be used already exists? What if inheritance from a pre-existing class clobbers Sigil's efforts to create the underline? It's a nightmare any way you look at it.

Here endeth the lesson; the reason that SO MANY people are unhappy that BookView persists. This is the exact reason. The "need" for insta-underlining and other "instant" push-button features--that are actually now WRONG. To use it--if you're a pro, or simply determined to do it correctly--you have to use it, then create some class for it, then regex the u's into spans with the correct name, and of course the closing tag, as well. If ever a nice simple argument for "why BookView can, not necessarily does, suck," this is it.

My personal preference would be to give U tags a free pass in Sigil's well-formed check, if at all possible. Let the epub validators do all the barking about them. Short of that, I guess I'd like to see it (the button) made unavailable in documents where Sigil/gumbo deems them un-spec-worthy.

Good stuff!

I think that's about all we can do, if the BV persists and PV doesn't win out as replacing same. Those of us who know and who check, can replace the "u" if we do something stupid, forget and use it; those who don't...well, don't. And won't. They'll either find out when they go to upload it (assuming arguendo it has to pass ePUBcheck), or they'll just build a mobi with it...and I can't now remember if i, u, b, will build uncomplainingly in KG or not. (We don't use them, so...).

In fairness to all, however, I have to say that my fingers still reach for i,u,b. I have to remind myself to NOT do it. (And what will happen is, just as soon as I finally remember without prompting, we'll all be working in ePUB3, ha!).

Hitch

[Doitsu]

Originally Posted by Hitch

I think that's about all we can do, if the BV persists and PV doesn't win out as replacing same. Those of us who know and who check, can replace the "u" if we do something stupid, forget and use it; those who don't...well, don't. And won't. They'll either find out when they go to upload it (assuming arguendo it has to pass ePUBcheck), or they'll just build a mobi with it...and I can't now remember if i, u, b, will build uncomplainingly in KG or not. (We don't use them, so...).

BTW, expect lots of fun converting epub2 books with embedded fonts to epub3 books, because media-type="application/x-font-ttf" font declarations are no longer valid; you'll have to change them to media-type="application/vnd.ms-opentype".
Otherwise, epubcheck will display an INFO(CSS-007) message. (The epub3 book will technically still be valid, but I seriously doubt that many ePubcheck users will be able to tell the difference between INFO, WARNING and ERROR messages.

[Toxaris]

I don't expect those kind of problems actually. It can be seen in the opf whether it is an ePUB2 or ePUB3. So that kind of conversion is not hard to build in.

[JSWolf]

Originally Posted by GrannyGrump

Can't you declare "u" in your css? I often do that for "em" and "strong"

u {text-decoration: underline}

I find it just really annoying when italics and bold are done via spans. That just adds code bloat where it doesn't need to be added. <i></i> and <b></b> work. So just use that instead of spans.

[Notjohn]

Originally Posted by JSWolf

I find it just really annoying when italics and bold are done via spans. That just adds code bloat where it doesn't need to be added. <i></i> and <b></b> work. So just use that instead of spans.

Amen!

@Hitch: <i> and <b> work just fine. That they were ever deprecated seems insanity to me. I've had trouble with <u> and had to create a style for it. But I think that that was because the underlined words were also bolded, and Sigil at least doesn't like me to do that, but creates a style of its own on the fly.

[Notjohn]

Originally Posted by eschwartz

A silly rule is still a rule.

And as DiapDealer said, the chances of any browser or ereader or any piece of code designed to render HTML NOT supporting it is... unlikely.

But if you want to conform to the spec and thus pass Epubcheck, you need to follow the silly rule. And if you want to submit an ebook to a store that demands you pass Epubcheck, you gotta conform to the spec...

I just ran my book-in-progress through epubcheck, and it passed just fine, with multiple <u>s and <i>s, though the underlines are done with a style, the last forced on me by Sigil. And most of my books (most of which contain <u> and <i>) are sold on the Apple store, which mandates epubcheckworthiness.

I've never been much of a follower of rules that don't make sense. Heck, I can't even remember whether <em> means bold or italics. Each is a form of EMphasis, and so is all caps.

[DiapDealer]

Originally Posted by Notjohn

@Hitch: <i> and <b> work just fine. That they were ever deprecated seems insanity to me. I've had trouble with <u> and had to create a style for it. But I think that that was because the underlined words were also bolded, and Sigil at least doesn't like me to do that, but creates a style of its own on the fly.

I know of no styles being created automatically by Sigil in the latest versions (with the exception of the html toc css). Can you be more specific?

EDIT: and in previous versions, it was my experience that the auto-generation of inline styles (and the code-modification their generation was triggered by) was easily avoidable by choosing the Pretty-Print-only clean-source preference. Tidy was responsible for creating inline styles (if you allowed it to) and Tidy has been gone since v0.8.900.

[Arios]

DiapDealer, Hitch has expressed my idea better than I would have done. In short, one more problem with BV!

But I'd reword my precedent post as follow: the funny thing is that <i></i> can pass validation correctly, the less funny thing is that <u></u> doesn't: incoherent!

PS By the way I avoid to use <u> as far as I can.

[DiapDealer]

Originally Posted by Arios

DiapDealer, Hitch has expressed my idea better than I would have done. In short, one more problem with BV!

But I'd reword my precedent post as follow: the funny thing is that <i></i> can pass validation correctly, the less funny thing is that <u></u> doesn't: incoherent!

PS By the way I avoid to use <u> as far as I can.

No problem. I get where everyone is coming from. Truly.

[Hitch]

Originally Posted by Notjohn

Amen!

@Hitch: <i> and <b> work just fine. That they were ever deprecated seems insanity to me. I've had trouble with <u> and had to create a style for it. But I think that that was because the underlined words were also bolded, and Sigil at least doesn't like me to do that, but creates a style of its own on the fly.

Really? And which ePUBcheck was that, pray tell?

Originally Posted by Notjohn

I just ran my book-in-progress through epubcheck, and it passed just fine, with multiple <u>s and <i>s, though the underlines are done with a style, the last forced on me by Sigil. And most of my books (most of which contain <u> and <i>) are sold on the Apple store, which mandates epubcheckworthiness.

I've never been much of a follower of rules that don't make sense. Heck, I can't even remember whether <em> means bold or italics. Each is a form of EMphasis, and so is all caps.

Yes. Please note the part about "...the underlines are done with a style,..."

My last direct experience with this was quite simply that using direct styling in the form of "u" did not pass ePUBcheck; I vaguely recall a discussion in-house about the inconsistency with b and i and u; and I'm fairly certain that the latest ePUBcheck will puke on underlining styling that's done directly.

Hitch

[Doitsu]

Originally Posted by Hitch

My last direct experience with this was quite simply that using direct styling in the form of "u" did not pass ePUBcheck; I vaguely recall a discussion in-house about the inconsistency with b and i and u; and I'm fairly certain that the latest ePUBcheck will puke on underlining styling that's done directly.

EpubCheck 4.0.1 will flag <u>...</u> in an ePub2 book as an error:

Error while parsing file 'element "u" not allowed anywhere; expected the element end-tag, text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big", "br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins", "kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small", "span", "strong", "sub", "sup", "tt" or "var" (with xmlns:ns="http://www.w3.org/2000/svg")'.

but is OK with <u>...</u> in ePub3 books.

[Hitch]

Originally Posted by Doitsu

EpubCheck 4.0.1 will flag <u>...</u> in an ePub2 book as an error:

Error while parsing file 'element "u" not allowed anywhere; expected the element end-tag, text or element "a", "abbr", "acronym", "applet", "b", "bdo", "big", "br", "cite", "code", "del", "dfn", "em", "i", "iframe", "img", "ins", "kbd", "map", "noscript", "ns:svg", "object", "q", "samp", "script", "small", "span", "strong", "sub", "sup", "tt" or "var" (with xmlns:ns="http://www.w3.org/2000/svg")'.

but is OK with <u>...</u> in ePub3 books.

Right. What @Doits said. We're not yet (except for FXL) doing ePUB3, as..why? Most of my clients aren't selling any place (except iBooks) that will do intake on ePUB3, any-damned-way, so we give them ePUB2. Happy to provide ePUB3, if asked (okay...that's a lie, but hell, we'll do it), but...why? We're a commercial firm, making presumably commercial books. We gotta do what works. :-)

Hitch

[Notjohn]

Noted. Thank you! I'm relieved to know it's not just a Sigil idiosyncrasy.

I started putting up web pages in 1993, when the only internet connection available to me was a 1200 baud modem and the only browser Lynx. Many of those pages are still there. Everything I've done for the past 22 years has been hand-built on WordStar 7d. If browsers ever stop rendering deprecated markup, I'll just have to go out of the web publishing biz.

[HarryT]

Originally Posted by DiapDealer

I honestly don't think there will ever be a browser/renderer/reader that doesn't honor <u></u> ... regardless of whether the document claims to be (x)html4|5. But specs are specs.

I still use "<center>". There's no browser or reader that doesn't support it, although it's part of no current standard. It's a very, very useful tag.

You may throw up your hands in horror if you wish .

[DiapDealer]

Originally Posted by HarryT

I still use "<center>". There's no browser or reader that doesn't support it, although it's part of no current standard. It's a very, very useful tag.

You may throw up your hands in horror if you wish .

I'm not appalled at all.

I've no real love for spec that exists only to justify its own existence. There are enough REAL differences between rendering engines to waste time worrying about tags that wouldn't cause a single one of them to bat an eye.

But as a Sigil developer, I have to worry about automated tools/features having a solid base-line from which to begin. As a user of Sigil and an editor (personal only) of ebooks, however, I don't care in the least about spec-compliance.

I have no problem with Sigil offerring to keep my work compliant, I would just prefer that I always be allowed to decline its offer.