Method to Convert Fancy CSS to Everyday CSS?

[Quoth]

William says, "Don't unnecessarily multiply entities"

Maybe in a reference work or textbook you need more complex css & html. But Fiction has headings that appear in TOC. Every other text even if it looks like a heading or is a character quoting a poem or singing or the narrator quoting (very victorian) is automatically suitable classes of <p> and is created automatically from the docx automatic conversion to epub. I never format tables, so there are really classes only for

Headings
unbulleted, unnumbered, unlettered lists. The i, ii or 1, 2 or a, b, or bullet are explictly typed in the source.
images (usually they need height & width edited because I can't figure how to tell LO Writer image settings that translate to the css desired. Headings & body text level & lists all work.
The text that's not a heading or a list.

All headings automatically are in the TOC. I've never seen <blockquote class="something"> created ever.
I've tried tables and the HTML & CSS is as expected. Not very useful in ebooks.
Putting numbering, Roman numbering, lettering or a bullet in the "style" in the Wordprocessor may not work as expected on Kindle or all epubs. Explicitly typing the list prefix always works, automatic doesn't. Indenting (first and wrap) all works as expected with expected HTML & CSS.

Simple is best. I'll let the purists designing specs worry about the semantics. We test any new WP style in kf7 on DX & KK3, kf8 on KK3 & PW3, epub on Kobo, Mars and Sony PRS-350 (5"), KoReader, Aldiko Basic and Lithium. Android from 4.3" v6 to 10" v10. eInk from 5" to 10".

Probably for completeness we should check Apple's Books on iPhone and iPad, but we distribute to Apple with epub2 via Smashwords. Amazon KDP and Google play books get the same epub2.

If it looks roughly the same as WP screen on 4K monitor (we set page to about 148mm x 197.5mm to edit master for ebook) allowing for KF7 fonts, then we are happy. We check epub and KF8 both in default setting a naive user would have and "publisher" mode.

Then when 100% proofed (a gazzillion cycles and all proofing & annotation on a Kobo) a copy is made with formatting & styles changed for paper. It's styled & formatted in 2 page up 100% actual paper size on the 28" 4K screen. We'd change space between digits and units to smaller space. Obviously headings, footers, page numbers and Contents page with numbers. Might fix any unsuitable page breaks, pointless for ebook.
Then electronic "proof" on Elipsa as PDF (the file to be uploaded) as well as PDF viewer on monitor, because sometimes you might miss a style. PDF export from LO Writer. We aren't doing anything fancy enough to need laTex or InDesign or whatever.
No dropcaps, no small caps, no text flowing round images on ebook or paper.

[Quoth]

Oh, and short "footnotes" go at end of the paragraph, smaller and right justified.
Bigger footnotes get a paragraph each and link both ways. If two places need the same footnote it's repeated so that tapping "back" works.
On paper version the bigger ones go at the bottom of the page. Only a textbook or academic work wants end notes.

[enuddleyarbl]

Based on the discussion in:

https://www.mobileread.com/forums/sh...d.php?t=347606

I've decided to move all footnotes/endnotes in the books I reformat to be just after their referencing paragraphs instead of where I usually find them as endnotes. Since I'm only reading fiction, this works well. Also, I'm converting everything over to epub3 and I can use <aside> instead of the more common <p><a> stuff (though, really, it's six of one, half a dozen of the other). And, again, because it's fiction, <aside> seems more semantically correct. For instance, Pratchett's bajillions of footnotes/endnotes are actually side comments and not really footnotes. So, having them right in the text works well.

Now, if the various readers would hide <aside> stuff as the reference material I find on it says they should, I'd be really happy. But, again, for fiction, that's a pretty minor complaint.

[DNSB]

Oddly, I've been adding header, section, role, type, etc. into epub3 ebooks I edit simply to get ebooks that are close to meeting the DAISY accessibility standards. While I don't miss acessibility features at this time, there are people out there using non-visual devices to consume ebooks and for them, they are rather important.

[JSWolf]

Originally Posted by DaveLessnau

Based on the discussion in:

https://www.mobileread.com/forums/sh...d.php?t=347606

I've decided to move all footnotes/endnotes in the books I reformat to be just after their referencing paragraphs instead of where I usually find them as endnotes. Since I'm only reading fiction, this works well. Also, I'm converting everything over to epub3 and I can use <aside> instead of the more common <p><a> stuff (though, really, it's six of one, half a dozen of the other). And, again, because it's fiction, <aside> seems more semantically correct. For instance, Pratchett's bajillions of footnotes/endnotes are actually side comments and not really footnotes. So, having them right in the text works well.

Now, if the various readers would hide <aside> stuff as the reference material I find on it says they should, I'd be really happy. But, again, for fiction, that's a pretty minor complaint.

If you are reading KePub or with KOReader, then put the footnotes as endnotes as you'll get popups. Also, make the tap points large enough as in [1] (full size text).

[Tex2002ans]

Originally Posted by DaveLessnau

EDIT: Tex2002ans kindly provided a lot of information in another thread:

Originally Posted by JSWolf

KISS is the way to do it.

Agreed. I wouldn't use that complex stuff.

Overly convoluted CSS—like "Blitz" or "CSS Resets"—should also be avoided. (In ebooks, those cause WAY more harm than "good".)

Side Note: I took a look at the linked ebook, and don't see anything SUPER egregious though. These things are squeaky clean compared to the horrors I've seen.

Originally Posted by DaveLessnau

But, I was hoping for a more "nutshell" version for converting between Standard Ebooks' formats to my everyday formats.

No. There isn't.

There's no working around it:

If you're doing an HTML->HTML conversion, you're going to have to:

• rip apart each book.
• figure out what's needed and what's not.

You can throw away most stuff ("Remove Unused CSS"), but beyond that point, you'll have to:

• "surgically" remove/adjust the HTML+CSS.

Why Can't I Just Push a Button And "Fix" All Books?

Like JSWolf said, who knows what the heck publishers might do inside THIS book or how they might handle THIS specific case.

Like a book might have any/all of the following:

• <span class="calibre123">italics</span>
• <span class="italics">italics</span>
• <span class="book-i">italics</span>
• <span class="i">italics</span>
• <em>italics</em>
• <i>italics</i>
• <i class="i">italics</i>
• <i class="italics">italics</i>

or who knows what else!

- - - - -

Side Note: For example, in this 2021 post, I described how I've seen InDesign books with:

<span class="CharOverride-4">italic</span>

where:

span.CharOverride-4 {
	font-family:"Minion Pro Italic";
	font-style:normal;     <----- See here. Should say italic.
	font-weight:normal;
}

This is an "italic" font, but isn't properly marked as italics!!!

(Hitch explained that it's some InDesign cloud font nonsense.)

If you randomly stripped all fonts + did a conversion, all italics in that book would disappear.

Because, according to the computer, all that text is NORMAL.

- - - - -

Basic Cleanup Method That I Do

1. Toss away most of the junk. (Using "Remove Unused CSS" + the other detailed tricks described in that thread.)

2. Judiciously use:

• Reports
  
  • Sigil: Tools > Reports > Style Classes in HTML Files
    
  • Calibre: Tools > Reports > Style classes
    
  • These show all the classes still left in the book.
    
• Diap's Editing Toolbag.
  
  • This helps change:
    
    • <span class="i"> -> <i>
      
    • <p class="heading1"> -> <h1>
      

I scroll through the book, tackling each one, mapping it to:

• Basic, simple, HTML
• + a handful of CSS classes.

Originally Posted by DaveLessnau

Also, JSWolf, how did you get rid of the <section> stuff?

Another trick I like to do is:

Search: <section>
Replace: <--- [COMPLETELY BLANK]

Yes, it "breaks the HTML", but then I "Mend & Prettify" and let Sigil/Calibre do the cleanup for me. :P

They'll disappear the closing </section> + reindent everything for you.

Originally Posted by DaveLessnau

Did you use something like Diap's Editing Toolbag? Or, go through it manually and delete?

Big-picture stuff like <section>? You can do the Mend & Prettify trick.

If you are dealing with heavily nested <span>s, definitely use Diap's Editing Toolbag.

- - - - -

You can also do many rounds of:

Search: <span class="useless">
Replace: <span>

and then use Diap's Toolbag to wipe away all empty <span>s in one shot.

- - - - -

Originally Posted by Karellen

For your <section search...

\n\s\s<section data\-parent=".*?" id=".*?" epub:type=".*?">\n

and then replace with nothing

Or just a simple:

Search: <section [^>]+>
Replace: <--- [COMPLETELY BLANK]

That will wipe away all <section>s (with extra stuff in them).

What does that regex say, in plain English?

• "Look for a <section"
• "Then keep on going until you hit a closing '>'."
• "Replace with NOTHING."

Originally Posted by DaveLessnau

for my purposes, I just need a simply formatted book that I can adjust as needed. I don't need thousands of lines of styling information across scores of classes. In this book, after I was done with it, I ended up with about a dozen:

[...]

And, it was that many only because of the footnotes and a couple of more-specific classes that I added in since they keep recurring in various books.

Fantastic.

And I've done over 650+ ebooks, mostly Non-Fiction, and I have everything boiled down to:

• The same basic CSS file I've been using for YEARS.
• + rarely, if ever, minor book-specific tweaks
  
  • A handful of extra classes.
    
    • Like the last book I worked on was a compilation, and had a special "AuthorBio" in the beginning of each chapter.

I've yet to see a book that completely breaks the mold.

Maybe it exists out there, but I'm having a tough time imagining it.

Originally Posted by DaveLessnau

Based on the discussion in:

https://www.mobileread.com/forums/sh...d.php?t=347606

I've decided to move all footnotes/endnotes in the books I reformat to be just after their referencing paragraphs instead of where I usually find them as endnotes.

I don't understand how you could've reached that conclusion from that thread... but okay.

Originally Posted by DaveLessnau

Now, if the various readers would hide <aside> stuff as the reference material I find on it says they should, I'd be really happy. But, again, for fiction, that's a pretty minor complaint.

Yes, theoretically, EPUB3 readers would hide those <aside>s (some do, like AZARDI).

But reality, almost all don't hide it.

That's why you shift+insert the footnotes at the end-of-file or end-of-book, so they're out of the way.

(Shoving them in the middle of the book is very similar to people shoving page numbers smack dab in the middle of their text! )

Originally Posted by DNSB

Oddly, I've been adding header, section, role, type, etc. into epub3 ebooks I edit simply to get ebooks that are close to meeting the DAISY accessibility standards. While I don't miss acessibility features at this time, there are people out there using non-visual devices to consume ebooks and for them, they are rather important.

If you use the ARIA markup properly, there is no harm in the extra stuff.

The problem is, most people don't apply it properly. :P

See the fantastic article at:

• MDN: Accessibility > "ARIA"

and their warning:

Warning: Many of these widgets were later incorporated into HTML5, and developers should prefer using the correct semantic HTML element over using ARIA, if such an element exists. For instance, native elements have built-in keyboard accessibility, roles and states. However, if you choose to use ARIA, you are responsible for mimicking the equivalent browser behavior in script.

But yes, precise usage of ARIA... like marking columns in your <table>s, good.

[Quoth]

Yes, + vote on Diap's Editing Toolbag.
Also regex search & replace, but I test just with searches first!

I'd only put very short footnotes after paragraphs inline. Regular footnotes would go at the end of a chapter or book (depending) and linked to and back.

[A short in-line note]

Another paragraph

[Turtle91]

Originally Posted by Quoth

Yes, + vote on Diap's Editing Toolbag.
Also regex search & replace, but I test just with searches first![/SIZE][/FONT]
...

Just FYI - the new version of Sigil has a new function to run a test of your search and show you what would be the results...which you can edit before accepting the changes...

[JSWolf]

I do use Diap's Editing Toolbag to blow away a lot of the junk I don't need or want such as <section> with or without stuff in them. Change span italics/bold to <i>/<b>, but the <a> page numbers and a number of other things.

Once you know you don't need any IDs, blow them away too. One thing I find really interesting is how much smaller the ePub becomes once you've blown away all the junk the put it like all those <p class="uselessclass"> when you convert to just <p>.

[enuddleyarbl]

Regarding Diap's <p class="heading1"> -> <h1>, that's a good suggestion. I hadn't thought of using that the change headings. I just went through another book that used standard <p class=...> stuff for all it's headings. Usually, I use regexes to replace them. But, I'll take a look at how Diaps does it.

[Tex2002ans]

Originally Posted by DaveLessnau

Regarding Diap's <p class="heading1"> -> <h1>, that's a good suggestion. I hadn't thought of using that the change headings. [...] But, I'll take a look at how Diaps does it.

For a little tutorial I wrote, see:

• 2020: "Replacing All Tags Of One Kind With Another"