figure page-break avoid causing issues on kindle about blitz HOT 8 CLOSED

Which maps to this util for those interested:

So easier fix would be to reset to auto in the amzn-kf8 media query. However I’d really like to test what the root of the issue is first e.g. combo of the 2 props, or only one of those.

I’m not sure their Android app is using a Chrome web view to be honest – may well be their embeddable fork of 2011–2012 webkit – but it’s weird it triggers this "blank" while the props are not officially supported/implemented so out of curiosity, I’d like to check.

from blitz.

OK can reproduce with page-break-inside: avoid;.

My assumption is that break-inside: avoid is ignored because it is not supported, and page-break-inside: avoid; is somewhat implemented but disabled.

Which reminds me of an issue in iBooks I had to debug when consulting for a publisher… Containers spanning multiple “pages” while having page-break-inside: avoid created a handful of nasty issues: for some reason that one line completely broke fragmentation with such containers of text, so margin-top was completely off (like 2 or 3 times the value you specified), lines of text were cut off, etc.

I’m wondering whether the “blank” couldn’t be an artefact, although the fact it’s happening with images and captions makes it even weirder. I’ll ask on eprdctn.

from blitz.

I always use "auto" for the Kindle CSS file. Up until now, the only thing I notice is that Kindle completely ignores "avoid", and "auto" is fairly useless for keeping elements together. Haven't experienced the "blanking". About ibooks, I'm concerned, bc I DO use page-break-inside: avoid; across multiple pages (sidebars) as a regular element. Unaware of nasty issues? What are they? What's the fix?

from blitz.

@simjon In my experience, triggering the iBooks’ bug took quite a long container with page-break-inside: avoid (like at least 4–5 pages) so I encountered that one on one occasion – but was able to reproduce it in a sample file.

That was back in 2015, and although I can’t share the recap/screenshots, I can see it also happened in Kobo on iOS. As anecdata, the container was so long that it would create a blank page in ADE for instance.

from blitz.

P sure there are a few of those instances floating around out there in my universe. Will work to avoid—erm, and auto. Thanks.

from blitz.

Thanks again for the quick fix, @JayPanoz.

Random side note: this also fixes an odd issue I had with nested figures (which had essentially figure > figure + figure { display: inline-block} which would lead to odd floating as well as distorted image aspect ratios.

If they could at least switch from phantomjs to puppeteer...

from blitz.

No problem, thank you again to both of you for reporting the issue and providing useful details. :-)

Re phantomjs, don’t quote me on that but I guess part of the reason why they’re not rushing to change it while it’s been abandoned for a while is that it may well offer a more accurate preview than anything else.

Indeed, if you’re checking their open source code for Kindle eInk devices for instance, you’ll literally find a fork of Webkit circa 2012 in there, with a few proprietary extensions. It’s been living in quasi-complete isolation of Vanilla Webkit, which explains why there are so many modern CSS modules not supported for instance.

So ironically, switching to Puppeteer (or something else) could even create more problems than it would solve for them – otoh they created those problems for themselves, by tying so much the the ebook format instead of the rendering engine so it’s really hard to feel pity for the people who made those tech decisions.

from blitz.

I was trying to add a reaction emoji to your comment but none felt appropriate 😉 I had no idea they had forked phantomjs that long ago -- amazing (in a terrifying way).

Thanks again for the fix!

from blitz.