Authors’ issues, how Reading Systems could help, and how to implement helpers?

[JayPanoz]

Warning: this is a debatable issue for which we MUST get feedback from both implementers and authors.

[This original message was edited with the following TLDR for clarification. It will also be easier to keep track of issues this way]

TLDR

Scope

The aim of this issue is to list common issues CSS authors have had to deal with. It is not strictly scoped to Readium CSS since I will document those issues so that could also serve as a reference for the upcoming specs.

At the moment, we’re very far away from discussing “how it should be done.” The idea is to explore whether “it can be done.” This will probably require prototyping and beta-testing in ways which are not 100% standards-compliant but beta-testing will also be documented so that the maximum amount of information can be made available.

Also, it’s worth repeating that two important changes were made in the EPUB 3.1 revision:

1. undated references to HTML in EPUB 3.1
2. replacement of EPUB Style Sheets with CSS References

We have to take that into account, which is why I’ll be referring to the HTML design principles for the sake of anticipation.

Most use cases will probably be about styling since I’m dealing with CSS there (there could be interactive use cases as well, but that’s out of this project’s scope). This has a lot of implications, the major one being it should not be markup territory.

What is critical is a list of use cases. So let’s focus on that at first. There may well be use cases interesting to the web platform, so “how it should be done” is extremely conditional (e.g. use cases fit for ARIA or specific media queries because they are a11y-related).

Use cases

• invert images in night mode (and possibly other styling depending on reading modes)
• bleeds, cf. EPUB-CG — Rendering

Original Message

While documenting the wiki, I came across nasty hacks which I’d personally like to prevent if possible.

• iBooks’ theme detect in CSS
• Device-specific styles via JS
• Some authors have also been using the iBooks’ meta for gaiji since it inverts images in night mode

And so on and so forth.

Worst-case scenario: it becomes a technical debt on the RS side.

Best-case scenario: it stops working at some point and authors will update their files.

Real-case scenario: it becomes a technical debt on the RS side if hacks’ usage is significant, authors don’t update their files, a minor update introduces regressions, nobody’s happy.

I guess we could acknowledge there are issues for which we definitely need authors’ help. It could be seen as some kind of “help us help you” mechanism. After all, the more hacks authors will create, the more issues we’ll have when it comes to reading modes and user settings.

For instance, we could imagine something like:

<img alt="Desc" src="img/my-image.png" data-reading-mode="adapt" />

In which data-readind-mode="adapt" ("adapt" is there because XHTML but we can make it boolean) automatically inverts or “sepiaes” the image with a CSS filter, depending on the current reading mode selected by the user.

If epub:type="noteref|footnote + popup is any clue, authors are likely to use such a mechanism if they can benefit from it.

In that case, we must reserve styling and make it clear it’s the RS’ responsibility to deal with it, not the authors’. And use super-specific selectors so that it has no effect on other elements.

Considering the image example, implementers might choose darker or lighter shades for some modes and will have to fine-tune filters accordingly, so that the background colors are exactly the same.

Of course there are probably other cases, and managing it entirely through CSS will make it more maintainable, updatable and portable (for other SDKs).

Custom attributes will be EPUB3-only though. But this is already the case for epub:type so, as far as I’m concerned, it’s not an issue. It’s whether we consider it presentation (classes) or behavior (custom attributes).

Sure, there are alternate stylesheets but support has been so rare that very few people have used it. And they are not likely to use it if other major RSs don’t support it, so I’m trying to be pragmatic here.

If we decide to provide such an “API”, question is do we design it as some kind of standard in disguise other SDKs can use, especially as authoring tools’ implementation is another issue to consider. It’s high time we tackle those issues, especially as implems might drive standards, w3c-style.

I’d like implementers and authors to discuss this, because I feel it’s a critical issue for which we have to find compromises sooner than later. It could also be of interest to browser vendors for reading modes (Safari, Pocket & al.) since authors might require such mechanism at some point.

Also, if you’re an author, please feel free to list problematic issues related to such a public API.

[acabal]

This sounds similar to the suggestion I made to IDPF back when they were soliciting suggestions for the next revision of the epub spec: w3c/epub-specs#672 @JayPanoz you got involved there too.

My thoughts are basically in that post. The crux of the problem, and the reason why device-specific hacks exist, is because there is not standard required CSS baseline for reading systems. Thus each one implements its own baseline. Since epubs are "frozen in time" at distribution, that leaves authors stuck with putting in as many hacks as they can to get their single epub looking nice on the widest variety of ereaders.

This is the exact same problem we see in the modern web, which developers mitigate by using a normalize.css stylesheet. These days the problem isn't as bad as it used to be, since browsers are starting to converge in their default stylesheets, but it's still there.

IMHO this is probably solved the easiest by making it a requirement that all reading systems conforming to the spec implement a baseline CSS stylesheet, and leave it to the ebook to style the rest. The baseline can be cascaded over by author styles, and reading systems can reserve some small number of properties to ultimately override, like text-justification or background-color. This can be achieved by making it a hard requirement in (for example) epub4, and reading systems can inspect the ebook's epub version number to decide on whether which default stylesheet to build on.

As far as what to put in the stylesheet, I think the HTML5 recommended stylesheet is a perfectly good choice for that. Since print and ebooks can have such wildly differing style and layout, it'd be futile to try to think of some alternate "perfect book stylesheet" to pick as an alternative. It's not as important to decide what goes in the stylesheet, as it is getting everyone on board to pick some single common default.

That approach would basically mimic what web browsers have been doing for many years--which makes sense because what is an ereader but a web browser with no scrollbar--but we have the head start of being able to reflect on the various issues the web has had to solve during its growing pains.

[JayPanoz]

Thanks for your feedback, and you’re right, I was indeed involved.

To clarify, I’m talking EPUB 2/3 stuff here, trying to find some specific compromise for these two versions of the format, because there is a short term (EPUB) and a longer term (Web Publications).

@HadrienGardeur can give more details about EPUB4/(P)WP but the basic idea, since we’ve discussed it lately, is having a super lightweight layer not interfering with authors’ CSS. I guess it would make more sense to discuss the longer term on this dedicated issue.

As for the shorter term, I’m just trying to be pragmatic. I’m an author (turned “RS implementer”) myself and any progress is significant. Authors have expectations we can’t really break for EPUB but there’s a possibility we can make it more a little bit more comfortable to them when it comes to recurring issues.

[acabal]

Yeah if we're just talking about some kind of compromise between a new reading system that wants to implement epub2/3, then I don't think we're going to get anywhere with that. IMHO the standard is both too complex and too lax, and bad epub authors have released too many bad epubs for us to bother with trying to massage things further.

Personally I think this issue can only be fruitful if we're discussing a new version of the standard, where we can simplify a lot of the cruft and enshrine new requirements and baselines, and then educate epub authors on best practices. But for epub2/3, with its curse of distributed files being "frozen in time" and not updateable like web pages over http are, it's way too little, too late :)

[JayPanoz]

OK, have thought about if for a while and I can at least clarify my own ideas.

The thing is the current page margins’ implementation (see issue #2) brings a lot of flexibility at the RS level and could allow for interesting layouts. This implementation is still hypothetical though, I must stress-test in the next weeks and see if we can indeed use it or apply all margins at the web view level. Anyways, it opens up new possibilities which aren’t currently covered. I’m not saying we should spec stuff at all, I just believe that it would at least be interesting to discuss them and maybe experiment with it if there is a visible incentive and technical possibility to do it.

Now, until Houdini becomes a real thing you can use in production, I can’t see stuff added to CSS going anywhere. Supporting those values/props implies performance issues. And considering the average (Android) smartphone is going cheaper, our performance budget will stay pretty limited for a while (so much that I’ve already planned to investigate performance optimizations we can get via the new CSS specs Chrome is promoting e.g. CSS containment, will-change, etc.). As a disclaimer, I am myself impacted: I own a middle-range Android device and reading ebooks with a lot of apps is super painful (slowness, rendering with heavy stylesheets, latency, etc.).

In other words, I consider this is a long term issue for various reasons. In the meantime, I’d like to explore what you could call “CSS Author’s Intents.”

The following is of course a simplistic abstract but:

1. Reading Systems control the config (pagination, reader modes, user settings, margins, etc.);
2. Authors are usually not provided with “APIs” to style according to the config, but some will find ways to do it anyway;
3. Some hacks may cascade into further issues and fixes/overrides at the RS level;
4. Enters JavaScript, which might result into a dump fire someday (have been personally super cautious about that as an author but with resizeObserver and other stuff on the radar, it could escalate super quickly).

In other words, RS have information authors doesn’t have, they can theoretically help authors do some things e.g. invert transparent PNG/SVG in night mode, do bleeds, put page numbers in margins, display footnotes (which is already being done automatically based on the epub:type attribute), etc. Currently, I can make most of those examples happen with pure CSS, but I need a signal at the markup level.

How a “CSS Author’s Intent” could help, you may ask?

• in its simplest form, it could be a data-attribute, which MUST be left unstyled (but styles for the class or element can be declared);
• the Reading System is responsible for the intent;
• the Reading System can manage this intent, depending on the config (it can ignore it, apply styles in some configs, etc.);
• if it’s not supported, it hasn’t any impact;
• if it’s simple enough that you can implement it via RS stylesheets, there’s a possibility it will be implemented, should authors require it.

Of course, I’m taking the W3C’s priority of constituencies into account and, well, it seems clear to me authors and implementers playing cat and mouse won’t help users in any way.

It is also worth mentioning that with Reader Modes in web browsers, especially as some browsers are willing to push them (cf. Safari in High Sierra), UAs now share some issues with ePublications (images management in night modes is an obvious one). Currently, they’re ignoring CSS and JS entirely but it has side effects which can hurt user experience e.g. having icons displayed at 100% of the container’s width.

As far as I’m concerned, I can design mechanisms at the CSS level if there is a class or an attribute in HTML so that shouldn’t create extra work at the JS/Swift/etc. level. I’d much prefer an attribute so that there is no collision with classes though. But what’s important is that I can kickstart experiments during dev/testing to see if 1. it can work and 2. it can be useful in practice.

I need authors’ feedback though. Here are some examples I’ve been experimenting with our current pagination implementation, maybe it can give you ideas (pinging @dauwhe as there’s almost an epub-bleed in there).

Edge-to-edge header background.

Edge-to-edge image.

Image bleed which doesn’t block text.

Once again, it’s hypothetical, I can’t make any promise, there is a lot of different factors to take into account at the RS level, but if we don’t discuss, experiment and beta-test it, we won’t know.

[acabal]

I'm not sure if adding a new "author's intent" data- attribute (is that what the idea is?) would be much more helpful than the situation we have now. In many ways, the HTML document itself describes the author's intent. HTML5 gives authors great tools in the form of semantic markup that describes the intent of the document they're laying out, and the epub spec which gives authors epub:type and a richer book-specific vocabulary to describe.

The problems are that (and I know you know this, I'm just putting out in the interest of public discussion):

1. Authors (aka ebook developers) don't care/are poorly educated on semantic practices, so they just use <div class="myparagraph noindent"> instead of <p>. Because <div> is meaningless and class names are arbitrary, this gives zero hints to the RS on what the author's intent was. This pattern is super common in a lot of ebooks, and is also be the fault of epub creation programs which spew out automated garbage markup. (Which in turn is the fault of the epub spec for being far too complicated for what it does, forcing people to turn to a program to simplify epub creation.)

2. RS developers all have different ideas of how to render ebooks and how to apply overriding styles, and all have different subsets of CSS and HTML that they do or don't support, and keep all of it top secret. This turns epub creation into a nasty guessing game for authors, who are so busy trying to hack each ereader's styling rules that they don't have time for semantics. Part of the blame on this is also on the epub spec, which has had enough time to recognize that RS developers need guidance too. (Like HTML has recognized with a default stylesheet defined in that spec.)

So as far as an "author's intent" attribute goes (if I'm understanding it correctly), I suspect that it would wind up being more complexity that RS's will ignore, and that authors won't know/won't care how to use because they already don't care about semantics, or they use an epub creation program that can only apply super complex styles to an unsemantic DOM.

Better, I think, to embrace the rich vocabulary HTML5 and epub already give us, and to simplify the spec so that authors don't feel the need to rely on epub creation programs.

[JayPanoz]

Well, actually no, I don’t know the authors’ intent from the markup. Take figure for instance:

The figure element represents some flow content, optionally with a caption, that is self-contained (like a complete sentence) and is typically referenced as a single unit from the main flow of the document. (Spec)

Please note the “The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc.”

This interesting note also

When a figure is referred to from the main content of the document by identifying it by its caption (e.g. by figure number), it enables such content to be easily moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix, without affecting the flow of the document.

In the examples you’ll find some use cases:

1. mark up a code listing;
2. mark up a photo that is the main content of the page (as in a gallery);
3. mark up an image;
4. mark up a video;
5. mark up a poem;
6. mark up a group of (nested) figures (as in a carousel or grid);
7. you also have an image which is part of the block quote (not using figure).

I can add some use cases as well:

• mark up ASCII art;
• mark up diagrams and charts generated via JS (which use either canvas or SVG);
• mark up audio;
• mark up a table of statistics;
• mark up an ad (because it’s not just books);
• etc.

So to sum up, I have edge cases for high contrast mode, invert, sizing, whitespace, etc. all over the place because figure is not only for images. And that’s only a sample of what figure can do, authors might come up with quite inventive use cases since the spec definition can be interpreted in so many ways. And ARIA roles for documents don’t cover all those use cases.

Styles-wise, it can be floated, it can be full-bleed, it can be a grid, it can be a slider, it can have a background-color to make it clear it is self-contained (night mode), or be using an icon system for some reason (night mode, user settings), it can use an embedded font I should not override, or use syntax coloring for code, and so on and so forth.

Enters ARIA, which is kind of an authors’ intent by the way, schemas, etc. and I have an awful lot of combinations to manage, will quite probably create additional bugs as a consequence, it will become unmaintainable at the RS level because you also have to take reading modes and user settings into account, it will turn into a nightmare then a failure because it’s so much debt, and we’re back to square one.

More importantly, like I said, it’s just about exploring such a mechanism, because you need to prove there are use cases for stuff to have a chance of becoming standard. Please consider the W3C model, we moved away from the IDPF model months ago and this has several meaningful impacts about standardization—in some cases, you might even be asked to prove it can done with what’s already available, and not something designed in isolation, requiring what wasn’t implemented or doesn’t exist yet; webkit implemented ARIA doc roles weeks after the spec/mapping publication, they didn’t bother implementing epub:type they deemed uninteresting while it’s been 6 years now.

Finally, Readium 2 will not only be about EPUB2/EPUB3, it was designed to deal with what comes next. And you will very likely encounter some of those issues again in the future, in browsers (reader mode, browsers settings, etc. are features browsers vendors certainly won’t disable because you ask them to).

Am just trying to be pragmatic, for all those reasons. And the more I can work on during dev/prototype, the more we’ll learn how to manage issues in future specs. In case it was not clear, a large part of my work is about collecting feedback, discussing current issues and possibilities with CSS authors, and document quite possibly everything CSS-related. So, there’s also a long-term aspect to my mission.

Also, for the record, the EPUB 3.1 spec allows the creation of custom attributes. I’m not even talking XHTML custom attributes there, just HTML5 custom-attributes for the sake of R&D during dev. “First do it, then do it well.” (in that case, my goal is just checking whether it’s possible and realistic or not.)

[acabal]

Sure, that's true. But that's what epub:type is for. I can do <figure epub:type="z3998:illustration"> for instance. (And that is what we do do at Standard Ebooks.) The default epub vocabulary is not rich enough for the general case, but there are other vocabularies one can pull from (and epub should probably just standardize on schema.org instead of its mishmash of dc and custom).

An RS doesn't have to support every possible semantic suggestion ever, just the big common ones. Like we were discussing for night mode on the SE mailing list for example--our current solution is to add a custom color depth epub:type semantic to <img> tags that show raster images (like PNG), and the RS can infer that if an image is marked as the "black on transparent" color depth then it's OK to invert in night mode. Our SVG images have no fill/stroke color so the RS can render them in its fill/stroke color of choice if it chooses.

So if we were to add yet another attribute to indicate author semantics, we'd wind up with something like <figure class="illustration" epub:type="z3998:illustration" data-author-intent="its-an-illustration-for-goodness-sakes"> Which, of course, all RS's will probably ignore anyway, since they already do a good job of mostly ignoring epub:type as it is :)

[JayPanoz]

Well, this is where our views are differing, I guess.

To sum up:

• epub:type has been a poster child for “EPUB3 doesn’t play nice with HTML5.”, which also partly explains the move to ARIA doc roles.
• Web Platform: Make previous versions of HTML and XHTML obsolete

So, if you want something to be future proof, forget designing it around epub:type or anything XML-namespace related, browsers vendors & al. won’t even consider implementing it if it refers to an obsolete spec. Once again, this is not strictly for EPUB2/3, there is a long-term aspect to it as well.

[edit] To be clear, I am not trying to discuss how it should be done there, but collect a list of issues authors have had so that I can document them and we can think about it. Custom data attributes are not the way to go. At all.

The presence/absence of a particular data attribute should not be used as a CSS hook for any styling. Doing so would suggest that the data you are storing is of immediate importance to the user and should be marked up in a more semantic and accessible manner. (source)

It’s just that it’s the easiest solution to experiment during dev. All I know is there is a discussion about -epub-bleed in the EPUB3 Community Group and that authors are trying to invert some images in night modes. Talking about how it should be implemented in prod is way overkill at the moment, I can’t even guarantee it can work in practice given the amount of EPUB files there are out there. And we’re not going anywhere if I don’t have a significant amount of listed items.

[acabal]

Heh, the link in your first bullet point is super incorrect; you can select epub:type with CSS (we do this often in SE ebooks, see any of our stylesheets), and therefore you can also likely select it with JS, and of course you can select it with xpath--xpath was literally designed to select X(HT)ML. I would argue that one shouldn't use XML tools like xpath on things that aren't XML, like HTML5, but whatever. In either case I don't think his point is that epub:type is bad, just that it should be data-epub-type instead, which is also a fine point but not super germane to this discussion.

It doesn't really matter how you write the epub:type concept out. The point is that the epub:type concept allows us an additional way to express exactly the semantics that we're discussing here. If we rename it to data-epub-type later, that's fine, because you're just painting the blue bike shed green, but it's still a bike shed. It would still be doing what it was already doing. But adding Yet Another Semantic Attribute to Really Really express the author's intent is reinventing the wheel and it'll likely be just as ignored as epub:type already is.

Anyway, good discussion here, thanks for letting me talk out loud about this. I think in the end I'm more interested in working on the spec end of the solution, than the RS end; and after some thought, possibly the secret sauce that's missing from the whole long epub saga is that maybe there wasn't a tight enough coupling between spec writers and RS implementors, like there is at W3C. But that's a political problem, not one we can solve by chatting on Github :)

[JayPanoz]

the link in your first bullet point is super incorrect.

If content is served as HTML5 (and not XHTML5), you indeed have to escape the colon in CSS and JS (with querySelector and querySelectorAll), which is later explained in the edit. I’ve just double-checked.

Also, if Tab Atkins trolled Brad (see tweet at the middle of the article) instead of correcting him, you can be sure this is correct. I’ll let you check Tab Atkins’ pedigree, but can say he knows a little about CSS.

[acabal]

Hey, if Brad wants to serve XHTML as HTML5, a different and looser standard, then all bets are off and that's his problem. But he can't complain if he wants to do that. That's like complaining that Python served as application/javascript isn't working in the browser.

You can definitely select XML namespaces in CSS (using the | selector, like we do in SE often and with no problems--you can even unzip one of our epub3s and open any XHTML file in your browser to see it in action if you don't believe me), and you can definitely use XML tools like xpath to select epub:type in XHTML, which our build process makes heavy use of. (Of course you should not be using XML tools on not-XHTML, like HTML5.)

Whether epub should be XHTML or HTML5 is a discussion for another day and a problem for the standards body du jour, but today's standard says XHTML so that's what we have to frame it as. One can't complain if one buys cookie dough and it doesn't bake when put in a blender instead of the oven. :)

[JayPanoz]

Yeah but you might want to take into account that the newest Kindle format serves contents as HTML, have had a nasty surprise a few weeks ago.

[JayPanoz]

For the sake of completeness, as regards the “how to ‘spec’ it?”, which was way outside the scope of the issue (authors’ issues listing, public API, etc.).

• Per spec, the RS “may associate specialized behaviors with terms from other vocabularies.” Problem is, if I do it for one publisher, there’s a chance I’ll be opening the Pandora’s box: some other publisher might do its own stuff because it didn’t fit their workflow very well, then another one because it didn’t cover their needs, then several others, etc, with various values, etc. Unless you can agree with a significant amount of publishers on a schema hosted and documented on schema.org, this is likely not happening. Another (technical) problem is that attribute selectors doesn’t scale particularly well in CSS, and it can impact performance heavily if you have a lot of them in the CSS + a significant amount of elements for which they apply in the DOM.
• Some people may consider this semantic enrichment (and not semantic inflexion), because epub:type is for structure, which means Microdata and RDFa11 as additional mechanisms to support.
• Some others may consider this shouldn’t be semantic at all, because they see it as a styling issue and it should not pollute either inflections or enrichment. The ImageObject and Creative Work schemas don’t already deal with this so you’ll have to find out why e.g. oversight, out of scope, etc.
• We nearly got HTML5 and aria doc roles/epub-type superseding epub:type in the 3.1 revision so that it can play nicer with HTML but that was deferred. Making something future-proof is a lot better, especially since the IDPF-W3C fusion. The best case scenario if you’re doing something for XHTML right now is that you’re doing twice the work (do it for XHTML then “port” to HTML). The worst-case scenario is you’re doing it for XHTML and it’s abandoned. It would be short-sighted to just think about EPUB3 there, and that would be a gross mistake imho.
• it’s worth repeating one major HTML Design Principle is the Priority of constituencies. For the most part, this issue has revolved around “theoretical purity” (we didn’t even talk about authors and users, which was the original scope of this issue). Another important principle is the error handling principle for interoperability reasons. We’ve done things the IDPF way, we now have to do things the W3C way—which also implies it may be critical to get browser vendors’ support for some stuff.

---

Can we now turn to practical issues, please? The most important thing we need to kickstart this is a list of use cases. Without use cases, it’s not even worth considering how this should be spec’d—which would be out of scope for this project anyway (I can only document issues, solutions we tried, drawbacks, etc. so that it can serve as a reference).

[artbyrt]

My work tends more to stylistic overview and less to the technical (I'm a designer, rather than an engineer) but I do think that the move to WC3 does not preclude the unique position an epub (book) has. The differences that exist (whether overtly understood or not) between books and websites, regardless of markup, is a fundamental, underlying, philosophical condition of the way forward in developing spec and standards. What my research has taught me is that what is most deficient about epub authoring is the tendency to 'replicate' a print book: serif typefaces, small and closely leaded, tight pagination (large loads) rather than to 'understand' from a design perspective what a digital book actually is, can be and can become. Some of the things that are being discussed have far-reaching implications and there is a priority-scale. For example, whether an image reverses in night-mode is probably not as important as whether the RSs can actually support the 'alt' attribute in a TTS rendition of the text.

[JayPanoz]

but I do think that the move to WC3 does not preclude the unique position an epub has.

Hum, I think nobody said that?

Personally, I just said that I’d be better off not relying on anything XHTML because WP, PWP can’t be XHTML-only and EPUB4 will probably lessen requirements (HTML is back). So having anything built on XHTML is not future-proof.

there is a priority-scale.

To be transparent, your scale and mine can’t be the same i.e. I have constraints and scope to factor in. Basically, here’s my decision path, which makes the concept of priority very loose:

1. can it be implemented in pure CSS? Y/N
2. how hard it is to implement it? Easy/Medium/Hard/Expert
3. are authors already trying to do it? Y/N
4. is it related to a11y? Y/N
5. does it impact performance in negative ways? Y/N
6. does it also impact rendering engines a.k.a. web browsers? Y/N
7. if yes, is a spec (dealing with it) currently being designed? Y/N
8. is the spec stable enough to bet it will become a recommandation and implement it? Y/N

When it comes to inverting images in night mode:

Yes, pure CSS is possible
→ Easy (one style to implement) 
→ Yes, see links in OP
→ Yes (eye strain, if you have an awful lot of images with a white background, it defeats night mode’s purpose) 
→ No, no significant perf impact if it’s easily targetable (if there is a lot of attributes to target, then yes)
→ Yes, cf. reader modes and high-contrast modes
→ Yes, Personalization Semantics
→ No, user settings are not yet addressed in the spec

When it comes to alt

No (depends on speech engine, which is obviously out of my CSS scope) 
→ Stop here

I mean, there is a lot of feedbacks and requests I must either report on the Readium 2 or Readium Desktop repositories because the answer to “can it be implemented in pure CSS?” is “No.”

Discussing some sort of API wasn’t even planned, I’m doing it in my free time.

You know, there is nothing preventing Reading System X to feed a neural network with all your EPUB images to check whether they should be inverted or not. Google is already doing it for speech bubbles in comics. But then Reading System X may use its own stuff, you’ll probably get false positives, it won’t be documented at all so you won’t be able to correct that. Only Reading System X will benefit, it might become a competitive advantage so Reading System Y implements it as well, with it own stuff too. In the end, there is no interoperability at all, spec comes years later, RS X and Y don’t bother porting their own stuff to spec, it complicates authoring a little bit more, it’s a lose-lose situation for everyone.

FYI, my top priority is designing a reliable and solid CSS system. The situation is getting worse: a lot of the latest Reading Systems resolve to inline styles and !important, or altering files beforehand (both are super hostile to authors). Convincing them it can be done leveraging the cascade and inheritance will already be quite a feat.

My biggest concern at first was implementers: “will they be willing to implement it, should I design it so that it’s super easy to manage?”

My biggest concern now is wondering whether it’s even useful discussing this and if I’d not better let the Personalization Task Force deal with it without the requests I can get.

Problem is, if you don’t have prototypes and stuff, you don’t know how hard it will be to implement (which is also why a lot of EPUB3 specs were not).

[JayPanoz]

Please also note this is a problem for gaiji (cf. issue #7) but it is a lot easier to solve because there is a japanese EPUB profile which makes use of CSS classes. In latin, there is simply no profile; everyone can style things, sometimes in unpredictable ways for the Reading System.

[artbyrt]

Thanks for comprehensive analysis of your important work. I merely put out these thoughts in the hope that the people with strings to pull will pull the ones that make most sense, in the long run, for the 500+ year-long tradition in book creation. ruth tait

…

On Jul 29, 2017, at 5:21 AM, Jiminy Panoz ***@***.***> wrote: Please also note this is a problem for gaiji (cf. issue #7 <#7>) but it is a lot easier to solve because there is a japanese EPUB profile which makes use of CSS classes. In latin, there is simply not profile, everyone can style things, sometimes in unpredictable ways for the Reading System. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMwGgBZ62qQF7e5K8QmdLCU_KNk67c1Mks5sSvmBgaJpZM4OMle->.

[JayPanoz]

Given the project’s progress, and our plans to move forward, I’ll close the issue (could be re-opened at some point, if needed).

Issues and requests have indeed been mainly collected outside of this github issue and a recap is available in issue #17. So if you want to add any issue to this list, go ahead, especially as it is referenced in the EPUB 3 Community Group’s repo.

Besides, this discussion turned super technical at some point (so much that I decided to rename it) and since User Agent Properties are now a thing in CSS, there is no reason to talk any longer about custom and data-* attributes, etc. Personally, I think it is even a lot better since we’re dealing with styling there, and it should not pollute markup or semantics.

Please bear in mind we don’t have User Agent Properties yet, we only have Reading System variables – which happen to be exposed to authors –, and their prefixes can be changed at implementers’ will. So don’t rely too much on them and hope your styles will work in all implementations of Readium CSS.

Thanks for your feedbacks.