CSS mess

[HarryT]

Surely it's not beyond the wit of man for publishing tools to strip out unused CSS? This sounds like a job for a machine, not a person. Much less error-prone that way.

[Sweetpea]

Originally Posted by HarryT

Surely it's not beyond the wit of man for publishing tools to strip out unused CSS? This sounds like a job for a machine, not a person. Much less error-prone that way.

It's an extra step they apparently don't want to take. I'd say it should be a part of the default process: generate book, clean book. If Calibre can do it, it shouldn't be hard to automate it.

[theducks]

Sweetpea remembers when we paid by the minute of connect time or KB of download (and probably, Core memory )

Bloat steals resources from the customer, the network provider and reseller.
Just because the 'pipe' is big and is included in many packages, does not give a license to waste.
Trim those CSS and I might fit another book into limited device storage.
Parce a smaller CSS and my battery might run an extra day.

Using the CSS tools available to Calibre users, it takes just seconds.

It is like the rumored Roll Royce technician, taking time to wipe fingerprints off the Radiator cap. He also checked that it was on firmly.

It is about attention to details

[rkomar]

I would guess they leave the extra CSS because it does no harm (besides slightly increasing the epub size), while removing something that turns out to be useful later just leads to even more work. Better safe than sorry.

It also it makes it easier to create a book without being an expert. You can hire cheaper people to do the job.

[DNSB]

As a recent horrible example, I purchased a bundle of James P. Hogan's books from Arc Manor/Phoenix Pick. Code of the Lifemaker opened slowly and the text displayed was a mess with larger font sizes overlapping on my KA1 so I opened it in Sigil to take a look. No stylesheet at all, a single HTML file with inline styles, file naming conventions that looks as if they simply packaged a MS Word save as html, etc. The Immortality Option and The Multiplex Man were no prettier.

About the only good thing to say is that the files were DRM free so I could edit them.

[DNSB]

Originally Posted by rkomar

I would guess they leave the extra CSS because it does no harm (besides slightly increasing the epub size), while removing something that turns out to be useful later just leads to even more work. Better safe than sorry.

In Sigil, under the Tools menu, Delete unused stylesheet classes. I generally run this after I have finished editing an ebook which involves replacing the existing stylesheet classes with my collection. If I need to re-edit it, I just copy and paste the master stylesheet. The cleanup takes about 3 seconds at the most. So far I haven't run into a used stylesheet class being removed.

I have run into a fair number of epubs where attempting to validate the stylesheet with W3C has failed. Quite a few of those give errors with either FlightCrew or epubcheck as well making me wonder about some publishers quality control.

[rkomar]

Originally Posted by DNSB

In Sigil, under the Tools menu, Delete unused stylesheet classes. I generally run this after I have finished editing an ebook which involves replacing the existing stylesheet classes with my collection. If I need to re-edit it, I just copy and paste the master stylesheet. The cleanup takes about 3 seconds at the most. So far I haven't run into a used stylesheet class being removed.

I have run into a fair number of epubs where attempting to validate the stylesheet with W3C has failed. Quite a few of those give errors with either FlightCrew or epubcheck as well making me wonder about some publishers quality control.

I was thinking about later changes where they might want to fix or add something that would then require one of the removed stylesheet entries.

[theducks]

Originally Posted by rkomar

I was thinking about later changes where they might want to fix or add something that would then require one of the removed stylesheet entries.

Since it was a 'House' Stylesheet, you just replace the cleaned sheet with the original (that they started with).
The whole purpose of a 'House' stylesheet is that you have a 'standard' selectors (and attributes) that every one uses (the parts of), when coding books

[rkomar]

Sure, but that's still more work than just leaving it in there as is in the first place and never worrying about it ever again.

[DNSB]

Originally Posted by rkomar

Sure, but that's still more work than just leaving it in there as is in the first place and never worrying about it ever again.

I do fairly regular updates (additions, deletions and amendations) to my "house stylesheet". If/When I go back and re-edit an epub, I replace the existing stylesheet with the latest update as part of my workflow.

OTOH, I would be very surprised if many publishers go back and edit their older ebooks on a regular basis. I've complained about spelling errors, chunks of paragraphs missing or inserted twice, weird styling -- who starts a chapter with a half line that uses a text size half the size of the rest of the paragraph?, images that use pixel sizing so any screen larger than 600x800 gives mini-images. So far I've found few publishers that actually pay attention and respond.

Hmmmm... interesting the [size=+2] bb code[/size] does not seem to work.

[Sweetpea]

Originally Posted by rkomar

Sure, but that's still more work than just leaving it in there as is in the first place and never worrying about it ever again.

Process: ebook is generated

Add HTML to folder
Add CSS to folder
Start process to clean exces information from HTML
Start process to clean exces information from CSS
Zip book into an epub.

All with one push of a button. You only need to code the cleaning process once. And we all know that it's possible, just look at Calibre, who already has such a process.

I doubt that if they change the HTML, they open an existing epub and change one of the multiple HTML files. I think they'd change the master after which a new epub is generated.

[JustinThought]

Just wanted to jump in here.

I generally use writer2epub to go from text to epub format, and it seems to throw in a style for everything except to make coffee.

Oops. Just found this one.

.make-coffee {
perk-time: 3min,
water-temp: 98deg;
needed-level: desperate;
}

Okay. I'm convinced.

[theducks]

Originally Posted by JustinThought

Just wanted to jump in here.

I generally use writer2epub to go from text to epub format, and it seems to throw in a style for everything except to make coffee.

Oops. Just found this one.

.make-coffee {
perk-time: 3min,
water-temp: 98deg;
needed-level: desperate;
}

Good one. (that temp must be C)

[Cinisajoy]

Originally Posted by JustinThought

Just wanted to jump in here.

I generally use writer2epub to go from text to epub format, and it seems to throw in a style for everything except to make coffee.

Oops. Just found this one.

.make-coffee {
perk-time: 3min,
water-temp: 98deg;
needed-level: desperate;
}

Okay. I'm convinced.

Does it do the dishes?

[latepaul]

Originally Posted by Sweetpea

I call it lazy as well.

I don't call it lazy because you're talking about a company, an organisation that exists to make money. There may be lazy people working for that company but that's not the same thing.

Choosing not to do something because you can't see how it will make more money, is not, for a company, "lazy", it's doing what they do.

It's the same reason I'm always surprised when people call companies "greedy" as if there's an acceptable level of profit at which they should stop trying.

I remember, when I first started working (software development for internet) we had to make pages as small as possible. Bytes were money! Even so that in the HTML, CSS and javascript you removed any non-mandatory space, just to make the file as small as possible.

Later, with the advent of ISDN (paired) and DSL, this became less and less necessary and we became lazy in removing extra lines or cleaning up code (beside what you have to do to keep it managable, naturally).

Later still, even though broadband was the standard, we had to return to the pre-DSL time and make pages as small as possible again: mobile phones. Time was again put in to clean any non-required spaces.

Now, with almost unlimited mobile bundles (at least, on this side of the big pond), developers are getting lazy again, and don't clean their code as they should.

Why "should" though? Are they being paid to write the smallest code possible? If so then "should" applies, if their employers have other priorities then perhaps not.

And yes things change. We do things now we would never have dreamt of in the days of slower CPUs, smaller memory, less storage and restricted bandwidth. And that is entirely appropriate.

Lest we forget the Y2K "bug" was really a space saving optimisation that lasted longer than it should have.

It might be "efficient" on the creator's side: no excess time spent, but most certainly not efficient on the reader's side: larger than required files, which might take longer to process, because of nothing important.

Which was my point. It's more efficient for the creator and the OP was asking why the creator did it. The only reason the creator should care about inefficiency on the reader's side is if it hurts their ability to sell it. Which I doubt it does.