[rogue_ronin]

Originally Posted by AlexBell

I absolutely definitely could not disagree more. Or to put it another way I think the statement above totally incorrect.

I think we might actually be somewhat in agreement. By "bad" XHTML, I meant "vague and lazy", not "incorrect". <span...> is, of course, perfectly correct and to spec. I should have been less vague and lazy.

My argument is that <em> and <strong> are both valid XHTML, and are "direct" and easily comprehensible -- unlike a lot of the <span...> tags containing redundant and difficult to understand styles that are exported by programs like Word.

Originally Posted by AlexBell

ePub is based on XHTML version 1.1 - it's right there in the specs. How can one expect to get consistent presentations if one does not live up to the basic fundamental standards of XHTML?

I know there are fudges and work arounds, and I know that they work sometimes. But in my opinion the first step in getting ePubs to appear consistently well in a range of readers is to get the original XHTML to meet standards.

True. And the second step is for the readers to display it correctly.

Originally Posted by AlexBell

But let's start from the basics. In my opinion the basic tool for writing a good, consistent ePub book is a good HTML editor and to get that XHTML to meet W3C standards.

Yup. I believe that we get most of the junk because of the natural desire to find a shortcut. Quick conversions, or rough unedited exports lead to this ugly stuff. 'Course, you're starting see it in pbooks too, due to cost-cutting and profit maximization, but the expectations still remain higher, at least for now.

Originally Posted by AlexBell

Finally, and a little off topic, for website designers CSS is your friend, and external CSS is your best friend. It is dead simple to remove the empty line between paragraphs with CSS, set it once, and do it consistently.

That's where I'm coming from; a well-tagged document and a clearly commented CSS ought to be our reality, not our dream. As you say, "set it once" -- in other words, it actually improves editing and layout by eliminating the possibility of missing something (assuming good structural tagging.)

Originally Posted by swr2408018

I see some value in both perspectives here. Certainly Word (for example), generates css and html with a lot of boilerplate code. For purposes of conversion to ePub, one could eliminate most of that. And if you are trying to edit the raw code, it is arguably simpler to use the deprecated tags, and the result is much clearer at the local code level. However, if an ePub document uses well-chosen CSS boilerplate, it becomes much easier to globally modify important settings across the scope of the entire book. I think this is the direction we'd like the industry to take (and the direction we should take in authoring ePub books ourselves.)

I sort-of agree with you about the deprecated tags, but what tags are we discussing? Italic, bold, center, justify and left? Color?

The replacement tags can be as simple as adding <em>, <strong>, class="center", and class="justify".

It's similar for images. Basic, (very basic) layout is not terrifically more complicated than it was -- I'd like to see us help folks understand it, and for folks to not be shy to ask about it.

(Money at my mouth: feel free to PM me with any questions about this stuff -- I'm no expert, but the basics are not too hard. I was intimidated when I started, too.)

Originally Posted by swr2408018

(...snip...)

For these features to be easily configured by a savvy reader, they need to be set in a standardized way in the CSS code so that we can quickly unpackage, tweak, and repackage an ePub (assuming this is not DRM-blocked.)

(...snip...)

This would be great -- it's basically an XHTML microformat for the ebook (like FB2 is for XML). The side effect is that it doesn't merely affect ePubs, it becomes the root format for conversion to any other format.

I actually put a bunch of work into such a set of standards for my own formatting. It's highly unlikely that anyone else will ever use it, but it does make changing the display ridiculously easy.

What this means, though, is that you are creating an archive format -- the one source that you use when you convert for the limitations of your reading device. Consider Calibre; Calibre is an awesome tool that can make your life simpler and keep you happy -- but the ePubs that it creates, even from a well-tagged XHTML source, are not easily editable and comprehensible. It does what it does for good reason (flow sizes, automation, etc.) and it makes good-enough ebooks.

If there were an industry-wide set of CSS and XHTML standards, I bet that Calibre (or other tools) would ultimately try to abide by it. And manually changing ePubs would be less challenging.

Originally Posted by swr2408018

This raises two questions:

(...snip...)

CSS has always had a sort of override: CSS is trumped by a <style> header, a <style> header is trumped by directly applied styles, and directly applied styles are trumped by display engine personal settings.

It's just a matter of the software/readers behaving to standards.

Originally Posted by Elfwreck

EPubs look different for the same reason that websites look different: no two people, companies, or programs assigns HTML the same way.

And we're at the equivalent of 1998 for ePubs.

(...snip...)

We're seeing the equivalent with epubs. No standards, lots of tags but no control over the browsers, many companies insisting "you should read our books on our software & hardware, and if it sucks on other devices, you're reading it wrong."

100% in agreement. It's actually the natural order of things -- everybody is grabbing what they can, and not looking to either history or a future ideal. Or rather, they may be doing that, but not looking for the lessons and ideals that we are -- ie: transparent and easily customizable formats, beauty, etc.

m a r