search

readium / readium-css

🌈 A set of reference stylesheets for EPUB Reading Systems, starting with Readium Mobile
https://readium.org/readium-css/
BSD 3-Clause "New" or "Revised" License
90 stars 20 forks source link

Fallback strategies for implementers #14

Closed JayPanoz closed 6 years ago

JayPanoz commented 6 years ago

This is an issue I prefer to open early, as discussions will undoubtedly happen when web app implementations will start.

To sum things up, we leverage CSS custom properties (a.k.a. variables), and that makes Readium CSS customizable, JS-friendly, flexible and fast (so far, since we don’t have to traverse the DOM all the time).

Unfortunately, there are a few browsers which won’t, or currently don’t, support CSS Variables. In particular IE11 and Edge 14. While I’ve been designing with this lack of support in mind (for instance, user settings can inherit from inline styles added to html whenever possible), other parts will need a fallback strategy.

It’s worth noting I could actually manage a fallback strategy in pure CSS. Indeed, we could write a static representation as the default, then switch to CSS Variables using feature queries (@supports).

It’s hard to say which strategy will be the best option though, as we need feedback from practical implementations. Some developers will probably resolve to classes or attributes (html) to manage that, others to JavaScript, others might simplify user settings in that case, etc. And there’s of course a consistency concern there.

Needless to say stylesheets can be edited if needed. Implementers could obviously use classes/attributes in the reading modes and user settings stylesheets, they’ve been designed to be strategy-agnostic (the cascade and inheritance being a key there, as this is what will allow implementers to avoid traversing the DOM in JS, wherever possible).

So let’s keep that in mind and see how we can work it out once this issue arises.

JayPanoz commented 6 years ago

A small update: we’re using CSS variables in the iOS implementation, for both flags and updated values, with inheritance kicking in whenever possible.

Which means that if you need it to be cross-platform, flags can be custom data-* attributes, most values can be appended as inline styles on html and some other user-settings can once again be custom data-* attributes, with preset values.

For instance

<html style="font-size: 200%; font-family: Seravek, sans-serif" data-reading-mode="night" data-user-margins="xl">

So you should still be able to manage everything in the same place: the html tag. I’ve made sure that our approach could quickly turn to fallbacks if needed when we started designing it.

Of course it requires you edit stylesheets’ selectors a little bit (user settings) but you should get ± the same performance as the one we can currently get in iOS.

JayPanoz commented 6 years ago

So to put it simply:

  1. Most of ReadiumCSS should work if you build a static representation (using the postcss-css-variables plugin, as described in the PostCSS doc), so you can definitely use it;
  2. user settings won’t though, so you’ll have to implement that using JS for instance.

In other words, change the custom selectors to manage reading modes, flags (advanced settings) and use either custom attributes or classes, then manage user preferences using JS (you can test for CSS variables using JS, as explained in the CSS variables doc).

There is little chance this decision will be reversed in the future as it’s a lot of work for a small usage and user settings fallbacks were partial, and subpar, especially as we removed support for Android 4.x.x.

You can still use this issue for questions though.