Archives for posts with tag: css

There are 3 quick changes that I like to make to ebook css, whether starting a new ebook or doing QA on an existing ebook. These changes help me to:

  1. Read the running text more comfortably
  2. Visualize the information hierarchy more clearly
  3. Give the design a bit of personality

I achieve this by:

  1. Resetting the p selector’s line height
  2. Resetting the p selector’s margins
  3. Adding color that matches the cover to the heads

Here’s what I’m usually looking at before I make these changes to the CSS.

And here’s what I’m thinking:

So I open the CSS and make these adjustments:

I find most ereaders’ line height default to be too tight to be comfortable. Bumping up the line-height fixes this. While I’m in there I throw in hyphenation, widow and orphan, and text-align declarations. I also set the text-indent to zero if I intend to push the epub through Kindle Previewer because older Kindles that read Mobi files (instead of KF8) put a text indent on every single paragraph, whether I want it or not. Note that if I have lists in my ebook, I need to repeat some of the declarations in the selector so that my design choices remain consistent.

While I’m in there I set the margins to zero so that there is no space between paragraphs. But when I do this, I make a p class for a text indent so that readers can see where the next paragraph starts. And that p class with the indent picks up all the good stuff I threw into its parent … the p selector. Now the space around the heads is more noticeable and this strengthens the information hierarchy.

To set off the heads even more, I add a color that matches the cover. Unlike adding color to print designs, adding color to ebooks doesn’t cost a thing. The proliferation of color tablets on the market makes this a quick win. On eink screens the color simply goes to grayscale (but check to make sure the color you choose doesn’t look too faint). The color doesn’t have to be flashy. In my example below it’s navy but it’s enough and it matches the cover to help make a polished package. And while I’m in there I throw in hyphenation declarations to prevent hyphenation in case the heads wrap to a second line. I also like to set the heads as sans-serf, at least in the beginning, to see them more clearly.

Now, of course, some ereaders will override or ignore some of these declarations and human readers have the choice of changing the line-height, font, and other aspects of the text. But as a designer I become familiar with the material first and my job is to present it in a way that will make it more easy to comprehend. If the reader doesn’t agree, they are empowered to make their own choices.

Here’s the before and after:

(click on image to enlarge)

So there’s my 3 favorite CSS changes that get me started on the road to developing an attractive and useful ebook. Feel free to try them yourself. And feel free to share your own favorite “resets.”


UPDATE 11.21.12 | Since writing this post, I’ve come to the realization that it’s more accurate to say “markup” instead of “code” in this instance. A programmer I am not!

  1. In the design stage, brainstorm with the team regarding all of the design ideas to try for the ebook. And then assign a hierarchy of importance to the ideas for the sake of productivity on a tight deadline. In this way no ideas get ruled out and, if you start at the top and work your way down, you will always be working on the next most important element of the project. This is especially helpful when I have to learn the code as I go along. Some things come together quickly while some things take a long time to research and get right.
  2. Working with code feels a lot like learning to recognize patterns. Everything that opens must close. Look at it and work with it long enough and it starts to make sense.
  3. Type code slowly and with thought. I’ve spent too much time trying to find unclosed tags. One trick I like is to type “/” in Dreamweaver while editing in the HTML doc to check for unclosed tags. If “/body” pops up, the file is in good shape. If any other tag pops up I go back and try to find the error. This saves time and less rounds of validation (but validation comes in handy for those times I just can’t find that &%@#! unclosed tag).
  4. Try a regex action on one example and be sure it works the way I want it to before applying it to every open HTML file. Enough said there.
  5. It’s going to take me a while to learn the cascading aspect of CSS.
  6. If I feel like I have all the answers on one day, I will inevitably feel like an idiot the next day. Conversely, when I feel like an idiot on one day, I will inevitably feel like I know what I’m doing the next day. Hang in there. That’s what learning feels like. I remember back when Quark felt the same way.
  7. There’s always going to be more to learn and this makes code seem fun and interesting. This makes my brain happy. (Reminder to myself to revisit #6 when this does not make my brain happy.)

UPDATE 11.09.12 | A good number of searches regarding deleting extraneous CSS continue to lead readers to this blog post. During the time since I wrote this post, my coworker India Amos started to use BBEdit to quickly isolate used CSS in her ebooks (which therefore allows her to get rid of unused CSS) and has shared her workflow on her blog. I highly recommend checking out her instructions.

Lately I’ve been working on editing the code on series of eBooks that need to look the same. Each of these eBooks was released at a separate time and each outsourcer treated the conversion from print (InDesign or PDF) to ePub a little differently (these ePubs have not benefited from a “meat grinder” approach and that’s all I’ll say about that). Most of the time, the CSS and HTML is similar enough so that I can work on one title, and then 1. copy that CSS and apply that to the rest of the ePubs and 2. do a find/change on the HTML to make it match the CSS.

The problem is that some of these .css files were huge and some of the CSS was making my files do weird things. For instance, one ePub had a blank page after every chapter on the iPad. After much trouble shooting, I pinpointed the error to a div in each HTML file that surrounded all of the text and had extra space added to the top and bottom margins. These divs were pushing each new chapter opener out a “page”. It didn’t appear in ADE but it appeared on the iPad. That’s just one example of the many fun times I got to say, “Why is this happening?”

So, I looked for a way to delete extraneous CSS from my ePubs in order to cut down on these pesky errors and avoid having to troubleshoot so much. I also wanted to be able to copy over only the CSS that I needed to the other titles in the series. I think I found a solution with Firefox’s add-on called “Firebug,” and Firebug’s extension called “CSS Usage.”

Here’s how it worked out.

Installing Firebug and CSS Usage

1. Open Firefox. Under tools / add-ons search for Firebug. Press the install button. Restart.
2. Open Firefox. Under tools / add-ons search for CSS Usage. Press the install button. Restart.

Running on an ePub

1. Check that the HTML across all of the files is consistent and that the CSS for that HTML is working the way you want it to. (Obviously the simpler the books, the better. Today I was working books with straight text).

2. Access an HTML file from an unzipped ePub by opening it in Firefox.

click on the pictures to enlarge

3. Click the Firebug icon in the upper right corner of the browser window.

4. In the panel that pops up in the bottom of the browser window, click on the “CSS Usage” tab and then click “Scan.”

5. There’s the results. The “Seen” CSS is highlighted in green.

Preserving the Seen CSS

1. Record the “Seen CSS” on a new sticky on your Mac. After you’ve reviewed all of your HTML files you’ll have all of the CSS you’ll want to keep in a list. You can use that list to move this CSS to the top of your .css file and then you can delete the unused CSS.

or 1. Click on “export cleaned CSS.”

2. Copy the used CSS (the unused is preceded by “UNUSED.” into a text editor to refer to later or directly into a clean .css file.

I then used my new, clean .css file on the rest of the series. I’m thinking that being proactive about searching out and applying only the CSS I want will cut down on weird things happening in these ornery ePubs. I’m going to pick this up again on Monday and apply this solution to another series and see what happens.

Now, the flip side of all this is finding extra HTML that needs CSS. Anybody know that trick? For now I’m using the new .css file in the whole series and then previewing the series in ADE or the iPad and visually finding text that has extra HTML (it just looks weird and out of place) and either changing the HTML to match the CSS, or adding new CSS.

So, while not a perfect solution, this worked for me today. As a print person I think this works but some of you web gurus might be seeing something I missed. Anybody have any suggestions? Comments? Think I’m crazy? …that tends to happen to me by 5:00 on a Friday after a week of checking ePub code.