CSS Cookbook/Basic Text
Styling the Running Text
By "running text" I mean the main contents of your book: body paragraphs set within the margins of the full page. The CSS rules quoted here are in the Styles page of the CSS Cookbook.
Setting Body Margins
An etext looks crowded when its text runs from edge to edge of the browser window. You set body margins to make the text easier to read and to make the browser window look more like the printed page. (When sidenotes are used, you set the right margin to provide the space in which they float.)
However, the reader may view the text on a small screen, or may have other reasons for using a narrow browser window. We don't want to waste much of a narrow window for margins, especially when we indent poetry and block quotes even further. The solution is to specify left and right margins in percentages of the browser window width. Then the margins stretch to match the reader's chosen window:
body { margin-left: 8%; margin-right: 7%; }
This tells the browser: set the margins for all contents of <body> (which is all the text) based on fractions of the window width. The browser adjusts the margins as the user drags the window wider and smaller. Note that if the reader is using a window 800 pixels wide (a typical width), this command reduces its effective width to 680 pixels before any further indents.
When the text is not justified (as in wiki text) the right margin can be slightly smaller than the left because most lines are less than full length. When sidenotes are used, or when there are small illustrations that you would like to "bleed" into one margin, that margin needs to be wider to accomodate them.
Setting Text Width
Some readers use windows that are too wide. Many Windows users habitually keep the browser window maximized, with the result that text lines are much longer than book designers recommend for comfortable reading ("1-1/2 alphabets" is the rule of thumb for a readable column width). You, as an editor concerned with the look of your book, might be tempted to code something like body {max-width:40em;}. This property makes the browser limit the width of the page body, adding white margins as needed to fill the window.
There are two good reasons not to code max-width. The first is that, although most browsers obey it, it is not supported by versions of Internet Explorer before IE 7. (Only one of several IE bugs that plague us.)
The other is that some users, finding their control over the width of the text removed (and half their wide browser window a blank right margin) feel deeply resentful. After all, readers who care about readability can put the page in the proper width and shape by dragging the corner of the browser window to size. We shouldn't override those who don't care.
Styling Body Text
The look of the body paragraphs is set by these rules:
p { /* all paragraphs unless overridden */
margin-top: 1em; /* inter-paragraph space */
margin-bottom: 0; /* use only top-margin for spacing */
line-height: 1.4em; /* interline spacing ("leading") */
}
body > p { /* paras at <body> level - not in <div> or <table> */
text-align: justify; /* or left?? */
text-indent: 1em; /* first-line indent */
}
/* suppress indentation on paragraphs following heads */
h2+p, h3+p, h4+p { text-indent: 0; }
/* tighter spacing for list item paragraphs */
dd, li {
margin-top: 0.25em; margin-bottom:0;
line-height: 1.2em; /* a bit closer than p's */
}
All these rules are open to discussion and modification.
Text Alignment
By default the browser will display text left-aligned, with a ragged right edge. Justified alignment, set by the property text-align: justify; looks more like a book. But when the text column gets narrow, as when it is crowded by a floating sidebar or image, the browser's attempt to justify text can be quite ugly. After you set justification on, inspect the whole book; you may find text-align: left; looks better.
Even if paragraphs in the body should be justified, those contained in tables, poems, sidebars or other special divisions should not (because the browser will make a mess of justification in a narrow column width—try it and see). Hence the rule uses a selector that applies only to paragraphs that are immediate children of the body. You can always add justification to other classes if you need to.
Paragraph Indentation
In older books the first line of each paragraph is usually indented. In modern word-processed documents and in etexts, it is usual to put extra vertical space between paragraphs. Both customs have the same purpose: to cue the reader's scanning eye where paragraphs begin. The vertical space is more effective, but in a printed book, vertical space costs money. Typographers used the indent instead so as to get more lines of text on a sheet of paper.
In the CSS above, body-level paragraphs are given a first-line indent of 1em. The em unit of measure means "the nominal size of the current font." Use it to ensure that the paragraph indent will be proportional to the reader's choice of font size. Experiment with values from 0.25em to 3em, and with no indent.
As with justification, a first-line indent is not appropriate in tables, poems, etc.
Space Between Paragraphs
There are several ways to set the space between body paragraphs. I prefer to use the margin-top property exclusively, with the rules margin-top: 1em; margin-bottom: 0;. It tells the browser, put at least the nominal font size in blank space above every paragraph. (The reason for explicitly zeroing the margin-bottom value is that most browsers will default to some nonzero bottom margin for paragraphs. If you leave that unchanged, there are times when you want to close down the space between by adjacent paragraphs to less than 1em, and the default bottom margin interferes.)
This spacing has a strong effect on the appearance of the text. Experiment with values from 0 to 2em.
If your book uses more than a couple of short lists, you need to pay attention to the spacing between <li> elements as well. Generally list items should be a little closer together than paragraphs. Compare to the original pages and experiment.
Interline Spacing
The historical name for the vertical distance from the baseline of one line in a paragraph to the baseline of the next is "leading" because once, printers inserted thin strips of lead between lines of type to create this space. The CSS property is line-height and the value you set strongly affects readability as well as the general look of your text. Most browsers use a value of about 1.2em by default, but you should experiment with values from 1 to 2ems, comparing to the original pages.
After setting the paragraph line-height, set the list item value to the same or a bit less.
Corrections
The Proofreading Guidelines say to flag apparent typos and printer's errors but leave them for the post-processor (you). The Post-Processing FAQ says it's OK to correct "obvious typos." So if something is clearly an error, not archaic usage or an author's idiosyncracy, you can fix it. Just the same, it would be a good idea to mark the correction in some way so that future readers (and maintainers) will know how the etext deviates from the original work.
These corrections can be documented by adding a list of corrections at the end of the ebook, by noting trivial corrections in HTML comments, by flagging the corrections in the text using HTML markup, or using a combination of these approaches. HTML doesn't have any markup designated for marking editorial "changes" to a document. It has, however, markup for deletion and insertion, and a change can usually be seen as a deletion plus insertion. Using HTML markup to flag corrections to an ebook, there are basically three different approaches: <del> + <ins>, <ins> alone, and <span>.
All three approaches use the title attribute to show a popup/tooltip to the reader when the cursor hovers over the word. The exact contents of the title can of course be modified, and could depend on which approach you use.
A discussion of the topic can be found in this forum thread.
Delete and insert
If we look at the correction as a deletion and insertion, we get an example like this:
<p>This <del class="correction">si</del><ins title="Transcriber's Note: original has si" class="correction">is</ins> a sentence.</p>
Example: This siis a sentence.
A problem with this approach is that screen readers by default don't handle it very well, and read out the contents of the <del> tag too. (Can't that be handled with CSS? Our books should also work without CSS, but then it's a browser bug, and not our responsibility to fix it.)
It's optional to include a title on the <del>, as it'll usually be invisible anyway, but you may want to do so for consistency.
Insert alone
If we decide to discard the <del> tag because it is badly handled by some browsers, we get an example like this:
<p>This <ins class="correction" title="Transcriber's Note: original has si">is</ins> a sentence.</p>
Example: This is a sentence.
This was originally suggested by Estreya on the forum. A problem with this approach is that when the markup is interpreted semantically, it says that the original text read 'This a sentence', which is of course not what was intended. The title attribute clarifies things, but this comment may not be seen by the reader. A user—or some future repurposing software—who would rely on the semantic markup of the document, and wish to see the "original version" by suppressing all <ins> and displaying all <del> would thus be presented with an incorrect result, and think the typesetter had accidentally left out a number of words, where in fact he only mistyped them. The PPers who use this approach believe that the number of such users is probably quite small and that the <ins> works for saving the information and presenting it to the majority of readers. HTML was not designed for marking up entire ebooks, so post-processors have had to be creative and adapt the tools and markup to fit the best use for most readers.
Span
Looking at the drawbacks of each of the above mentioned methods, one can decide not to mark up the corrections semantically at all, and simply add a visible indication and/or hover comment to the corrections:
<p>This <span class="correction" title="Transcriber's Note: original has si">is</span> a sentence.</p>
Example: This is a sentence.
One drawback of this approach is that it can only include semantic information about the correction indirectly via the class name (which is arguably better than including wrong semantic information). Also, browsers don't apply any default styling to the span tag, so any mention of styling in an overarching Transcriber's Note will be confusing to readers who encounter the book without CSS.
The actual CSS
Regardless of which of the above methods is used, we can apply CSS to the class="correction" that is applied in all three examples:
.correction {
text-decoration: none; /* replace default underline, if present ... */
border-bottom: thin dotted gray; /* ... with delicate gray line */
}
Result: This is a sentence. (This will look identical for all three approaches, as long as CSS is enabled.)
This will remove any underlining that the word might have (required if using <ins>, which has a default underline in most browsers, not necessary if using <span>), and add a thin dotted gray line below the word.
If you use the <del> + <ins> method, you probably want to add some CSS to hide the deleted text when reading the book:
del.correction {
display: none;
}
Links
You may consider styling links to improve accessibility.
| CSS Cookbook Topics | |
|---|---|
| Intro | • Styles • Browser Issues • About • Reference |
| Styling | • Basic Text • Heads • Lists • Tables |
| • Block Quotes • TOC and Index • Images • Poetry | |
| • Sidenotes • Drama • Footnotes • Page Numbers | |