Go read my post on ebook formatting before you begin; this is a follow-on post that focuses on HTML and its good buddy CSS. If you’re already up on formatting, you’re all good to go. You definitely don’t have to format the same way I do. Everyone has a process flow that works for them. If you don’t have a process flow or want to see a bit more about formatting, check out the post. If not, no worries. Carry on.
Once you’ve finished writing your novel or story the journey is only partway over. You’ve got edit it, format it, make the dreaded table of contents, make a cover, and get the file ready for publication. There are services and people out there who do most of this for you but for those of you who like to get your fingers covered with digital dirt the following links will at least get you started.
The post on formatting goes through a lot of the process of formatting and getting the file ready for publication, but there are a few more tricks that might come in handy. If you’ve never designed a web site you might not be familiar with the twin heroes of web design: HTML and CSS. The HyperText Markup Language and Cascading Style Sheets work together to define the look and feel a website. Think of them as extremely lightweight programming languages even though neither of them technically fall into the realm of programming.
For instance, this is programming:
la.alertID = rdr.IsDBNull(9) ? Guid.Empty : new Guid(rdr[“AlertID”].ToString());
This is HTML:
<p>I’m a tag!</p>
This is CSS:
Don’t worry. Things are only strange until you get to know them. As the Skipper says, “An enemy is just a friend who hasn’t betrayed you yet.” To get your head around HTML and CSS you don’t need to understand programming at all, especially since this post is focusing on HTML and CSS for eBooks. Once you hit the realm of web sites the complexity increases dramatically, but an eBook is a pretty straightforward thing.
So, why worry about HTML and CSS in a post that’s supposed to be for authors? The simple answer is this: an eBook is really nothing more than a very basic website and your eReader is really nothing more than a cut-down web browser. In a lot of ways it makes an enormous amount of sense to use web technologies for eBook publishing. They’re established technologies that most developers have already wrapped their heads around and it makes for portable data, which was what the Internet was going for all along.
The HTML code defines what’s in your book and gives it a basic breakdown of what’s a paragraph and what’s title and so on. The CSS code takes that information and tells the browser how to render it into something that looks decent on a screen. You don’t have to code out the whole thing from scratch. If you’re using a modern-ish writing platform like Word, Scrivener, OpenOffice, LibreOffice, or any other number of tools, the program is creating the HTML and CSS for you as you type and format. All you need to worry about is tweaking the occasional HTML tag or CSS instruction to make things perfect.
If you’re still worried about the idea of coding, don’t fret. Here, have a kiss from a giraffe.
So, you’ve got everything written and formatted and converted to an epub file, but there are those nagging little things you want to change. For me, it’s always the damned Table of Contents. Others might see the epub rendered and want to change some things on the fly. In order to do that, you need to have a basic understanding of HTML and CSS. Since an eBook is just a website, I’m going to eschew the complicated stuff and just put together a simple site with some text and then do some basic formatting.
Here’s a simple HTML file with no CSS references in it. Okay, so there’s one, but it’s commented out and I’m lazy.
and here’s a CSS file that I’ve already done some work on.
And this is what the page looks like in Chrome.
So, let’s link up the HTML and CSS files. Conveniently, I’ve already done this. If you look back in the HTML file up in the <head> section, you should see a line that looks like this:
<link href=”stylesheet.css” rel=”stylesheet” type=”text/css” />
This links the HTML file to the CSS file. Now we can make changes to the CSS file and the changes will … cascade to the HTML file. Meaning any time the browser sees a thing with a particular class name (or a particular type of thing, like an <a> tag), it looks back to the CSS file to figure out how to render it. If there is no set of specified rules about how to render something, the browser just uses some default values.
So, the files are linked, but we haven’t told the individual elements of the HTML file what parts of the CSS file they’re associated with. That’s why the screenshot of the site in Chrome looks like crap; those are the default ways of rendering HTML in Chrome. So, we’ll start at the top with the title and work our way down.
To link the title element (Henchmen) to the correct class in the CSS file, I just have to tell the HTML file what class a title is. Right now the code that generates the Henchmen line looks like this:
That just means its an HTML paragraph. To make it all purdy and stuff, I’m going to associate that one thing with a part of the CSS file. All I have to do is change <p>Henchmen</p> to this:
<p class=”BookTitle”>Henchmen</p> and I get this:
If I start hooking up the rest of the elements in the HTML file, like so:
I get this:
Not perfect, but good enough for jazz and government work.
CSS and HTML can do an awful lot more than what I’m showing here. For instance, check out the CSS Zen Garden sometime. It’s a site that lets designers use their own CSS files to style the site and it’s an excellent example of what you can do with it. Obviously, what the talented folks over at the Zen Garden are doing is far more in-depth than anything that will wind up in an eBook any time soon, but it does demonstrate what you can do with CSS.
The rule of thumb in eBook CSS and HTML is to keep it simple, but there are some common CSS settings that will come in handy. For instance, here’s an example of CSS that Calibre defined for me based on Word formatting when I put Arise together.
Most of it’s pretty obvious but there are a couple oddballs. display:block, for instance. Block just means start this element on a new line and take up as much screen real estate as possible before wrapping. For a kind of decent example look at this page. Each time there’s a paragraph break there’s an extra line added. Each paragraph has about 1.2 to 1.5 line spacing, but between paragraphs there’s a 2.0 line space. The paragraphs are likely defined as block elements with a specific line height. Each time I hit enter, I get a new paragraph with a new block element, those are spaced around 2.0 or so.
A couple other tags that might come in handy are orphans and widows (Thanks to S.K. Holmesley for pointing this out to me). An orphan is the first line of a paragraph that gets left on page 1 while the rest of the paragraph continues on page 2. It looks wonky to see just the first line, so you can set orphans: 2; or however many lines need to be left. A widow is exactly the opposite, it’s the number of lines that have to fall to the next page if a paragraph gets split. widows: 2; would ensure at least two lines of the paragraph fall on the next page. If you have a paragraph where you have to worry about both orphans and widows you either have very small pages or may want to break that paragraph up a bit more.
The CSS generated by programs like calibre is basically the same stuff you see here, there’s just more of it. Every CSS/HTML interaction works exactly the same way. If you open an epub in Sigil and something looks off, examine the HTML, find out what class it thinks it is and use that information to look up what the CSS is doing. If you don’t like it, change it.
It’s pretty hard to seriously mess things up with CSS, but it can be done. Follow the old standard of backing things up before you mess with them and you’ll be fine.
For more information on CSS, check out W3 Schools CSS reference.
Congrats. You made it through. Have a picture of a boxer.