CSS linked but not working on last chapter

[Trane]

So I linked a CSS to my Sigil project several days ago and it works fine, except in the last chapter. I had copy/pasted a section originally in the Appendix into the main body and created a chapter for it. The hi heading formatted fine upon choosing hi, per the CSS. However sub-chapter formatting is not carrying over in this new section.

When I cut/pasted from the Appendix into the body, I did so in code mode. Also, this is still one file so all the content is in single file. (Have not split it into HTML files yet, but split markers are in.) And also FTR the Appendix has the same formatting specs as the body.

Checked the CSS with W3C and no errors. Also tried the tool for fixing any HTML errors.

Suggestions?

[MickiTee]

CSS class names are case sensitive so check that you haven't made any typos.

You could also run Reports from the Tools menu. It will highlight any classes in the HTML files that do not have a corresponding entry in the CSS.

[Trane]

Originally Posted by MickiTee

CSS class names are case sensitive so check that you haven't made any typos.

You could also run Reports from the Tools menu. It will highlight any classes in the HTML files that do not have a corresponding entry in the CSS.

Thanks for that tip. No errors though! Odd. There has to be an error somewhere.

EDIT: Went back into Code mode at the point the first h3 header was that was not formatting per the CSS. For some reason there was a large empty space in the page (30 lines or so). Took out the empty space and selected the heading in code mode vs book mode, hit h3 and it applied the brackets (which it did yesterday too when I tried it this way)... switched to book mode and VIOLA. Finally it was formatted correctly.

I did this same exact thing last night... went through the code and found Sigil had inserted large spaces for no apparent reason... took them out... tried formatting the h3 headings, and it would apply the brackets but the formatting would not be from the CSS. But just now, it worked.

Don't look a gift horse in the mouth! Thanks much... maybe running the report helped somehow.

[Notjohn]

Originally Posted by Trane

EDIT: Went back into Code mode at the point the first h3 header was that was not formatting per the CSS. For some reason there was a large empty space in the page (30 lines or so). Took out the empty space and selected the heading in code mode vs book mode, hit h3 and it applied the brackets (which it did yesterday too when I tried it this way)... switched to book mode and VIOLA. Finally it was formatted correctly.

I did this same exact thing last night... went through the code and found Sigil had inserted large spaces for no apparent reason...

I've been using Sigil for almost five years and maybe twenty books, and I have never seen it do any such thing. I would suspect the underlying code. Did it come from Word? Calibre?

[JustinThought]

Originally Posted by Trane

//snip!//
... went through the code and found Sigil had inserted large spaces for no apparent reason...

That sounds similar to a problem I was having, that I posted in another thread. What was happening was, Sigil was doing some housekeeping each time I saved, and placing a blank line before a certain section. This was code that wasn't inside a <p> tag, but instead in a <div>, but that div was way up on the page. I ended up just placing the errant code inside a dummy <div>, directly before and just after the section that was being spaced out, and it has taken care of the problem.

Any similarity to your code? Find the place where the blank areas are being made, clear them out, then repeatedly hit ctrl-s to save and see if it doesn't move down. If so, you're running up against the same problem. Use a <div> </div> to bracket that section, and it should go away--which may solve your other problem as well.

[KevinH]

Is this after running prettyprint or is this when going back and forth from codeview to bookview? What does your Sigil preferences for Cleaning set to?

KevinH

[Trane]

Originally Posted by Notjohn

I've been using Sigil for almost five years and maybe twenty books, and I have never seen it do any such thing. I would suspect the underlying code. Did it come from Word? Calibre?

The original code pasted into Sigil worked fine for almost 2 weeks. It was only after I copy/pasted the Appendix section into the body, and then only the h3 headings were not formatting. But again, it's fine now. (However it's still inserting blank lines - more on that later.)

FTR wrote in Word, saved as Text, opened the text file and copied the text back into a new Word doc as text, then used the Toxaris EPub add-in to Word to generate clean HTML. Pasted that HTML into Sigil.

Originally Posted by JustinThought

That sounds similar to a problem I was having, that I posted in another thread. What was happening was, Sigil was doing some housekeeping each time I saved, and placing a blank line before a certain section. This was code that wasn't inside a <p> tag, but instead in a <div>, but that div was way up on the page. I ended up just placing the errant code inside a dummy <div>, directly before and just after the section that was being spaced out, and it has taken care of the problem.

Any similarity to your code? Find the place where the blank areas are being made, clear them out, then repeatedly hit ctrl-s to save and see if it doesn't move down. If so, you're running up against the same problem. Use a <div> </div> to bracket that section, and it should go away--which may solve your other problem as well.

You are definitely on to something as to when blank lines appear. I just went into Code view and scanned down, and again it has put in stretches of blank lines in certain places, (not where they were before).

Took out the blank lines in one spot, hit CTRL+S and it inserted a blank line above somewhere, b/c all of the HTML lines showing in the window shifted down (jumped line numbers downward like a line was inserted further up).

And the number of blank lines that crop up correspond to about the number of times I have saved (both yesterday and just now when I noticed I had stretches again, but the stretches weren't as long as before b/c I have saved fewer times between).

Haven't tried the <div></div> tag as a fix, as the blank lines (or the sections of several blank lines) are not relegated to appearing in the same part of the book each time.

EDIT: FTR when I say blank lines I don't mean one, and I don't mean it cleans up the code so it's easier to read. It inserts lines with nothing on them whatsoever, and it keeps inserting a new line next to the other one with each consecutive save. So there are huge sections of blank space, and it does this in various places. If I delete all the blank sections, it starts creating new blank sections in new spots... adding one line per each blank section "it's building" every time I save.

Also FTR [in case it matters] this is a long book, over 75k words/~115 Word pages.

[Trane]

Originally Posted by KevinH

Is this after running prettyprint or is this when going back and forth from codeview to bookview? What does your Sigil preferences for Cleaning set to?

KevinH

Was this directed to me (the OP), or to JustinThought?

If it was directed to me, I'm not sure what you're asking. "Is this after running prettyprint..." The blank lines, you mean? FTR I have never run "prettyprint" (don't even know what that is) but under Preferences the default is checked to Mend XHTML on Open and Save. Though seems like mending the file should remove blank lines, not add them. And I do go back and forth from code view to book view.

EDIT: Having removed all blank sections, then CTRL+S and scrolling through the entire book again, now it's partial to inserting blank lines after the ordered lists. (This is a how-too book.) There are three ordered lists that follow each other with a few words at the start of each list (describing the list). When I SAVE, Sigil injects a few blank lines after each </ol> tag.

[Doitsu]

Originally Posted by Trane

EDIT: Having removed all blank sections, then CTRL+S and scrolling through the entire book again, now it's partial to inserting blank lines after the ordered lists. (This is a how-too book.) There are three ordered lists that follow each other with a few words at the start of each list (describing the list). When I SAVE, Sigil injects a few blank lines after each </ol> tag.

Usually, Sigil will insert at most one blank line. However, the cleanup code might insert additional lines, if your book contains invisible Unicode characters (e.g. &#8203; or &#65279;) that some book distributors insert as part of a social watermarking scheme.
If you're cleaning up a commercial ebook that is protected by a social watermarking scheme, it might contain several of these invisible characters, which you can find with DiapDealer's Shady Characters plugin.

The following customized ShadyCharacters.json file will help you find many commonly used invisible characters:

Spoiler:

{
  "matrix": {
    "zwnj": [
      "0x200C", 
      "‌"
    ], 
    "zwj": [
      "0x200D", 
      "‍"
    ], 
    "shy": [
      "0x00AD", 
      "­"
    ], 
    "zwnbsp": [
      "0xFEFF", 
      ""
    ], 
    "wj": [
      "0x2060", 
      "⁠"
    ], 
    "nbsp": [
      "0x00A0", 
      " "
    ], 
    "thinsp": [
      "0x2009", 
      " "
    ], 
    "zwsp": [
      "0x200B", 
      "​"
    ], 
    "nnbsp": [
      "0x202F", 
      " "
    ]
  }
}

For more information on where to find this file, see the Shady Characters MR topic.

[Toxaris]

Originally Posted by Trane

FTR wrote in Word, saved as Text, opened the text file and copied the text back into a new Word doc as text, then used the Toxaris EPub add-in to Word to generate clean HTML. Pasted that HTML into Sigil.

Why? The HTML can be imported into Sigil of course (don't paste!), but it is much easier to export to ePUB from Word with the add-in. That will split (if you want) as well into multiple sections and will create a valid ePUB.

[DiapDealer]

Originally Posted by JustinThought

That sounds similar to a problem I was having, that I posted in another thread. What was happening was, Sigil was doing some housekeeping each time I saved, and placing a blank line before a certain section. This was code that wasn't inside a <p> tag, but instead in a <div>, but that div was way up on the page. I ended up just placing the errant code inside a dummy <div>, directly before and just after the section that was being spaced out, and it has taken care of the problem.

Any similarity to your code? Find the place where the blank areas are being made, clear them out, then repeatedly hit ctrl-s to save and see if it doesn't move down. If so, you're running up against the same problem. Use a <div> </div> to bracket that section, and it should go away--which may solve your other problem as well.

I was trying to remember this very incident, but couldn't find the thread. I knew it was reproduceable, but couldn't remember what we determined concerning its "fixability." Thanks for the reminder. I vaguely remember something about Prettify adding extra spacing to code that needed to be contained within block-level tags.

@O.P. I agree with Toxaris that pasting content into Sigil should be a last resort. If you have clean html you're happy with, import it.

[DiapDealer]

@KevinH : Regarding the extra spacing @Trane (and previously @JustinThought) is reporting, here is an epub that clearly demonstrates the issue. Open the epub, open Section0001.xhtml in Code View and watch the spacing grow with each and every Save (so long as "Mend XHTML Source Code on Save" is enabled in Preferences). It also adds a line with each subsequent Open when "Mend XHTML Source Code on Open" is enabled.

Somehow, the preceding "p" tag confuses "Mend" into thinking the following text isn't properly contained within a block-level tag (other than "body"). It's not something many people are probably going to encounter, but it probably shouldn't be happening since the xhtml is technically valid.

[KevinH]

Sounds like a bug in the routines that convert the gumbo nodes/dom back to a string.
I will take a peek at it. Thanks for the test case!

KevinH

[KevinH]

Yes, I can recreate this even by just right clicking inside Section0001.xhtml and asking it to Reformat XHTML -> Mend.

It appears to happen when bare text is a child of a div and the preceding child of the div is any type of block level tag including p, h1-h6, another div, blockquote, etc.

So somehow that code that converts the gumbo node tree (dom) back to strings is inserting a return after a block element that is a child of a div (or before bare text).

I will see if I can fix this.

KevinH

[KevinH]

Just pushed a fix for this to master. But since it changes a major heavily used routine (gumbo serialize_contents), we definitely want to really test this change to make sure that the "fix" does not have any unintended side effects before the next release.

Hope this does the trick.

KevnH