[slide 1][slide 2]

Books are sacred. Think of how we react to book burnings. Think how hard it is to throw one away. We build temples for them—there’s a library in almost every town.

They might be the most spectacularly successful technology of all time. Many of us have more books in our houses than any other object, besides Lego.

A book’s contents might be great art. The book itself might be great art, too. A book may take years or decades to create—the work of dozens or hundreds of people beyond the author. It’s a monument you can hold in your hand.

The web can also be described as a spectacularly successful technology. Like books, browsers are everywhere. Unlike books, browsers don’t have a thousand years of history; many of us are older than the web.

[slide 3]

Books in browsers have an even shorter history. Ebooks don’t have that aura of sacredness, and often don’t feel like art. But all of us are here today because we want more for books in browsers. We want them to be beautiful. We want to use our new-found digital powers to create great things.

I have a vision for books in browsers, that tries to learn from history, from the art and craft of print. I want them to be as beautiful as print, but flexible, accessible, adaptable.

Take a book and change the font or screen size, and have it automatically adjust to the new size, but still without widows and orphans and bad breaks. Be able to use ideas from the history of print, like drop caps or footnotes or running heads, as well as links, popups, javascript, forms, and all the machinery of the age of browsers.

Art forms advance not by forgetting the past, but by building on it, re-imagining it.

[slide 4]

So how do we make the world we want? To a large extent, we can do these things if browsers can do these things, if CSS can do these things. CSS is the key.

Today I’ll talk about a few things we might want to do with books in browsers, and the experimental work done in CSS to make it possible. So what, exactly, are our demands?

[slide 5]

Web pages scroll. Books have pages.

Not everyone agrees. Digital fundamentalists, naturally, are big fans of scrolling and argue against pagination. But even the author of the most famous book ever, when faced with content that overflowed its container, decided to fragment that content and render it onto multiple pages.

Most ebook readers paginate, badly, because it’s hard. And having to support pagination makes it very hard to build a reading system. Native support for pagination in the browsers would do more for books on the web than any single thing I can think of. And, as Ivan and Markus just told us, EPUBWEB depends on this.

[slide 6]

What is pagination?

[slide 7]

Pages are about breaking things. Even the spec says so!

[slide 8]

Some things can’t break at all, like images. Some breaks make the structure of the content clearer, like starting a chapter on a new page. Most other breaks are contextual—it’s usually OK to have a page break in the middle of a paragraph, but not if there’s only one line of text after the break.

Every rule of pagination, in fact, boils down to a single principle: break pages with as little disruption to the reading experience as possible. A widow leaves the last line of a paragraph isolated from the rest of the thought. A recto hyphen means a word is interrupted by a page turn. A heading at the bottom of a page removes the title from the section, and the section from the title.

So we need rather complex rules to describe when it’s ok to split things up. Luckily there’s already a spec for this.

But we also need to tell the browser we want pages. As we’ve said, pages are a way of handling content that doesn’t fit. CSS has a special term for stuff that doesn’t fit.

[slide 9]

It’s called OVERFLOW. In a browser, everything lives in boxes. If your stuff doesn’t fit in the boxes, you can just let it all hang out (overflow: visible), you can make the extra stuff disappear (overflow: hidden), put a scroll bar on the box (overflow: scroll), or make more boxes, which is pagination. The general term for splitting stuff into these pieces is fragmentation.

Much to the horror of english speakers everywhere, the boxes which hold the pieces are called fragmentainers, short for fragmentation containers. So a page is really a fragmentainer. We’ll try to avoid the blockification of fragmentainers :)

[slide 10]

Here’s a proposal for telling browsers to make pages.

We’re saying to make new pages, and create them to the right of the existing pages, which is effectively how most ereaders work.

[slide 11]

Short digression: Why X? CSS has done a lot of work over the years to more elegantly handle the fact that many languages are not left-to-right, top-to-bottom. So they’ve defined logical directions based on whatever direction you write the next word (the inline direction) and the direction you go for the next paragraph (the block direction).

This is my favorite ascii art diagram of all time, which is part of the CSS writing modes spec. But even that didn’t have X and Y, so I added them. I still think that saying overflow-y: paged-x is confusing, though. Next week I’ll ask someone why it isn’t overflow-block and overflow-inline

[slide 12]

But just being able to make pages isn’t enough. We need a more fundamental understanding of what a page is and how it behaves, in the context of HTML, CSS, and the DOM.

Right now we have no way of answering even simple questions about pages. How many pages in this file? What’s on page seven? How would you display two pages side-by-side?

We can answer these kinds of questions about regular HTML documents because we have Javascript and the DOM. But the DOM doesn’t know about pages. And so we should talk a bit about the DOM, and how browsers work.

[slide 13]

The Document Object Model is just what it says it is. For our purposes it’s an abstract model of an HTML document, where the document is turned into a “tree” of objects.

There’s a root object (or node), which is a representation of the HTML element.

The root may have one or more “children,” in this case the head and the body. The body may then have children, and the children have children, on to the seventh generation.

Javascript can talk to these objects, find out what sort of thing they are—elements? attributes? text? images?, change them, add them, or delete them.

But the DOM is all about the HTML itself.

[slide 14]

Browsers read the HTML from the web site’s server, turn those raw bits into characters, “parse” the stream of characters to turn it into objects, and then builds a tree of those objects, which is the DOM.

In the meantime the browser also has to parse the CSS, creating the CSS equivalent to the DOM, called the CSSOM, or CSS Object Model. Each node in the DOM has some relationship with a node (or nodes) in the CSSOM, which tell that node what it’s style should be.

The browser takes the DOM and the CSSOM, and from those creates the “Render Tree” or “Frame Tree.” Different browsers use different terminologies.

The render tree is a bunch of boxes. Each box knows what DOM node it belongs to. It knows about its parents, its children, its preceding and following siblings, and all applicable CSS rules.

There’s not a one-to-one correspondence with the DOM. The render tree omits elements that won’t display (like the HTML head or things with display: none). Some elements may create lots of boxes—go read about anonymous boxes when you need some excitement in your life.

Think of the render tree as the raw material for laying out the page. And in fact what happens next is layout, also called reflow.

Layout figures out how big all these boxes are, and where they go.

[slide 15]

(showing relationship of DOM and style)

[slide 16]

(diagram of box model)

[slide 17]

The DOM doesn’t know about the render tree. Browsers have implemented APIs for accessing some layout information, and some have been codified in CSSOM View.

But once browsers have a paginated view, we’re also going to need information about what’s going on. When Opera implemented pagination, it added a few properties to the DOM and CSSOM.

If we can query the result of layout, the actual boxes that have been styled and sized, then we can easily ask what content is on page ten, where that sidebar is, how many pages are in our document, and so on. Javascript could talk to the Box Tree just as it now talks to the DOM.

Back to our pages—we could define pages as anonymous boxes, fragmentainers for a paginated view, and then build an API that would allow us to access and manipulate those boxes. If we build all of this, then pages become as natural a part of the web as scrolling content. It’s a huge step towards books in browsers.

So I couldn’t resist bringing a book in a browser. Of course some of you can guess which book I would pick :)

[slide 18]

This is, of course, Moby Dick. It’s a reflowable, paginated book in a browser. I click the arrow keys to navigate. I can change the size of the viewport, or make the fonts bigger. I made running heads. There are footnotes.

Of course the browser needs help to do all this. A few years ago, the IDPF published a spec called “EPUB Adaptive Layout.” This is a javascript implementation of that spec created by Peter Sorotokin. It includes CSS Regions, a version of CSS Page Templates, and CSS Shapes and Exclusions. We’ll look at all of these things.

But Regions are really what make this possible.

[slide 19]

“The core concept behind CSS Regions is the ability to say, “Display this content (a named flow) over there (a region chain).”

This is incredibly important. “This content” may be an aside that needs to go “over there” in the margin. This one idea makes it possible to do footnotes, running heads and footers, pull quotes, marginal notes, sidebars—all sorts of complex layouts.

And, of course, you might want to take “this content,” meaning a whole books, and put it “over there” into discreet pages. Some browsers are using regions under the hood to implement multicol and pagination. Fidus writer and book.js use regions to create pages, and thus books, in browsers

That gives you a sense of the power of the idea, and how fundamental it is.

Interestingly, regions are controversial. Håkon Wium Lie, co-creator of CSS, wrote an article called “Regions Considered Harmful” on A List Apart.

Regions have been implemented in Trident (aka Internet Explorer) and Webkit. It was implemented in Blink and then removed “for increased mobile performance,” which has become a meme. Mozilla and Opera seem to be against it.

[slide 20, demo]

So how might we use regions for books? Say I want a running head on my page. It’s a useful way of keeping track of where I am in a book. Most commonly, you want to display some content that’s already in the book in a special place. Regions lets you take stuff and move it somewhere else. Perfect!

Except...

We probably don’t want to MOVE our chapter title or H1 to the running head, we want to COPY it.

AND if the h1 changes, we want the running head to change, too.

Regions can’t do those things yet, but we’re working on it.

[slide 21, demo]

Now we need to move the stuff to the place. So we need a box to put the stuff in. This requires some work. Nobody wants empty divs all over the place, just waiting for content to move to it. This breaks the separation of content and style, and was one of Håkon’s fundamental objections to regions.

So what if we can make the box using CSS? It keeps the design stuff in the CSS, and we don’t need to change our markup, which is really important when we’re publishing to many different formats.

There’s been lots of ideas about how to do this. One of the most promising of these ideas is page templates.

For anyone with a background in desktop publishing, I’d describe page templates as master pages for CSS.

Page templates create CSS boxes. You can absolutely position boxes and create columns. You can just specify a column width in ems, and as the screen gets wider more columns would be created.

Different page templates can be used in different circumstances. The first page can be different, as is common in books. A page template might only be used if a particular element in the document is present.

Here’s an example from my demo. Sorry about all the prefixes. But here we’re making a partition for a quote. It’s in the middle of the page, and we can calculate the position using something like calc.

[slide 22, demo]

We can do lots of interesting things.

Unlike Minecraft, not everything in this world is a rectangle. It’s quite common for books to have non-rectangular images, and it’s great if text can flow around them. CSS shapes lets us do that.

The text wrapping around this whale would look pretty good if I had any clue how to write a polygon.

[slide 23]

Sometimes a problem is so common you don’t even notice it. When breaking text into lines, browsers try to make as few lines as possible. They fit every possible word onto the first line. So you get things like this.

[slide 24]

Now, isn’t that nice?

Adobe has created a polyfill to do this automatically. The New York Times is using it for headlines on some web sites. And the CSS Working Group is looking at proposals to make this part of CSS.

[slide 25]

Drop caps are another small thing. But, like a pebble in my shoe, horrible drop caps on the web made me really annoyed. And I’ll use this story to describe how things happen in the world of standards.

[slide 26]

Initial Letters on the Web are Broken.

[slide 27]

Normally I wouldn’t make fun of websites with poorly-aligned drop caps. But every example I’m showing today is taken from a tutorial on making drop caps on the web.

[slide 28][slide 29][slide 30][slide 31]

(all examples of poorly-aligned drop caps)

[slide 32]

We used to do these with floats. The problem is that you have to guess at the font size and line height to get them to align, and this depends on the font.

[slide 33]

What works for Garamond

[slide 34]

Doesn’t work for Georgia

[slide 35]

Or for Palatino.

[slide 36]

This is what should happen.

As some of my friend’s Facebook pages say, it’s complicated. I knew what I tried to do in ebooks wasn’t working, and I knew how things should look. And, conveniently enough, by a most-improbable series of events, I was a member of the CSS Working Group.

My theory is that every possible CSS idea is already written down in an abandoned draft spec somewhere. And so I stumbled across a draft of the CSS Line Layout Module which had an extensive section on drop caps. But I was puzzled by some of what I found. Some of the examples didn’t show what I thought was the correct alignment. And it wasn’t very simple.

And so I brought up the issue at the CSS working group’s face to face meeting this May. I showed some of the examples you’ve just seen, and argued that this was something worth doing.

[slide 37]

And it turned into a wonderful discussion. Ted O’Conner from Apple came up with a lovely, simple syntax. We worked out a few of the complications (there are ALWAYS an insane number of complications when it comes to writing a spec), and then I went home and tried to write things up.

Unfortunately I didn’t do a very good job, but the ball was now rolling, as they say.

Discussion continued on the world’s most intense mailing list, www-style. Adobe and Apple were interested. And things happened. Webkit implemented the basic feature in September. Adobe released a JS polyfill at the beginning of the month (thanks Sylvain and Alan!). It will be a while before we can use that in ebooks, but I think it will happen, if I can fix all the horrible mistakes I made in the spec.

[slide 38]

Yes, we can make things better for books on the web. But it involves ... (dramatic pause)

Standards Work.

[slide 39]

Here’s a few places to learn more about what I’ve been talking about.

But to really understand CSS, one site stands above all others:

[slide 40]

http://w3cmemes.tumblr.com

[slide 41]

Thanks to all the smart people who’ve welcomed me into the standards world. And thanks for listening. Please run back to your computers, and tell the digital publishing interest group and www-style how things ought to be done.

The revolution will not be televised, but it will be minuted on IRC.

[slide 42]

We used to do these with floats. The problem is that you have to guess at the font size and line height to get them to align, and this depends on the font.