Fallbacks, fallbacks, fallbacks

So how many fallback methods is too many fallback methods? Or is there such a thing?

EPUB 3 certainly has its share. There are fallbacks for items in the spine, content switching fallbacks at the markup level, element intrinsic fallbacks, manifest fallbacks for content elements, and even binding of media types to scripted fallbacks (before reaching intrinsic fallbacks!).

Sometimes the number of them is directed at compliance with EPUB 2 content, knowing that there would be a transition phase, but looking at each of the methods none is actually specific to backwards compatibility. And remove any of them and you lose some predictability of rendering.

This post isn’t going to be a how-to guide to fallbacks. You can read the details of each in the specs, and there’s an explanation of them in the best practices book. I’m instead going to look at the role fallbacks play and see what patterns arise.

Intrinsic Fallbacks

Let’s start at the most basic of fallbacks first: intrinsic. An intrinsic fallback is one available by default in the host grammar, whether that’s XHTML, MathML or SVG.

The object element is an example of an HTML element that has an intrinsic fallback mechanism: content embedded inside it is rendered only if the source content can’t be:

<object data="flash-movie.flv">
   <p>Sorry, but flash video pretty much died with EPUB 2. You can access this video on the web at ...</p>
</object>

You can also stack object elements to create fallback chains before giving up (and the final fallback doesn’t always have to be a failure message):

<object data="file01.abc">
   <object data="file02.xyz">
      <p>Here's my best HTML representation of this format:</p>
      <table>...</table>
   </object>
</object>

The audio and video elements are slightly different in that they have two parallel intrinsic fallback mechanisms: the source element to provide fallback formats, and embedded content as a fallback for devices that don’t recognize the elements.

<video controls="">
   <source src="clippy.mp4">
   <source src="clippy.webm">
   <p>Sorry, but this must be a dated reading system as the video element isn't supported. You can access this video on the web at ...</p>
</video>

There’s simply no way for EPUB to change or remove these intrinsic fallbacks without altering compliance to the standards themselves. You can’t just go monkeying around with HTML5 and still call it HTML5, in other words (or any of the other markup grammars). These fallbacks are about as core as you get.

The question you have to ask yourself is which intrinsic fallbacks are worth including. Since EPUB 3 requires HTML5 support, why bother with a message about not supporting HTML5 video, right?

<video controls="">
   <source src="clippy.mp4">
   <source src="clippy.webm">
</video>

A prime case for fallback messages for new HTML5 elements would be EPUB 2 compatibility, which may not be a concern to you considering all the other things that might break. But you also have to consider possibilities like whether your content will end up in a cloud-based reader. In that case, the browser used to access the content can’t be controlled, so it’s possible that someone using an older browser could be viewing your book. While the reading system itself might barf an error at the person that they need to upgrade their browser to effectively read the content, it’s probably unlikely that the person would be banned access.

A theme we’ll see more of as we go along is that the fallbacks allow normally unsupported content formats to be included (especially for object). That usage is a little more complex, as at its root is reading systems supporting content types not officially part of the specification.

Long story short, though, we’ll say that intrinsic fallbacks are a necessity, even if they open the door to experimentation.

Content Switching

Probably the least effective fallback method EPUB currently has is the switch element. This namespaced element existed in EPUB 2 and was ported forward, with some tweaks, to EPUB 3, but it’s never gained widespread traction in reading systems.

But first things first, it’s effectively like a programming switch, where the reading system can pick from a bunch of potential markup grammars, otherwise the default XHTML content gets rendered:

<epub:switch id="cmlSwitch">
   <epub:case required-namespace="http://www.xml-cml.org/schema">
      <cml xmlns="http://www.xml-cml.org/schema">
         <molecule id="sulfuric-acid">
            <formula id="f1" concise="H 2 S 1 O 4"/>
         </molecule>
      </cml>
   </epub:case>
   <epub:default>
      <p>H<sub>2</sub>SO<sub>4</sub></p>
   </epub:default>
</epub:switch>

Despite my misgivings with its lack of implementation, it’s actually a pretty handy little mechanism for experimenting with markup within markup. Not every replacement can be done at the file level, after all.

When few reading systems handle it correctly, however, it’s kind of a death knell for using it in production. Why would you implement something that’s likely to blow up in weird ways across reading systems? Maybe you’ll see nothing. Maybe you’ll see every case and the default. Maybe you’ll only ever see the default regardless of support for the cases.

I expect the switch is languishing in support because it requires a measure of preprocessing to implement. At a minimum, every case has to be hidden to properly ignore it.

So what are the needs for switching? EPUB 2 support pops up again here, since switching is rooted in that spec. You could put your MathML for EPUB 3 in a case and an XHTML or image equivalent in the default to make an EPUB 2-compatible publication, but then your MathML might not be rendered even in an EPUB 3 reading system with math support (e.g., ibooks, which supports math rendering but ignores all cases).

The currently theoretical (at least so far) need for switching in EPUB 3 proper is to allow new HTML features to be implemented before they are standardized. The picture element might be an example, but exactly how you reference these features hasn’t been worked out in detail. In other words, if we drop switch, experimentation’s going to take a bit of a hit. (For the record, I favour this kind of experimentation within the bounds of the HTML than allowing random formats to be rendered.)

Conclusion: this one is problematic. It strives for predictability of rendering in a changing web support landscape, but it isn’t well supported and also binds EPUB to the XHTML serialization (together with triggers).

I wouldn’t be surprised if it ultimately fades away, but I’m trying not to be too negative on fallback methods. And it’s just my personal opinion, which counts for little in the grand scheme of EPUB.

Content-Level Manifest Fallbacks

The next content-level fallback mechanism is via manifest fallbacks. These allow you to include non-core media types in your publication with a core media type fallback, but where the element itself doesn’t have an intrinsic fallback method.

You might want to include an image format like  TIFF, for example, which normally wouldn’t be allowed. Epubcheck would barf an error at you if you put this in your markup:

<img src="pics/somepic.tiff" alt="Some pic"/>

Since the img element doesn’t have a fallback mechanism, manifest fallbacks provide the necessary flexibility to specify a core media type:

<manifest>
   <item id="tiff01" href="pics/somepic.tiff" media-type="image/tiff" fallback="jpeg01"/>
   <item id="jpeg01" href="pics/somepic.jpeg" media-type="image/jpeg"/>
   ...
</manifest>

It’s easy to argue that these kinds of fallbacks shouldn’t be part of EPUB, at least if you think non-core media types shouldn’t be encouraged. There’s no HTML equivalent for this functionality, for one. It’s like adding a feature that HTML never decided was necessary, but then HTML was never predicated on predictability of content.

Once again, though, this feature doesn’t benefit the content producer so much as the reading system developer. It’s not the producer who dictates what formats get supported or when.

Discouraging you from playing along is that you pay the penalty in having to create your content twice for the reading system that strays from the pack.

Bindings

In the spectrum of cool ideas that probably won’t see extensive real-world use, fall bindings. What bindings do is allow you to attach a scripted XHTML document to another media type as a first fallback.

For example, say I wanted to include slideshows in my publication and there was a specialized format for them that only one reading system implemented. I want the super-awesome slideshow technology, but to cover all my bases I’d like to write a single javascripted fallback for all of them. Simple enough, I just create an xhtml page containing the javascripted equivalent functionality and bind that to the slideshow media type in the package document:

<bindings>
   <mediaType handler="impl" media-type="application/x-demo-slideshow"/>
</bindings>

The handler attribute references the ID of the manifest item containing the javascripted slideshow:

<item id="impl" 
      href="impl.xhtml" 
      media-type="application/xhtml+xml" 
      properties="scripted"/>

I’m not going to go into the details, but if the reading system doesn’t support the slideshow it’s supposed to take the arguments in the object tag, create a query string and use it to call the scripted page. You can then access those arguments from the javascript and potentially render a different slideshow for each call.

It’s a nifty feature, but a) requires a reading system to implement a non-standard format before they even come into play, b) requires reading systems to support bindings call (which isn’t widespread despite being a requirement), and c) requires triplicating your content as you’ll probably want a last case static HTML fallback for reading systems that don’t support scripting and/or bindings. That’s a lot of work, eh?

They’re another example of the push and pull between predictability of rendering and not wanting to bind anyone’s hands.

You can think of possible way to avoid bindings, but none is quite as good as the real thing. You could put an iframe inside the object, for example, and call the scripted file directly, but then you lose the ability for the last-case static fallback (i.e., bindings give a reading system the chance to not call them if scripting is not supported, whereas the iframe will be rendered whether scripting is supported or not).

Not to drag this out, at their core bindings are about supporting experimental content, so we’re again into the open question of whether EPUB bends too much to accommodate anything a reading system developer might want to support.

Spine-Level Manifest Fallbacks

And finally, there are fallbacks for spine items. (Tired of fallbacks yet?)

These allow you to put non-core media types into the spine with a fallback to a core media type. They use the same mechanism described for content-level fallbacks above, so I’m not going to go any deeper into them here. Again, they allow reading systems to deviate from the specification while keeping compatibility.

Okay, that’s not a completely fair statement. You can use them for EPUB 2 compliance (SVG with XHTML fallbacks, as SVG wasn’t allowed in the spine previous), and even for script-less reading systems (fallback from an EPUB 3-compliant XHTML content document marked as scripted to another EPUB 3-compliant XHTML content document not marked as scripted).

That’s as much as needs saying about these.

Conclusion

So what’s been learned? Anything?

Well, I think it’s fair to say that EPUB makes a lot of affordances to allow reading systems to experiment with what represents EPUB content, which does somewhat push EPUB in the direction of being more a container than a format.

A lot of fallbacks don’t benefit producers, since they open the door to duplicating and triplicating content. Producers also have no say in the experimentation, unless they throw around enough weight to make a reading system developer listen. Producers seem relegated to working within the specification during revisions.

(One thing I didn’t touch on is that fallbacks don’t mean content equivalency. Chances are high when faced with duplicating or triplicating content that a producer will just implement a hack to get around complaints from epubcheck. Requiring a core media type in the fallback chain doesn’t mean it’s going to be a content equivalent, after all. You could just dump an empty XHTML file into the chain to meet the requirement, for example. So fallbacks also have the potential to undermine the very cross-compatibility of content they’re intended to promote.)

You can also throw away all of the fallback methods except for the intrinsic fallbacks (the ones not created specifically for EPUB) and the only downside is that you have to create content conformant to the specifications as written, and only expect it to fully work on EPUB 3 reading systems. Probably not such a bad approach.

But, to wrap up, I’d probably rather EPUB had a more agile revision process that could handle the need for new formats and markup than such elaborate fallback methods for experimentation. While they’re all well-conceived, the complexity both for implementation is reading systems and by content producers suggests they’re perhaps too much.

With EPUB 2 compatibility a key consideration during the revision, however, I don’t think it would have been possible to drop any of the fallbacks ported forward. Only bindings was new, after all.

Do I hate fallbacks? No. Do I worry they might undermine the format in the long run? Possibly.

Feel free to voice your own opinion on them in the comments.

Tags: , , , ,

Reply

Your email address will not be published. Required fields are marked *