If you’ve ever tried to create custom headers and footers for your ebook, you probably realized pretty quickly that it’s a near impossible task. Although reading systems generate their own headers and footers, control over them has never been afforded to the people creating the content.
The EPUB specification has, for a long time, included the custom CSS values
oeb-page-foot for the
display property. Control over the headers and footers was ostensibly given to content creators by setting these values on an element containing the header or footer. I’d typically give an example of how this is done, except…
Despite the best intentions of the specification, no one’s implemented the feature in a reading system (or not very well, as Digital Editions has an awkward attempt at them). But optimism prevailed, and the functionality has persisted through revisions without any real-world application. That is, until 3.0.1.
The decision was finally made to deprecate these values in the current revision, as you can see if you followed the earlier link to them. It doesn’t mean they’re gone from the specification, obviously, but it’s an acknowledgement that they aren’t working and there’s really not a lot of value in using them anymore, so you should stop.
The plan at this point is to replace them with a real CSS option, assuming ones evolves out of the W3C’s paged media work, or to drop them entirely in a future revision.
Who killed them?
It’s easy to blame the reading system developers for this one, since they ultimately decide what they’re going to support or not, but I don’t think it’s fair in this case.
The header and footer implementation in EPUB, although seemingly simple enough from a markup perspective, I expect would be a pain to implement.
The way the functionality was designed, the reading system would have to keep constant lookout for changes as the reader progresses. Headers and footers could be modified many times within a single file, so the reading system has track when headers or footers fall out of scope and new ones have to be applied. That sort of constant monitoring of what content is visible on the screen sure sounds like a pain, anyway.
And there have to be various fallback checks in case someone forgets to set a new header or footer, so ultimately the reading system has to implement its own system of headers and footers regardless of what the specification allows. Once you implement your own of anything, making it extensible often becomes a secondary consideration.
I’ve fielded the question of whether you can create your own headers and footers in a reflowable EPUB enough that I’ll just briefly restate a few reasons why it’s not possible.
For one, you need static control over the page, and you simply don’t have that without a specialized mechanism like the old header and footer styles. Only the reading system can allocate boxed space outside of the content area.
Second, you cannot use the fixed CSS display value to position content at the top and bottom of dynamically paginated content. It just doesn’t work that way, as each dynamic page is not a new page in the web sense, so the fixed content will not persist from page to page. The only place it might work is in a scrolled interface, but I can’t see the aesthetic appeal of pinning a header or footer in such a scenario.
The length of headers and footers would also be variable, as inside the content area they will be affected by reader changes to text appearance. A static appearance requires the reading system generating them outside the reader-controllable area.
Fixed layout headers and footers
Although headers and footers are pretty much an unsolvable problem with dynamic pagination, at least within the content, there’s actually nothing stopping you from generating your own in fixed layout publications. As fixed layout pages are supposed to dominate the screen space, and you have positioning control over the entire page area, you can allocate your own space.
Of course, this means adding a header and footer to every single fixed layout page you create, but using a template for your pages would speed this along. You’ll still have to manually verify the header and footer information is correct for every page, which is a limitation compared to real running headers and footers, but that’s the nature of the beast.
There will probably also be some overlap with reading system-generated headers and footers, although what information they present, and what value it is to the reader, is questionable. The reading system headers and footers are also only likely to appear during transition from one page to the next, where the ones you embed would be continuously viewable.
In other words, whether it makes sense to use them or not is ultimately a personal decision, but they are feasible when you control the page.
Although headers and footers are dead for the moment, I’m holding out hope that they’ll come back looking for brains.
But unlike the smooth, creamy goodness of human brains that make zombie pain go away, the brains needed are ones that will find a more elegant solution to the problem, so we aren’t left with a good-sounding theory on how to include headers and footers that again languishes in reading system limbo.
There’s certainly a clear desire on the part of content creators to have this control over rendering, so I’m sure we haven’t heard the last word yet.