What great secret do you share with them that the rest of us aren't privy to?
No great secret: I've shared them here ad nausea for the last couple years. People just don't listen. 1) One can talk all one wants about HTML and how it is *supposed* to render but one needs to understand instead how it *does* render on different devices, especially the small devices such as EPUB devices and MOBIs. Also, if one actually reads the HTML specs carefully one finds out that basically no rendering device is ever under any obligation to render HTML the way you think you've specified. CSS is basically *hints* not page layout "demands". This is especially true of the EPUB spec. And Mobi/Kindle? -- the only "spec" is basically the actual behavior of this or that Kindle device. 2) If in the HTML one chooses to horizontally stack elements, then that is not going to work on small devices, which physically only have the space to attractively display ONE element horizontally at a time. Vertically stacking elements basically works on all devices. Examples of horizontally stacked elements: i) text, ii) images, iii) page numbers, iv) left margin, v) right margin. On a small device: Choose One. Because that is all that fits. 3) It is much easier for people who want to have margins, or who want to "throw away" excess horizontal real estate they have on their display to add those, than for people who don't have the real estate to come up with that real estate once you've thrown it away. 4) To whit, <body> specifications should never be made. 5) The process of creating books to read is one that has developed slowly over the course of the last 400+ years. If you want your readers to believe they are "reading a book" you need to respect that tradition and follow it closely. If you do not follow that 400+ years of tradition then the reader *will not* "suspend disbelief" and accept that they are in fact "reading a book." Inventing your own system of typography is very probably a very bad idea -- even if K&R started it. 6) Read some books on typography. The DeVine series from the turn of the century (free on Google Books) are really good. The formatting of books is not "arbitrary." It follows in a 400+ year tradition. 7) Characters, "glyph points" or code points in Unicode, have meaning. Try to follow that established meaning. Don't invent your own meanings for existing code points. Doing so will cause breakage. 8) Sentences have meaning. If it was a sentence in the original book, it should be a sentence in this book. 9) Paragraphs have meaning. Traditionally there are three ways to format a paragraph, from "cheapest" -- using up the least amount of paper, to "classiest" -- using more paper but much easier to read, and which traditionally was used in the highest quality printings, such as first editions. Since there is no paper cost to creating e-books, it behooves us to use the "classiest" method, which surprise surprise, is the same method that Michael Hart recommended. (Strange how that works) Cheapest Method to "Classiest" Method a) No indent at start of paragraph, no spacing between paragraphs, "notch" the right end of the last line of the paragraph. b) Notch, i.e. indent the start of the paragraph, no spacing between paragraphs, allow the last line of the paragraph to run ragged. c) Do not notch but put a 1em vertical spacing between paragraphs, last sentence runs ragged. This is basically the same paragraph formatting which is used on the PG txt70, so if you do c) then you have the advantage of following what has been PG "style" for quite some while. This style also has the practical advantage of being the easiest to work with, and to read! Things which look stupid (at least if you have some background in typography) e) Notching AND putting a space between paragraphs (a common error) f) And/or putting 2em of spacing between paragraphs. Which you may be doing without realizing it. === 10) Don't try to specify font families. It really doesn't work. If you think it works you need to read #10 again. 11) Try to follow the meaning of HTML tags. If you use <p> tags on something which is not a paragraph, that is probably a mistake. 12) Illuminated letters don't work. If you try to do them you will break many reader's experiences. If you insist on retaining them, do so as images, not by trying to do "letter placement" on them. See "Float doesn't work." 13) Drop caps don't work. Don't do it. 14) Colored lettering, grey lettering, etc, doesn't work. Don't do it. 15) "Literalism" -- trying to literally recreate the layout of the original text using HTML doesn't work. Don't be literal. 16) Poems: There is lots of great advice on how to format poetry in various places on the internet. That advice doesn't work. Suggest at this point in time try something simple such as indent plus <br> to terminate individual lines of the poem. The poem won't wrap exactly correctly, but that is a softer failure mode than the other "really cool" suggestions one finds on the internet. 17) Background colorings don't work. 18) Try taking out your CSS and see if your coding is still attractive and 100% readable. If not, you are doing something wrong. 19) Common PG/DP methods of encoding page numbers in HTML don't work. Don't ask me how to do it "correctly" because I haven't seen anything yet which isn't "busted." 20) If you think it works, test it. When you test it, you will find out that contrary to what you have read "everywhere" it doesn't in fact work. 21) Behavior exhibited in *your* copy of IE, Moz, or Chrome, is NOT the behavior the end customer will experience in *their* copy of IE, Moz, Chrome, EPUB reader, MOBI reader, Android tab, etc. Test it on various devices, and if it doesn't work it is because *you* are doing something wrong, not because the *device* is doing something wrong. Do not blame the device, and do not blame the end reader. They are not under any obligation to read your effort. On the contrary you are under an obligation to make something worthy of their reading. If you don't believe this, no problem: don't do the work -- and they won't read it. 22) Measurements in terms of ems usually work except on very old copies of IE. Measurements in terms of % may work. Other units of measurements tend not to work, and a desire to use those units indicates you are doing something wrong. In particular measurements in units of pixels don't measure pixels, and measurements in units of points an picas do not measure those things. Specifying in absolute measurements inches or cm is a disaster. 23) Absolute placement doesn't work. 24) Floats don't work. 25) "Comment this out to make page numbers disappear" doesn't work. In fact, contrary to your expectations the page numbers will not only not disappear, but they will show up in unpleasant places. 26) Almost anything one can read about HTML in books or on the internet is destructive to one's ability to make good books. People who write on the subject, who on some level tend to know what they are talking about are: Elizabeth Castro ["Epub straight to the point", "Pigs Gourds, and Wikis"] Joshua Tallent, and Rufus Deuchler -- and even then one needs to look at what they are saying with a jaundiced eye. 27) Top and bottom margins may or may not merge depending on the device. If you want your work to look attractive and not ugly broken choose to use one or the other, not both. 28) Top and bottom margins may round to the closest 1em. Combining with 27) this means if you "split the baby" and set <p> top and bottom margins of 0.5em (of the equivalent in other units) you have just specified a really ugly 2.0em spacing between paragraphs on some devices. 29) Read the Amazon formatting suggestions. It should give you some feeling of what you are up against. http://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf If you can't write "correctly" against the limitations of a Kindle, then you are breaking on many other machines also. Not every EPUB device runs ADE. Not every PC runs Moz, IE, or Chrome. 30) If you don't care, then neither will the reader -- they will simply choose to read something else. 31) Page numbers really don't work on small devices, but, oh well. 32) The basic rule about rules: Rules don't work. Especially if you use decorative rules. [[Please understand that the rules we are talking about here are "horizontal rules"]] However, if the original book used rules you may feel some obligation to retain them. Please understand however, in traditional typography a rule is a publishing house's cheap substitute for spending more money on more paper by providing a real page break or a large <tb>. IE understand when and why you are propagating a "cheat" on the current reader *for no good reason.* Rules really don't work on many EPUB devices which will do something really ugly where you thought you were specifying a rule. 33) Old books of lower quality often use "printers art" -- the "clip art" of the day -- to gin up sales of shelf stuffers at Xmas time. Retaining that clip art may not actually represent a contribution. If the artwork *does* relate closely to the content of the book and/or if there is a credited illustrator, then its probably worth keeping the artwork. Most famously Hans Christian Anderson took a "clip art" and built one his most famous stories around it -- the "clip art" came first, the story came second. 33) Things which you put in HTML "as documentation" such as programmers comments and unused page anchors tend to get automagically thrown away by one or another automated tool before you even realize it. 34) Things which you slavishly retain, such as original line breaks, tend to quickly get discarded in the real world. 35) Right margins don't work. 36) Check your images on real devices particularly EPUB devices. I'm not sure what is going on, but commonly used image storage formats at DP/PG breaks horribly on many EPUB devices, leading to un-viewable images. 37) PG efforts are reprocessed, repackaged, and redistributed from dozens if not 100s of different sites, often without given PG any credit (but if are the creator of that PG book, you will certainly still recognize it.) These redistribution efforts are often *inferior* to the versions offered on PG's site. Why? Because these other sites cannot afford to take the time and effort to "fix" "broken" HTML CSS efforts by *One or Another* PG submitter. The end result is that they choose to throw away some or ALL of PG's formatting efforts -- because they cannot afford to track down and fix the individually broken submissions! Conclusion: "We" all live and die together. One person making bad CSS formatting choices drags down *everyone's* efforts leading to inferior copies of PG books being read "everywhere." 38) Literalism: Not all books fit well into the reflow mechanism implied by HTML and small devices. If your book really needs fixed layout, then don't bother trying to use HTML for your effort. Consider using PDF instead, for example. But what we really see is that people who don't know what they are doing submitting in PDF when HTML reflow would have worked perfectly well for their book, and other people trying to force their book into HTML when fixed-format PDF would have been a better choice for that book. 39) Justification: Choice thereof is best left to the end user. Do not override their freedom of choice. 40) Font sizes. Many devices DO NOT have an infinite variety of font sizes. Assuming that they do so will fail, often in an ugly manner. Relative sizing ie <small> <medium> <large> does tend to work -- most of the time. 41) Font choices: Most devices support four fonts: regular, italic, and bold, and a "teletype" font such as used in pre. The only reliable way to specify these fonts are no-tag, <i>, <b> and the "pre" family of tags. If you try to go beyond this set of assumptions your assumptions will fail in an ugly manner on many many devices. 42) Formats, including choice of HTML, EPUB, and MOBI "flavor" changes rapidly and if you think that you can just specify which flavor you want and that is all it takes then you are wrong because someone is going to want to reuse your effort in a different "flavor" and/or process through a tool which assumes a different flavor. If your coding depends on the "flavor of the month club" then your coding will soon be broken, if not already. 43) The actually implemented "Unicode" code points varies widely from device to device and from code release to code release. If you need a code point, use it. If you don't need it, then why use it? That "optional" code point is probably something the device manufacturer decided was "optional" also. 44) Tables often don't work. Links inside of tables often don't work. Tables of more than a few columns will probably fail. 45) Horizontal scrolling doesn't work. 46) Pre without wrap doesn't work. See #45. 47) Frames don't work. 48) Colors don't work. Take a look on an old monochrome device to see what you are doing to the reader. 49) CSS: Don't specify that which you don't need to specify. Many devices come with a perfectly well designed set of CSS choices which actually work on that machine, until you go out of your way to break them. 50) CSS: Don't do "CSS Resets." It doesn't work. See #49 above. 51) Don't use massive CSS "cookbooks." When something is found broken in your HTML then trying to track down what is broken within your massive CSS "cookbook" becomes prohibitive. Include in the CSS that which you actually use and need in this book. What else?