KDP Formatting Guidelines clarification KFX KF8

[TechieBooks]

Are we to suppose that KFX supports the specified KF8 HTML tag elements unless explicitly stated they're unsupported by the KFX supported/unsupported list? (And the same for the CSS attributes and values?)

For instance: <kbd> is supported for KF8 but not supported for KFX.

KDP's guidelines are ambiguous about this. Many of the HTML5 tags (e.g. <section>) aren't even present in the KFX list, is why I am asking.
__
I'm endeavoring to attempt to develop a resource for these ambiguities (such as stripping out every detail not relevant to eBooks off of the WHATWG HTML living standard), along with a simplified workflow for rich-text to finished EPUB and with the goal that it will serve as a "wide publisher" master copy that will, per for the source code, function on all of the major platforms. Instead of people having to go through this process from 0 to 100 again and again and again for each platform using the platform's proprietary auto-conversion software and which results in screwed up and limited formatting, and at the cost of being locked to those specific platforms for those specific files (and resulting in inconsistent presentations between platforms). Specifically for "text-heavy" reflowable eBooks (seeing as this isn't possible to accomplish with e.g. "fixed-layout" types, which are all platform proprietary without a common standard).

To that end, because Kindle is the most bastardized from the EPUB standard - the most resultingly limited - clarification on this is critical to the success of this effort. If it makes a difference, when I succeed, this resource won't be paywalled.

As far as I am aware, a resource like this doesn't currently exist. Certainly not for XHTML5.
___
Aside from that, there's one other part of the KDP guidelines I'd appreciate clarification on and it's this: "When using left or right margin and padding CSS properties, specify the values in percentage (%) instead of em units. This ensures that the margins do not grow too wide with large font sizes and impair reading."

They don't provide a code example for this anywhere in the guidelines. I am well versed in HTML/CSS and even I cannot come up with a means of making this actually work in percentage rather than ems. It does not at all look similar nor behave similar to em units in percentage (for instance, you can't actually CENTER the content with a left and right margin using percentage units; I also observed that the margins are fixed and therefore look dipropionate and ridiculous at larger font sizes, anyway). The desired behavior/presentation of these usage instances would be declaring a width (like with images, in percentage)... which is the same presentational look and behavior we get when we use em units for this, but not with percentage units for this.

I have not personally observed this cited "problem" with using em units for this instead of their suggested percentage units. Opinions? Please do air them. I am tempted to directly recommend disregarding this suggestion in favor of em units not percentage units.

For usage instance: offset content, like letters, news articles, fancy formatted signage, things like that. Mostly that would be limited in left and right margins to 1em, 2em, and 3em, depending on what they are (very small margins). I can't think of any reason to apply margins greater than that for anything in either fiction or nonfiction. But I can imagine that applying large values to this with ems would result in what they describe... I just don't see it with 1em to 3em.

[JSWolf]

It would be best to make this program you are working on a plugin for the calibre editor and/or Sigil where is can show what needs to be edited be is removed or changed.

For something like KFX, it's only needed to be changed if it causes a problem or need to work, but doesn't. <section> is an example of something you can ignore as it doesn't make any difference when reading the eBook. It only makes a difference when coding.

[JSWolf]

Originally Posted by TechieBooks

Aside from that, there's one other part of the KDP guidelines I'd appreciate clarification on and it's this: "When using left or right margin and padding CSS properties, specify the values in percentage (%) instead of em units. This ensures that the margins do not grow too wide with large font sizes and impair reading."

They don't provide a code example for this anywhere in the guidelines. I am well versed in HTML/CSS and even I cannot come up with a means of making this actually work in percentage rather than ems. It does not at all look similar nor behave similar to em units in percentage (for instance, you can't actually CENTER the content with a left and right margin using percentage units; I also observed that the margins are fixed and therefore look dipropionate and ridiculous at larger font sizes, anyway). The desired behavior/presentation of these usage instances would be declaring a width (like with images, in percentage)... which is the same presentational look and behavior we get when we use em units for this, but not with percentage units for this.

I have not personally observed this cited "problem" with using em units for this instead of their suggested percentage units. Opinions? Please do air them. I am tempted to directly recommend disregarding this suggestion in favor of em units not percentage units.

For usage instance: offset content, like letters, news articles, fancy formatted signage, things like that. Mostly that would be limited in left and right margins to 1em, 2em, and 3em, depending on what they are (very small margins). I can't think of any reason to apply margins greater than that for anything in either fiction or nonfiction. But I can imagine that applying large values to this with ems would result in what they describe... I just don't see it with 1em to 3em.[/QUOTE]

Don't use % for margins. If you do, you get a different size margin for different size screens. I've seen a lot of eBooks from Amazon with a text indent of 7% witch is too large. And on a Kindle Scribe is even larger. I use a text indent of 1.2em and that looks good. Even if it changes with the font size change, it keeps it consistent based on the font size.

Also, don't make the chapter headers with so much wasted space. I've seen wasted space of 15% in some eBooks. Don't use %. Use em. 1em top/1em boom margins works well.

It sounds like Amazon's guidelines have some rather stupid stuff in there.

[TechieBooks]

Originally Posted by JSWolf

It would be best to make this program you are working on a plugin for the calibre editor and/or Sigil where is can show what needs to be edited be is removed or changed.

For something like KFX, it's only needed to be changed if it causes a problem or need to work, but doesn't. <section> is an example of something you can ignore as it doesn't make any difference when reading the eBook. It only makes a difference when coding.

Alas, I'm not a programmer. I wouldn't even know where to begin. However, I have dug up one MIT licensed resource ("Word Up") that is local and uses JavaScript to markup rich-text into actually clean HTML (no CSS mess; but preserving style markup that is otherwise blown-out via other suggested means of doing this, which totally sucks) that would be great as a plugin 'conversion', but... it's piggybacking off of something else (CKEditor 4). I don't know if it could be made to function by itself in just a Calibre plugin. However, something like that (without the markdown option), is sorely needed as such a resource as this. In the meantime, it'll be that and copy/paste (I have repackaged Word Up as a portable app).

Personally, I like WordtoHTML better, but it isn't open source and there's some funky variant sever-side key preventing you from even looking at the full source code (JavaScript), so lol.

Anyway, yes, I'm attempting to make this resource (X)HTML5 compliant; semantically correct. Not <div> salad. It matters to assistive technology. If we're bothering, might as well be bothering to do it right and to current spec, I figure. (And, there is a valid argument in that it is easier to read and therefore to maintain; a nice plus).

Originally Posted by JSWolf

Don't use % for margins. If you do, you get a different size margin for different size screens. I've seen a lot of eBooks from Amazon with a text indent of 7% witch is too large. And on a Kindle Scribe is even larger. I use a text indent of 1.2em and that looks good. Even if it changes with the font size change, it keeps it consistent based on the font size.

Also, don't make the chapter headers with so much wasted space. I've seen wasted space of 15% in some eBooks. Don't use %. Use em. 1em top/1em boom margins works well.

It sounds like Amazon's guidelines have some rather stupid stuff in there.

It's the only resource that bothers to (poorly) document what actually is supported or not at the code-level, so there's that. But, yes, this particular one stands out. And thank you for clarifying that, I suspected it was erroneous but wanted to make extra sure.

[nabsltd]

Originally Posted by TechieBooks

Aside from that, there's one other part of the KDP guidelines I'd appreciate clarification on and it's this: "When using left or right margin and padding CSS properties, specify the values in percentage (%) instead of em units. This ensures that the margins do not grow too wide with large font sizes and impair reading."

You can ignore this. The "font resizing" on Kindle apps and Kindle eInk readers is a very weird rescaling that leaves left and right margins and indents alone.

Essentially, if the font size slider is set where a capital "H" is 1/4" high, then you increase it so that the same letter is now 1/2" high (twice as big), then all vertical measurements will also increase by the same factor (2x as large). But, the left and right margins and text-indent remain the same in both cases.

It looks like in this change the root em does not change, and all horizontal measurements appear to still use the root em as a basis, while all vertical measurements get scaled with the font. Even percent measurements, which should be based on the screen height, get scaled.

[nabsltd]

Originally Posted by JSWolf

It does not at all look similar nor behave similar to em units in percentage (for instance, you can't actually CENTER the content with a left and right margin using percentage units;

You can't truly center anything without using more than just margins, and you don't need to touch margins to center something...text-align: center; centers the content.

OTOH, you can use the following to "center" an image without centering text:

.image-box {
text-align: left;
margin-left: 20%;
margin-right: 20%;
}

.image-fill {
width: 100%;
}

<p class="image-box"><img src="some-image.png" class="image-fill"><br />
An un-centered caption.
</p>

[JSWolf]

Originally Posted by nabsltd

You can't truly center anything without using more than just margins, and you don't need to touch margins to center something...text-align: center; centers the content.

OTOH, you can use the following to "center" an image without centering text:

.image-box {
text-align: left;
margin-left: 20%;
margin-right: 20%;
}

.image-fill {
width: 100%;
}

<p class="image-box"><img src="some-image.png" class="image-fill"><br />
An un-centered caption.
</p>

There is one thing you can center with margins. This leaves a 20% 2px line centered.

hr {
  margin-top: 0.9em;
  margin-right: 40%;
  margin-bottom: 0.9em;
  margin-left: 40%;
  border-top: 2px solid;
}