Quote:
Originally Posted by Hitch
Well, we all know that you would be one seriously tough taskmaster, Wolfie. I doubt that there is anyone alive on this forum who wouldn't know that. :-)
Hitch
|
What I think makes for good eBook code is simplicity. Just use as little code as possible and do it such that you don't have a huge CSS. I've seen the mess some publishes produce and when I get done, it's like it was made by someone else. The other day, I used Calibre to remove unused CSS code and 74 entries were removed. Also, I can take an ePub some publisher made and reduce the size very easily. If it has embedded fonts, subset them. losslessly compress images and sometimes compress again because the compression is too high and you won't notice the difference. Then there is removing the useless files like an internal ToC for an ePub 2. Also, making an ePub 3 the way it's being done also adds bulk because of the excess code that is not needed for an ePub 2.
Good code means less potential problems with programs/apps and/or Readers. I've read of people having problems with some Readers because of some eBook. That's because the code inside is either a mess and/or it's not valid. I've never had an issue like that because I make sure the code is valid. It takes very little time to validate.
One thing I don't get is why most eBooks are made with most paragraphs being like <p class="tx"> when you don't need that class because you can easily define the p class for the most common use?
Also, who decided that using up at least 14% of the screen for a chapter title is a good idea? I could go on, but you get it so I'll stop here for now.