CSS Feedback from Readium users

[dauwhe]

Just want to make sure we don't forget this: readium/readium-css#17

[JayPanoz]

I can provide further details regarding some points (I guess this is the best place to record them). Please consider it some implementation feedback which can serve as some kind of info.

Interop

We’re spending a lot of time and energy to make sure Readium CSS, and Readium 2 in general, are interoperable.

For instance, we had to replicate some other Reading Systems’ styling in some places to make sure we can guarantee some kind of interoperability on some platforms (e.g. iBooks/iOS).

At the Readium 2 level, I know decisions related to page numbering (dynamic) or non-linear contents have been taken based on interoperability as well.

So, let’s say we have a legacy to deal with: authors usually design their CSS with this legacy in mind, users have expectations in terms of UI/UX, etc.

To sum things up, any “breaking change related to rendering” in the existing or upcoming EPUB specs would need some kind of flag at the file level (remember the “do-not-override” switch).

Flag

Although it’s still a little bit early (user agent properties are just a proposal at the moment), I do believe that the flag itself wouldn’t be enough, it would need user-centric authoring.

In theory, if an author sets this flag, and makes sure to use user agent properties in his/her CSS, we just have to set values dynamically, we don’t have to override anything. But if the user sets the flag and don’t use user agent properties at all, there is no way we can respect this signal (back to user expectations).

Does this put the burden on authors? Sure. But given the nature of the CSS language, there’s very few alternatives I can see working in real life.

Font size

I know I already reported that during the last conference call, but font-size is the worst™ (source), and authors using absolute values don’t help.

User have this expectation that increasing/decreasing font-size will indeed increase/decrease font-size, but we don’t have anything specific to achieve that in CSS (and zoom is a proprietary property even Microsoft doesn’t want to deal with anymore).

So the worst-case scenario is walking the entire DOM to change the font-size for every tag, because you can’t increase/decrease the :root font-size and expect 100% of EPUB files to work (px, pt and keywords value are the issue there). I’ll let you imagine the huge performance hit of doing so.

We’re trying to get around those absolute values in pure CSS (without the CSSOM, which makes it even more complex) but I can’t guarantee this is what we’ll end up using.

This is an issue we’ll have to deal with anyway, but it would be useful to explicitly tell using absolute values for font-size (and thus line-height) is bad practice as it can break the font-size user setting in Reading Systems and degrade accessibility.

I feel this is all the more important as some authoring tools, developed by companies also developing EPUB apps, will output absolute values for those properties. So that’s perpetuating the issue and re-inforcing the technical debt.

Hard-to-implement specs

Although I’m not directly involved in those implementations, I know some (part of the) specs are really really hard to implement well. For instance, I can tell navigator.ePubReadingSystem requires a lot of efforts and compromises to work as expected, while very little content is making use of it, because implementations are lacking (chicken, egg, etc.).

That’s also true of any property or value prefixed with -epub-. When you rely on web browsers’ rendering engines, and build on top of them with web languages, it’s super super difficult to implement support for it. We must in practice polyfill them if the rendering engines didn’t alias them, and polyfilling is so hard that polyfill.js has been put on a hiatus, waiting for Houdini.

The alternative is sponsoring a consulting company to add support in rendering engines, cf. Igalia + Bloomberg.

[antelopeb]

Font-size has the same issue for accessibility in regular web browsers. If you set static font sizes on elements within the browser, you screw it up for people who use custom stylesheets, which is pretty common for people with dyslexia, low-sight and other problems (like turning off animations). It's a common web-dev problem at this point, so is it something we have to plan for, or is it something we just have to educate people on?

On that note, browsers use different capabilities to scale the page up and down, so maybe reading platforms need to adapt to content vs trying to hope that everyone who authors will follow the rules? After all, I still see newbies in the industry using

tags, so we all know that bad habits die hard.

I don't know the answer, but maybe it's beyond this spec to try and solve it.

[JayPanoz]

so is it something we have to plan for, or is it something we just have to educate people on?

We have quite a “legacy” to take into account (millions of files already distributed) so we have no other choice than planning for it at the moment.

But education is always good, obviously, especially if it is a11y-related.

On that note, browsers use different capabilities to scale the page up and down, so maybe reading platforms need to adapt to content vs trying to hope that everyone who authors will follow the rules?

Being pragmatic, I guess it’s not worth hoping that everyone who authors will follow the rules. But at least there is a possibility to say that if some critical authoring practices are not followed, then you can’t expect things to work as expected.

Just an idea there, nothing else, but at some point (when Houdini’s widely available and you can parse stylesheets way more easily), some Reading Systems could simply choose to strip the font-size user setting from their UI if they find values they don’t like and fall back to PDF-like zooming. Or normalize those font-sizes (which will obviously be more work), etc.

In Readium, changing the font-size is a complex process. The whole DOM has to be walked in order to find specific elements, then check the computed values for font-size and line-height, those elements are modified using a style-attribute, and their original values are stored (using JS). They had no other option at the time, and it is a quite a demanding job for the rendering engine (reflow, relayout, recalc, etc.).

As far as I can tell, this is not an uncommon strategy (other RSs are doing this as well), and when your Reading System must be cross-platform, there are very few alternative options; you don’t have the flexibility to do some settings in native code. If I fail to manage that well enough in Readium CSS for instance, we’ll go back to the original JS solution for font-size.

I don't know the answer, but maybe it's beyond this spec to try and solve it.

Oh yeah, don’t know either, and I guess this is why best practices exist.

My personal viewpoint is that specs shouldn’t try to solve everything.

Worst-case scenario: the author is building a lib, a spec is published, and all of a sudden his/her lib becomes a ponyfill, which means he has now to try abiding by the spec. Unfortunately, it can kill the lib if some parts of the spec are too difficult to do in JS. Or he/she can ignore the spec, but spec-alignment may become a popular request at some point… and we’re back to square one.

To be honest, I’m not even expecting ePubCheck to put a kind of warning for that, since we have to support W3C snapshots in EPUB 3.1. But yeah, we’re back to IE6 with absolute values for font-size, we have nothing in CSS/JS yet to specifically deal with this at the RS level.

[JayPanoz]

I’m taking the liberty of adding our (Readium CSS) EPUB compat issue as it discusses some authoring pain points, CSS practices, implementations’ shortcomings, etc.

Authors’ requirements, interop and compat being strongly tied, I guess it makes sense to do so.