EPUB 3 is NOT a reflowable document format.

24 posts / 0 new
Last post

It just occured to me that though EPUB 3 claims to be a reflowable document format (RDF), it is NOT a RDF.

Why do I say this? Because EPUB 3 uses a fixed-layout document format which is HTML, along with its associated stylesheet (CSS).

So, how is EPUB 3 a RDF at all? Well, you can specify "reflowable" in the metadata and pray that the Reading System (RS) implements it, which is optional from the viewpoint of the RS. A RS that implements reflowable makes the interpretation of what the word means. There's nothing in the EPUB 3 specification that supports the Quality of reflowability in a RS.

EPUB 3 is not a reflowable document format. It is a fixed-layout document format only that "encourages" RSs that support multiple viewport sizes to support the reflowability feature.

No, the spec does allow some latitude for the reading system in handling "overflow" content but I am not aware of a reading system that enforces "fixed layout" even if the rendition:layout property is set to reflowable (see http://www.idpf.org/epub/31/spec/epub-packages.html). Can you point to one that does this?

Many reading systems, including Readium, DO paginate the overflow (or offer to present a galley-like scrolling form, per spec).  If anything, support for reflowable is broader and better than fixed-layout.  IDPF encourages use of the reflowable format because it is more accessible.

What do you mean the spec allows some "latitude" for the reading system to handle overflow content? Where in the spec is there provision for how to handle reflowability?

I'm talking about the fact that HTML+CSS cannot be used as a format for encoding arbitrary reflowable content.

You say things that have no basis in reality. Things like "IDPF encourages use of the reflowable format because it is more accessible" is pure fiction and fantasy. HTML+CSS and SVG (the two top level formats supported by EPUB) are not reflowable document formats.

Can you address the fact and stay on point?

What do you mean the spec allows some "latitude" for the reading system to handle overflow content? Where in the spec is there provision for how to handle reflowability?

I'm talking about the fact that HTML+CSS cannot be used as a format for encoding arbitrary reflowable content.

You say things that have no basis in reality. Things like "IDPF encourages use of the reflowable format because it is more accessible" is pure fiction and fantasy. HTML+CSS and SVG (the two top level formats supported by EPUB) are not reflowable document formats.

Can you address the fact and stay on point?

HTML alone, by itself, is mostly reflowable (tables have to be broken, making the page not look very nice). Understand this basic reality, everyone must.

CSS is not reflowable. It uses a box model, with margins, borders and with endless nesting, of HTML tags, it simply cannot be reflowed in a civilised manner.

SVG, I shouldn't have to say is not reflowable but it's actually OK because pictures will be shrinked to fit on the screen.

You can't treat HTML CSS boxes as images, this is the main reason EPUB 3 is not a reflowable document format (RDF).

SVG is surely not reflowable, this is always fixed layout.
It has another concept than XHTML, CSS oder raster images.
As far as I can see, this is currently the only meaningful way to provide really fixed layout in EPUB, if one needs this.
But if you provide width and height with different units than percentage, it does not shrink to fit on the screen, than there is a requirement to scroll or to have some other mechanism to get access to other parts of the graphics within the viewBox, which do not fit on the screen. There is a requirement to provide scaling as well to the audience.
The is comparable to PS oder PDF.

Obviously raster images or tables, something with some need to be presented visually at all are not completely reflowable.
But devices usually have some typical size related to the typical viewing distance for them, therefore authors of books can rely, that for a visual presentation there is some space available, for example at least ~30em, else the device is not meaningful for the visual presentation of books anyway.
And the usual viewers and libraries for the visual presentation of XHTML have the capability to arrange the simple text content to the width of the available viewport.
Some have problems with long words however.

Concerning CSS - it depends, how you use it. It is quite simple of course to obfuscate presentation of text to nonsense with CSS - and some authors do this, but as well it is simple to avoid such nonsense.
Any program with the capability to display CSS styled content should have an option for the audience to switch to the user-agent stylesheet by switching off the author stylesheet, therefore in case of problems there is a way out for the audience, else the program is borked anyway.

Concerning specific EPUB viewers, there are indeed problems, if words or images, tables etc are larger than the available viewport, this needs to be fixed.
This problem appears typically for all programs trying to simulate somehow printed books, what is a stupid idea for digital books anyway - especially if the developers of such pseudo-print-books do not solve the problem of content larger than the viewport - but this problem is already solved for about ~20 years in browsers, developers do not have to invent the wheel once more. Such programs just get borked, it they try to reinvent ;o)

We've filtered down the problem to publisher-supplied-stylesheets vs user-agent-stylesheets, since HTML and SVG are not a serious concern for the reflowability issue.

Try to stay on point: the problem is CSS.

By allowing authors to create REFLOWABLE renditions with CSS, the IDPF and the publishing industry in general are shooting themselves in the foot because authors will generally use CSS and by the very nature of CSS which gives room to do all sorts of fixed-layout, the reflowable model is broken.

My point: reflowable EPUB and publisher-supplied CSS are like oil and water. They do not mix. WHY NOT ADDRESS THIS TIME BOMB OF A PROBLEM IN THE SPEC ITSELF? WHY NOT REMOVE THE CANCER BEFORE IT SPREADS?

AM I THE ONLY ONE WHO SEES THIS VERY SIMPLE BUT SERIOUS PROBLEM? I.E. THAT CSS *CANNOT* BE GIVEN FREE-REIGN OVER REFLOWABLE CONTENT?

Why would you assume that authors would know "how" to use CSS in a way that doesn't break the reflowable model? Why??

SURELY THIS IS BAD SPECIFICATION DESIGN.

There are many options in (X)HTML (and SVG) as well to obfuscate content with the usage of wrong elements.

If you have a powerful language, there are always options to corrupt documents or presentations by wrong/stupid usage.

CSS has media queries to adjust more complex styles to the available viewport and of course, no author is forced to obfuscate the presentation with stupid types of stylesheets.
Of course, there are some almost useless CSS 3 modules under preparation, I cannot see any meaningful usecase together with (X)HTML, but they are not part of the current EPUB subset anyway - and it is pretty surprising, that some CSS 3 modules are already mentioned in EPUB, which are still beeing only a working draft, no recommendation at W3C - here it is clearly a bug of EPUB to encourage authors to use features from such not yet thought through draft modules in their books.

You're still missing the point.

I am saying that CORRECT use of CSS can break the reflowable model.

The idea of languages, whether high level or low level is that the compiled code is GUARANTEED to work provided the author follows the rules of the language, otherwise what's the point in having rules?

The author is not stupid, if he writes CORRECT CSS that works on a browser but fails to work in EPUB 3 reflowable mode. It is the specification that is "stupid" in that regard. If for instance I write a Java program that compiles successfully into a .class file, it should run on any JVM. That's the point, the reason for the specification - that if I follow the rules (say of EPUB 3) then my book should render correctly on any reading system that implements the spec correctly.

The point remains: all the permitted CSS within EPUB 3 cannot be used arbitrarily without breaking the "reflowable" model and this is a TIME BOMB.

It is not a big problem, to create problems for accessibility with CSS and (X)HTML for the presentation in browsers as well with correct CSS and (X)HTML.
These are complex languages and it is a task for any author to learn how to use them in a meaningful way.

However, if some CSS works without problems in a browser environment, but not for some EPUB readers, it is presumably a bug of the EPUB readers.
Often they use the same library (Mozilla Gecko or WebKit/Blink), therefore maybe only the EPUB reader developers pessimised the presentation, because they do not understand either the concepts of CSS (and (X)HTML and SVG) completely.
Therefore they do not understand the implications for accessibility, if they simply try to impose their naive concept of a book on (X)HTML documents.

Documents in the web or in EPUB - both is (X)HTML (SVG) styled with CSS - no difference in rendering, what is specified by CSS, not the EPUB environment.
Such bugs in EPUB readers/viewers need to be fixed.

The problem here really, O.H., is that you don't have a comprehensive understanding of the underlying technologies of HTML, SVG and CSS.

You are dancing around concepts like accessibility and the use of browser engines, two issues that are irrelevant to the current discussion.

The point is this: the arbirary use of CSS for LAYOUT & STYLING in reflowable mode which, fyi, is permitted in EPUB 3 *breaks* the reflowable mode.

I will repeat that again a couple more times so you won't go off tangent on your next post:

The point is this: the arbirary use of CSS for LAYOUT & STYLING in reflowable mode which, fyi, is permitted in EPUB 3 *breaks* the reflowable mode.

The point is this: the arbirary use of CSS for LAYOUT & STYLING in reflowable mode which, fyi, is permitted in EPUB 3 *breaks* the reflowable mode.

Now, to fix the problem, the specification MUST address the issue by EXPLICITLY stating which CSS attributes can (or cannot) be used in reflowable mode. This needs to be made clear, to prevent authors from proverbially jumping out the window by creating reflowable renditions that are DOOMED to not display properly in EPUB 3 Reading Systems.

The problem I see with your approach is, that you can typically use the same property or feature both for reflowable content and to obfuscate attempts to get a flow presentation.
Sometimes you need to combine different features to get some meaningful reflowable presentation, but you can get trouble with a similar combination as well.

For example, if you note, that a p element has a width of 80em and a height of 30em, surely you have no reflowable content anymore.
If you set it to a width of 80% - no problem, a max-width of 40em no problem as well. And for elements like figure, img, object etc you may need width and height with other units as well to improve the result for the audience and to adjust images to the available viewport.

But sure, what is excluded for EPUB 2 gives already a hint, what might cause major trouble concering some flowable layout:
position, top, bottom, left, right, z-index, overflow, clip and visibility.

EPUB 3 excludes only position: fixed
Others are meaningful, if one needs some fixed layout, therefore not excluded anymore.
But sure, such a rough list might be already a help for authors to avoid trouble for reflowable layouts.
But such a simple list does not avoid some more difficult cases as those with width and height.

"For example, if you note, that a p
element has a width of 80em and a
height of 30em, surely you have no
reflowable content anymore."

Right. You FINALLY get the point. But the markup is permitted in reflowable EPUB 3. Why would you permit such markup when you know it is illogical?

The problem here really, O.H., is
that you don't have a comprehensive
understanding of the underlying
technologies of HTML, SVG and CSS.

You are dancing around concepts
like accessibility, flowable/re-flowable and the use of
browser engines, two issues that are
irrelevant to the current discussion.h
The point is this: the arbirary use of
CSS for LAYOUT & STYLING in
reflowable mode which, fyi, is
permitted in EPUB 3 *breaks* the
reflowable mode.
I will repeat that again a couple
more times so you won't go off
tangent on your next post:
The point is this: the arbirary use of
CSS for LAYOUT & STYLING in
reflowable mode which, fyi, is
permitted in EPUB 3 *breaks* the
reflowable mode.
The point is this: the arbirary use of
CSS for LAYOUT & STYLING in
reflowable mode which, fyi, is
permitted in EPUB 3 *breaks* the
reflowable mode.
Now, to fix the problem, the
specification MUST address the issue
by EXPLICITLY stating which CSS
attributes can (or cannot) be used in
reflowable mode. This needs to be
made clear, to prevent authors from
proverbially jumping out the window
by creating reflowable renditions
that are DOOMED to not display
properly in EPUB 3 Reading Systems.

I think, I have a comprehesive understanding ;-) I was already an invited expert of the W3C SVG group, therefore I'm a coauthor of one recommendation, I had discussions with implementors, authors and editors of CSS and (X)HTML recommendations as well.

As an author of a recommendation you cannot completely avoid, that some people do stupid things with such languages, you cannot even avoid, that implementors do stupid things calling this an implementation of such languages.
Of course, you can give some hints and example concerning best practice, but this is not the core task of a recommendation, the right place for this are mainly tutorials and other secondary works to help and to guide authors to do less stupid things ;o)

OK I see your position is more influenced by politics than pragmatism.

I wouldn't call authors or implementers stupid. I think we need to demonstrate a greater level of respect for implementers if we ever want this technology to see the light of day. The developer, who uses his mind, hard-earned knowledge and effort to code the system is by far the most important variable in the equation that includes users, authors, publishers, analysts etc

My point remains that the current spec needs to explicitly remove the inappropriate CSS attributes (like it did in EPUB 2) for reflowable renditions. I'm not at all concerned by fixed-layouts because a fixed-layout is just a regular webpage like the one you're reading these words on. There's no innovation there. Webkit or any browser engine can be used to implement fixed-layouts.

The unfinished business is reflowable renditions and I think you would be doing the EPUB 3 community a great good if you make this recommendation that we should have a specific REFLOWABLE-CSS PROFILE.

Cheers.

According to CSS 2.1 user agent conformance:
'The UA must allow the user to turn off the influence of author style sheets.'
Because EPUB uses CSS, this is a requirement for EPUB viewers as well.

If you press this button, you almost have what you want.
If the user agent does not have something like a button to switch off, it has a bug.
If author do not structure their XHTML in such a way, that without their stylesheet the content order is not meaningful anymore, it is a bug auhtors have to fix.
This applies for normal webpages as well, if they do not work with switched off CSS interpretation (or script interpretation), the page has a bug, bad design.

There is not really a need for a reflowable CSS profile for EPUB, because the primary XHTML content is already as reflowable as it can be by design.

You're playing devil's advocate, which is fair enough. Both sides of an argument should be heard.

"If author do not structure their
XHTML in such a way, that without
their stylesheet the content order is
not meaningful anymore, it is a bug
auhtors have to fix."

I disagree with that. I might want to create a reflowable-layout rendition where my layout CSS (e.g. align text to the right of the page) is a reproduction of the printed page. It's reflowable but it also has styling like text-color which is absolutely necessary for the narrative of the text. A good Reader should give users the option to change the global CSS, but it shouldn't simply switch-off the author's CSS. Note, I use the word "change" not "switch off". This would make a great and flexible reflowable model for EPUB 3. A good spec will also remove the CSS attributes that are the mistakes - e.g. margins are totally unnecessary for authors to use in a reflowable context because, duh, it's gonna be reflowed, why would you allow a arbitrary margin? And when a publication gets so complicated that you must place text and images at precise locations, then you must use SVG.

The CSS Profile for Reflowable, is a Quality feature. It ensures that authors don't make crap eBooks. I think a good specification should 'ensure' that the users of the specification do not make mistakes. Does that make sense?

Margins, paddings and borders can be pretty useful to indicate structures like headings, chapters, sections, subsection, paragraphs, blockquote, stanzas, stanza lines etc.
Unfortunately the (non normative) suggestions in HTML5 how user agents may style especially new elements in HTML5 does not really work to indicate such structures - therefore it is pretty important, that authors can provide meaningful stylesheets to indicate the structure.

Margins or a restricted width for text can improve readability in case of a viewport with large width (> 50em). For such wide screen why not to place graphics or other text next to the first column. Obviously one needs features like media queries, floats, max-width etc to optimise the presentation for all available viewport sizes. Still the result can be reflowable without trouble for the audience.

Unfortunately colors can be problematic especially in some EPUB viewers due to bugs concerning CSS priorities. There are some, which ignore background color from author but use text color - this can result in a desaster for the audience, especially if they do not know how to switch off author stylesheets completely to compensate the bug of the EPUB viewer.
For example fitting to the content I created already books with light grey text on dark grey background - there are viewers replacing the background color with white - result of this viewer bug is almost unreadable text.
Following your approach to avoid nonsense presentation one has to take into account such bugs and remove any color information provided by the author from EPUB books - as you see, not easy to get it right in a specification, because soon you remove pretty useful features, if you start to remove everything, that can be problematic, if either implementors or authors do nasty things with them, or even worse, if finally just the combination of implementor and author efforts result in a problem for the audience.

SVG 1.1 (only this is allowed in EPUB currently) is problematic for larger amounts of text, line breaks have to be done manually by the author and SVG fonts are ignored by several viewers. To have complete control, one needs to convert text to path data (and for accessibility reason) one has to add the text additional das description. And SVG 1.1 has no feature to indicate the semantics of the text (heading, paragraph, stanza, stanza line etc).
In practice one needs a document with XHTML+SVG+CSS to get something appealing with a combination of larger amounts of text and graphics.
SVG tiny 1.2 has a feature for automatic line breaks and SVG 2 will have as well.

O.H., you have a very developer-centric view of EPUB3. Raise your awareness up to more of an architectural framework - which is what EPUB3 is.

All the stories you've just told in your last post are a mishmash of fixed-layout requirements and reflowable-layout requirements.

Forget fixed-layout for one second so that your story can become coherent so that a logical meaning can be extracted from it.

Text color is just fine my friend. It has no effect on layout. In reflowable layout, the author MUST sacrifice some control over layout otherwise what's the point in the text being reflowable and adaptable to screen size?

I think about this a little differently. For HTML in general, a User Agent may do custom reflow, regardless of the CSS employed, on behalf of the user (that's why we call it a User Agent!). For example you can read HTML using systems like Readability. These are still User Agents.  More exotic user agents may not be doing visual rendition at all, but aural rendition for people with print disabilities, or highly customized visual rendtions, such as for people with dyslexia. By definition an aural rendition is "flowing" not fixed-layout. So to me, EPUB is not more or less reflowable than HTML in general. but in the EPUB context there are simply more hints (metadata) about the expectations. And, most Web developers don't even think about special User Agents that may be "mangling" (from their intentions perspective) their content, but those who create EPUB that is not designated as fixed-layout must think about that: the default in EPUB-land is that this kind of drastic User Agent intervention a la Readability is the rule, rather than the exception. But I don't see it as a fundamental since as I said Uer Agents can do such reflowability for HTML in general, and you can and do have EPUB reading systems that don't paginate but just present each chunk of HTML rendered just as a web page would be by a vanilla User Agent.

A CSS Profile for Reflowable, would be a
Quality feature. It would ensure that
authors don't make crap eBooks. I
think a good specification should
'ensure' that the users of the
specification do not make mistakes.

A CSS Profile for Reflowable, would be a
Quality feature. It would ensure that
authors don't make crap eBooks. I
think a good specification should
'ensure' that the users of the
specification do not make mistakes.

Quote: "According to CSS 2.1 user agent conformance: 'The UA must allow the user to turn off the influence of author style sheets.' Because EPUB uses CSS, this is a requirement for EPUB viewers as well."

Why does idpf persist in using languages and standards developed by people who have absolutely no interest in electronic publishing?

Why do you think, that no member of the W3C has such interests?
Meanwhile EPUB is migrated to W3C.
As far as I have seen, unfortunately there was no viewer interpreting the format DTB (Digital Talking Book), required for EPUB2, only the XHTML variant. DTB would have been better for digital books, but obviously this was widely ignored.
No surprise, that it was dropped in EPUB 3 and is pratically not used in Books published as EPUB 2.
DTB is XML as well, therefore in general stylable with CSS.

And the core concepts of XML, XHTML, SVG, RDFa combined with decoration (CSS and XSLT) ist pretty good to markup content including semantic information.
The separation of information from decoration is a big progress for writing down digital formats.
If the audience has a option to strip off decoration, to replace it with own preferred decoration or to switch between different author styles is a quite important feature to ensure accessibility and quality of presentations.

If you only have s tag soup format, mixing everything up, you can only create low quality documents with different accessibility problems for several groups.

What format do you expect to be better for the purpose?

Secondary menu