Are there CSS-Statements that slow everything down?

Cyberman tM · 05-19-2011, 02:50 PM

I know that question doesn't make much sense without context, but bear with me.

I know that in HTML, some CSS statements/functions can cause a serious slow-down of the system. Usually anything that forces a re-render of the page flow.
These shouldn't happen in ePub, I suppose?

Are there other statements that can cause a slow-down? Or that should be avoided?

I realize this will depend highly on what system is rendering the ePub - but perhaps there are CSS commands that all systems have problems with?

Point in case, I'm having trouble reading ePubs from O'Reilly on my Kobo. They're beautifully designed and rendered, but chapter-turns take ages, while font resizes cause a system freeze.
It has been suggested in this thread that I replace the CSS with a default file from Calibre.
I tried it and indeed it was MUCH faster. But of course I lose the special formatting.

So now I'm thinking perhaps the CSS can be - "slimmed down" to a more palatable size. Or at least be freed from a few indigestable lumps.

Suggestions, ideas?

DaleDe · 05-19-2011, 07:22 PM

One possibility is cascading. It may be that the system is having to resolve a bunch of cascades of the same paragraph types. It there a bunch of CSS in the xhtml file? Perhaps you could resolve some of the things manually or group completely separate CSS files for each chapter that would resolve quicker. The long chapter loads are clearly related to resolving CSS I believe.

Dale

Cyberman tM · 05-20-2011, 02:32 AM

Quote:

Originally Posted by DaleDe

One possibility is cascading. It may be that the system is having to resolve a bunch of cascades of the same paragraph types. It there a bunch of CSS in the xhtml file?

Good call.
I'm looking through one of the files now and I'm screaming inside.

Stuff like

Code:

<h3 class="title">Title</h3>
<span class="emphasis"><em>Text</em></span>

should be outlawed.
(I am right in assuming that weird things like that aren't suggested by the ePub standard, am I? Don't want to blame someone because of my ignorance.)

And of course the H3 has (several) statements in the CSS file as well.
There is no class "emphasis", though. Does the non-existing class slow it down too? It should, right?

Also "nice", each TD tag has it's own style="text-align: left" attribute, instead of it being in the CSS file.

So the problem isn't just the load of CSS but also that it's spread to the xhtml and the coding itself contains superflous additions that all have to be resolved.
Great.

So now I'm looking for a tool that can "clean" that file. Fortunately I'm at the right place for that. :-)

Cyberman tM · 05-23-2011, 04:35 AM

Well, good news, myself! Calibre was the answer. (As to be expected.)

I ran the offending book through Calibre, changing nothing and saving as ePub again -> the font changed (no big loss) and everything was fast suddenly. Chapter turns, loading the book, resizing, the works.

Apparently Calibre inserted a lot of the CSS into the files themselves and rearranged the statements. I didn't really check to be honest, just a quick glance.
I'm just glad it works now.

soapygina · 10-29-2011, 02:27 PM

Quote:

Originally Posted by Cyberman tM

I ran the offending book through Calibre, changing nothing and saving as ePub again ->

What does this mean exactly - what operation did you have Calibre perform to clean up the book?

I have a problem where ADE and Kobo are not recognizing the styles in my epub at all but it displays fine in Sigil and on iBooks.

Any ideas?

theducks · 10-29-2011, 04:19 PM

Quote:

Originally Posted by soapygina

What does this mean exactly - what operation did you have Calibre perform to clean up the book?

I have a problem where ADE and Kobo are not recognizing the styles in my epub at all but it displays fine in Sigil and on iBooks.

Any ideas?

ADE is ultra-fussy, where Sigil will forgive a tiny typo.

My big offenders: colon missing or a semi-colon.
Semi-colon missing between statements
bogus data in a statement: 12empt; (2em was wanted,was 12pt)
Close paren instead of closeing curly brace

soapygina · 11-04-2011, 10:51 AM

Quote:

Originally Posted by theducks

ADE is ultra-fussy, where Sigil will forgive a tiny typo.

My big offenders: colon missing or a semi-colon.
Semi-colon missing between statements
bogus data in a statement: 12empt; (2em was wanted,was 12pt)
Close paren instead of closeing curly brace

Thanks - I forgot to post that I had found it - indeed it was a missing semi-colon - found it using the CSS validator at W3c http://jigsaw.w3.org/css-validator/

05-19-2011, 02:50 PM	#1
Cyberman tM Evangelist Posts: 439 Karma: 2248782 Join Date: Aug 2009 Location: Austria Device: Inkbook Prime; Icarus Illumina;ImcoV6l;EB600;Kobo	Are there CSS-Statements that slow everything down? I know that question doesn't make much sense without context, but bear with me. I know that in HTML, some CSS statements/functions can cause a serious slow-down of the system. Usually anything that forces a re-render of the page flow. These shouldn't happen in ePub, I suppose? Are there other statements that can cause a slow-down? Or that should be avoided? I realize this will depend highly on what system is rendering the ePub - but perhaps there are CSS commands that all systems have problems with? Point in case, I'm having trouble reading ePubs from O'Reilly on my Kobo. They're beautifully designed and rendered, but chapter-turns take ages, while font resizes cause a system freeze. It has been suggested in this thread that I replace the CSS with a default file from Calibre. I tried it and indeed it was MUCH faster. But of course I lose the special formatting. So now I'm thinking perhaps the CSS can be - "slimmed down" to a more palatable size. Or at least be freed from a few indigestable lumps. Suggestions, ideas?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
OI 2.2 - Slow	BobC	OpenInkpot	2	03-27-2011 09:51 AM
epub CSS versus "Regular" CSS	konrad	ePub	4	02-18-2011 09:29 AM
css pseudo elements and adjacent combinators in extra css?	ldolse	Calibre	2	12-21-2010 05:09 PM
PRS-600 Slow to Shut Down, Slow to Start	UniquelyMoi	Sony Reader	10	11-29-2010 04:57 PM
calibre - very slow conversion, very slow on PRS	cremofix	Calibre	3	06-10-2009 04:21 PM

05-19-2011, 07:22 PM	#2
DaleDe Grand Sorcerer Posts: 11,470 Karma: 13095790 Join Date: Aug 2007 Location: Grass Valley, CA Device: EB 1150, EZ Reader, Literati, iPad 2 & Air 2, iPhone 7	One possibility is cascading. It may be that the system is having to resolve a bunch of cascades of the same paragraph types. It there a bunch of CSS in the xhtml file? Perhaps you could resolve some of the things manually or group completely separate CSS files for each chapter that would resolve quicker. The long chapter loads are clearly related to resolving CSS I believe. Dale

05-23-2011, 04:35 AM	#4
Cyberman tM Evangelist Posts: 439 Karma: 2248782 Join Date: Aug 2009 Location: Austria Device: Inkbook Prime; Icarus Illumina;ImcoV6l;EB600;Kobo	Well, good news, myself! Calibre was the answer. (As to be expected.) I ran the offending book through Calibre, changing nothing and saving as ePub again -> the font changed (no big loss) and everything was fast suddenly. Chapter turns, loading the book, resizing, the works. Apparently Calibre inserted a lot of the CSS into the files themselves and rearranged the statements. I didn't really check to be honest, just a quick glance. I'm just glad it works now.

Advert

Advert