Why put deprecated element <u> on toolbar?

[eschwartz]

Originally Posted by skreutzer

Just think about this issue as follows: EPUB gets processed with XML tools. XML tools use XML schema validation. The validation fails for an invalid EPUB input file. What are web services supposed to do in such a case? The initial post about <u> invalidity didn't mention if this issue was raised by a web service or processing tool or if the user just did a validation voluntarily, but at least he posted the issue and asked for a solution. Can he solve it in Calibre? Manually or automatically?

And the <u> tag will pass xml validation.

Granted, it may fail xhtml validation....

Yes, it can be solved in calibre. regex it out. Or convert it with calibre and create beautifully conformant xhtml.

Regardless, it is more important to sell a working book than to comform to the standards. Change must start with the distributors who enforce noncompliant ebooks.

[skreutzer]

So you're suggesting to divert from standards and to increase incompatibility for no benefit at all (quite the opposite), just that some EPUB editors can stay with their invalid output or introduce even more errors and incompatibility?

[eschwartz]

Originally Posted by skreutzer

So you're suggesting to divert from standards and to increase incompatibility for no benefit at all (quite the opposite), just that some EPUB editors can stay with their invalid output or introduce even more errors and incompatibility?

No, I am suggesting you should speak to Apple and Kobo and B&N but in the meantime producers of ebooks should ignore the specs if that's what it takes to create a working book. It was, in fact, an irrelevant comment, at least as much as your comment about xml processing workflows.

[skreutzer]

Replacing <u> with a CSS class won't break a book. <u> might break a book or might have no effect or might have a different effect than underlining or might underline. Why should I speak to Apple, Kobo and B&N? I don't use Calibre, my EPUBs are valid. At least Apple was involved in the EPUB3 specification process, so they probably won't violate the standard they've helped to develop in order to create a common protocol for e-book interchange and consumption.

[DoctorOhh]

Originally Posted by skreutzer

The validation fails for an invalid EPUB input file. What are web services supposed to do in such a case? The initial post about <u> invalidity didn't mention if this issue was raised by a web service or processing tool or if the user just did a validation voluntarily, but at least he posted the issue and asked for a solution. Can he solve it in Calibre? Manually or automatically?

Calibre is not a publishing platform. It is a end user tool for cleaning up a book for personal use. Folks requested the ability to insert the various tags <b>, <i>, <u> etc... directly into the text and it was granted. The functionality of the book is not hindered by doing this.

If I were to do an epub to epub conversion after inserting these tags I am relatively sure that most of the inline tags would be moved to css.

[DaleDe]

Originally Posted by eschwartz

@skreutzer calibre is actually quite good about xml, it will only convert books into strictly xhtml-compliant code. So since the problem with the <u> tag has nothing to do with conformance to xml, but s rather an html and by extension an html-as-it-relates-to-xhtml problem, can we stop dragging xml workflow into it? Even though it is a cause you care about?


I never claimed <u> is a valid part of the epub spec. I simply said it has nothing to do with the xml aspect of it.

This is exactly why in real life <u> works for ebooks.

You are correct that <u> is not in any way related to xml. In XML you can define the meaning of any tag to be anything you wish, so long at the structure rules are maintain and you have a definition table available to interpret the meaning. XML is a very generalized specification of which xhtml is one specific implementation and is the one chosen by ePub.

Dale

[Toxaris]

Originally Posted by skreutzer

At least Apple was involved in the EPUB3 specification process, so they probably won't violate the standard they've helped to develop in order to create a common protocol for e-book interchange and consumption.

Unfortunatly Apple was involved... That is one of the reasons why we have crappy ePUB3 specifications with a lot of loopholes and Javascript possibilities. They focussed on those kind of things and audio/video instead of solving the real issues with the ePUB2 specs.
And you are mistaken. Apple is one of the biggest specification violators with their iBooks program. Not only for ePUB2, but also for ePUB3.

[Toxaris]

Originally Posted by skreutzer

@Toxaris:
What is your impression, are those integration problems caused by proprietary applications and their questionable data formats or by the lack of tools that would translate and interact between XML formats if it were in XML? At least for publishing, there are huge advantages in XML-based workflows, and it is widely used in various ways. What kind of formats are increasing in application integration, binary ones with corresponding APIs to access them?

Binary with corresponding API's? We are not in the 90's anymore... Although certain SaaS vendors think a little different about that. The problem with XML is not the tools. They work fine. However, XML is bloated and slow compared to other formats. For a few messages that is not a big issue, but for a large number of messages it really counts. The fact that is widely used has nothing to do with the fact that it is a perfect format, but just that sometimes it is the best of the rest.
You are really too much focussed on 'proprietary applications and their questionable dataformats'. These are not the 90's anymore. Applications that really matter all support open formats besides some closed ones.
I am just saying that there are more efficient formats and they are gaining ground fast. One of those formats is JSON. Not always the best, but then again the best format for the job at hand needs to be chosen.

Now, lets get back on topic.

[arspr]

Originally Posted by skreutzer

@eschwartz:
I frequently run into people who have problems with Calibre EPUB files (with reading them or using them for online services), and a portion of those problems are due to the lack of standard conformance, which is absolutely avoidable, but forces users to fix those errors while they usually don't know how.

Hey guys. I'm not a coding expert so I'm not going to speak about breaking or not the 4.5.6.1 rule of the ePub 2.56 spec or whatever.

But I think I can give you an advice. You are trying to convince Kovid about changing his freely given software. Why the hell don't you post any of those conflict examples rather than just saying "you don't know what you are doing"?

In my veeeeery little experience with Calibre I haven't found any single compatibility issue, so for the time being I really cannot blame Kovid about any of his "non-compliant" decisions.

[Alexander Turcic]

Moderator Notice
Everything has been said to answer the OP's original question. Thread cleaned up and closed.

Alexander