iBooks margins and clipping

[SantafA]

Hello everyone,

I'm making an epub book and I'm trying to get it to work well across multiple platforms.

I read this on this site (https://wiki.mobileread.com/wiki/EPub):

"The iBooks reader prevents problems with text ending up in the margins (and getting clipped) by setting -webkit-line-box-contain: block glyphs replaced;."

Should I actually insert this in my css? Like this:

html {-webkit-line-box-contain: block glyphs replaced;}

or does iBooks somehow automatically "set" this without the creator needing to put it in their style sheet? I don't have a Mac so I have no way to test this.

And more importantly, does anyone know if including this code could adversely affect how the book will be displayed on other devices/software besides iBooks?

I'm unfamiliar with this particular style and don't really understand what it does exactly. And I'm having trouble finding a clear discussion of it online.

Thank you everyone very much for your help.

[dgatwood]

Originally Posted by SantafA

I read this on this site (https://wiki.mobileread.com/wiki/EPub):

"The iBooks reader prevents problems with text ending up in the margins (and getting clipped) by setting -webkit-line-box-contain: block glyphs replaced;."

Should I actually insert this in my css? Like this:

html {-webkit-line-box-contain: block glyphs replaced;}

or does iBooks somehow automatically "set" this without the creator needing to put it in their style sheet? I don't have a Mac so I have no way to test this.

The iBooks reader includes the "glyphs" form of that CSS property in its built-in user agent stylesheet. Because of that line, if your book uses drop caps, and if they stick up above the top of the enclosing paragraph, iBooks will artificially push the drop cap lower to ensure that it does not stick up above the top of the paragraph. This is done to ensure that if the paragraph is the first thing on the page, the drop cap won't stick up above the top margin.

Unfortunately, the result is that these drop caps are rendered lower than they are in any other reader, and can potentially even collide with the line of text below them. For this reason, if your drop caps stick up above the paragraph, you should specify the "inline" form in your stylesheet, which overrides the default reader stylesheet, and tells the underlying WebKit engine not to shift the drop cap down.

The best way to test your content if you don't have a Mac or an iPhone is to grab a copy of WebKit (free, runs on most platforms). For previewing the way pagination will happen, print the page to PDF with variable page sizes. This isn't 100% accurate by any means, but it is a decent starting point that will get you about 85% of the way there, with the biggest difference being image handling behavior.

Of course, WebKit doesn't include the "glyphs" form of that style in its own default stylesheet, so if you want to better approximate what it will look like in iBooks, you can add:

html {-webkit-line-box-contain: block glyphs replaced;}

to your stylesheet. If that makes your content look wrong, change it to:

html {-webkit-line-box-contain: block inline replaced;}

and smile because you just avoided a bunch of iBooks users complaining about your drop cap formatting.

IMPORTANT: If a paragraph containing a drop cap could realistically appear at the very top of a page, you must use padding-top on that paragraph to ensure that the drop cap can never stick up above the top margin of the page. (After a page break, the margin-top property of a paragraph is zeroed, so you must use padding-top rather than margin-top, to ensure the necessary separation.)

[SantafA]

Thank you dgatwood for your very thoughtful reply. It totally answers my question.

[JSWolf]

But, if you are doing this for an eBook you plan on selling, you might have to remove your webkit commands in order to get it to validate.

[dgatwood]

Originally Posted by JSWolf

But, if you are doing this for an eBook you plan on selling, you might have to remove your webkit commands in order to get it to validate.

The W3C Validator doesn't care much about CSS as far as I can tell. You can specify pretty much any random crap as long as it follows the rules for CSS syntax structure, and it won't complain. Same goes for iTunes Producer's validator. I've had no trouble with that CSS in submissions to Apple, Amazon KDP, B&N, Kobo, Google, Smashwords Direct, Draft2Digtal, etc. Besides, vendor prefixes in any proper validator should be ignored because they can't (by design) ever conflict with legal CSS property names in the standard namespace.

I mean if you want it to get a clean bill of health without any warnings from something marginally abusive like the CSS linter, then maybe, but doing that is usually incompatible with getting usable results anyway. (For example, overqualifying selectors is often required if the reader's UA stylesheet is abusive/evil.)

[JSWolf]

Originally Posted by dgatwood

The W3C Validator

You have to pass an epubcheck validation. You don't validate the CSS using the W3C validator. You use epubcheck to validate the entire ePub eBook.

[Jellby]

Originally Posted by dgatwood

You can specify pretty much any random crap as long as it follows the rules for CSS syntax structure, and it won't complain.

That's according to the CSS spec, which says that the renderer should simply ignore properties it doesn't know about.

Originally Posted by JSWolf

You have to pass an epubcheck validation.

As far as I know, epubcheck validation is the same. It may warn about unknown properties (which is fine, they may be misspelt, or the content may rely too much on them), but it should not flag them as an error. And a renderer choking on unknown CSS properties is just buggy.

[JSWolf]

Originally Posted by Jellby

As far as I know, epubcheck validation is the same. It may warn about unknown properties (which is fine, they may be misspelt, or the content may rely too much on them), but it should not flag them as an error. And a renderer choking on unknown CSS properties is just buggy.

I don't know if newer versions of ADE (past 2.x) will choke or not. We do know ADE ignores the entire CSS if there is an error and if ADE thinks this is an error, then the entire CSS will be ignored.

[Jellby]

Originally Posted by JSWolf

I don't know if newer versions of ADE (past 2.x) will choke or not. We do know ADE ignores the entire CSS if there is an error and if ADE thinks this is an error, then the entire CSS will be ignored.

And we know ADE is buggy

I often use properties that are not strictly part of CSS 2 or ePub 2 (visibility, opacity, text-transform, hyphens...), and I don't recall ADE having a problem with them, other than ignoring them. It does ignore the whole CSS if there is a syntax error, like a missing semicolon or wrong units in a value, but that's different.

So, my advice with CSS: use whatever you want, validate and test with ADE. If it's not seriously broken, go ahead.

[dgatwood]

Originally Posted by JSWolf

I don't know if newer versions of ADE (past 2.x) will choke or not. We do know ADE ignores the entire CSS if there is an error and if ADE thinks this is an error, then the entire CSS will be ignored.

ADE handles those rules just fine (by which I mean that it ignores them without keeling over).

The only standard-ish rule that I've seen ADE barf on is a workaround for opacity problems in older versions of the IE rendering engine:

filter:alpha(opacity=0);