Sigil file failing validation due to ePub3 standard

[eggheadbooks1]

Hi,

I just created a test ePub2 file in Sigil using various elements such as lines, ordered lists, etc. Problem is, when I try to validate in EPUB-Checker or online at IDPF, the file fails because ePub3 standards are being applied.

For example, I had to change

<strike>

to

<del>

for strikethrough text. I could not apply a background color to my tables directly in the table element; I had to create a class for the color.

Most irritating of all, I cannot specify a bullet type in my lists;

<ol type="a">

for example, because "type" is not allowed here in HTML5. It also didn't like my nested list, declaring

<ol type="a">

to be disallowed, as in:

<ol>
<li>You may enter at will;</li>
<li>You may leave at will:</li>
<ol type="a">
<li>before noon;</li>
<li>or after midnight.</li>
</ol>
<li>You may forfeit entry.</li>
</ol>

Yet all not only work perfectly in Sigil and ADE, but convert nicely to Kindle in both Previewer and Previewer3.

I Googled HTML5 for lists but I cannot find anything that allows me to add a type to the list. I tried, for example, to create various classes for the usual bullets --

.circle
{list-style-type:circle;}
.disc
{list-style-type:disc;}
.a
{list-style-type:a;}

-- but to no avail.

Does anyone know either a) how to finesse lists in HTML5 OR how to force ePubCheck to apply ePub2 standards to my ePub2 file?

[DiapDealer]

I'm not following very well. The IDPF's Epub Checker cannot be influenced to treat an EPUB2 like an EPUB3 or vice versa. EPUB3s are validated against EPUB3 spec, and EPUB2s are validated against EPUB2 spec. It determines which spec to use by checking the version attribute of the OPF's package tag (which determines whether an EPUB is an EPUB2 or an EPUB3).

Also ... HTML5 is not supported in EPUB2. Not sure why you're referencing it with regard to an EPUB2.

I'm also not certain what any of this has to do with Sigil (except for the fact that you created your test EPUB with Sigil). Why do you believe EpubCheck is validating your EPUB2 using the EPUB3 spec in the first place? I've never known it to get that wrong.

The fact that Kindlegen/Preview is OK with an EPUB, or that it "works" in ADE has absolutely nothing to do with whether or not it meets EPUB specifications.

I can tell you that advanced list manipulation in an epub isn't worth the trouble. Trying to alter the starting numbers or the bullet type will work on one device/app but not another. There is no consistent support for lists other than ones that start with the number 1, or that use a standard bullet. Fighting to get anything else to consistently work across a wide range of devices will only drive you nuts.

Regardless of where it "works", the strike tag is obsolete in XHTML (which is what Sigil and EPUB2 uses).

[eggheadbooks1]

I assumed it was applying ePub3 standards because the HTML that I had used (re: adding background color directly in the td tag instead of creating a class) was previously accepted last time I used it about a year or so ago. Now the validator rejects it as not allowed. This is why I believed that the validator was using ePub3 standards despite my trying to validate an ePub2.

My understanding is also that the "type" attribute in un/ordered lists is allowed in HTML4. So when it failed validation, I googled it and I found that "type" as an attribute in the ol and ul tags was deprecated in HTML5. Again, this led me to believe that ePub3 standards were being applied to my file by the validator.

When I tried to use CSS to create a class to do the same thing -- create lowercase lettered bullets, for example, using the list-style-type attribute -- Sigil didn't apply the class. I tried to find if there is an alternate attribute that I am supposed to be using, but to no avail (hence my OP). I'll try again in Sigil in case I missed something.

I know that devices do not render such lists equally; this is an experiment in which I need to see what, if anything, works and where. I have been testing both in my ePub apps and converting to Kindle via the new Previewer3.

Re: strike: I thought strike was only rendered obsolete in HTML5, but not HTML 4, because when I used the strikethrough icon on the Sigil toolbar, it applied <strike>, not <del>, to the text. I just tested it again in a new file in Sigil; it definitely applies <strike> to the text -- but only in book view. In code view, if you use the strikethrough icon, Sigil applies <del> to the text. I didn't notice this anomaly before. Hence my confusion.

While we're on the topic, <u> was deprecated in HTML 4.01 and will cause validation failure but Sigil still uses it if you underline text using the underline icon on the toolbar. Why is that?

[KevinH]

The u tag has been undeprecated in html5 and redefined. Either way using css is better.

I will look for and change BookView to use del if possible instead of strike but many of the BookView icon based changes are hardcoded in webkit. That is why I strongly recommend never editing anything other than simple text in BookView. Our plan is to make BookView go away eventually.

[Toxaris]

Also ePUB2 uses XHTML, not HTML4. There are differences. Are you sure you created an ePUB2? You should be able to see it in the titlebar.

[DiapDealer]

<strike> is obsolete in HTML4.1 as well, I think.
Sorry deprecated in HTML 4.01 and obsolete in XHTML 1.0, 1.1

[Doitsu]

Originally Posted by DiapDealer

<strike> is obsolete in HTML4.1 as well, I think.
Sorry deprecated in HTML 4.01 and obsolete in XHTML 1.0, 1.1

BTW, the IDPF doesn't like <strike> in epub2 and epub3 books; epubcheck will flag it as an error:

ERROR(RSC-005): Error while parsing file 'element "strike" not allowed anywhere; expected the element end-tag, text or element [...]

(<u> is only flagged in epub2 books.)

[KevinH]

Okay, I took a closer look at how "strike" is implemented in BookView. BookView is simply live editing an existing html page. To do that you put the page in "designMode" and then can more easily run a number of commands using javascript with the "document.execCommand(blah)" and it operates on the currently selected text all automatically controlled by the browser's webkit widget.

BookView uses this interface correctly and uses the "strikeThrough" command to toggle strikeThrough on and off. How that is actually accomplished is browser (ie. webkit in this case) dependent. For Qt's webkit, they appear to be using the old "strike" tag and not "del".

See this page that documents this standard designMode interface and its commands:

https://developer.mozilla.org/en-US/...nt/execCommand

So there is no easy way for Sigil to change this without having to write our own javascript to get the current selection and then wrap this in "del" tags all in a live html page under designMode. You can of course do this already in Sigil with clips and things at the code level (CodeView)

It simply is not worth the time for us to spend changing it in BookView or adding a filter workaround to replace all strike tags with del tags (as that can easily be accomplished by global find and replace or a plugin). And since Webkit has effectively been dropped by Qt, they will not fix this bug. Yet another nail in the BookView coffin.

Hope this explains things.

KevinH

Originally Posted by KevinH

The u tag has been undeprecated in html5 and redefined. Either way using css is better.

I will look for and change BookView to use del if possible instead of strike but many of the BookView icon based changes are hardcoded in webkit. That is why I strongly recommend never editing anything other than simple text in BookView. Our plan is to make BookView go away eventually.

[KevinH]

That said, if "strike" is obsolete under both epub2 and epub3, then we could modify Sigil's "Mend" to automatically replace any "strike" tags with "del" tags.

KevinH

[Doitsu]

Originally Posted by KevinH

That said, if "strike" is obsolete under both epub2 and epub3, then we could modify Sigil's "Mend" to automatically replace and "strike" tags with "del" tags.

IMHO, that's a good idea. While you're at it, you might want to consider replacing <u></u> tags in epub2 books with <span style="text-decoration:underline;"></span>.

(As you know, this change won't be necessary for epub3 books, because the <u> tag has been undeprecated in HTML5.)

[DiapDealer]

Originally Posted by Doitsu

IMHO, that's a good idea. While you're at it, you might want to consider replacing <u></u> tags in epub2 books with <span style="text-decoration:underline;"></span>.

(As you know, this change won't be necessary for epub3 books, because the <u> tag has been undeprecated in HTML5.)

I'm not entirely opposed, but at the same time, I'm not crazy about the idea of Sigil injecting inline styles. They just make things so difficult to change later.

And while I'm not personally opposed to "Mend" changing the occasional "strike" to "del" in my code, I worry about how others would feel about it. Does Mend currently change any other tags to different ones under normal operation? Still, those who don't like it can always turn off Mend on Save/Open, I guess. *shrug*

What if we let it brew a little bit and let some others chime in? While spec compliance is important, it's also important to realize that there really isn't a rendering system in the world that will kick up it's heels at "u" and "strike" tags. There's too much legacy material out there to risk breakage by removing support. Would it really hurt to let the user decide how compliant they want to worry about being?

[KevinH]

I did find one interesting tidbit. If we run document.execCommand("styleWithCSS", "true") once BookView has been loaded up properly, it will force the internal webkit wiget to use inline styles to handle underlining, strike, subscript, superscript, etc.

That means that the code produced by BookView (although unsightly with all of those spans with inline styles flying around) would at least be technically correct for both epub2 and epub3.

My guess is this is why the strike bug has not been noticed and fixed by Qt previously as many users will have this set.

So that is at least an option.

KevinH

[eggheadbooks1]

Originally Posted by KevinH

The u tag has been undeprecated in html5 and redefined. Either way using css is better.

Hi Kevin: I do, ever since a file I had that used it failed validation and I found out <u> was deprecated. Since then I've merely been curious as to why Sigil left it in.

Originally Posted by KevinH

I will look for and change BookView to use del if possible instead of strike but many of the BookView icon based changes are hardcoded in webkit. That is why I strongly recommend never editing anything other than simple text in BookView. Our plan is to make BookView go away eventually.

I beg you, no! While it's true I do 90% of my work in Sigil in code view, being able to switch to Book View to see how something is rendering is invaluable. It saves a lot of time, and it's easy to see mistakes right away. In Code View it's too easy to gloss over the content itself because one is focused on the code. But in Book View one can easily see at a glance that, for example, the wrong paragraph style was used, or that an image is not positioned properly. Please do not underestimate this value.

I would suggest that instead of removing Book View entirely, you simply remove the ability to edit in it.

[KevinH]

Preview handles that visual confirmation quite well.

[DiapDealer]

And with Preview there's no need to switch away from Code View just to see how something "looks".