from BISG survey

from BISG survey

from BISG survey

From BISG survey

from BISG survey

Or at least add my name to the EPUB for Education and A11y Task Force teams?

Thanks very much!

Does someone have the knowledge and skill to rewrite the APIs in Section 6 of the EDUPUB spec in WebIDL format? I don't even know enough to know if that's the right thing to do! :)

Request from BISG survey

From Makoto via email:

Apple iBook does not recognize a reserved prefix(*) which was
introduced in EPUB 3.0.1. If this prefix is explicitly declared,
iBook has no problems in handling it. But if it is not, iBook reports
an error. Since this prefix is predefined in EPUB 3.0.1, this
behaviour does not conform to 3.0.1. Apple turned down the request by
KADOKAWA to change this behavior.

• http://www.idpf.org/epub/301/spec/epub-publications.html#sec-metadata-reserved-vocabs

I am personally sympathetic to Apple, as additions of reserved
prefixes causes troubles to existing RSs. I thus propose to add
a warning about this issue and a recommendation to explicit
declare this prefix by publishing an erratum to EPUB 3.0.1 and 3.1.

I hope that this topic can be discussed in the CG.

Please consult readium/readium-css#32, which has the same title (we'll keep it to summarize the conclusion of this thread in the scope of Readium CSS).

The crux of the issue is that distributors shouldn't ask EPUB authors to harm interoperability by asking constrained EPUB implementations. It this case, the issue is about prefixed properties (e.g. those required for handling vertical writing). But it could be in other domains of CSS, or why not HTML5.

We think that such issue must be escalated to the EPUB 3 CG, acting as a "WHATWG-style" forum for enhancing the interoperability of reading systems. What should the CG do for such issues? can it act as a hub where authors, distributors/booksellers (Google in this case) and reading system developers can settle on good practices?

Related threads:
readium/readium-css#19
readium/readium-css#26

(Request via BISG research)

• What are best practices for applying advanced HTML5 in epub?

From BISG survey - both in how best to structure content and how best to include the correct metadata pertaining to accessibility

The Publication Metadata section of the epub for education profile (https://w3c.github.io/publ-cg/education/epub-education.html#publication-metadata) contains materials relevant to the 3.1 specification. As we break down the education profile, this section should go to 3.1 and be referenced in the forthcoming best practices document.

from BISG survey

People have started talking about a revision of EPUB 3.1 to improve compatibility with previous versions of EPUB. See the google doc with the initial proposal and the EPUB 3.X spec repository itself for more information. Feel free to file and comment on issues there.

(from BISG survey)

• What are best practices for applying CSS3 in layout of epub3

Hi,
Would it be meaningful to add "amateur" or "hobbyist" words in EDUPUB 8.2.2 (audience / audience Type)? -> http://www.idpf.org/epub/profiles/edu/spec/#h.eufqqw4y93wy

From BISG survey

from BISG survey

From BISG survey

As we are talking about going forward with edupub, I would like to raise (maybe again, sorry) the structural issues related to what is stated [here] (http://www.idpf.org/epub/profiles/edu/spec/#h.9obeul6ergfp) in the EPUB for Education draft regarding heading rank inside aside/article/nav element.

My point is that asides are by definition out of the main flow of the content (particularly in higher education textbooks) and therefore imposing an heading rank based on the aside's outer context is probably wrong and for sure very annoying when you need to reorganize/reshuffle/move around pieces of content.

In the last months we converted from DTP files a lot of structurally very complex content and we have found that starting always the aside inner sectioning at h5 is a far better option.

If I remember well, all this was related to a9y issues, which I think could be addressed by ARIA roles.

regards,

__peppo

For those who are new to GitHub, feel free to comment on this issue for practice!

The various things listed in the wiki here https://github.com/w3c/publ-cg/wiki/Rendering#rendering don't seem to quite fit the scope of the CG, which is, as far as I understand the charter, about maintenance of EPUB3 and related things, not about new features.

Regardless of the charter, Image Bleeds (including page floats and the actual bleed), footnotes, and Marginalia are absolutely in scope for the CSS WG, and already have partial answers there.

https://drafts.csswg.org/css-page-floats/
https://drafts.csswg.org/css-page/#bleed
https://drafts.csswg.org/css-gcpm/#creating-footnotes

I strongly encourage members of EPUB CG to work on these topics, but not in isolation, and to join the CSS WG to contribute to the development there. Ending up with two partial answers to these questions, one in EPUB and one in CSS, would be a very bad outcome.

I thought it would be more useful to open a new issue about rendering (-epub-bleed, overrides) in the context of pagination since I’m kind of being overly active about that in the bleed issue.

Disclaimer: @dauwhe, speaking as an RS “implementer” there, although it’s a really early feedback and will be able to provide more details later. But please be assured I’m coming in peace.

Pagination

To sum things up, you can’t do without columns at the moment if you want a cross-platform implementation and don’t want to make super heavy manipulations using JavaScript (for which, if some Reading Systems can be any clue, you have to tweak files beforehand).

Won’t dive into super technical details (compromises, tricks you have to use to break the least amount of things possible, especially the box model) but the spec to improve them already exists. It can be found here.

It is, in my humble opinion, critical that we can nest columns in a super simple page model dealing with overflow, padding, etc. (because columns + overflow is super nasty at the moment). Also, it could be useful for web publications, if the publisher wants to provide a paginated view for instance. Finally, that could open up the possibility of -epub-bleed (say for EPUB 3.2, should that exist in the future).

Have (pretty quickly) explored shadow DOM (+ Regions) for the longer term but I’m not particularly hopeful it will solve all the issues we have. If you have to manipulate the entire DOM, performance becomes an issue.

Overrides

Am pretty uncomfortable with this since I’m an author too but it would be interesting to discuss with implementers of browsers’ Reader Modes, Read-later services, AMP & IA & Apple News. We have issues in common e.g. how to manage images in night and high-contrast-mode, overrides, etc.

This is probably our best bet to find practical solutions.

Some initial thoughts are on the wiki.

We may want to raise this issue in some other places, such as Readium. I would love to see some experimental implementations in reading systems before we try to specify this.

From BISG survey

How can we document the inconsistencies across reading systems?

From BISG survey

a quality community developed "CSS reset" that guaranteed sufficient margins, good font size, etc. would be helpful

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

From BISG survey

From BISG survey

From BISG survey

Amazon guidelines guide that the book cover is not included in an XHTML file. (topic 4.2)
Kobo guidelines guide you to include the cover in an XHTML file. (see here)
Several examples that I found have the cover in XHTML.

However, Amazon warns that if the cover is included, it may appear twice on the Kindle. The same is true for iBooks: when you open a book, you first open the cover that the app "interprets" from the "cover" tag and then open the cover of XHTML.

What would be the right thing to do?

from BISG survey

Establish guidelines for versioning epub. See w3c/epub-specs#983

The Navigation section of the epub for education profile (https://w3c.github.io/publ-cg/education/epub-education.html#navigation) contains materials relevant to the 3.1 specification. As we break down the education profile, this section shoul go to 3.1 and be referenced in the forthcoming best practices document.

Request from BISG survey

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.

<style type="text/css" media="screen">
    @namespace epub "http://www.idpf.org/2007/ops";
    div[epub|type~="bodymatter"] {
        ...
    }
</style>
<body>
    <div epub:type="bodymatter">
        <section>
            ...
	</section>
    </div>
</body>

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.

a[href*="#"]{color:blue;text-decoration:none;font-weight:bolder;}
a[href*="#"]:after{font-family:Helvetica,Arial,sans-serif;background:blue;content:"S";color:white;padding:2px 5px 3px 5px;margin:-5px 0 0 4px;font-weight:bolder;font-size:60%}
a[href*=".xhtml"]{color:#6A2A07;text-decoration:none;font-weight:bolder;}
a[href*=".xhtml"]:after{font-family:Helvetica,Arial,sans-serif;background:#6A2A07;content:"L";color:white;padding:2px 5px 3px 5px;margin:-5px 0 0 4px;font-weight:bolder;font-size:60%}
a[href^="http:"]{color:#6A2A07;text-decoration:none;font-weight:bolder;}
a[href^="http:"]:after{font-family:Helvetica,Arial,sans-serif;background:#6A2A07;content:"W";color:white;padding:2px 5px 3px 5px;margin:-5px 0 0 4px;font-weight:bolder;font-size:60%}
a[href^="https:"]{color:#6A2A07;text-decoration:none;font-weight:bolder;}
a[href^="https:"]:after{font-family:Helvetica,Arial,sans-serif;background:#6A2A07;content:"W";color:white;padding:2px 5px 3px 5px;margin:-5px 0 0 4px;font-weight:bolder;font-size:60%}
a[href^="mailto:"]{text-decoration:none;color:limegreen;padding:0 5px 0 0;font-weight:bolder;}
a[href^="mailto:"]:link{text-decoration:none;color:limegreen;padding:0 5px 0 0;font-weight:bolder;}
a[href^="mailto:"]:visited{text-decoration:none;color:limegreen;padding:0 5px 0 0;font-family:Helvetica,Arial,sans-serif;font-weight:bolder;}
a[href^="mailto:"]:after{font-family:Helvetica,Arial,sans-serif;background:limegreen;content:"@";color:white;padding:4px 5px 3px 5px;margin:0 0 0 4px;border-radius:15px;font-weight:bolder;font-size:90%}

6.

The cover should be the appropriate CSS for the XHTML page. It may be useful to use the SVG element in this page.

<style type="text/css" media="screen">
    @namespace epub "http://www.idpf.org/2007/ops";
    div[epub|type~="cover"] {
        ...
    }
</style>
<body>
    <div epub:type="cover">
        <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="100%" height="100%" viewBox="0 0 916 1197" preserveAspectRatio="none">
            <image width="916" height="1197" xlink:href="image/cover.jpg"/>
        </svg>
    </div>
</body>

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

While implementing Readium CSS, I came across “4.5 Reading System Overrides”, especially the following:

the getOverrideStyle method [DOM2 Style]

There is currently an open issue about override declarations on CSSWG-draft. Apparently, it’s never been implemented and is very likely to be dropped in CSS Cascade.

The EPUB for Education spec refers to the EPUB for Education Structural Semantics document. How does this relate to the DPUB-ARIA roles?

And how might we best present this kind of information to the poor user who just wants to know which value to use?

I know all EPUB 3 samples have not been upgraded to EPUB 3.1 yet but this is something you might want to keep in mind: a lot of samples use the -epub- prefixed property only, and don’t have the standard one at all.

Prefixed properties are temporary by nature and not future-proof but, unfortunately, it seems like a lot of authors and authoring tools didn't get this concept. InDesign CC 2018, for instance, is still outputting the -epub- prefixed properties and nothing else, which builds an increasing debt (more on that in a few paragraphs).

Example output from InDesign:

body {
  -epub-writing-mode: vertical-rl;
}
span.j-tatechuyoko {
  -epub-text-combine: horizontal;
}

Now, there is a caution in the EPUB 3.1 spec and I guess it would be a good idea to set an example, esp. as the samples may be used as a reference by authors and authoring tools.

I’m obviously not criticizing the fact -epub- properties exist. That was how things were done at the time they were created, but a lot of things have changed since, and it looks like the de facto EPUB ecosystem is a little bit lagging as regards authoring practices.

But how are -epub- properties supported in the first place then?

For transparency’s sake…

When the Reading System is built on top of Blink and Webkit, we get support for free. Webkit indeed aliased -epub- properties to -webkit- properties. We don’t know whether Blink will deprecate and remove those aliases at some point, but they’re aggressively removing support for a lot of webkit CSS props to improve perfs so this could be a possibility. Also, God only knows what will happen when -webkit- properties are removed – will they alias -epub- properties to the standard one? will they forget about it? will they remove support as well?

When the Reading System is using Gecko/Quantum or Trident/EdgeHTML (i.e. a web app), we must polyfill those properties. But since they are not supported, we can’t get it using getComputedStyle so we must parse all the stylesheets, in full. And this is a huge issue, cf. the Dark Side of Polyfilling CSS.

As a result, it will add a lot of complexity to the Reading System, will highly impact performance, and might be buggy. We (Readium CSS) must deal with this issue right now for vertical writing, and we’re leaning towards pre-processing files to add the standard properties when they’re not used in the EPUB stylesheets (but we won’t be able to manage inline styles) because the perf impact is simply too high at runtime – just think about XHTML files taking 3+, perhaps 5+, seconds to load on low and middle-end devices to get the idea, I guess authors don’t want such a thing to happen.

There’s an app a PostCSS plugin for that

If it can help, I’ve created a PostCSS plugin, which will parse the stylesheets you feed it, find the -epub- properties, check if the standard one is in the same declaration and if it isn’t, add it. You can find the repo on my personal github account.

It’s obviously using the EPUB 3.1 mapping to do this task.

A word of caution: it was developed in a hurry and is more of a Proof of Concept at the moment. It can probably be improved but should be pretty reliable, although I didn't stress-test it yet.

On a related note, it’s such a complex issue that we’ve been thinking about creating a web app for authors to edit their stylesheets (and add the standard properties). So it might be a good idea to “promote” the EPUB 3.1 caution.

From BISG survey

See original issue at w3c/epub-specs#987

Need to fill in best practices documentation for math.

• Visual appearance, especially in education and journals is important.
• Must be accessible

It turns out we have a guide to using schema.org with EPUB: https://idpf.github.io/epub-guides/schema-org-integration/

Let's not forget this! I'll try to move it to one of the CG repos at some point. Looks like it will need updating due to @refines anyway...

from BISG survey

requested through BISG survey

From BISG survey

I’ve been trying to understand why a lot of our samples (for Readium CSS) had page-spread-* spine overrides in reflowable and after reading the specs, I’m even more confused.

Our first assumptions was that they were meant for fixed-layout, the title of the section being “Fixed-layout properties” indeed. But then, when reading subsections, reflowable kicks in.

My educated guess is that we’re talking about reflowable documents (HTML files if you wish) in fixed-layout publications (EPUB file, i.e. a collection of HTML files although this is a simplistic representation). Fact is I can’t tell for sure though, and it looks like quite a significant amount of authors can not as well.

Sure there is

This section defines a set of metadata properties to allow declarative expression of intended rendering behaviors of Fixed-Layout Documents in the context of EPUB 3.1.

But then…

The rendition:page-spread-left, rendition:page-spread-right and rendition:page-spread-center properties apply to both pre-paginated and reflowable content, and they only apply when the Reading System is creating Synthetic Spreads.

So OK, content is used there, not documents. But then…

EPUB Content Document
A Publication Resource that conforms to one of the EPUB Content Document definitions (HTML or SVG).
An EPUB Content Document is a Core Media Type Resource, so can be included in the EPUB Publication without the provision of fallbacks.

While it is my understanding that Fixed-Layout Publication should have been used if it should apply to the Publication itself:

EPUB Publication
A collection of one or more Renditions that conform to this specification, packaged in an EPUB Container.
An EPUB Publication typically represents a single intellectual or artistic work, but this specification does not circumscribe the nature of the content.

And then:

Fixed-Layout Document
An EPUB Content Document directly referenced from the spine that has been designated pre-paginated in the Package Document, as defined in The rendition:layout Property [Packages 3.1].
The dimensions to use for rendering Fixed-Layout Documents are defined in Fixed Layouts [Content Docs 3.1].

Sorry but I happen to find myself in some sort of loop in which we can’t tell for sure whether it applies to fixed-layout publications with reflowable contents inside it or it applies to reflowable publications as well.

If it applies to rendering behaviors of Fixed-Layout Documents and not the Publication, should I ignore the parts related to reflowable as well?