Why put deprecated element <u> on toolbar?

[JLius]

I use the calibre editor to clean up my epubs.

In my last epub I used the toolbar a lot, especially the underline element <u>. Little did I know that this element is deprecated and gives you an error when validation your epub.

Why are there deprecated elements on the toolbar?

[kovidgoyal]

Because whatever nincompoops deprecated it for HTML 4 were overridden and it is no longer deprecated for HTML 5.

[JLius]

Thank you for your answer.

But I get an error message when I validate my epub. All my instances of

<p><u>some tekst</u></p>

get this error.
So you're saying the validation is incorrect and I should just ignore it?

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")

Definition and Usage
The <u> tag represents some text that should be stylistically different from normal text, such as misspelled words or proper nouns in Chinese.

--------------------------------------------------------------------------------

Tips and Notes

Tip: Avoid using the <u> element where it could be confused for a hyperlink.

Note: The HTML 5 specification reminds developers that other elements are almost always more appropriate than <u>.

--------------------------------------------------------------------------------

Differences Between HTML 4.01 and HTML5

The <u> element was deprecated in HTML 4.01. (the <u> element was used to define underlined text).

The <u> element is redefined in HTML5, to represent text that should be stylistically different from normal text, such as misspelled words or proper nouns in Chinese.

[kovidgoyal]

Yes. epub validation is an entirely pointless waste of time.

[Toxaris]

Originally Posted by kovidgoyal

Because whatever nincompoops deprecated it for HTML 4 were overridden and it is no longer deprecated for HTML 5.

True, but in ePUB2 it is still not allowed according to the specs. There might therefore be readers that will ignore it.

[Toxaris]

Originally Posted by kovidgoyal

Yes. epub validation is an entirely pointless waste of time.

I think it has some value, but definitely not the value that most people or websites think. It can help you to find issues though if things don't work.

[kovidgoyal]

Originally Posted by Toxaris

True, but in ePUB2 it is still not allowed according to the specs. There might therefore be readers that will ignore it.

No, there wont. No one in their right mind will ever create a reader that ignores widely used HTML constructs just to comply with a spec, and that too an obsolete spec.

[kovidgoyal]

Originally Posted by Toxaris

I think it has some value, but definitely not the value that most people or websites think. It can help you to find issues though if things don't work.

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.

[JLius]

Allright, thank you! I'll just leave the <u>'s where they are then.

[Toxaris]

Originally Posted by kovidgoyal

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.

I totally agree with that!

[skreutzer]

Well, as far as I've heard, Calibre doesn't support EPUB3 creation (yet?), so you're limited to XHTML 1.1 of EPUB2. Even if Calibre supports EPUB3 in the future, if you don't disable EPUB2 creation, you have to comply with XHTML 1.1 of EPUB2.

I find your position quite scary, because there's more software that works with EPUB files than just e-reading devices, and you deliberately break them by producing invalid EPUB files. So I don't wonder anymore why users of Calibre frequently run into problems when they try to use their Calibre files in serious processing software or services.

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.

I don't know if EPUB validation is usually done with DTD or XML Schema validation, but the latter is standard for all kinds of XML formats, and therefore will be (if it isn't already) used to validate EPUBs too, so you'll never escape checks for EPUB standard compatibility on files Calibre produces. Regarding your explanation, it seems you want to check for all kinds of more complex errors, but introduce simple errors yourself.

[kovidgoyal]

Originally Posted by skreutzer

I find your position quite scary, because there's more software that works with EPUB files than just e-reading devices, and you deliberately break them by producing invalid EPUB files. So I don't wonder anymore why users of Calibre frequently run into problems when they try to use their Calibre files in serious processing software or services.

You haven't the faintest clue what you are talking about.

[skreutzer]

So you object to the claim that there is other software for processing EPUB than e-reading devices?

[kovidgoyal]

Really? You picked the most obviously true fragment of your post to ask me if I object to it? I doubt that kind of rhetorical trick will work on anyone other than a politician.

Dig deep, you can do better than that.

[skreutzer]

Sorry, I'm not a native English speaker, so I don't get what your impression is from the words I've wrote. But as far as I understand, you seem to acknowledge that there are many uses for EPUB files. So I can't imagine why it shouldn't be a good concept to validate EPUB input files before further processing in order to make sure that the code doesn't run into unexpected constructs or even non-well-formed XML. It's actually quite common for all kinds of XML applications with standardized or custom XML Schema format specifications, because XML validation can be done off-the-shelf with programming libraries and it clearly points to the various errors in a XML input file, which need to be fixed anyway in order to produce quality output that can be used as input for other applications in the future.

Edit: I really want to encourage everybody to get familiar with the process behind EPUB standardization, see “Introducing ePUB3” by Bill McCoy and “EPUB3: Not Your Father's EPUB” by Bill Kasdorf if you haven't already.