Sigil file failing validation due to ePub3 standard

[eggheadbooks1]

Originally Posted by KevinH

Preview handles that visual confirmation quite well.

OMG, I've been using Sigil for years and I never noticed the F10 preview before (similar to Dreamweaver's Split View). Ha, ha -- I'm such a dork! I've been so used to switching back and forth between Book View and Code View that I never looked for anything else. Ya learn something new every day.

BTW, I tried it out. But now I have a new question:
In the lower right-hand corner an error displays. (See SS.) It appears to be somehow related to my browser? The file is otherwise fine (ie., passes validation). What might it be? I haven't figured out how to get Sigil to tell me where the error is. And the error disappears when I hide/unhide the console. It then reappears if I close down Preview and reopen it. Another mystery.

[DiapDealer]

That's just the html Inspector widget. Some people have a use for it, but I don't. If you don't need to inspect the various html element in that way, just grab the divide between the Preview Window and the Inspector widget and squeeze the Inspector down to nothing.

I have no idea what that particular error is, but it has nothing to do with epub, IMO.

[KevinH]

That indicates that some javascript is trying to access $.browser.msie but that has been removed from jQuery. I will try to track down if that is something in the Sigil code or something in QtWebkit.

It can be safely ignored unless you are using your own javascript in a epub3 ebook.

[eggheadbooks1]

Thanks. That's a relief.

BTW, with regard to my initial post, is there a way to specify the bullet type in CSS? I got

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

to work but I cannot find a way to get lowercase or uppercase letters. In older (X)HTML it would have been type="A" or type="a" but list-style-type:A (or a) is not working.

I found another HTML site that recommends list-style-type:upper-latin and list-style-type:lower-latin, but those don't work either. When I google "XHTML list types", I don't get anything beyond the basics.

[Turtle91]

list-style-type:upper-latin or list-style-type:upper-alpha

found at W3schools: https://www.w3schools.com/csSref/pr_list-style-type.asp

edit:
Works great...make sure it's all lower case. Of course, you can put this in a class instead of an in-line style.

As in:

<ol style="list-style-type:upper-latin">
<li>asdsad</li>
<li>asdsad</li>
<li>asdsad</li>
<li>asdsad</li>
<li>asdsad</li>
</ol>

or

.upperlatin {list-style-type:upper-latin}

<ol class="upperlatin">
<li>asdsad</li>
<li>asdsad</li>
<li>asdsad</li>
<li>asdsad</li>
<li>asdsad</li>
</ol>

[KevinH]

Our copy of the jquery plugin wrapSelection.js uses the now deprecated $.browser.msie interface which in our case (webkit) is always false anyway.

I will edit that javascript to remove the unneeded code for old ie explorer. That should make your error go away.

KevinH

Originally Posted by KevinH

That indicates that some javascript is trying to access $.browser.msie but that has been removed from jQuery. I will try to track down if that is something in the Sigil code or something in QtWebkit.

It can be safely ignored unless you are using your own javascript in a epub3 ebook.

[eggheadbooks1]

Hi Turtle--

I tried the second one, but Sigil, ADE, Kindle -- none of them recognize

{list-style-type:lower-latin}

Also does not recognize upper-latin. I'm stymied. Maybe they all think upper-latin is like Old English.

[Doitsu]

Originally Posted by eggheadbooks1

I tried the second one, but Sigil, ADE, Kindle -- none of them recognize

The following code works at least in ADE 1.7-4.5 and Sigil. Maybe there's a typo in your code.

<ol style="list-style-type: lower-alpha;">
  <li>Veni</li>
  <li>Vidi</li>
  <li>Vici</li>
</ol>

<ol style="list-style-type: lower-latin;">
  <li>Cogito</li>
  <li>Ergo</li>
  <li>Sum</li>
</ol>

(The inline styles are only for testing purposes.)

[eggheadbooks1]

Originally Posted by Doitsu

The following code works at least in ADE 1.7-4.5 and Sigil. Maybe there's a typo in your code.

The code was fine. Turns out it was due to synaptic malfunction: when the inline type was rejected I converted to using CSS but forgot to link that particular XHTML file to the stylesheet.

I have my days...

[DiapDealer]

Originally Posted by eggheadbooks1

I converted to using CSS but forgot to link that particular XHTML file to the stylesheet.

I have my days...

Trust me; we've all fought that particular bug from time to time.

[KevinH]

Okay, removed the now obsolete use of $.browser.msie in Sigil's version of jquery.wrapSelection.js so it should remove any javascript errors from the Inspector Console window. It does under my tests.

That just leaves how to handle underline and strike. I can easily now force BookView to add spans with in-line styles to prevent Sigil from introducing "strike" when in BookView and using "u".

If we go ahead with those changes, Sigil, even in BookView will at least generate 100% correct code although ugly and ungainly. BookView will then handle thigns differently than CodeView but I am okay with that given that the code BookView generates at times is truly awful.

I would like to get a fix in the tree for use of strike at least (deprecating u and then undeprecating it is just stupid, so I don't really care about use of "u" or not).

DiapDealer, what do you think?

[DiapDealer]

Originally Posted by KevinH

I would like to get a fix in the tree for use of strike at least (deprecating u and then undeprecating it is just stupid, so I don't really care about use of "u" or not).

DiapDealer, what do you think?

Let me take a peek at how difficult it would be to leave it up to a user preference (enabling document.execCommand("styleWithCSS", "true")). What area of the source am I looking at? BookViewEditor.cpp?

It would seem to be the best of both worlds if a user could ultimately decide for themselves between ugly-but-compliant and clean-(and functional)-but-technically-in-violation-of-specs, no?

[KevinH]

Yes just before emiting the page open signal in the following method:

BookViewEditor::CustomSetDocument(const QString &path, const QString &html)

You can add a line:

ExecCommand("styleWithCSS", "true");

[DiapDealer]

Sounds pretty simple (and I see the effect when compiled). Do you think it makes good sense? If so, we just need to decide where to add the setting in the prefs (unless an environment variable makes more sense?).

EDIT: looks like that would affect all the GUI formatting buttons ... making them all styled spans (including italics and bold). I don't use the buttons myself (in Code View or Book View), so it doesn't matter to me.

[KevinH]

If we add a setting, should we then also try and honour it in CodeView as well?

Most of CV formatting code is done manually, so we should be able to make it use the span and inline style approach as well for underline, strike, subscript, superscript, etc, etc after checking the setting. A bit more work but it would at least allow the user to control things in both BookView and CodeView.

What do you think, worth the trouble or just hard code the horrible spans for BookView only?