What’s the baseline for best practices?

[JayPanoz]

In issue #30 @llemeurfr said:

Such a discussion must take into account a reality that seems too often hidden: they are two kinds of reading systems: those which are built around a Web rendering engine (Chrome, Webkit) and therefore support the extended range of CSS properties supported by the underlying engine; and on the other side almost every e-ink reader and some well known apps (incl. FBReader I think) which are built around an in-house rendering engine and support a limited range of CSS properties (from different levels). It would be more than sad to have best practices limited to the intersection of all RS implementations, but it's very very difficult to create EPUB 3 publications that contain "progressive enhancements".

Now, there are quite a handful of issues for which setting such a baseline will be useful: #30, #31, #32 (which is discussing Kindle), #38 (depending on the baseline, fallbacks won’t be the same), and #48.

Examples:

• if the rendering engine doesn’t support CSS, it can become tricky to handle HTML5 elements because you can’t normalize their display and they consequently are inline for instance;
• if you take RMSDK < 11 into account, then using calc() without safeguarding it (@supports) will break CSS parsing and the entire stylesheet will be ignored;
• if you take some other, then <hr/> is not even implemented;
• etc.

There are very different levels of support, should Reading System Conformance serve as a basis? What do we make of less-capable apps used by dozens of millions of users?

As a matter of fact, for a lot of practices, we’ll probably be able to find Reading Systems which choke on something and things go horribly wrong. Now, we know a lot of authors already delay their use of css modules, HTML elements, etc. when they are not supported somewhere significant, even if they don’t create issues…

[teytag]

I design EPUB3 for corporate companies. And, I use TextMate. I mean, I'm a designer who dominates everything. I develop content and design in line with the feedback of company employees. In the meantime, employees like to listen to their corporate ebooks.

However, on the other hand, another important problem emerges in educational institutions. For example, when you switch from IOS to Android, the performance of the device changes. And some documents need to be reproduced in EPUB3 format. Even when device usage habits change, there is a problem. In this example we see that the RS change is also creating anxiety for the user.

This may or may not matter. However, it may be necessary to give importance to user feedback in "best practice" studies. Maybe a large-scale survey of needs. I do not know exactly.

N. Erhan Uzumcu

On May 11, 2018, at 12:44 PM, Jiminy Panoz notifications@github.com wrote:

In issue #30 https://github.com/w3c/publ-cg/issues/30 @llemeurfr https://github.com/llemeurfr said:

Such a discussion must take into account a reality that seems too often hidden: they are two kinds of reading systems: those which are built around a Web rendering engine (Chrome, Webkit) and therefore support the extended range of CSS properties supported by the underlying engine; and on the other side almost every e-ink reader and some well known apps (incl. FBReader I think) which are built around an in-house rendering engine and support a limited range of CSS properties (from different levels). It would be more than sad to have best practices limited to the intersection of all RS implementations, but it's very very difficult to create EPUB 3 publications that contain "progressive enhancements".

Now, there are quite a handful of issues for which setting such a baseline will be useful: #30 https://github.com/w3c/publ-cg/issues/30, #31 https://github.com/w3c/publ-cg/issues/31, #32 https://github.com/w3c/publ-cg/issues/32 (which is discussing Kindle), #38 https://github.com/w3c/publ-cg/issues/38 (depending on the baseline, fallbacks won’t be the same), and #48 https://github.com/w3c/publ-cg/issues/48.

Examples:

if the rendering engine doesn’t support CSS, it can become tricky to handle HTML5 elements because you can’t normalize their display and they consequently are inline for instance; if you take RMSDK < 11 into account, then using calc() without safeguarding it (@supports) will break CSS parsing and the entire stylesheet will be ignored; if you take some other, then

---

is not even implemented; etc. There are very different levels of support, should Reading System Conformance serve as a basis? What do we make of less-capable apps used by dozens of millions of users?

As a matter of fact, for a lot of practices, we’ll probably be able to find Reading Systems which choke on something and things go horribly wrong. Now, we know a lot of authors already delay their use of css modules, HTML elements, etc. when they are not supported somewhere significant, even if they don’t create issues…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/publ-cg/issues/64, or mute the thread https://github.com/notifications/unsubscribe-auth/AGmy-v6cL6k2KKiVm9J7PqmF4gRA14dGks5txV1ygaJpZM4T7MLy.

[RachelComerford]

There is an IEEE group that is focusing on reading system standards/consistent experiences/interoperability: IEEE Learning Technology Standards Committee (IEEE-LTSC). It sounds as though their efforts may be relevant to this question.

The best practices documentation we're working on right now is focused on building usable, accessible, interoperable epubs that meet the needs of specific markets (such as journals or education). A part of that is identifying where interoperability will not be available (ie when specific reading systems don't support certain features).

[teytag]

We produce EPUB3 conforming to the standards. I know the meaning of "Best pratice". However, some reading systems do not support your design. This leads to design generation by focusing on a uniform reading system. So how do we show our power to design EPUB3? How do we present new and good examples? How will we contribute to the development of the EPUB3 format? As an EPUB designer I wanted to put up with this problem.

N. Erhan Uzumcu

On May 11, 2018, at 5:48 PM, RachelComerford notifications@github.com wrote:

There is an IEEE group that is focusing on reading system standards/consistent experiences/interoperability: IEEE Learning Technology Standards Committee (IEEE-LTSC). It sounds as though their efforts may be relevant to this question.

The best practices documentation we're working on right now is focused on building usable, accessible, interoperable epubs that meet the needs of specific markets (such as journals or education). A part of that is identifying where interoperability will not be available (ie when specific reading systems don't support certain features).

[JayPanoz]

BTW, is the BISG survey available publicly?

I can commit to at least add useful details to some issues if it is – cf. some issues where we’re trying to know what is discussed more precisely.

[RachelComerford]

@JayPanoz sadly - I pasted all of the detail I received into the tickets that I opened. Not a lot of detail from the survey takers. I've been reaching out to them as I have bandwidth to get more information where I can. If there's an area where you're interested in digging in more and providing the initial documentation for the team to discuss and review I would be VERY happy to put you up with the respondent that provided that feedback so you could dig into the need more :D

[RachelComerford]

@teytag I think what you're asking about - the interoperability of the spec and how to contribute to future development - actually speaks more to the work that the Publishing Working Group is doing on WP/PWP/EPUB4

[RachelComerford]

I'm going to close this issue since I haven't heard back - hope these answers helped!