Some Decent stylesheet.css files?

[DNSB]

Originally Posted by JSWolf

This is some rather poor CSS generated by the atrocious program Vellum. Try using that CSS in the first post of this thread and watch it fail. This CSS uses not much you can pre-edit. You need to do the editing by hand. That's why the CSS I add has not all that many classes.

Spoiler:

/*
 * Little Shattered Dreams
 * Stylesheet generated by Vellum
 */
@font-face {
  font-family: Montserrat;
  font-weight: normal;
  font-style: normal;
  src: url(../fonts/Montserrat-Regular.ttf);
}
@font-face {
  font-family: Montserrat;
  font-weight: 500;
  font-style: normal;
  src: url(../fonts/Montserrat-Medium.ttf);
}
@font-face {
  font-family: Montserrat;
  font-weight: bold;
  font-style: normal;
  src: url(../fonts/Montserrat-Bold.ttf);
}
p {
  margin-bottom: 0;
  text-indent: 0;
  line-height: 1.4;
  margin-top: 0;
  text-align: justify;
}
p.subsq {
  text-indent: 1.5em;
}
.implicit-break {
  margin-top: 1.4em;
  margin-bottom: 0;
  height: 0;
}
.element-bodymatter .text > .implicit-break {
  margin-bottom: 1.4em;
  clear: both;
  margin-top: 0;
  height: 1.4em;
}
.toc-item p, .heading h1 {
  line-height: 1.2 !important;
}
.toc-item {
  margin-bottom: 0.1em;
  page-break-inside: avoid;
}
div.alignment-block.inset-block {
  margin-right: 1.5em;
  margin-left: 1.5em;
}
ul {
  padding-left: 3em;
  padding-right: 1.5em;
  margin-top: 1.4em;
  margin-bottom: 1.4em;
  clear: left;
}
p, li {
  hyphens: auto;
  adobe-hyphenate: auto;
  -webkit-hyphens: auto;
  -webkit-hyphenate-limit-lines: 2;
  -webkit-hyphenate-limit-after: 4;
  -webkit-hyphenate-limit-before: 4;
}
body {
  font-family: Palatino, serif;
  font-weight: normal;
  font-style: normal;
}
h1, h2 {
  margin-top: 0;
  margin-right: 0;
  margin-bottom: 0;
  margin-left: 0;
  page-break-inside: avoid;
  font-kerning: auto;
}
@page {
  margin-left: 24px;
  margin-right: 24px;
}
a, a * {
  color: rgb(36, 39, 116);
}
a, span.underline {
  text-decoration: underline;
}
li {
  line-height: 1.4 !important;
  text-align: left;
}
.implicit-break {
  page-break-inside: avoid;
}
.alignment-block {
  clear: both;
}
.element-type-epigraph.element-without-heading {
  margin-top: 10em;
}
.element-type-also-by .heading .title-block, p.copyright-content {
  font-size: 90%;
}
.heading-container-single h1.element-title, .heading-alignment-fixed .element-title, p.alignment-block-content-center {
  text-align: center;
}
p.also-by-content {
  text-indent: 0;
  font-size: 90%;
  text-align: center;
}
p.also-by-content, p.also-by-content.alignment-block-content {
  margin-top: 0.5em;
}
.cover-image {
  max-width: 100%;
  max-height: 100%;
  display: block;
  margin-left: auto;
  margin-right: auto;
}
.toc-contents {
  padding-left: 5%;
  padding-right: 5%;
}
p.toc-content {
  text-align: left;
  font-size: 90%;
}
.toc-item.has-no-children .toc-item-title {
  text-indent: -1.5rem;
  padding-left: 1.5rem;
}
.toc-backmatter-group {
  margin-top: 0.75em;
}
h2.title-page-contributor-without-introduction {
  margin-bottom: 0.5em;
}
.element-type-toc .heading .title-block {
  font-size: 95%;
}
p.copyright-content {
  text-indent: 0;
  text-align: left;
  margin-top: 0.75em;
}
.element-type-copyright.element-without-heading {
  margin-top: 2.5em;
}
div.title-page {
  text-align: center;
  margin-right: 2%;
  margin-left: 2%;
}
div.title-page .title-page-title-subtitle-block {
  margin-left: 6%;
  margin-right: 6%;
}
div.title-page-title-subtitle-block {
  min-height: 140px;
  margin-top: 140px;
  margin-bottom: 2em;
}
h1.title-page-title, h2.title-page-contributor {
  font-weight: normal;
  text-align: center;
  margin-top: 0;
  margin-right: 0;
  margin-bottom: 0;
  margin-left: 0;
  line-height: 1.2 !important;
}
h1.title-page-title {
  font-size: 150%;
  text-transform: uppercase;
}
div.title-page-contributor-block {
  min-height: 80px;
  margin-bottom: 1.5em;
}
h2.title-page-contributor-primary, .heading-format-reduced .element-title {
  font-size: 120%;
}
.heading-container-single {
  text-align: center;
  margin-left: 6%;
  margin-right: 6%;
  letter-spacing: 0.03em;
}
.heading-size-full {
  min-height: 12em;
}
.heading-size-full.heading-without-image .heading-contents {
  padding-top: 4.5em;
}
.heading-size-small .heading-contents {
  padding-top: 2em;
}
.heading {
  margin-bottom: 2em;
}
.heading-alignment-fixed {
  margin-left: 6%;
  margin-right: 6%;
  text-align: center;
}
.heading-size-small .title-subtitle-block, .heading-size-small .title-subtitle-block .title-block, .heading-size-small .title-subtitle-block .element-number-block {
  padding-top: 0;
}
.heading-container-single .element-title {
  font-size: 130%;
}
.heading-format-full .element-number-block {
  min-height: 1.75em;
}
h2.title-page-contributor span.title-page-contributor-name, .element-title {
  text-transform: uppercase;
}
.element-title, h1.title-page-title {
  font-family: Montserrat, sans-serif;
  font-weight: bold;
  font-style: normal;
}
h2.title-page-contributor span.title-page-contributor-name {
  font-family: Montserrat, sans-serif;
  font-weight: 500;
  font-style: normal;
}
div.alignment-block {
  margin-top: 1.4em;
  margin-bottom: 1.4em;
}
p.alignment-block-content {
  text-indent: 0;
  margin-top: 0;
}
p.alignment-block-content-left {
  text-align: left;
}

Whereas I actually find Vellum created ebooks to be relatively easy to clean up since while the CSS may be crap but it's consistent crap.

The work flow is:

• download and add to calibre
• use KindleUnpack if an Amazon format ebook to produce an epub.
• update metadata, update cover, edit as/if needed.
• use ModifyEpub to update metadata/cover in the epub, remove embedded fonts, etc.
• open in Sigil and replace the media.css with my heavily modified one.
• remove the various Amazon media queries in the HTML files. Some authors use the Kindle epub for all vendors.
• run my first pass task list.
• clean up the CSS files removing much redundancy using a saved search.
• replace the p and .subsq with my preferred code in the style.css.
• run the second pass task list.
• clean up empty div and span tags using TagMechanic.
• take a quick look for any oddities that survived.

The total elapsed time is about 10-15 minutes.

I prefer to read left justified (AKA ragged right) so remove any text-align: justified bits. Since Vellum uses a class for indented paragraphs, I live with that though my personal preference is the default paragraph is indented since there are so many more of them in most ebooks.

body {
  display: block;
  font-size: 1em;
  margin: 0 0 0 0;
  padding: 0 0 0 0;
  text-indent: 0;
  widows: 1;
  orphans: 1;
}

p {
  text-indent: 0;
  margin: 0 0 0 0;
  padding: 0.1em 0 0 0;
}

p.subsq {
  text-indent: 4%;
}

[JSWolf]

I dump all <p class="someuselessclass"> and make it <p>. I then go through the HTML looking at the classes and seeing what needs to be fixed. It can be pretty quick at times.

[nabsltd]

Originally Posted by theducks

fmtx1 is Front matter alternate body style 1

I absolutely hate those naming conventions, for so many reasons:

1. The editor/designer just keeps incrementing the number for slight changes, which doesn't tell you why its different or what its really being used for.
2. The names are meaningless because you often see a "front-matter" style used on an epilogue, afterword, etc., just because it happed to match the formatting they wanted. Since the designer isn't shy about creating new styles for even tiny changes (see point #1), this is particularly painful.
3. In one book, "fmtx1" means "paragraph with no indent and 1em margins top and bottom. In another, it means "paragraph with 2em left margin and -1.5em text indent (hanging indent)". Because of this, the name is useless, because it conveys no information other than "front matter paragraph of some sort"...except when it doesn't (see #2)
4. Longish (we don't need full sentences), meaningful names are far easier for everybody to use. Instead of "fmtx1", how about "FrontMatter-p-noindent". Much better for both veterans and newbies. Note that because all eBooks are inside a ZIP format, the length of the class name adds negligible size to the file. And, it adds negligible memory use because the classes are all turned into lookups by the parser. So, class="xy" uses the same amount of memory as class="SuperDuperLongClassNameThatIsTooLong".
5. All those "special" classes are often just dupes of other classes, and the fact that they are in the "front matter" make no real difference...it's still just a plain old indented paragraph.
6. 99% of "special" classes can be tossed out the window if the designers were taught the CSS box model. There is no reason to create classes to style paragraphs so they can be used for block quotes (all have left and right margins, first has top margin, last has bottom margin). Just slap the plain old body paragraph inside a DIV that creates the block.

[Quoth]

See, there are things we completely agree on, like meaningful names for stuff. And these folk probably never had to suffer CP/M, ISIS and DOS short filenames.

OTOH if the epub is entirely automated creation using Calibre from a properly styled docx, then the only time the "creator" sees the CSS is to edit the properties of a few image classes. With meaningful names!

[JSWolf]

Originally Posted by Quoth

See, there are things we completely agree on, like meaningful names for stuff. And these folk probably never had to suffer CP/M, ISIS and DOS short filenames.

OTOH if the epub is entirely automated creation using Calibre from a properly styled docx, then the only time the "creator" sees the CSS is to edit the properties of a few image classes. With meaningful names!

I do try to give meaningful names when possible. But sometimes I don't because I'm reusing an existing class such as .cover to do a full screen graphic image.

But yes, a lot of CSS have really meaningless class names and Vellum gives really long names that are less then meaningless.

[DNSB]

Originally Posted by JSWolf

But yes, a lot of CSS have really meaningless class names and Vellum gives really long names that are less then meaningless.

Oddly, I find most of Vellum's long names are actually meaningful. Horribly wordy but then any hierarchial structure tends to get that way. Now if you wanted to criticize the love for single entries so a class name is used multiple times instead of a single class name with multiple entries for margins, width, etc., that is a PITA.

inline-image
inline-image-after-section-begin
inline-image-flow-within-text
inline-image-flow-left
inline-image-flow-within-text
inline-image-flow-right

[JSWolf]

Originally Posted by DNSB

Oddly, I find most of Vellum's long names are actually meaningful. Horribly wordy but then any hierarchial structure tends to get that way. Now if you wanted to criticize the love for single entries so a class name is used multiple times instead of a single class name with multiple entries for margins, width, etc., that is a PITA.

inline-image
inline-image-after-section-begin
inline-image-flow-within-text
inline-image-flow-left
inline-image-flow-within-text
inline-image-flow-right

I just had a look at an eBook made with Vellum and your correct that the names are somewhat meaningful.

[nabsltd]

Originally Posted by Quoth

OTOH if the epub is entirely automated creation using Calibre from a properly styled docx

But, because the DOCX format doesn't understand the CSS box model, you end up with the direct styling of paragraphs instead of using an enclosing box.

As far as I know, there aren't any WYSIWYG editors that allow you to create a "box" and use relative margins on a group of paragraphs. Even ones that are designed for eBook editing don't have this feature.

And, you can only apply one style to a paragraph in the DOCX format, so you can't take advantage of class="indent spacebefore", so you end up with way too many individual paragraph styles. Even I'm guilty of this a bit, because most of my EPUBs were targeted at my first reader (Onyx Boox), and it couldn't handle multiple classes in the attribute. So, I have both "indent" and "indentspacebefore" classes.

[nabsltd]

Originally Posted by JSWolf

I do try to give meaningful names when possible. But sometimes I don't because I'm reusing an existing class such as .cover to do a full screen graphic image.

If I need a full page image, I copy the SVG-based Calibre/Sigil cover page and replace the filename and pixel sizes.

The img tag gets special treatment by too many readers to be sure it will do what you want.

[JSWolf]

Originally Posted by nabsltd

If I need a full page image, I copy the SVG-based Calibre/Sigil cover page and replace the filename and pixel sizes.

The img tag gets special treatment by too many readers to be sure it will do what you want.

SVG doesn't always work. In fact, it works less then the way I do it with CSS, div, and img.

[Quoth]

Originally Posted by nabsltd

But, because the DOCX format doesn't understand the CSS box model, you end up with the direct styling of paragraphs instead of using an enclosing box.

It's a huge lot better than direct styling and what you get works on every ereader (gracefully degrades on mobi) and looks like the original. Then a copy can be edited adding page styles, headers, footers, page numbers, registration, line spacing and other things good for paper publish best avoided in ebooks for a good experience for the user.

You are giving yourself extra work by obsessing over what is possible than simply using what works very very well. Excessively complex use of CSS box model leads to errors and maintainability issues. It's not even needed for ebooks and has to be flattened to process to make a version to edit for paper. It's purely a shorthand.

Ebooks are not web pages/sites. They just happen to use some of the same technology. Also even a lot of web sites are now a bit broken because of people wanting latest browser feature and rating appearance higher than usability (such as grey text, unfolding or zooming as you "move" down the page etc).