element "u" not allowed anywhere

[mrmikel]

It may not be a waste of time, if you are publishing commercially. I think they all use some kind of validation, whether valid or not. You will need to do what they demand in that case.

[JLius]

I'm not publishing, but I'll take your advice in consideration for future reference.

[skreutzer]

Then obviously using Calibre for EPUB creation is a waste of time, because you have to fix errors introduced by Calibre anyway.

[Toxaris]

In all fairness, Kovid did put it that harsh but he has a good explanation.

What you need for that is a tool that checks the book for known causes of error. Not a mindless tool that validates it against a DTD. The only reason epub validation exists at all is because, it is, quite literally, the simplest thing to program a tool that check HTML against a DTD and pops up lots of meaningless errors, as opposed to writing a tool that intelligently checks the HTML for things that are known to be problematic in real world usage.

And that is a valid point.

[mrmikel]

I am not publishing commercially so it is a waste of time to check for things that are not issues in real world readers. There are many of us that place our books in the library here that do it for our own use and the benefit of others.

Not everything worth doing is worth doing is worth doing perfectly according to some abstract standard.

[skreutzer]

Well, such explanation might sound pragmatic, but it is part of the problem instead of the solution. There's off-the-shelf EPUB validation (based upon off-the-shelf XHTML validation according to W3C's specification) according to IDPF's specification, and if some software creates invalid EPUB output, it will deliberately break all reading/processing software which benefits from those off-the-shelf solutions. Further, the goal of creating an EPUB initially is to be compliant to an industry standard, because otherwise why not just create plain HTML output and maybe zip it? Oh, maybe because you have to be HTML compliant if you want browsers and other HTML software to work properly. One might question the value of standards in general, so please go ahead and specify your own binary data format which nobody then will be able to read.

Especially in the context of the future of the web, we can't afford to repeat the mess of the past with browser-specific HTML rendering, which hurts us badly with all kinds of incompatibilities up to the present day.

[odedta]

I disagree with what kovid said about validation being a waste of time and I agree with skreutzer. None-conformance to standards is what got us in this mess in the first place, each reader requires it's own quirks.
I am all for validating any document you make, sticking to standards when writing code is more than good practice, it's crucial.

On the subject matter: I create an ePub 3 with <u> tags and it passed validation with no errors. View attached.

[skreutzer]

Your file is EPUB3 and <u> is valid according HTML5, on which EPUB3 is based upon. Calibre doesn't support EPUB3 (yet?).

[Jellby]

The "correct" way to add underline is probably just <em> or <em class="whatever">, as underline is very likely added for emphasis.

If the only way to emphasize in a book is with underlines, use <em> and set:

em {
font-style: normal;
text-decoration: underline;
}

If underlines cohabit with italics, bold, colors, etc. use <em class="whatever">.

[odedta]

Originally Posted by skreutzer

Your file is EPUB3 and <u> is valid according HTML5, on which EPUB3 is based upon. Calibre doesn't support EPUB3 (yet?).

It doesn't support ePub3? :P

Anyhow, he has all the answers he can hope for

[skreutzer]

I don't think that Calibre necessarily needs EPUB3 support, because besides some additional features (like footnotes), EPUB3 is primarily for multimedia and interaction (JavaScript), so an editor would look more like a programming IDE combined with an animation program rather than a book management tool.

[Toxaris]

Originally Posted by odedta

I disagree with what kovid said about validation being a waste of time and I agree with skreutzer. None-conformance to standards is what got us in this mess in the first place, each reader requires it's own quirks.
I am all for validating any document you make, sticking to standards when writing code is more than good practice, it's crucial.

On the subject matter: I create an ePub 3 with <u> tags and it passed validation with no errors. View attached.

The problem is, that even if the validation is green, it is saying nothing. It can still be a broken. It checks several things, but not if the ePUB will work. The real issue is that all readers (and applications) have their own interpretation of the specifications and that the specifications give room for interpretation.

Sticking to the specifications and standards is always a good idea, but the validation will not help you with that.

[DiapDealer]

Originally Posted by Toxaris

Sticking to the specifications and standards is always a good idea, but the validation will not help you with that.

And there's the rub. The specs (ePub 2) are about as wishy-washy about as you can get, with regard to what a compliant reading system "may" do and still remain compliant. Epub3 is not worded much better. How can you effectively "validate" what is left far too open-to-interpretation by the specs themselves?

[odedta]

I'd like to see some example of a validated ePub3 that doesn't work on an ePub3 reader. Not that I don't believe you, I want to learn.

[skreutzer]

Well, but you guys are missing one important point here: the standard specifications are for machine readability, a check for formal correctness. They too define how a device manufacturer should render the defined constructs, but of course they can't force them to react on constructs according to the standard, they can't provide implementations for every combination of constructs, and they even leave some decisions up to the implementor (such as footnote rendering in EPUB3), which is perfectly fine. There is other reading software than the renderer software in e-reading devices, such as webservers and processing tools, which might have a completely different rendering or no rendering at all, and as devices change over time, the standard definition serves as common protocol about how information should be encoded, so that software and devices of the future might access the encoded information in the best possible way.

@odedta:
There are many features of EPUB3 which aren't supported by even one single implementation, and it will stay this way for a while, because EPUB3 is far ahead of its time, while at the same time it is closely connected what's happening with HTML5 in the browser area, so it somehow tracks the progress made in modern web technology.