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.