[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