15.2 | More On CSS

##Revise: Under re-construction to include more about using your own CSS

CSS = Cascading Style Sheet

CSS is nothing more than a set of very straight-forward rules about how devices or applications should display things like text.

Devices can be instructed where to find our CSS rules in a number of different ways. For the purposes of this tutorial, we use a separate CSS file named ebookstyle.css. This file contains rules for how text should render on any given display device.

To tell devices where to look for our rendering rules, a line has been added to the HTML template supplied for this tutorial. The line is found in the head section and looks like this:

<link href="../Styles/ebookstyle.css" rel="stylesheet" type="text/css" />

Because of this line, display devices will look for the CSS rules contained in a CSS stylesheet called ebookstyle.css. This stylesheet, in conjunction with the simple in-line tags like <i></i> or <b></b> determines how text will look on screen to our readers.

One very important factor in CSS are attributes. Attributes are units of measurement (sort of; just go with it.)

Why Did You...

##Revise: Maybe a little less vitriol would be good.

For this tutorial I chose the "em" attribute. 

em = ephemeral unit.

Time out for me to vent some frustration: This is a free tutorial. Because I'm not getting paid, I don't have to worry about hurting anyone's delicate writer-feelings, so hear me: Any guide that tells you to use any attribute OTHER than "em" (or, arguably, percent) does not understand quality control very well. Those folks are stuck in spatial production land, which is completely understandable. Few people can afford to buy every e-reader device, so most of us aren't familiar with the settings available to our customers, and all the factors readers can set as preferences. As a result, a lot of lessons aren't learned until that nasty email from a pissed-off customer lands in the inbox explaining why a file is horribly broken or won't render properly, and they want their money back.

Plus the shotgun wedding between standard print convention and the digital world has not been a raging success thus far. Balancing reader expectation and standard print convention against the constraints of HTML and CSS can be a major challenge. Worse is trying to balance author expectation into the mix. Some things authors regularly see in print books and want reproduced in their own e-books just aren't possible in digital... yet. Or at least not without breaking rules and giving a file a terribly short shelf-life in file-stability terms. Or making a file work on only very limited number of devices.

For those reasons and more, I've stuck to scalable units in our CSS.

"em" is a scalable unit. 1em = regular font size set by the reader.

Imagine me sitting here wearing a very pained, frustrated expression. I have been yelled at and argued with countless times by authors on this subject. I have no patience left to be polite about why the reader is more important than the author.

In digital publishing, regular font size is SUPPOSED to be set by the reader, not the author. Readers bought the book file. They're our customer, and they have the means and every right to set font-face, font-size, line-height, margin depth and whatever else exactly how they want them.

We don't declare font-face for the same reason. Not only can that definition cause a lot of known bugs, but it can interfere with a reader's preference (which we absolutely should not presume to do.)

Now, back to scalability and the em unit. This unit grants us a beautifully simple "relative to" ruleset for our CSS.

Kyle Schaeffer has an excellent explanation of all this on his site.

Looking at our stylesheet, take, for instance, indent depth. In the ebookstyle.css file, it's the second line, defined as:

text-indent: 1.2 em;

This definition tells our rendering devices that the first line of each regular text paragraph must be indented 1.2 em. 1.2em means that that indent will measure a depth equal to one regular-sized text character plus .2 of a regular-sized text character (or 120% of a regular-size text character).

This means that if the reader has regular font-size set at 14 point, the indent will be 120% of that size. No matter which font-size the reader has chosen, the indent depth will scale to 120% of that value to suit.

The reason we use a relative ruleset instead of hard-coding these depths and sizes in pixels (px attribute) is that scalability factor.

For instance, if we were to set that indent at 15px instead, and the reader has chosen a tiny or gigantic font-size, that indent will always render at a constant depth of 15px. Indent depth might seem ridiculously deep or far too shallow to sufficiently mimic print convention.

Conversely, look at the "flush" paragraph class. The text-indent for those paragraph types is set at 0em, which measures as no depth. No indent.

Another example of scalability would be a dropcap. For this tutorial, I set the dropcap size at 2em, that is twice the size of a regular-sized text character. If we were to hardwire this by pixel size, the difference could be either too small or too ginormous, depending.

Now, the beauty of Sigil is that you can play with CSS right in an EPUB file and see immediately each change's effect on the text. Try it. This is quite possibly the best way anyone could learn how to handle CSS, in my opinion. When mucking about with things, stick to scalable attributes. It really is best for your paying customers.

Using Your Own CSS

I do need to touch on two issues before this section begins. First is this line in the <head> section of each HTML file in our EPUB:

Note this line:

<link href=“../Styles/ebookstyle.css" rel="stylesheet" type="text/css"/>

• • This entire line must appear in the <head> section of each HTML file listed under the Text folder in the Book Browser. If it doesn't, our custom CSS will not apply to anything in that HTML file.

  • This line tells Sigil and EPUB-display software where to look for the rules on how to render text. (CSS is those rendering rules.)

  • This line tells the software we're looking for a CSS filetype named ebookstyle.css.

  • Our rendering rules are contained within the ebookstyle.css file.

  • This stylesheet-link line was embedded in the blank HTML template provided for this tutorial. If, for whatever reason, that line does not appear at the head of any HTML file in the EPUB, the CSS will not work because Sigil and any other display device will not know where to find the CSS stylesheet.

If users want to use a different CSS file in one or more sections, please have a look at this supplemental CSS page.

Okay, so after that very long, emo diatribe on relative rulesets...

To change the CSS stylesheet for any given project:

• In Sigil, the new CSS file must be added to the Styles folder, exactly the same way ebookstyle.css was added. (Right-click the Styles folder in Book Browser and select "add existing file". Navigate to the new CSS file, &etc.)

• The new CSS filename needs to be substituted in place of ebookstyle.css into every single HTML Text file (listed under the Text folder in Book Browser) in which the new CSS should be used. I recommend changing this before creating the HTML version rather than waiting until Sigil stage. That way, you only have to change the filename once instead of changing every single HTML file you've split. (Sigil will copy the <head> section of the source HTML file each time a file is split. If you change the CSS filename before those splits happen, you only have to change it once.)