Adequacy of EPUB?

[Hitch]

Originally Posted by Sarmat89

It is—if HTML cannot provide semantic markup, users cannot customize it. Also, this way of thought is ridiculous—should we also not to have a customizable typeface, body text alignment and color schemes, because the publisher has already decided on them for us?

As for the format, we already have the tools we need: XML (not the obsolete (X)HTML, 5 or not), CSS and OPC to bring it all together. What we do not have, is the will coming from EBook consumers, not some 'open' 'standards' committee.

I started to write a response to this, but...I absolutely don't understand the gist here. I think that the OP thinks that simply because you can NAME an element in HTML, something like ARTICLE, that's somehow "better" than having "p.article" and p class="article" (respectively) in CSS and HTML.

The point here completely eludes me. For XML, 99% of the time, you have to transform it with XSL, etc., into XHTML, in the first place. So...what's the advantage? Exactly?

P.S.: @eschwartz: yeah, I'm with you on this one. I think the real problem is a lack of usage; but I'm always open to new ideas, if a better format can be created, sold, bought, and implemented.

Hitch

[eschwartz]

Originally Posted by Hitch

I started to write a response to this, but...I absolutely don't understand the gist here. I think that the OP thinks that simply because you can NAME an element in HTML, something like ARTICLE, that's somehow "better" than having "p.article" and p class="article" (respectively) in CSS and HTML.

It *is* true that a named element is more standardized than an arbitrary id.
But I doubt both the need and the practical adoption of it.

The point here completely eludes me. For XML, 99% of the time, you have to transform it with XSL, etc., into XHTML, in the first place. So...what's the advantage? Exactly?

I dunno, XML is cooler I guess? Saying XHTML and HTML5 is obsolete already tells me that that this whole thread is just a lot of navel gazing.

P.S.: @eschwartz: yeah, I'm with you on this one. I think the real problem is a lack of usage; but I'm always open to new ideas, if a better format can be created, sold, bought, and implemented.

Hitch

[JSWolf]

For most books ePub 2 is just fine. But we would be better off with ePub 4. ePub 4 would be ePub 2 done right without using the crap from ePub 3. ePub 4 would be what ePub 2 should have been from day 1. And no multimedia. No extra junk in the OPF or XHTML that we do not need. Take a look at the ePub 3 a lot of publshers are making today. If I convert one of them back to ePub 2, I remove a bunch of excess code that's not needed and doesn't actually do anything for anyone.

[eschwartz]

Originally Posted by JSWolf

For most books ePub 2 is just fine. But we would be better off with ePub 4. ePub 4 would be ePub 2 done right without using the crap from ePub 3. ePub 4 would be what ePub 2 should have been from day 1. And no multimedia. No extra junk in the OPF or XHTML that we do not need. Take a look at the ePub 3 a lot of publshers are making today. If I convert one of them back to ePub 2, I remove a bunch of excess code that's not needed and doesn't actually do anything for anyone.

What makes you think EPUB 4 would be a return to sanity, rather than adding even more multimedia and "extra junk"?

[JSWolf]

Originally Posted by eschwartz

What makes you think EPUB 4 would be a return to sanity, rather than adding even more multimedia and "extra junk"?

Because all the stuff needed to make ePub 4 would be done by sane people instead of the insane committee that created ePub 3. Well, maybe not fully sane people, but sane enough when it comes to eBook features. And no company such as Apple will be allowed to submit suggestions or bribe anyone. And finally, no features would be added that would not work on an eInk Reader that was of a certain specification. So that would remove audio and video for sure.

[eschwartz]

Originally Posted by JSWolf

Because all the stuff needed to make ePub 4 would be done by sane people instead of the insane committee that created ePub 3. Well, maybe not fully sane people, but sane enough when it comes to eBook features. And no company such as Apple will be allowed to submit suggestions or bribe anyone. And finally, no features would be added that would not work on an eInk Reader that was of a certain specification. So that would remove audio and video for sure.

Who says the EPUB 4 committee would be a new group of people? And what makes you think Apple will be stopped?

Now, I think I would like it if your suggestion came true, but there is a difference between wanting something and expecting it will come to pass.

[JSWolf]

Originally Posted by eschwartz

Who says the EPUB 4 committee would be a new group of people? And what makes you think Apple will be stopped?

Apple will be stopped because the new committee will ignore Apple. Yes, it will be a new group of people who are sane when it comes to making eBooks.

We can make the committee from MR users. There are enough here that I would trust not to add in stupid stuff that we could easily get a new specification out and call it ePub 4.

[Turtle91]

Originally Posted by JSWolf

...And finally, no features would be added that would not work on an eInk Reader that was of a certain specification. So that would remove audio and video for sure.

That would cut out a great deal of useful features. How about pushing eInk to catch up and support those features instead of hampering progress?? I don't doubt that you think a lot of those features are unnecessary, but that doesn't mean no one wants to use them. I mean, really, how often is strikethrough used in a book... But it would really suck to have to figure out how to create that feature when you REALLY need it to tell the story.

Don't throw the baby out with the bath water...

[JSWolf]

Originally Posted by Turtle91

That would cut out a great deal of useful features. How about pushing eInk to catch up and support those features instead of hampering progress?? I don't doubt that you think a lot of those features are unnecessary, but that doesn't mean no one wants to use them. I mean, really, how often is strikethrough used in a book... But it would really suck to have to figure out how to create that feature when you REALLY need it to tell the story.

Don't throw the baby out with the bath water...

Strikethough would not be an issue on an eInk Reader. So it could stay or be added in. It's silly features that go. One silly feature if the <section> thing in ePub 3. It's not needed at all. It's just excess code that does nothing that the OPF's guide doesn't do. The NAV ToC does nothing useful. The NCX ToC is all that's needed 99.9% of the time and for those rare cases, an inline ToC can be made. some of the new stuff in the metadata of the OPF is excessive and poorly thought out as to the formatting. They changed some of the metadata to be more complex with no benefit at all.

Let's work on useful features for READING. eInk handles that just no problem. Also, standardizing on features of the Reading software would be good as well. So all devices using the same software would all work the same. We could eliminate pet peeves that way. For example, margins. Make it so there are no margins for most of the eBooks except for what's wanted to be offset and the reading software would allow the user to set the margins how it's wanted. make the default fonts with a full extended character set for most cases. There's lots of little things that could be done to make things better overall.

[eschwartz]

I just want a decent Dublin Core metadata specification...

[dickloraine]

Some standard classes for book specific tasks could be useful. Like the mentioned poems, drop caps could be nice, letter, heck we could even get as far as making dialogue semantic. Readers then could define, how they wanted to style these elements. But, even if these were there, I fear they wouldn't be used or used wrong or inconsistent. Like it is now with the existing tags.

[Sarmat89]

Originally Posted by Hitch

because you can NAME an element in HTML, something like ARTICLE, that's somehow "better" than having "p.article" and p class="article" (respectively) in CSS and HTML.

It is obviously better, as it is more clear this way than generic divs/paragraphs with arbitrary classes assigned.

Originally Posted by eschwartz

Saying XHTML and HTML5 is obsolete already tells me that that this whole thread is just a lot of navel gazing.

Once again, (X)HTML was designed for computer manuals, not books. Take any book and tell me what elements have its semantic representation in HTML: Title page/Title -- none, Dedication -- none, Epigraph -- none, chapter titles -- none again, 'letters' -- none! Everything has to be imitated with the direct formatting!

Originally Posted by Turtle91

I mean, really, how often is strikethrough used in a book...

I can recall two books which used it for in-universe text correction.

[eschwartz]

Originally Posted by Sarmat89

It is obviously better, as it is more clear this way than generic divs/paragraphs with arbitrary classes assigned.

But surely using a standardized class is just as good.

So what is really needed is publisher consensus. Or at the absolute worst, an extension to XHTML.

Once again, (X)HTML was designed for computer manuals, not books.

Oh no, whatever shall we do -- Wikipedia is wrong!
https://en.wikipedia.org/wiki/XHTML#Motivation

XHTML is HTML defined as a strictly XML-compliant form, which means it will error out on malformed XML.
It's useful for programmatic parsing, not for specific genres of ebooks.

Take any book and tell me what elements have its semantic representation in HTML: Title page/Title -- none, Dedication -- none, Epigraph -- none, chapter titles -- none again, 'letters' -- none! Everything has to be imitated with the direct formatting!

I don't consider "direct formatting" to be a flaw.

TItle pages, dedications, epigraphs, chapters are all documents, they are separate XHTML pages.
And the EPUB manifest recognizes "type" semantics declared in the <guide>. Like the ones calibre's editor knows how to place, including "title-page", "toc", "index", "glossary", "acknowledgements", "bibliography", "colophon", "copyright-page", "dedication", "epigraph", "foreword", "loi", "lot", "notes, "preface", and "text".

[Hitch]

Originally Posted by Sarmat89

It is obviously better, as it is more clear this way than generic divs/paragraphs with arbitrary classes assigned.
Once again, (X)HTML was designed for computer manuals, not books. Take any book and tell me what elements have its semantic representation in HTML: Title page/Title -- none, Dedication -- none, Epigraph -- none, chapter titles -- none again, 'letters' -- none! Everything has to be imitated with the direct formatting!
I can recall two books which used it for in-universe text correction.

I wrote a big long response to this, and eschwartz' response, and realized that this is a honking waste of time.

Sarmat89: how many ePUBs have you built? I'm not snarking, I'm asking so that I can try to understand your frame of reference. And how many XML-->XSLT to eBook transformations have you done?

Hitch

[eschwartz]

Originally Posted by Hitch

I wrote a big long response to this, and eschwartz' response, and realized that this is a honking waste of time.

Probably.