Mobigen Why are css media query examples in Amzn Kindle Publishing Guidelines so terrible?

[rjnagle]

Why are css media query examples in Amzn Kindle Publishing Guidelines so terrible?

A few weeks ago, I was testing an ebook on Kindle Previewer and Paperwhite and Kindle apps, and I see that my media queries don't work on the Paperwhite (and they ought to). It looks okay in Kindle Previewer though. My goal is on the title page and chapter headings to keep the headings bigger for large displays and smaller for small displays. Sounds logical, right?

But what I see instead on the Paperwhite device are title and heading fonts which come from my media query for large displays even though Paperwhite shouldn't do this.

 /*                                     Start naked css without queries */
div.book h1.title 
{font-size: 2em;
color: blue; 
}

 /*                                     END naked css without queries */
 /*                                     BEGIN query for large displays  */
@media only screen 
  and (min-width: 1025px) and (max-width: 4000px)
  and (orientation: portrait)
                {
div.book h1.title {
    font-size: 7em; 
    font-weight: bold;
   margin: 1em 0em 1em 0em;
   text-align: center; 
  }
}
 /*                                     END query for large displays  */

I'm simplifying my problem, but basically paperwhite displays the css inside the large display query. That seems bizzare.

I don't know where the problem lies. But things look fine in Kindle Previewer (even for simulated devices) and larger displays on android.


Look here: https://kdp.amazon.com/en_US/help/to...4KL488MXKPZ5BK


I see this format

@media amzn-kf8. This is only applied for the KF8 format.
For Mobi CSS styles, use the media query @media amzn-mobi.

And then:
@media amzn-kf8 and (device-aspectratio:1280/800)


Sorry, what is that garbage? Does Kindle only process proprietary tags such as amzn-kf8? Why did they specify an exact device-aspectratio rather than min-width and max-width?

(Ok, maybe because Kindle doesn't support max-width css property, does that also mean you can't use such statements in media queries?

Finally, if the only way to query a reading system is using device-aspectratio, doesn't that mean that Kindle ought to be providing exact dimensions of all their devices? Where does such information exist?

If you have to declare aspectratios in order to do your queries, should there be better examples? (and a table of device aspect ratios)

I have several other ebooks with problems like this. Although the code examples are about h1.title, in fact I'm seeing this thing in other css as well.


How do you make queries so that smaller displays actually are activated by them?

[jhowell]

Originally Posted by rjnagle

My goal is on the title page and chapter headings to keep the headings bigger for large displays and smaller for small displays. Sounds logical, right?

I don't see the logic in that. Sizing headings in ems allows them to be naturally proportioned to the body text. I don't see any advantage to having them be even larger on displays with more pixels. Especially since device resolution is increasing over time, resulting in displays with more pixels for a given screen size.

Originally Posted by rjnagle

How do you make queries so that smaller displays actually are activated by them?

If you are planning to produce a Kindle book for sale on Amazon then I would avoid the use of media queries for anything except providing different formatting for backward compatibility for older Kindle devices. This is the use case that the documentation you called out focuses on.

For the last five years Amazon has been transitioning to KFX format. (They do not mention that format by name in their documentation, but instead refer to it as Enhanced Typesetting.) KFX format does not support media queries. Any that are present in the source EPUB file are evaluated during the publishing process using generic values for the various properties and the resulting styles are baked into the KFX file.

[rjnagle]

Thanks.

Jhowell, To push back a little on your point.

Title page must have something more than a heading font. Also, the defaults don't especially seem well-suited for large devices 10-12 inch width.

Actually, the original reason for using queries is that I wanted to substitute a heading with an illustrated graphic and then to resize according to screen width. You would expect form factors over a certain size to have these heading graphics about 50% of width, but on paperwhite and iPad minis it makes sense to make the image a little wider (maybe 75% or 80%) for legibility....

Frankly, I haven't been keeping up with KFX (although maybe I should). It would really be sad if Amazon is drifting further from supporting css in the epub3 standard. I never really saw the benefit/value of the KFX format. How is it helping readers? How is it helping publishers? I kind of got the impression that KFX is mainly for Amazon creation tools (though I see in Previewer that I could export my epub to kfx).

(I for one would welcome changes to make it easier to force new pages. Even Google Play Books is pretty terrible about supporting that).

[ps67]

Originally Posted by rjnagle

...
I never really saw the benefit/value of the KFX format. How is it helping readers?

Hyphenation, ligatures, kerning and generally a better typography.

Originally Posted by rjnagle

How is it helping publishers?

I don't know, if there is a publisher here he can answer, but may be it doesn't

[jhowell]

Originally Posted by rjnagle

Title page must have something more than a heading font. Also, the defaults don't especially seem well-suited for large devices 10-12 inch width.

Most books that I have seen from the big publishers use an image for the title page so that it scales nicely to the screen size. This is a case where layout wins over user font size choice. This seems fine to me since it is a page that most readers skip over anyway.

Headings on the other hand are usually text specified in ems so that they scale with the reader's preferred font size without regard to the screen size. That works out well in most cases.

Originally Posted by rjnagle

It would really be sad if Amazon is drifting further from supporting css in the epub3 standard. I never really saw the benefit/value of the KFX format. How is it helping readers? How is it helping publishers? I kind of got the impression that KFX is mainly for Amazon creation tools (though I see in Previewer that I could export my epub to kfx).

Amazon has always maintained a sharp distinction between the open e-book formats that they accept from publishers and the closed proprietary formats that they pass on to customers.

The MOBI and KF8 delivery formats were both based on HTML standards that were current at the time. The content was wrapped in a proprietary container, but it turned out to be fairly easy to extract the original HTML.

With the newer KFX format they created a much more proprietary format with only loose connections to HTML. That, combined with the aggressive maintenance of DRM for KFX format, shows a commitment to keeping the customer side of Kindle e-books totally under their own control.

[rjnagle]

I remember all the Kindle-only kludges I had to devise in 2011 and 2012 (not that Adobe's own support for epub2 was much better). But after KF8, I held out hope that the epub standard and proprietary standard would move closer. Indeed for a few years that seemed to be the case, and I even was able to use a common stylesheet for both kindle systems and epub-based systems. I fear that is no longer becoming possible anymore. If the css media queries supported by Kindle are mostly proprietary and undocumented, then the two systems will continue to diverge.

I have used media queries mainly to scale/resize/position images; on android and ios based systems, they seem to have more support. It's the reading systems on the e-ink devices (as opposed to the e-ink simulations on Kindle Previewer) that have always been the problem.

I think there is a need is for a mechanism to adjust layouts depending on the size of the display. With images it is particularly hard because max-width is not supported.

Sure maybe we could differentiate between kf8 and mobi using amazon's current media queries, but display size is a much bigger concern for me.

[Hitch]

Originally Posted by rjnagle

Why are css media query examples in Amzn Kindle Publishing Guidelines so terrible?

A few weeks ago, I was testing an ebook on Kindle Previewer and Paperwhite and Kindle apps, and I see that my media queries don't work on the Paperwhite (and they ought to). It looks okay in Kindle Previewer though. My goal is on the title page and chapter headings to keep the headings bigger for large displays and smaller for small displays. Sounds logical, right?

But what I see instead on the Paperwhite device are title and heading fonts which come from my media query for large displays even though Paperwhite shouldn't do this.

 /*                                     Start naked css without queries */
div.book h1.title 
{font-size: 2em;
color: blue; 
}

 /*                                     END naked css without queries */
 /*                                     BEGIN query for large displays  */
@media only screen 
  and (min-width: 1025px) and (max-width: 4000px)
  and (orientation: portrait)
                {
div.book h1.title {
    font-size: 7em; 
    font-weight: bold;
   margin: 1em 0em 1em 0em;
   text-align: center; 
  }
}
 /*                                     END query for large displays  */

I'm simplifying my problem, but basically paperwhite displays the css inside the large display query. That seems bizzare.

I don't know where the problem lies. But things look fine in Kindle Previewer (even for simulated devices) and larger displays on android.


Look here: https://kdp.amazon.com/en_US/help/to...4KL488MXKPZ5BK


I see this format

@media amzn-kf8. This is only applied for the KF8 format.
For Mobi CSS styles, use the media query @media amzn-mobi.

And then:
@media amzn-kf8 and (device-aspectratio:1280/800)


Sorry, what is that garbage? Does Kindle only process proprietary tags such as amzn-kf8? Why did they specify an exact device-aspectratio rather than min-width and max-width?

(Ok, maybe because Kindle doesn't support max-width css property, does that also mean you can't use such statements in media queries?

As you already knew that max-width isn't supported in CSS, seriously, why would you expect it to work in the media query--which is still just CSS?

Looking at those sizes, did you think about what would happen in the Amazon LookInside? Or on a desktop reader like K4PC or KCR?

And yes, IME, you need to get the dimensions exact, or the query doesn't work. Using greater than/less than doesn't work at all, at least, not that I've seen.

Finally, if the only way to query a reading system is using device-aspectratio, doesn't that mean that Kindle ought to be providing exact dimensions of all their devices? Where does such information exist?

You can find that information online, both in their developer documentation and in their sales pages (for the devices). However, those queries don't always work, IME.

As jhowell mentions in his reply, using ems for text headings, or images from your print version, will more-easily achieve what you're trying to do. Trying to create an if/then scenario--"if this device is smaller than X, then use this graphic element, otherwise do this" is probably more aggravation, and less reliable than you want and need.

If you have to declare aspectratios in order to do your queries, should there be better examples? (and a table of device aspect ratios)

Well, Amazon is increasingly moving its self-publishers over to Kindle Create, which will do things like creating Hero Images (full-bleed chapter head images) and the like. They're clearly taking a cue from Apple and their "iAuthor" program, which creates proprietary, not-usable-elsewhere coding for solely their devices. It's frustrating, but there you are. Given that, I would not expect them to invest a ton of time in upgrading their CSS.

I have several other ebooks with problems like this. Although the code examples are about h1.title, in fact I'm seeing this thing in other css as well.

Like?

How do you make queries so that smaller displays actually are activated by them?

In my experience, mostly, you don't. Honestly, for title page and chapter head graphics, images work more easily and more reliably (although you can run into problems in the LookInside, too.)


Hitch

[rjnagle]

Honestly it had never occurred to me to use images on the title page, so I guess I learned something interesting and important

I think the potential "missed opportunity" here is the ability to float images on larger displays. Frankly, a lot of the reading systems are software-based and found on larger nonnative operating systems (kobo and Kindle app on android, & kindle and google play books on ios, etc).

It may seem easy just to say write a query for each device (Sanders Kleinfeld refers to this as the Heinz 57 method of ebook formatting), but this can increase the complexity and cruft. Also, I don't know; how many devices does Kindle produce in a year -- and how many years has it been producing devices? This seems like a lot of extra work to gather this information.

I hate to start wearing my "Boo Amazon" hat again, but I think they overestimate the willingness of authors and publishers to create the same ebook on different platforms. Or the willingness of consumers to purchase devices that disallow many important reading apps on it.

[Hitch]

Originally Posted by rjnagle

Honestly it had never occurred to me to use images on the title page, so I guess I learned something interesting and important

Well, good.

I think the potential "missed opportunity" here is the ability to float images on larger displays. Frankly, a lot of the reading systems are software-based and found on larger nonnative operating systems (kobo and Kindle app on android, & kindle and google play books on ios, etc).

? I float them on small and large displays all the time. What's Kobo, et al, got to to with the price of tea in China?

It may seem easy just to say write a query for each device (Sanders Kleinfeld refers to this as the Heinz 57 method of ebook formatting), but this can increase the complexity and cruft. Also, I don't know; how many devices does Kindle produce in a year -- and how many years has it been producing devices? This seems like a lot of extra work to gather this information.

So, why not simply write 1-3? One for KF8, one for KF7 and one for any devices that are iOS? I mean...why do you feel that you HAVE TO write one for each device? Generally speaking, I find exceedingly few instances in which this sort of granularity might be required.

I hate to start wearing my "Boo Amazon" hat again, but I think they overestimate the willingness of authors and publishers to create the same ebook on different platforms. Or the willingness of consumers to purchase devices that disallow many important reading apps on it.

But see...again, why do you think any of that? Publishers do NOT create the same eBook for "many" platforms; by and large, trade publishers make one ePUB and that's it; however it renders on KDP, it renders. Smaller publishers will do an ePUB for ALL ePUB-reading devices and a MOBI for KDP. That's it.

People buy their Readers, by and large, from the bookstore that they use. The MR community shops for the "best" device, but this population is incredibly tiny, compared to the typical buyer of Kindles, Nooks, Kobos, etc. I mean, how many millions upon millions of people buy iPhones? And use that as their "best" Reading device, when it's far from? Meh...people use what suits them and only the teeny population of places like MR actually sit there and think "oh, no, if I buy this book on Kindle, it might not work on my Nook," or whatever. Hell, *I* have all those devices and by and large, I still read, 99%, on my Oasis. Why? Because it's the one that I like. When I'm out and around, sure, I read on my Droid phone, but if the book isn't perfect there, I don't give it a moment's thought.

Hitch

[rjnagle]

Hitch, you asked, What's Kobo, et al, got to to with the price of tea in China?

Hitch, I realize that you have formatted a lot more kindle ebooks than I have, but treatment of images in a smaller display and in a bigger display is a big deal for my ebooks. On smaller e-ink devices, img can only be a block element. On larger displays, images often look much better when floating alongside text. It's discouraging to hear your report that even those hyper-specific aspectratio queries don't always work. Even doing that seemed onerous and hard to maintain.

Thanks for your thoughts on this. This gives me things to chew on while revising my template.

[Hitch]

Originally Posted by rjnagle

Hitch, you asked, What's Kobo, et al, got to to with the price of tea in China?

Hitch, I realize that you have formatted a lot more kindle ebooks than I have, but treatment of images in a smaller display and in a bigger display is a big deal for my ebooks. On smaller e-ink devices, img can only be a block element. On larger displays, images often look much better when floating alongside text. It's discouraging to hear your report that even those hyper-specific aspectratio queries don't always work. Even doing that seemed onerous and hard to maintain.

Yes, but you're overthinking it. If the images work, as a centered block element for smaller devices, they'll be just as usable, just as viable, for larger. We write floating images all the time, and we assume that they'll "not float" for those devices where they can't, the KF7's, for example. And yes, we'll use devices and aspect ratios to give it a "helping hand," but bear in mind, Amazon does change its devices yearly, and they update them and the CSS/coding/firmware ALL the time.

Believe me, I am with you, wanting more-complex books to look/work perfectly and all that, but...I've had to accept that sometimes, I'm just giving into my OCD desire to control everything. That can create a book that doesn't work very well in some circumstances. (For example, I was proud of us when we figured out how to do floating sidebars. Yeah, us! But you know what? They don't work worth a DAMN on smartphones. Yes, we did it--but we shouldn't have done it, no matter what the Client wanted.)

Thanks for your thoughts on this. This gives me things to chew on while revising my template.

You're welcome, of course. Um...lemme think...although I find most of their coding cringe-worthy, Vellum has a huge list of device-specific CSS in their standard CSS sheets. I mean, if you're looking for stuff.

Also, be advised, ironically, much fo the sample CSS that Amazon shows in its manual and HELP pages--typically doesn't actually work. Yep, I know. Weird, but true. I could be misremembering, but IIRC, that blue-background stuff (exemplar) doesn't work on the devices upon which it should. Again, it could be one of their other examples, but over the years, over and over, seriously--their examples don't work. Whacky, I know. I swear that they have guys in KDP Tech that put that stuff in there just to see who catches it and will complain.

Hitch

[Quoth]

Don't use media queries.
Keep it simple.

[Hitch]

Originally Posted by Quoth

Don't use media queries.
Keep it simple.

Dude.

You're just no fun a'tall, are ya? :-)

To be fair, while that can work for fiction--no MQ's, it's not that easy for non-fiction. Sometimes, working mqs would be nice.

Hitch

[Notjohn]

Originally Posted by Quoth

Don't use media queries.
Keep it simple.

Yeah, that's what I do. (Pace Hitch, most of my books are non-fiction.)

[Hitch]

Originally Posted by Notjohn

Yeah, that's what I do. (Pace Hitch, most of my books are non-fiction.)

Pax, NJ, but those are the ones that need it the most! :-)

Hitch