The new layout language for the book is HTML. It has never been easier to make web content using HTML, hence it has never been easier to make a book.
Generally speaking, HTML is frowned upon as a source file format for books because it is seen as worst practice. Best practices require complicated file formats like “docbook” or, worse, Latex. These file formats have been designed to contain and describe content so that beautiful books can be made. Unfortunately, the process of creating docbook and Latex is extremely complicated. Getting a new user to work with either of these formats is quite a process. On the other hand, WYSWYG editors which produce HTML work very much like simple text editors. It is trivial to create HTML with a WYSIWYG editor or similar tool and it can be done online.
HTML is a very established, very well used, and very well distributed format. There are already an enormous number of people using HTML, and an enormous amount of content already stored in HTML. That content and those people are networked, and HTML has a rich legacy of tools that enable transformations into other formats. HTML is the new source format for books.
CSS (Cascading Style Sheets) is the syntax that controls the look and feel of HTML. E-readers and web-browsers can read this syntax and present the content accordingly. Book production platforms such as Booktype enable the customisation of CSS for ebook output, but, more interestingly Booktype also enables CSS to control the look and feel of paper books. Designing in this way takes some thought since it is usually disorientating for book designers to ‘design in code’ and it is equally disorientating for web designers to use code to design material products.
The W3C CSS Working Group1 (responsible for overseeing the standard) anticipated the intersection of the book and the web some time ago. In the latest drafts of the CSS standard, new additions are almost entirely focused on typography2 . As a consequence of this emphasis, this area is starting to blossom. There has also recently been a sharp rise in the websites offering tips on CSS typography3 and an explosion of web fonts. (If you are interested in a very good insight about how fonts get to the web please watch the Unbound Book video presentation by Otmar Hoefer, the Director of Font Marketing at Linotype Library4 ).
There are also some very interesting JavaScript libraries available that are trying to make up for what is lacking in CSS typographical controls. Most are based on the well-used and prolifically distributed JQuery JavaScript libraries.
Of particular interest is the kerning.js library which combines the previously available lettering.js library. What these libraries do is to make each glyph (letter/number) into its own element, each of which can then be transformed by CSS-like rules. In plain speak, these code libraries allow you to change each letter individually in a paragraph or heading etc.
There are some nice demonstrations online about why this is interesting, of which the most interesting demo can be found at kern.js. Try visiting that page, double click the big blue circle, then click on and drag the letters individually.
If you then click ‘Finish Editing,’ you will get the CSS controls necessary to implement this effect (if you had kerning.js linked from your page).
There is also another interesting typographical library called colorfont which enables dual toned glyphs.
It is a pretty good trick they used to achieve this. Essentially they created two fonts from the same master font, each displaying just partial glyphs. When overlayed, they display the full glyph. Hence each ‘layer’ can be targeted with a different color.
With libraries like this, it is apparent that JavaScript has a future with web typography but maybe it doesn’t stop at that. These kind of tricks can also be implemented with ebooks and with more and more book designers entering the world of ebook design, I am sure we will see a growing need for more of these libraries.
Good nuanced control over font rendering is good enough at the moment and getting better quickly. However, many e-readers and all web-browsers do not support all of the CSS controls and most ebook readers do not currently support JavaScript. This will change in time, especially since ebooks are becoming a revenue stream for Apple, and Apple (together with Google) is behind the development of webkit – the rendering engine behind iBooks, Safari and Chrome. Good support of CSS typographical controls is on its way and we can expect more web designers to start designing books, and to see more book designers learning code.
What is dismaying, however, is the current trend of vendors like Apple to use non-standard CSS controls to layout the books. Baldur Bjarnasons has written some very good blog posts about this. The strategy by Apple is to make any book authored by the iBook Author software only work (or work well) when viewed with the iPad. I do not really understand this strategy – yes it is the typical platform / sales channel lock-in that Apple is known to perpetuate. However, it means that content creator content has limited distribution because of this. Apple might wave this away by saying that it is ‘innovating,’ but innovation like this cannot be seen without a degree of skepticism about the intended goals.
Nevertheless, it is possible to say with some confidence that CSS and JavaScript will come to be seen as an important development in the history of typography. Just as Gutenberg “was concerned only to imitate the book of his day – which was handwritten”5 but unintentionally gave birth to new aesthetics, we can imagine the new CSS typography to have similar consequences.