Body: <p>I have some really simple CSS styles that work fine in the Kindle preview software, and on my actual Kindle Paperwhite, but when I send it to my iPad/iPhone and use the Amazon Kindle App, they don't work.</p>
  
  <p>For example...</p>
  
  <p>The CSS:</p>
  
  <pre><code>#copyright p {
      text-align: center;
  }
  </code></pre>
  
  <p>The HTML:</p>
  
  <pre><code>&lt;div id="copyright"&gt;
    &lt;p&gt;©2014 Author's Name&lt;/p&gt;
  &lt;/div&gt;
  </code></pre>
  
  <p>The output is centered in the Kindle Previewer, and on actual Kindle Paperwhite, but left aligned in the iOS app.</p>
  
  <p>Another example:</p>
  
  <p>CSS:</p>
  
  <pre><code>p.author-s-voice {
      font-style: italic;
      text-indent: 1.2em;
  }
  </code></pre>
  
  <p>HTML: </p>
  
  <pre><code>&lt;p class="author-s-voice"&gt;Lorem ipsum dolor sit amet, consectetur....&lt;/p&gt;
  </code></pre>
  
  <p>The output is italicized in the Kindle Previewer, and on actual Kindle Paperwhite, but not in the iOS app.</p>
  
  <p>This seems like really basic styling, why is it being ignored by the Kindle app?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-29T20:59:27.693Z
Comments.Text: Are you using the .azk file generated by Kindle Previewer and then sideloading it onto your device? If not, try doing it that way.
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-29T21:15:59.700Z
Comments.Text: @Tom I'm converting the .epub using Amazon's KindleGenerator (v2.9), and then emailing the resulting .mobi file to my devices.
Comments.UserDisplayName: Chuck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-29T21:20:00.253Z
Comments.Text: Kindle Previewer will auto-generate an .azk file for you when you select iOS view. Sideload (rather than email) that file (rather than the mobi) onto your iOS device.
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-29T21:21:07.530Z
Comments.Text: @Tom Ok, I'll try that, but isn't the resulting .mobi from KindleGen the actual file that gets distributed by Amazon when the book goes on sale?
Comments.UserDisplayName: Chuck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-29T21:21:54.680Z
Comments.Text: Nope, not for iOS. That's why they generate the .azk for you to proof with :D
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-29T21:31:21.583Z
Comments.Text: @Tom Thanks for your help, I just don't get it. The book is in my personal library and is download from Amazon Cloud onto my iOS device. Amazon must have converted the .mobi to .azk when it was added to my personal library for it to be available for download there. Ugh. So weird. I'll try your trick.
Comments.UserDisplayName: Chuck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-29T21:34:07.830Z
Comments.Text: yeah, I hear you. The reading system they used on iOS was behind their other platforms for a long time--it would only show the most barebones, KF7 (old mobi) formatting. At least it's catching up a bit, but the fragmenting they have within their own closed little ecosystem is just ridiculous. I'm pretty sure that what they do is just deliver you an .azk file when you buy a mobi on an iOS device, but not certain.
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-08-29T21:34:40.060Z
Comments.Text: Anyway, hope all that helps!
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-07T22:45:46.917Z
Comments.Text: You were right. For some odd reason "side loading" reduced (but not completely) removed the number of errors. Baffling, but there you go.
Comments.UserDisplayName: Chuck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-07T22:47:34.560Z
Comments.Text: Yeah, sometimes dealing with Amazon's formats can feel a bit like voodoo. Glad it mostly worked!
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-09-10T13:05:05.263Z
Comments.Text: Unfortunately the book has gone live and the "Look Inside" preview version is the same cruddy version I saw on the iOS version. Argh!
Comments.UserDisplayName: Chuck
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-11T00:37:03.137Z
Comments.Text: I believe that on the legacy format KF7 they converted the CSS style sheet on the .epub file to this wonky inline CSS and basically this resulted in the text only being able to accept _one_ style from _one_ class so if there were say three classes/selectors that were styling text it would arbitrarily have to drop two of them.  Baffling.
Comments.UserDisplayName: maxwell
Tags: <kindle><kindle-app><kindle-previewer>
Title: Basic CSS not working in Kindle iOS App
UserDisplayName: Chuck
ThreadText: # Basic CSS not working in Kindle iOS App
  
  (Asked by: username_0 on 2014-08-29)
  
  I have some really simple CSS styles that work fine in the Kindle preview software, and on my actual Kindle Paperwhite, but when I send it to my iPad/iPhone and use the Amazon Kindle App, they don't work.
  
  For example...
  
  The CSS:
  
  ```
  #copyright p {
      text-align: center;
  }
  
  ```
  
  The HTML:
  
  ```
  <div id="copyright">
    <p>©2014 Author's Name</p>
  </div>
  
  ```
  
  The output is centered in the Kindle Previewer, and on actual Kindle Paperwhite, but left aligned in the iOS app.
  
  Another example:
  
  CSS:
  
  ```
  p.author-s-voice {
      font-style: italic;
      text-indent: 1.2em;
  }
  
  ```
  
  HTML:
  
  ```
  <p class="author-s-voice">Lorem ipsum dolor sit amet, consectetur....</p>
  
  ```
  
  The output is italicized in the Kindle Previewer, and on actual Kindle Paperwhite, but not in the iOS app.
  
  This seems like really basic styling, why is it being ignored by the Kindle app?
  
  **Tags:** kindle, kindle-app, kindle-previewer
  
  > **Comments:**
  > **username_1**: Are you using the .azk file generated by Kindle Previewer and then sideloading it onto your device? If not, try doing it that way.  
  > **username_0**: @username_1 I'm converting the .epub using Amazon's KindleGenerator (v2.9), and then emailing the resulting .mobi file to my devices.  
  > **username_1**: Kindle Previewer will auto-generate an .azk file for you when you select iOS view. Sideload (rather than email) that file (rather than the mobi) onto your iOS device.  
  > **username_0**: @username_1 Ok, I'll try that, but isn't the resulting .mobi from KindleGen the actual file that gets distributed by Amazon when the book goes on sale?  
  > **username_1**: Nope, not for iOS. That's why they generate the .azk for you to proof with :D  
  > **username_0**: @username_1 Thanks for your help, I just don't get it. The book is in my personal library and is download from Amazon Cloud onto my iOS device. Amazon must have converted the .mobi to .azk when it was added to my personal library for it to be available for download there. Ugh. So weird. I'll try your trick.  
  > **username_1**: yeah, I hear you. The reading system they used on iOS was behind their other platforms for a long time--it would only show the most barebones, KF7 (old mobi) formatting. At least it's catching up a bit, but the fragmenting they have within their own closed little ecosystem is just ridiculous. I'm pretty sure that what they do is just deliver you an .azk file when you buy a mobi on an iOS device, but not certain.  
  > **username_1**: Anyway, hope all that helps!  
  > **username_0**: You were right. For some odd reason "side loading" reduced (but not completely) removed the number of errors. Baffling, but there you go.  
  > **username_1**: Yeah, sometimes dealing with Amazon's formats can feel a bit like voodoo. Glad it mostly worked!  
  > **username_0**: Unfortunately the book has gone live and the "Look Inside" preview version is the same cruddy version I saw on the iOS version. Argh!  
  > **username_2**: I believe that on the legacy format KF7 they converted the CSS style sheet on the .epub file to this wonky inline CSS and basically this resulted in the text only being able to accept _one_ style from _one_ class so if there were say three classes/selectors that were styling text it would arbitrarily have to drop two of them.  Baffling.  
  
  ---
  
  ## 0 answers
  
  