I have no problem formatting lists for PDF since I can control page breaks. But how does this work in something fluid like epub and mobi? Are there any best practices?
How does it work for tables?
Tables only barely work in most e-book readers, so don’t expect much of them. In fact most publishers avoid HTML tables altogether and use pictures of nicely designed tables instead. I’ve been wrestling with table formatting recently, trying to find a way to get them centre-aligned instead of left aligned, and half of the e-readers out there just don’t respond to that kind of formatting. It’s frustrating to be unable to do something even as simple as centring a table on the display.
Regarding lists (and really anything that comes along with common best practices regarding what to do around a soft page-break) there is no solid analogue in the e-book realm. Expect widows and orphans, awkward spacing, scene breaks that get lost (I recommend sticking with symbols for this reason in e-books), lists that don’t look good and so on. It’s a known problem, but the solutions are not simple because unlike a printed paper book, every customer can have their own differently shaped book with varied typesetting and formatting options within that “paper” shape. There is no just way to predict it, because a Blackberry is nothing like an iPad is nothing like a Paperwhite is nothing like an iPhone is nothing like a 27" HD computer monitor.
Another principle (though slightly unrelated) problem is the underlying technology itself, which is based on HTML and primitive CSS. Until widespread support for higher level CSS layout is possible, many layouts will not be possible to achieve, and even the most cutting edge CSS recommendations do not have full word processor or desktop publishing levels of quality control (much less the implementations in web browser and such, which lag many years behind the recommendations). HTML just wasn’t designed with any kind of text cut in mind. A long document is ten stories tall, not hundreds of handwidths tall.
We’ve got a long ways to go yet with electronic publishing! To a typesetting geek like myself, it’s frustrating, and hurts my eyes, but I’m willing to live with it as it sure beats the stacks of back-breaking boxes it otherwise took to move my old library around. 
Thanks Amber.
If I wanted to switch out lists for something that works better, what might be best?
I’ll print that same format in the PDF so there isn’t any inconsistency.
I’m not sure, could you describe what you are looking for precisely? I’m thinking in terms of fundamentals here, and trying to keep lists from overrunning by one or two list items, and I can’t think of any way around that because of the basic problem of having zero awareness of where a screen is going to cut. Any kind of multi-line construct is going to have that orphan problem. In general I would say it is best to stick with the list tool because if (or maybe it is best to say when) e-readers are capable of better handling list item orphans automatically based upon the list environment itself—your book will be ready for it even if you published it years before. Any attempt to manually control the process on the other hand will likely be incompatible with such incremental improvements, and won’t really work in a stable fashion anyway because of the varied “paper size” problem.
Thanks. It sounds like the best option is to use a paragraph format some how and completely avoid lists.
What is the list tool?
There is a list tool button in the Format Bar along the right. You might need to widen your window to see it. It can also be accessed from the Format menu.
ok, you mean the toolbar item. I’m familiar with that tool but I didn’t notice it made any difference.
The lists I’m using don’t have bullets. I select Other for style and checked to prepend enclosing list marker. Doing a side by side comparison in the Kindle Previewer, I didn’t notice that it made any difference with a non prepend enclosing list version. Lists still break over onto another page.
Guess there isn’t any advantage, at least if you aren’t using bullets/numbers. I’m not sure what it does otherwise.
Right, like I say e-books at this point in time have no concept of widows and orphans. There is nothing you can do about it either manually or via using different tools. It’s just something we have to live with right now, like non-hyphenated justification.
Is this still the case for ebook (.mobi) format in Feb. 2015? Are there any work-arounds? I am working with a document that is basically one long two-column table with 101 items (3 - 5 lines in the 2nd column: heading, title, and brief explanation) keep getting broken apart at the page breaks.
The “Format>Table” options don’t help, nor do the “Advanced Table Options” in the Compile to .mobi. At least that I can figure out.
I’m not aware of any developments along these lines, but paying attention to the detailed change logs for the Kindle firmware is where you’d need to be looking.
As for mammoth tables on a Kindle, that sounds like an exceptionally difficult use case. Are you testing with the non-KF8 models as well? Most of the Kindles out there are using the legacy engine that is rather woeful at table rendering.
Thanks for reply AmberV. Yes, it is a fairly simple two-column table for a tips & ideas ebook, but I am leaning toward doing the best I can with given constraints, rather than battling windmills. Not ideal, but acceptable given where we are with the ereaders and expectations, but I guess we have come a long way. It just doesn’t seem like it should be that hard to keep a chunk of text together on the same page, or drop it down to the next page as a whole chunk! Thanks again for the update.
The closest I’ve seen is more recent versions of Adobe’s display engine, as seen in Kobo (not sure about Nook). I’ve noticed in the last few firmware patches to my Kobo Aura HD that it does seem to be attempting W&O protection. It doesn’t, I would say, do a very good job of it, but sometimes I’ll see the page content terminate about a half to a full inch above where it normally does, in order to better fit the following paragraph on the next page.
Part of the difficulty is that there is no “document” on an e-reader. There is the current slice of text you’re looking at, and maybe a chunk or two after to speed up forward page flips (you can tell devices that do this if going back a page is significantly slower than forward a page). So really, it’s reading text off of a huge stack, slice by slice, and that makes it difficult to make the kind of larger, more contextual calculations required for this. And I’m just talking about prose here. Tables are a whole different can of worms when it comes to “keeping it together”. That’s some pretty sophisticated stuff that even Word gets wrong (no surprise there though, eh?). 