Adequacy of EPUB?

[dgatwood]

Originally Posted by eschwartz

I can already do that with custom CSS.

Are you saying you don't want authors to be allowed to define CSS?

I think that what the original poster was saying is that if you use CSS to format standardized semantic markup instead of formatting HTML whose semantics are defined only by arbitrary, author-defined classes, then it would be easier for book readers to define alternative styles that override the publisher design in a way that the individual reader prefers. And this is almost certainly true.

With that said, the same thing could also be achieved by convincing the EPUB standards folks to come up with a standard set of CSS classes that should be present in all books, and a standard set of rules for when and how readers can override CSS classes (both those and others). And IMO, the EPUB folks need to do that anyway; right now, it's the Wild West out there.

Originally Posted by eschwartz

I strongly disagree with your opinion that   is absurd.

I'm going to have to agree with the original poster on this one. A paragraph is a unit of text, so a paragraph that contains no text is not a paragraph, and shouldn't be marked up using a paragraph tag. At best, it should be a div, but really, vertical spacing should be handled with CSS instead.

[PeterT]

Just wondering how on earth you expect to force all creators to follow any proposed rules? People can't even follow advice on how to correctly use STYLES in Word documents??

[eschwartz]

Originally Posted by dgatwood

I think that what the original poster was saying is that if you use CSS to format standardized semantic markup instead of formatting HTML whose semantics are defined only by arbitrary, author-defined classes, then it would be easier for book readers to define alternative styles that override the publisher design in a way that the individual reader prefers. And this is almost certainly true.

With that said, the same thing could also be achieved by convincing the EPUB standards folks to come up with a standard set of CSS classes that should be present in all books, and a standard set of rules for when and how readers can override CSS classes (both those and others). And IMO, the EPUB folks need to do that anyway; right now, it's the Wild West out there.

And content creators need to be able to define the look with more granularity than is allowed by such a rigid XML spec.
So HTML is the best of both worlds unfortunately it relies on people not being utter fools.

I'm going to have to agree with the original poster on this one. A paragraph is a unit of text, so a paragraph that contains no text is not a paragraph, and shouldn't be marked up using a paragraph tag. At best, it should be a div, but really, vertical spacing should be handled with CSS instead.

I am going to have to disagree on whether you internalized the meaning of my post that you quoted.

Perhaps it would help if you didn't chop off the second half:

Originally Posted by eschwartz

I agree that there are some formatters that use it in the wrong way.

Well, to clarify, what you are saying is exactly the wrong way that I speak of.

But in theme with @Sarmat's suggestions so far, I believe he would rather outlaw the non-breaking-space character entirely.
Why, I don't know. How, I don't know that either. (XML only works with the Sarmat subset of unicode?)

Unless you can propose to me an alternative explanation of his statement, that would fix the non-breaking-space-as-a-paragraph issue, without outlawing the non-breaking-space.
Because, duh, content creators can write <para>&nbsp;</para> just as easily as <p>&nbsp;</p>
Unless that whole line of thought was an irrelevant tangent.

[Hitch]

Originally Posted by PeterT

Just wondering how on earth you expect to force all creators to follow any proposed rules? People can't even follow advice on how to correctly use STYLES in Word documents??

Amen, brother.

Only those of us who labor over OPB (Other People's Books) all day know just how absurd it is to think that people will actually obey ANY effing schema.

My take--after however many posts--is that Sarmat wants to tag every element in a book with XML. Period. NO styling. Then the reader (the person) can attach styling elements as s/he sees fit. Basically, books wouldn't look like books, in their "final" form; they'd look like big honking XML documents, and the device would then interpret the semantic markup into the layout preferred by the human reader. And here's my response to that idea:



There are so many issues with that that my head spins. What if the reader doesn't like the default layout that would have to be created by the device manufacturer? Does s/he then have to go into some other settings program, and muck around endlessly to figure out how to change it? Am I the only one that sees the hilarity in that? Sure, WE would all do it in a heartbeat, but Sally Reader? Bob Boyfriend? Gimme a damn break.

@eschwartz: even though I've certainly done it--we ALL have--the nbsp contained inside paragraph tags is definitely not kosher. Dag's point, I think, is that there really is no instance in which that specific usage is correct, because a paragraph, by definition, is intended to contain text--not a space. Sticking solely to the specifics, that would be correct.

Not that that actually adds weight to Sarmat's argument; the same people that format books now using the ubiquitous <p>&nbsp;</p> will do something similar in XML. After all, how hard is it to create a clip for <simpara>&nbsp;</simpara>? Same s**t, different day.

The OP, Sarmat, wants everything in XML, so that he can search on arcane information to his heart's content. To be able to do that, he wants to impose an extremely rigid form of XML on book creators. That all sounds great (not), but the bottom line is, as I said in my lengthy post on the topic: the millions of books created by folks uploading Word files won't conform to that. Given that that's a huge piece of the action, neither Amazon nor B&N nor anyone else will force them to change that. Moreover, that would require such a greater amount of knowledge to do right (using the "right" xml tags for everything) that it would put a massive dent in self-publishing. NOT to mention, the huge cost to convert all existing eBooks to meet the criteria.

Honestly, the whole thing is daft. It's pie in the sky, even if we all loved it. That's the irony of this thread. It doesn't matter if Sarmat convinces ALL of us that it's the best idea since sliced bread; he has to convince the DC folks, plus Amazon plus Barnes & Noble, plus Apple, plus...well, you get my drift. This is an even bigger exercise in futility than usual.

Hitch

[AnemicOak]

Originally Posted by PeterT

Just wondering how on earth you expect to force all creators to follow any proposed rules? People can't even follow advice on how to correctly use STYLES in Word documents??

[HarryT]

Sarmat, I've asked you this question before, but didn't get an answer, so I'm asking you again:

What do you want people who are creating ePub books today to do?

[Jellby]

The possibility of adding all kinds of specific metadata, does not prevent real ebooks to be published with something like:

<title>An Introduction to Silliness, by My Favourite Author (translated by Some Guy)</title>

... and nothing else, no author, no translator...

[BetterRed]

Originally Posted by AnemicOak

- folks can't even follow the rules of the road, even if they have a license that 'proves' they know what they are.

And AFAIK no-one ever died from overdosing on nbsp's or shy's

BR

[Sarmat89]

Originally Posted by HarryT

What do you want people who are creating ePub books today to do?

What a strange question: if you created LIT and MOBI books before the invention of EPUB, you can continue to create books in the new format too.

[Sarmat89]

Originally Posted by Jellby

The possibility of adding all kinds of specific metadata, does not prevent real ebooks to be published with something like:

<title>An Introduction to Silliness, by My Favourite Author (translated by Some Guy)</title>

... and nothing else, no author, no translator...

Such things are possible with simple EPUB editors like OO.o plugin or Sigil, with their ascetic UI.
If the metadata dialog follows the XML scheme and gives you nice form with "First Name", "Last Name" fields, with autocomplete and "look online", the possibility to have malformed metadata is much, much less.

[HarryT]

Originally Posted by Sarmat89

What a strange question: if you created LIT and MOBI books before the invention of EPUB, you can continue to create books in the new format too.

It's not a strange question at all. You seem to be dead set against ePub, but you've not actually made any practical suggestions. You're advocating a "better" format, but don't appear to have to done any work to create a specification for such a format yourself. Do you expect someone else to do it for you?

[Toxaris]

Originally Posted by Sarmat89

What a strange question: if you created LIT and MOBI books before the invention of EPUB, you can continue to create books in the new format too.

What a strange answer. The question is what do you expect that the people that are creating ePUB's must do? Of course they can adapt to a new format, but that is not the question. What do you expect US to do? We are using the format, not defining it. The PTB (Powers That Be) can change things. So, you need to take it up with IDPF and associates.

Originally Posted by Sarmat89

Such things are possible with simple EPUB editors like OO.o plugin or Sigil, with their ascetic UI.
If the metadata dialog follows the XML scheme and gives you nice form with "First Name", "Last Name" fields, with autocomplete and "look online", the possibility to have malformed metadata is much, much less.

Again, nothing holds you from using that. As you ignore it every time, let me tell you again a few things about metadata:
* The publishers do not care about most metadata, nor does the vast majority of the readers
* Lack of metadata values like 'First Name', etc, lies with the Dublin Core, not ePUB. Let me say it again: NOT ePUB
* Most reader applications or readers support only the core metadata, if at all! A lot just try to 'read' the metadata from the filename instead.
* For a good search program or library program it matters not if the name is split in a first name and last name. They can search and sort either way. Most names follow quite simple rules.


I really, really, don't get your issues. What you are proposing will never work. A book is a form of art and like all the art, the writer wants the last word on how it looks. Changing the fontsize is fine, but that is about it.

[eschwartz]

Originally Posted by Sarmat89

What a strange question: if you created LIT and MOBI books before the invention of EPUB, you can continue to create books in the new format too.

Toxaris


And what you are proposing is a format that makes it significantly harder for people to create books.

By creating styles, you can turn a decently-formatted DOCX into a decently-formatted EPUB. But adding dozens of new first-class elements is going to throw a few wrenches in that...
And many authors actually understand enough HTML to author a book properly. And since MOBI was based on HTML, moving to AZW3/EPUB was not a significant challenge.

Your proposed XML monstrosity on the other hand is orders of magnitude more complicated, and poses a serious barrier to entry.

[eschwartz]

Originally Posted by Sarmat89

Such things are possible with simple EPUB editors like OO.o plugin or Sigil, with their ascetic UI.
If the metadata dialog follows the XML scheme and gives you nice form with "First Name", "Last Name" fields, with autocomplete and "look online", the possibility to have malformed metadata is much, much less.

Now you've lost me. Or maybe I've lost it.



As you so wisely point out, we already have that right now.
And it still doesn't stop authors from putting absolute garbage in there. Even though the correct metadata fields are staring them in the face and waving little red and green flags.

Adding more metadata fields to the exact same, pre-existing UI is not going to make them use the new fields, any more than it will stop them from ignoring the old ones!

[JSWolf]

Originally Posted by HarryT

What do you want people who are creating ePub books today to do?

My answer would be to do it correctly and stop making the same mistakes over and over.