Odd discovery fixed all my centering issues

[jttraverse]

I'm posting this because I had never found a solution to my problems with centering and other non-working style issues--until today! I set out to find a hack solution to get a line of text to center because, no matter what I'd tried, it would not be centered on my Nook (I thought it was the Nook reader app and how it handled CSS..which in a way it is!) In testing with Sigil, I stumbled, quite by accident, across what had been my whole problem, so I'm hoping this might also solve some problems others may be having. The point is that everything looked perfect in Calibre, Sigil, in a browser, all programs that ran on my pc--but on my color Nook it all went left aligned.

The problem, after a lot of testing, turned out to be one messed up line in the stylesheet. To clarify, I do not build stylesheets by hand, and rarely thought to look at it closely; I use Dreamweaver for editing the xhtml and let DW generate the CSS stylesheet file. I guess it's perfect 99.99% of the time...but..
In one tag in one line of the CSS file there was a glitch where the ending em; (that's the size measurement and closing quote) was on a different line beneath where it should have been. I'll insert images below. I proved this was the problem by testing with just the two entries. When I fixed the error by moving the ending em;...problem solved. Actually, fixing a couple of other similar glitches resolved a whole host of other issues too, which suggests to me that wherever a problem like this occurs, it kills all subsequent tags. After manually going through the template.css file and cleaning up this kind of glitch...my book looks wonderful now. The standard span entry, or just a text:center will line things up fine. So, if you're having weird problems, do scroll through your stylesheet and check for misaligned or disconnected spots. Anyway, see the images below for before and after results, and picture showing the problem CSS tag (at the top of the picture.)







Fwiw, this now displays perfectly on my color Nook using the built-in reader app. I've also tested it using fbReader app, which is a nice app but apparently doesn't use the stylesheet. Nevertheless, since you can now double-tap to zoom in on images with the latest Nook update, things are working well all the way around.
-JT

[theducks]

FWIW
Adobe Digital Editions is also intolerant of any error and will ignore the entire style.

you can validate your stylesheet here: http://jigsaw.w3.org/css-validator/#validate_by_upload

[WS64]

I don't think the problem is that the em is in a new line.
The problem is that the line before (font-size: 1) does not end with a semicolon.

[ghostyjack]

Originally Posted by WS64

I don't think the problem is that the em is in a new line.
The problem is that the line before (font-size: 1) does not end with a semicolon.

And neither is there an ending curly bracket either.

The semi-colon isn't required on the last line of the style, but you do need to close it.

[ghostyjack]

Hmm didn't fully read the first entry here, please ignore my previous comments.

Looking at the css, I'm not really seeing the problem, aprat from it showing it as ".em". Maybe the reader was thinking that the entry was the start of a new style and thought the styles were malformed?

[WS64]

Hmm, I think my comment did not make too much sense...

[ghostyjack]

Originally Posted by WS64

Hmm, I think my comment did not make too much sense...

Nope, but then I ended pretty much at the same point as you, so you not the only one that managed to cock-up the response.

[mmat1]

I guess, it would be a good idea that Sigil (or the built-in epub-validator) would make some simple checks on css, so that missing colons, semicolons, brackets will never cause a problem again. Maybe at 0.7.0 ?

[Serpentine]

Originally Posted by mmat1

I guess, it would be a good idea that Sigil (or the built-in epub-validator) would make some simple checks on css, so that missing colons, semicolons, brackets will never cause a problem again. Maybe at 0.7.0 ?

Feel free to write it

[douglsmith]

CSS does not allow anything between the number and the unit of measurement. So it must be "1em" and not "1 em" or anything else in-between. The extra line break was between them.

[Hitch]

For the love of heaven, people...

The Nook (or ADE, etc.) thought that the ".em" was a new STYLE.

That's all. Just like any other class style decoration that starts with a "."

That's it, no big mystery. It would have ignored everything after that as being malformed because the ending brackets were missing from the previous style (if you try reading this line-by-line, as a device would) and the opening brackets were missing from "style .em"

That's all. The return, occuring before the ".," caused the ruckus.

Hitch

[mtravellerh]

Originally Posted by Hitch

For the love of heaven, people...

The Nook (or ADE, etc.) thought that the ".em" was a new STYLE.

That's all. Just like any other class style decoration that starts with a "."

That's it, no big mystery. It would have ignored everything after that as being malformed because the ending brackets were missing from the previous style (if you try reading this line-by-line, as a device would) and the opening brackets were missing from "style .em"

That's all. The return, occuring before the ".," caused the ruckus.

Hitch

exactly. always a good idea to check css manually, btw