Vertical writing

[JayPanoz]

This will be a tougher one.

Unlike horizontal RTL, for which there is an attribute you can target in CSS (dir), vertical-writing is a CSS property: you need to know its value (and there are deprecated values to take into account if you want to support IE 11). Please feel free to confirm/infirm, maybe I’m missing something obvious there.

We definitely need to constrain the height of the document in scroll mode, when vertical-writing is used, so I’ll probably bet on appending a flag inside html so that we can do that in CSS.

Unfortunately, there is another painful issue we must take into account: -epub-writing-mode (in which the prefix is the culprit).

Blink and Webkit have aliased the -epub- prefix, Gecko didn’t (FYI didn’t check Trident/EdgeHTML yet). Consequently, if the author is using -epub-writing-mode: vertical-rl, it will fail in Firefox, Gecko wants the unprefixed property there.

I’m pretty sure those issues were tackled in Readium 1 at some point, so any hint would be greatly appreciated.

I just checked on Readium based cloud reader and it seems not be handled for firefox. (Here: http://idpf.org/sites/default/files/cloud-reader/index.html?epub=epub_content%2Fkusamakura-japanese-vertical-writing).
Thinking about there might(should) be already a bunch of content created in this way, I feel it worth to polyfill it.

[danielweck]

@rakutenjeff this IDPF link points to a very old deployment of the Readium "cloud / web reader".
This is the most up to date:
https://readium.firebaseapp.com/?epub=https%3A%2F%2Fcdn.rawgit.com%2FIDPF%2Fepub3-samples%2Fmaster%2F30%2Fkusamakura-japanese-vertical-writing&epubs=epub_content%2Fepub_samples.opds
(same "kusamakura-japanese-vertical-writing" EPUB from the official IDPF samples, directly loaded from GitHub)

Thanks @danielweck. I just checked the above one on firebaseapp and it displayed horizontally as well.

[JayPanoz]

Just checked with the most up to date and Firefox ignores the vertical writing.

While it should be

So, if it only relies on CSS’ vertical writing, I can confirm -epub-writing-mode will be an issue if the unprefixed property is not used as well (this is actually the file I originally used to check support).

[JayPanoz]

And despite native EPUB support, Edge 16 seems to not support it either (so it’s safe to assume IE11/Trident doesn’t).

[JayPanoz]

EPUB 3.1 spec mapping for future reference, since it impacts a significant list of properties: http://www.idpf.org/epub/31/spec/epub-contentdocs.html#sec-css-prefixed

[jccr]

I have always wondered how the -epub prefixed CSS prop for writing-mode worked out of the box in Blink/Webkit without some sort of JS logic. It's an alias coded in webkit/blink! -epub-writing-mode alias_for=-webkit-writing-mode -epub-writing-mode is an alias for -webkit-writing-mode

[danielweck]

Yes, and CSS property alias deprecation is also an interesting topic amongst browser implementors in the CSS Working Groups ;) (for their own respective vendor prefixes)
But yeah, the -epub- prefix is an odd one :)

[JayPanoz]

Yeah they probably added that at the time they implemented stuff they needed for iBooks directly in Webkit. There’s a couple of other extra properties for which they added support (e.g. -webkit-line-box-contain to deal with raised caps) at some point.

But as far as I can tell, they’ve stopped doing that so should they deprecate and remove that, here goes support.

To clarify, the issue really lies in CSS authoring, it’s been bad practice to use prefixed properties without the (at least expected) standard one and this is what we’re having to manage there.

From the EPUB 3.1 spec (emphasizes mine):

CAUTION

Authors are strongly encouraged to use unprefixed properties, and Reading Systems to support current CSS specifications. The widely-used prefixed properties from [Content Docs 3.0.1] have been retained, but support for the other properties has been removed. Authors are advised to use CSS-native solutions for the removed properties where and when they are available.

Authors currently using these prefixed properties are advised to move to unprefixed versions as soon as support allows, as these properties are not anticipated to be supported in the next major version of EPUB.

Unfortunately, we don’t have data so we don’t know how many files use the prefixed property only. But if people actually checked the sample we’re testing there, it means the bad CSS practice might have spread pretty widely.

[JayPanoz]

The dated references may also become a complication, cf. http://www.idpf.org/epub/301/spec/epub-contentdocs.html#sec-css-writing-modes, and it seems that people may want to translate that to:

The rule might have changed, or will change in the future, yet -epub- prefix guarantees behavior consistent to when EPUB 3 standard was defined. (Source: how to article).

I really don’t know how tricky this could become at some point.

I agree with this is rather a bad css practice problem. On the other hand, I am afraid there are (could be) a lot of existing JP contents are created with prefix -webkit- and -epub-. The reason is there is a widely used JP epub template (http://ebpaj.jp/cmspage/wp/wp-content/uploads/2015/04/ebpaj_epub3guide_ver1.1.3-en-1.zip) in the book-template.epub you can see stylesheet (stylestandard.css) is created in this way unfortunately... It would be awesome if can provide some solution to cover those prefix problem.

[JayPanoz]

Oh definitely, this is one of my fears as well, since this is what happened with prefixed properties on the web already: the -webkit- one was used and that’s it, which is why Microsoft had to add support for the -webkit- prefix recently.

So, let’s sum up the current situation:

• we know Webkit and Blink have an alias, which means we’re OK on:
  • Safari/Chrome;
  • iOS/Android.
• this issue primarily impacts Gecko and Trident/EdgeHTML so that’s:
  • Firefox/IE11/Edge;
  • Windows (PWA, UWP, native).
• for at least RTL, we can rely on:
  • page-progression-direction in the manifest;
  • the dir attribute (all things considered, I wouldn’t bet my life on this one though).

There might be other browsers we must take into account on the markets impacted.

If we choose to polyfill there, we’ll need to:

• explicitly state we can’t conform to the EPUB 3.0.1 spec (i.e. dated references since the polyfill will evolve according to the W3C spec);
• nitpick the properties and values we should polyfill (see list and mapping in the EPUB 3.1 spec);
• find out if there is some super clever way to do it so that we don’t take a huge performance hit – my assumption being we might do that only when we find some languages declared in the manifest or XHTML files, my gut feeling being that option won’t necessarily be reliable and we’ll have a significant failure rate;
• plan to switch to Houdini (CSSOM) when available;
• make it clear than patching those files’ CSS before distribution would be the best option (if there is a possibility to do it), but side loading files would still be an issue.

@danielweck and @jccr You’ll be the ones mostly impacted there, as it requires doing things at runtime. Do you have any thought or remark you’d like to add to this list?

I know we’ve discussed that in the Readium 2 engineering call and we agreed that:

• it is a complex problem as it requires detection and handling of the vertical writing at runtime;
• whether this is a requirement, in the short-term, for the web implementations;
• discuss this issue with the publishers and sellers impacted.

But it is starting to feel like this is a problem we’ll have to deal with sooner or later.

[edit] On a related note, we’ll probably have to choose in which repo the polyfill issue should be moved since even if it is related to CSS, it out-scopes Readium CSS quite significantly.

[JayPanoz]

An important detail being that you can’t obviously get the computed style since the property is not supported. Here’s what Firefox returns for instance:

So we’re entering the dark side of polyfilling CSS there: fetching the stylesheet(s) to find the properties/values.

If we can do that any other way (for instance in the streamer), we’d better try it first.