[needs further details] Purely HTML with conventions

[JayPanoz]

Just read the Wiki twice, and I guess this line probably needs further details:

An authoring format, EPUB Zero, which is purely HTML with conventions.

Judging by AMP, Apple News, Facebook IA and stuff, you probably need to address “styling” sooner than later. There’s no mention to CSS in the manifest destiny, and I can hear a very large part of authors scream already.

So is the “HTML with conventions” something like a set of components e.g. “footnote”, “drop/raised cap”, “collapsible aside”, “bleed” “images grid”, etc., in which case you try to enforce a micro format? Or something else?

Also, you’ll need styling for scripting (think about pop-up which are positioned and stuff, or even the UI).

Or maybe the idea is to provide with a set of interactions, AMP-style, with attributes in the markup, à la Mavo?

At first sight, it seems to me that “ignore any styling” and rely on proper markup attributes (classes + custom) is the saner way to go if you want to keep it stupidly simple, because stuff like <p class="title-1"> will fail visually and the author’ll have to use <h1>.

Also, it would open up the possibility of themes, including the publisher’s. Could also make it a lot easier to provide authors with a boilerplate. In other words, user-settings would be a customization of one theme away—possibly using CSS custom properties (a.k.a. variables), which makes it a freaking bliss since it solves so many problems we currently have in EPUB with so little effort, in the mid term.*

(I know this sounds like it’s trying to solve the problems of implementors but the problems of implementors have become the huge problems of authors in EPUB so I tend not to make a hard distinction.)

As for scripting, if there’s anything we can learn from epub:type=noteref|footnote, it’s that authors love it when they don't have to script at all. So it makes sense to provide with a set of common interactions, and to possibly make it extensible for further needs (extra interactions).

It seems like this model could work for both the ‘pure web; the book has it’s own UI’ situation and the ‘a reading system takes some content as input’ situation.

Footnote

* for example you could have font-family for body and headings, base line-height and the type scale (font-sizes) as variables, which would be super easy to modify whenever needed, in different contexts. You could also probably have a CSS file only for those variables so that if they aren't supported, you could “hardcode” the values on the fly.