View Full Version : iBooks Night Mode Overriding CSS


zephyrmays
02-24-2013, 06:51 PM
Is there a way define a CSS stylesheet for an epub viewed on iBooks 3.0 in night mode?

I've tried all the permutations of the Night Vision Style Set Tags as defined in Appendix B found here http://idpf.org/epub/altss-tags/, but with no luck.

There are a few black backgrounds defined in the regular stylesheet that I need to set alternate colors for when the iDevice is in night mode.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
<meta charset="utf-8" />
<title>
SECTION 1 Part B Avionics
</title>
<link rel="stylesheet" type="text/css" href="css/formatting.css" class="day" title="Day"/>
<link rel="alternate stylesheet" type="text/css" href="css/formatting_night.css" class="night"/>

</head>
<body>
...
</body>
</html>


Also, is there any developer reference for Apple's iBooks? I cannot find much documentation...

Regards,

Zephyr

Toxaris
02-25-2013, 02:45 AM
As far as I know that is only supported in ePUB3, so you might want to ensure that your ePUB is ePUB3. Then again there is no garantuee it will work. The actual reader has to support it.

There is a developer reference I think, I seem to recall there are links to it in some posts around here.

dgatwood
02-25-2013, 03:22 AM
Is there a way define a CSS stylesheet for an epub viewed on iBooks 3.0 in night mode?


I don't think so; night mode is just like any other set of reader style overrides; as a rule, you pretty much have to assume that the reader is going to override certain styles when people specify those modes, and make sure that text doesn't suddenly become invisible with judicious use of !important.




I've tried all the permutations of the Night Vision Style Set Tags as defined in Appendix B found here http://idpf.org/epub/altss-tags/, but with no luck.


It might be worth filing a feature request bug over at bugreport.apple.com. It requires you to create a free developer account.



There are a few black backgrounds defined in the regular stylesheet that I need to set alternate colors for when the iDevice is in night mode.


You could always do something subtle like setting the background to #101010 or something so that it looks basically like black in normal mode, but looks like a dark grey in night mode.



Also, is there any developer reference for Apple's iBooks? I cannot find much documentation...


If you decide to distribute through the iBookstore, then yes. After you sign up for an iTunes Connect account (http://www.apple.com/itunes/content-providers/book-faq.html), you should gain access to the iBookstore Asset Guide.

Otherwise... well, there are various copies floating around, all of which seem to be badly out of date. *sigh*

JSWolf
02-25-2013, 07:01 AM
Is there a way define a CSS stylesheet for an epub viewed on iBooks 3.0 in night mode?

I've tried all the permutations of the Night Vision Style Set Tags as defined in Appendix B found here http://idpf.org/epub/altss-tags/, but with no luck.

This is not a bug. It's Apple doing things their way. A lot of iBooks is non-standard. Filing a bug report is going to be a waste of your time.

zephyrmays
02-25-2013, 05:19 PM
I appreciate the feed back.

in addition to not implementing the alternate stylesheets iaw the ipdf spec, iBooks night mode also disregards background: <color> and !important statements.

I've got an email into the iBookstore team, who's referred my questions about night mode to the technical folks. Here's to hoping they have a workaround, or tell me I was just doing it wrong along with an example of how to do it correctly.

JSWolf
02-26-2013, 08:53 AM
Night mode is already an override of whatever color is on screen anyway. So it's logical to think it will override your color choices.

Jellby
02-26-2013, 09:13 AM
Night mode is already an override of whatever color is on screen anyway. So it's logical to think it will override your color choices.

But if there's nothing in the book that sets the colour of the main text, then nothing is overriding anything, and night mode could be applied above or below (in priority) the book styles.

JSWolf
02-26-2013, 09:16 AM
But if there's nothing in the book that sets the colour of the main text, then nothing is overriding anything, and night mode could be applied above or below (in priority) the book styles.

A lot of eBooks created from Word documents have the text set as black. So if iBooks didn't override the color choices, then you'd get black on back.

Jellby
02-26-2013, 11:16 AM
Shame on book creators then. What I mean is that it's not necessary for a "night mode" to override anything. iBooks does? fine then, that's their choice, but it could have been done otherwise. No method is perfect, though, whatever the choice, it will fail in some cases, work in others.

zephyrmays
02-26-2013, 11:26 AM
As a little background, my epub is completely hand coded with no extraneous coding. Every line, css rule, file has a purpose, and 100% conforms to the ePub 3.0 spec.

Jellby
02-26-2013, 12:54 PM
You are in my team then, and you'd probably like an ebook reader that plays nicely with your book. Unfortunately, most ebook readers out there are not designed for well-coded ebooks, but for real-world (often non-compliant) ebooks.

zephyrmays
02-26-2013, 01:18 PM
WARNING: Soapbox follows. :offtopic:

Unfortunately, most ebook readers out there are not designed for well-coded ebooks, but for real-world (often non-compliant) ebooks.

And that is the worst part. I understand e-readers (hardware and software) are limited by the design choices their creators make, but at least publish what those limitations are, what parts of the spec are supported, and fully disclose the proprietary features and behaviors (and how to use them!) so we as authors can target our content take full advantage of each platform.

End soapbox.

JSWolf
02-26-2013, 01:46 PM
As a little background, my epub is completely hand coded with no extraneous coding. Every line, css rule, file has a purpose, and 100% conforms to the ePub 3.0 spec.

But, iBooks does not conform 100% to any ePub spec.

zephyrmays
02-26-2013, 01:55 PM
But, iBooks does not conform 100% to any ePub spec.
I understand that, but see my comment above. It would be nice to have some guidance about what is and isn't supported from the e-reader makers.

JSWolf
02-26-2013, 02:01 PM
I understand that, but see my comment above. It would be nice to have some guidance about what is and isn't supported from the e-reader makers.

I agree. But with iBooks, what works and what doesn't work can can change from release to release. Say a bug get s fixed that you had a workaround for. That workaround might not work any longer.

dgatwood
02-26-2013, 11:19 PM
I'm assuming that you already have the magic file in there that tells iBooks to use the publisher-specified fonts, right? I would expect any "We'll fix your broken books" behavior to be keyed off of the presence or absence of that file; if somebody has take the time to update their content to work in iBooks, then there's no need to assume that the content is broken, and if they haven't, then it probably is broken. :D

Either way, I want to strongly disagree with JSWolf's advice. Please do file bugs every time you find something that doesn't behave the way you expect it to behave. This does three things:

1. It ensures that the development team knows that a particular behavior is dubious.
2. It ensures that they have an accurate picture of how many people that behavior is causing problems for.
3. If it really is an expected behavior and they have already come up with a better way of doing what you're trying to do, they'll tell you and save you a lot of wasted time. :)

I can't tell you how many times I've filed a bug and been told, "You're the first one to complain about it" even though people have been whining and kvetching about it on forums for years. You can safely assume that nobody will ever fix problems that they haven't been told about, and that the priority of bug fixes is proportional to the number of people it affects.

You should never assume that developers of any application, whether they work at Apple or Adobe or Kobo or B&N or Amazon or whatever, have any idea that they've broken something, because 99 times out of 100, they don't. They're not producing content that has to work with the devices; they're producing devices that have to work with the content. You folks—the people who are in the trenches producing content—are the ones who know what problems you're hitting in the real world.

More to the point, you're the ones who notice and hear about it when your content breaks. When your content breaks, it is quite frequently caused by a poorly designed fix to work around something wrong with somebody else's content. But if your content is right, it should take priority over somebody else whose content is wrong. By screaming early and often, you ensure that poorly engineered fixes don't become so engrained in the behavior of an app that they can't be changed, and you greatly increase the chances of the engineering team going back to fix the problem the right way. The earlier you notice a bug, the easier it is to fix, and all that.

So please do file bugs. Please.

JSWolf
02-27-2013, 06:46 PM
This isn't a bug. It's a feature request. If you do file this as a bug, it very well may get ignored since it's not a bug. If you do report this to Apple, do so as a feature request.

dgatwood
02-28-2013, 01:19 AM
I agree that supporting the night colors feature of the specification is either a feature request or an enhancement request, depending on how you look at it.

But when I said "file a bug", I was talking about the comment that iBooks was ignoring the specified background color and substituting its own even when the CSS specified !important. If that's really happening (as opposed to something more subtle), then I would call that a bug. :)

JSWolf
03-01-2013, 04:02 PM
I agree that supporting the night colors feature of the specification is either a feature request or an enhancement request, depending on how you look at it.

But when I said "file a bug", I was talking about the comment that iBooks was ignoring the specified background color and substituting its own even when the CSS specified !important. If that's really happening (as opposed to something more subtle), then I would call that a bug. :)

It's not a bug. iBooks is specifically overriding color settings in order to have night mode. That's the way it's written. So it's still not a bug. You go into night mode and your colors are overridden. So what you want to do is something iBooks doesn't do because it was programmed to override.

So what you are asking for is a feature request. It's not a bug.

dgatwood
03-02-2013, 12:19 AM
It's not a bug. iBooks is specifically overriding color settings in order to have night mode. That's the way it's written. So it's still not a bug.


By that standard, there's no such thing as a bug, because every bug is something that the code was programmed to do. :D

The intent of !important is to be a line in the sand. It indicates that your content could break if the style is overridden by other styles. The CSS spec didn't allow user agent stylesheets to override those for a reason, and folks designing eBook readers should respect that decision. For that reason, I consider it a spec compliance bug when a reader crosses that line.

Either way, the question of whether it is a bug or a feature request is pretty much quibbling over semantics. They all go into the same bug queue, and if the people who get the report decide that a bug should be a feature request or vice-versa, they can change it in less time than it took you to set it in the first place.

Just please don't set it to "Security". :)

JSWolf
03-02-2013, 09:27 PM
By that standard, there's no such thing as a bug, because every bug is something that the code was programmed to do. :D

The intent of !important is to be a line in the sand. It indicates that your content could break if the style is overridden by other styles. The CSS spec didn't allow user agent stylesheets to override those for a reason, and folks designing eBook readers should respect that decision. For that reason, I consider it a spec compliance bug when a reader crosses that line.

Either way, the question of whether it is a bug or a feature request is pretty much quibbling over semantics. They all go into the same bug queue, and if the people who get the report decide that a bug should be a feature request or vice-versa, they can change it in less time than it took you to set it in the first place.

Just please don't set it to "Security". :)

If I programmed iBooks to allow you to set a background color in night mode and it did not work, then that would be a bug.

If I programmed iBooks to override background colors in night mode and that's what is does, then it's not a bug.

So in this case, it's not a bug as it was specifically programmed to override background colors in night mode. It's not semantics. Its not a bug.

You want to put in a feature request.

Jellby
03-03-2013, 04:02 AM
What Jon says is that bugs are unintentional. If it's intentional, no matter how wrong or harmful it is, it is not, strictly, a bug.