Reading System Overrides and Basic EPUB3 CSS File #9
Comments
|
Mmmkay, a few thoughts.
I must admit I’m a little bit uncomfortable with the idea of “normalize.css”, since it’s been the realm of CSS authors. What we should be probably talking about is “suggested rendering”, à la HTML5. Now, it is my understanding that apps relying on web views or web apps (in the browser) are already leveraging it. The stuff I don’t really like in there is horizontal spacing in pixels e.g. But basically, we’re covered there, even the old RMSDK and Kindle have some sort of default rendering albeit not HTML5, so it seems to me this is not that big an issue after all. Even made another small CSS framework for that and you could almost perfectly rely on that. Fact is it doesn’t prevent bad CSS, because this is not much of a technical than a human issue. It’s about people, the tools they use, the software designers they trust, the hacks they design, the overrides they fight, etc. When people are putting double
See my previous paragraph (technical/human). When designing blitz, I became aware how easy it is to screw up user settings for instance. In some cases, use some web CSS snippets and BOOM, some user setting doesn’t work anymore. Nobody knows how much effort it actually required, and we ended up “abusing” the cascade and inheritance to make it work. The reset, which may look simplistic at first sight, is the result of months of debug/QA/author testing. And yeah, I discovered I previously fucked up some user settings in some Reading Systems, I didn't know and I paid an insane amount of attention to that. I mean, such a metadata is bound to fail in my opinion. If that can be any signal, Amazon automates CSS changes (fonts, color, size, etc.) which break user settings or provide readers with a shitty reading experience (contrast). It means that enough files were problematic to invest in that automation. It’s probably in the dozens of thousands, if not more. It is now my belief user settings is one critical issue on which we should focus. Finally, you have to take “tag soup” into account. How are RS devs supposed to cope with an infinite amount of “tags + classes” combo? Sure, you could say “never mind, we’ll do it anyway, the problem with fix itself” but it will require years, the back catalog won’t likely be updated and won’t at least be a visual aside, which is likely to create comprehension issues because maybe there was a border and now there isn’t and you don’t understand what the author is saying anymore. It’s not like amp, Instant Articles or Apple News, in which there is a set of pre-defined building blocks you can use or else it won’t work, thus making it completely overridable for the Reading System.
Sorry, I don’t get this part to be honest. One important issue to note though is that, when CSS multicol is involved, there’s not much you can do about it. Web developers have had issues with that too, because positioning, offsets, etc. in columns are terrible (negative offsets, etc). It actually blows my mind the multicol spec has not been updated/discussed for so long, especially as Apple, for instance, is using it for iBooks. Instead, they designed crappy JS hacks to make some stuff happen… I’m convinced that in order to really solve this issue, we’ll need a CSS multicol Level 4 at some point, if only to renew interest in their implementations because it is super hostile to the new layout specs (flexbox and grid, for which there are nasty bugs currently). But another problem is, you could use JS to solve some problems but… at the time you get all the accurate data you need, pagination is over and out, and you can't force a recalc.
Some reading systems are already lukewarm to using SVG for images and demotivate it. I know we’ve been using this a lot because of Adobe’s ePub2 RMSDK but there are so many issues with figures that this one doesn't look so important to me, especially as there’s
As far as I can tell, there’s none because you have to think in terms of whole declarations, and not specific values. Most stylesheets are the result of the following:
So it vastly depends on the Reading System itself. It’s worth repeating blitz just make it more predictable on the authors’ end, and try helping them not break user settings but that’s it. It’s just default values. Should an author put a problematic style in there, it will become an issue. You could probably build a comprehensive list of best practices for overrides, i.e. “this stuff has been painful to us, could you please pay attention to it when designing your CSS?” I guess RS devs would welcome that much much better that any metadata, etc. Don’t forget it’s also a business for them and should they implement that and crappy files generate reimbursements as a result, it won’t last long. |
If I may, an additional word of caution about that: it can screw up inheritance (and the cascade). I had to deal with some nasty bug with a test file in Kobo iOS and Android at some point; all contents were centered, even text. It appeared it was because I dropped a quick and dirty There are probably some files out there with styles declared for |
|
OK, if I may, a new perspective on this since I’ll be on the RS side for the next three months.
Have documented browsers’ UA stylesheets this week, and believe me, it was kind of painful. What's important there is that you can use
Unless you make its absence an epubcheck error, I can’t see how you can get everyone on board—spoiler, making it an error would probably create a shitstorm.
Related: responsibility of UI is currently discussed for Web Publications.
It breaks cascading and the inheritance, possibly viewport units (
As far as I’m concerned, that’s an author’s preference, it shouldn’t find itself in an “official” stylesheet.
This is one of the issues I’ll have to tackle but I already have a solution, and SVG is not required at all (you can use it if you want but it’s two extra lines of CSS in any case).
You’ll find them in HTML Suggested Rendering. Have spent 2 days validating major browsers’ UA stylesheets against suggested rendering and there’s no nasty surprise there.
Having spent part of the last week discussing how to address pagination, user settings, default styles and stuff, can confirm the following:
In some Reading Systems, bugs authors experience might just be side effects, but trust me, it currently takes tremendous effort to find compromises so that those side effects don’t happen.
That’s authors’ territory, not specs. See how many CSS frameworks exist for the web and how little exist for ebooks. So, once again, this is a cultural issue. You won’t improve that with specs, you’ll improve that with evangelization—which is pretty hard if the effort is not collective. Or you can check Dave’s EPUB Zero repo and try to make that happen at the industrial scale. |
Hi @dauwhe
I have read the "Reading System Overrides" and references to the wiki page. In order to contribute to the revision of EPUB 3.1, I expressed my ideas on the subject in terms of references. (9 items)
With the "Basic EPUB3 CSS file (normalize.css)" and "metadata"
1.
The "Basic EPUB3 CSS file" will of course not carry a valid document quality in order to display each content. This is not possible. This document should be prepared taking into account the important standards for better viewing of the e-book. I believe it is important for the revision of EPUB 3.1.
2.
EPUB design is as difficult as making a chocolate box design. I agree with the opinion that the text formatting information of EPUB3 format creators is low. RS developers have developed a defender for dealing with nightmare files and have created an improvement by activating UA basic styles. With "Basic EPUB3 CSS file", there will be a technical increase in the quality of the formatting. This will provide an average balance in the imaging capabilities of the reading systems. Developers will no longer deal with problematic files.
3.
The reading system needs a metadata file to ignore the author's CSS document. In a sense, this metadata data will be like a "do not intervene please" intervention. Professional designers need this. The example given by @rdeltour -> rendition: default-css -> w3c/epub-specs#672 (comment)
4.
Especially for the reflowable design, the contents of the element must then be used strictly within a
<div>element. The basic ground must be established to implement the "box-model" design with the basic CSS values (relative or absolute) to be given to the<div>element. In fact, this<div>element should be passed through the "test-validate" operation in every XHTML.5.
In order to improve the reading experience in EPUB3 format books, we produce user-oriented icons with dynamic CSS. In the text;
[W] Web link
[L] Navigation between pages
(@) Email
[S] Dictionary (words with technical meaning)
We customize the
<a>elements with CSS. So we try to help the user during reading. Such visual standards may be in "basic CSS". I think it will be useful.6.
The cover should be the appropriate CSS for the XHTML page. It may be useful to use the SVG element in this page.
7.
It would make sense to try to list the "default values" of new HTML5 elements such as Section, Aside. I want to be among those who will do this work. @dauwhe is the opinion owner. -> w3c/epub-specs#672 (comment)
8.
It would be good to look at the work done by @JayPanoz to examine the CSS values of reading systems in creating the "basic EPUB3 CSS file". Thus, we can predict the values that can coincide with UA style sheets. -> https://github.com/FriendsOfEpub/WillThatBeOverriden/tree/master/ReadingSystems
9.
EPUB3 CG CSS Themes: In the following years we can build EPUB3 CG CSS Themes to simplify the work of authors. For example, we can increase the "design and render quality" by providing the use of standards elements. I am sure there are people who work like me in this regard. Even @JayPanoz has worked on this issue -> w3c/epub-specs#672
The text was updated successfully, but these errors were encountered: