Quote:
Originally Posted by DiapDealer
But only because you can't really read, edit, sell or share imaginary epubs built to a "better" spec. 
Face it: the current ePub spec is largely ignored whenever it suits specific vendors of devices/apps that must read the ePubs. That wouldn't change with your new utopian ePub spec. So what's the point of building (or even imagining) a better--more concise-- imaginary ePub spec that would be adhered to (or supported/implemented in toto) by almost no one?
Don't get me wrong ... idealism can be fun. There's nothing wrong with dreaming about what could be. It's just that most of us here (with intimate knowledge of how ePub works-- practically--on a range of devices/apps) have already gone through that idealistic phase long ago ... and had it crushed out of us by reality. |
I think that the people who care about quality ePUBs are already making them. Those that don't--those that simply want to churn as many ePUBs and MOBIs as possible through, in the shortest amount of time possible, for the highest profit margin, don't and won't. 99% of all readers
certainly don't care if a TOC has a spanned paragraph entry versus a header class; they want the content, not the code behind the content.
There already
are ePUB specifications, and there already are "good" HTML coding versus "bad" HTML coding specifications. Anyone who wants to make a higher-quality ePUB can do so--certainly, no one is stopping them. Anyone who wants to can code "perfect" ePUBs or ePUBs that meet their own "should" criteria...{shrug}. When it comes to many of the original "shoulds," as I said some posts ago, everyone's going to have their own view on that, as there are, again, multiple roads to Damascus. While structural issues have more basis in "should," (so as not to confuse what something is versus what it looks like), all the rest is driven by how someone learns; what they like, versus what they don't; what program they're using (someone using INDD with an export plug-in is going to be far, far likelier to use spans for stylistic choices than someone using Sigil, for example), and the like.
{shrug}. And what's the point of a set of "rules" or "shoulds" when it's likely that the books we make will have to be altered to work on retail devices, anyway? As we discussed some posts back, as merely one example, all those extra spans in an ePUB for iBooks are to make centering and other aspects work, for the first-gen iPad. For a 1st-Gen iPad, you still can't float images and text at the top of a screen without the text overwriting the images, and Apple can't be bothered to issue a fix, because they have a positive animus about supporting older tech. Like I said, don't mean to sound like a buzz-kill...all these woulda's and shoulda's...but it's a bit difficult when nobody else is playing along, particularly the Elephants.
Just my $.02. Again.
Hitch