Basic rules of ePubs

[JSWolf]

Originally Posted by odamizu

Oh wow, I love this! Didn't realize Calibre could strip unused CSS.

Is there a difference doing it via "Edit Book" rather than "Polish books" as far as results go? Or is it the same function/module?

It is the same function. But doing it in the editor lets you see what's been removed. You can also do other editing you might want to do.

[jackie_w]

Originally Posted by odamizu

Oh wow, I love this! Didn't realize Calibre could strip unused CSS.

Is there a difference doing it via "Edit Book" rather than "Polish books" as far as results go? Or is it the same function/module?

As far as I know, it's the same.

[theducks]

In addition, there is a editor plugin that can be used to cleanup pesky spans or divs by class=name

[odamizu]

Calibre is truly powerful. I know I've just scratched the surface. It's like an onion!

I've been experimenting with removing unused CSS via the command line (ebook-polish -u). I didn't see any options in the Calibre manual that will trigger a listing of what was removed. Did I miss it somewhere?

I will explore that plug-in for removing those irritating empty <spans> (where do they come from and why? why? why?)

[Turtle91]

Sometimes I use empty spans to designate a special span inside of another element. There is no reason to give it a special class as long as you define it properly in your css file.

h2      {font-size:1.2em; text-transform:uppercase}
h2 span {display:block; font-size:.8em; text-transform:none; 
         font-variant:small-caps}

<h2>Chapter One <span>The Woes of CSS</span></h2>

Always applies the proper formatting to the spanned portion - making a title for the chapter in this case. But it ONLY applies to spans within an h2 tag. It also provides the complete chapter title for Sigil's auto TOC algorithm without having to define title="", and it saves on unnecessary bits & bytes for the file size.

I do agree with you that there are really annoying publishers that go empty span crazy for no reason at all...

<p class="first-letter-in-a-new-section-of-text text-overide-party-on-dude">
<span><span><span>I</span></span>'d</span> like to say...</p>

CSS:
first-letter-in-a-new-section-of-text {font-size:1em}
text-overide-party-on-dude {}

and then they don't even code for an empty span....

[eschwartz]

Originally Posted by odamizu

Calibre is truly powerful. I know I've just scratched the surface. It's like an onion!

I've been experimenting with removing unused CSS via the command line (ebook-polish -u). I didn't see any options in the Calibre manual that will trigger a listing of what was removed. Did I miss it somewhere?

You haven't missed anything.
That kind of in-depth analysis is only available via the special Editor feature for showing the difference between two checkpoints.
(Remove Unused CSS like most global tools creates a checkpoint. Then it offers to show you What Changed.)

I will explore that plug-in for removing those irritating empty <spans> (where do they come from and why? why? why?)

They can come from a few places, but almost always because someone did something wrong.

Or because you just cleaned up unused CSS -- there is an option to cleanup unused classes as well.
Very handy for Kobo or Google Play books which include squillions of junk spans for bookmarking purposes.

[eschwartz]

Originally Posted by Turtle91

Sometimes I use empty spans to designate a special span inside of another element. There is no reason to give it a special class as long as you define it properly in your css file.

h2      {font-size:1.2em; text-transform:uppercase}
h2 span {display:block; font-size:.8em; text-transform:none; 
         font-variant:small-caps}

<h2>Chapter One <span>The Woes of CSS</span></h2>

Always applies the proper formatting to the spanned portion - making a title for the chapter in this case. But it ONLY applies to spans within an h2 tag. It also provides the complete chapter title for Sigil's auto TOC algorithm without having to define title="", and it saves on unnecessary bits & bytes for the file size.

I do agree with you that there are really annoying publishers that go empty span crazy for no reason at all...

<p class="first-letter-in-a-new-section-of-text text-overide-party-on-dude">
<span><span><span>I</span></span>'d</span> like to say...</p>

CSS:
first-letter-in-a-new-section-of-text {font-size:1em}
text-overide-party-on-dude {}

and then they don't even code for an empty span....

Well, you can achieve the same effect in a more specific manner by matching on a class "small" inside of an h2 -- which also tells you or others coming back to the code, what it is supposed to do.
spans weren't made to provide an extra tag selector for matching CSS. They were made to provide an arbitrary class selector, and you should use them for what they are meant for.
(Otherwise your code is ugly. )


And it saves you from falling prey to heuristics.

But no one said you have to use the plugin either.

[Difflugia]

Originally Posted by odamizu

I will explore that plug-in for removing those irritating empty <spans> (where do they come from and why? why? why?)

Probably something automated. Though eschwartz is almost certainly correct to say that "someone did something wrong", I bet it's more accurate to say that someone did something lazy.

I've done some automated generation of epubs from databases and going from the sloppy-but-valid stage to something more refined is often a non-trivial amount of work.

[Turtle91]

Originally Posted by eschwartz

Well, you can achieve the same effect in a more specific manner by matching on a class "small" inside of an h2 -- which also tells you or others coming back to the code, what it is supposed to do.
spans weren't made to provide an extra tag selector for matching CSS. They were made to provide an arbitrary class selector, and you should use them for what they are meant for.
(Otherwise your code is ugly. )

wow...I have ugly code too...

I've seen <small> used like that but <span> is 20% shorter and <big> isn't supported in HTML5 . I use it for all kinds of specific formatting inside another tag. It was just coincidence that my example had a smaller font size.

I didn't realize <span>s were designed specifically/solely as a class selector. I thought classes could be applied to any element and that spans were simply to structurally differentiate a... well... span of characters. Not unlike the <em> tag which allows you to identify some text as emphasized. Then 'emphasize' it however you want using css and/or define them using different classes. Some people are even happy with no classes and relying on the default for most readers (simple italics).

I completely understand the uselessness of nested empty spans and/or those with no corresponding css.

Originally Posted by eschwartz

And it saves you from falling prey to heuristics.

But no one said you have to use the plugin either.

Perhaps adjusting the heuristics of the plugin to check <span>s for corresponding css...if found=don't delete... would be better?? Otherwise, for consistency, you could also delete all empty <em> tags...

[eschwartz]

Originally Posted by Turtle91

Perhaps adjusting the heuristics of the plugin to check <span>s for corresponding css...if found=don't delete... would be better?? Otherwise, for consistency, you could also delete all empty <em> tags...

strong and em tags have intrinsic formatting, which is what they are usually used for. They always do something.

And I've never seen the point of them anyway -- you should be using b and i, they're shorter.

If you want to style them so they work differently, well, you can do some pretty crazy stuff with CSS, and mostly ignore what tags are "supposed to" do.

But span is a no-op. It has no structural meaning, and no fundamental styling quirks.
All it does is redefines an arbitrary chunk of characters (allowing you to slap a label on it), unlike every other tag.
Redefining the default nature of a tag is something to be done with deliberation.


So why ask for trouble?


...


The reason I suggested matching on "small" wasn't because there is a tag like that. It's because if you are going to use a span, use a span class="small"
Classes rule. "but <span> is 20% shorter" is an excuse.

You can probably get away with it, though. Just pointing out that when you say "but it's shorter" you are quite obviously valuing short and quick over meticulous devotion to correctness.

One place where you won't get away with it, is when anyone tries applying heuristics to your work.
And the appropriate response is not "breathe down the neck of anyone who ever writes a heuristic to make sure it knows about all the crazy things @Turtle91 (or ____) might do".


Down that road lies madness.


Of course, additional checks might be a useful feature, but depending on them?

[theducks]

Re: is shorter excuse

<span class="small" usage should be an EXCEPTION to the base <Body>, <P>, <Div> style, not frequently appear.

Since it is a limited (in frequency) use, the few characters saved is a big waste of effort on all but the (ridiculously) HUGEST book

IIRC there are a few special cases where a nested <span> worked around a device flaw. Again, those are exceptions

[Turtle91]

Originally Posted by eschwartz

strong and em tags have intrinsic formatting, which is what they are usually used for. They always do something.

And I've never seen the point of them anyway -- you should be using b and i, they're shorter.

If you want to style them so they work differently, well, you can do some pretty crazy stuff with CSS, and mostly ignore what tags are "supposed to" do.

But span is a no-op. It has no structural meaning, and no fundamental styling quirks.
All it does is redefines an arbitrary chunk of characters (allowing you to slap a label on it), unlike every other tag.
Redefining the default nature of a tag is something to be done with deliberation.

Not to belabor the point...but I'm bored...


According to W3Schools - The Span element:

The <span> tag is used to group inline-elements in a document.
The <span> tag provides no visual change by itself.
The <span> tag provides a way to add a hook to a part of a text or a part of a document.

"Grouping inline-elements" certainly seems to mean "structural". As you pointed out - and I agree with - without css the tag provides no formatting by itself but provides a way to hook to that part of the text...it's not required to use a "class", "id", or "name" to provide the "hook".



The EM tag:

The <em> tag is a phrase tag. It renders as emphasized text.
Tip: This tag is not deprecated, but it is possible to achieve richer effect with CSS.
...
Most browsers [not all] will display the <em> element with the following default values: em {font-style: italic;} [notice no class required]

(emphasis mine)

While most browsers and readers will display using the default value - italic - it is not 100% guaranteed and one SHOULD define what they want via css.
Other "phrase tags" are: strong, code, samp, kbd, and var, which may have different levels of default styling/support.


As for the <b> and <i> tags...

Note: According to the HTML 5 specification, the <b> tag should be used as a LAST resort when no other tag is more appropriate. The HTML 5 specification states that headings should be denoted with the <h1> to <h6> tags, emphasized text should be denoted with the <em> tag, important text should be denoted with the <strong> tag, and marked/highlighted text should use the <mark> tag.

(emphasis mine)

This makes clear the intent to differentiate between <em> structurally emphasized text and styled <i> italic text. Tell me how a device that is reading aloud your book will present text with an <i> tag...which is a visual styling?? If you define it as <em> emphasized then the device could give more stress to the word with more volume, or whatever you decide in the css.

Originally Posted by eschwartz

The reason I suggested matching on "small" wasn't because there is a tag like that. It's because if you are going to use a span, use a span class="small"
Classes rule. "but <span> is 20% shorter" is an excuse.

You can probably get away with it, though. Just pointing out that when you say "but it's shorter" you are quite obviously valuing short and quick over meticulous devotion to correctness.

Well, I was trying to be a little amusing with the 20% shorter...thus the winky Not making an excuse but yes, I am probably a little OCD-ish with trying to make my code as concise and compact as possible... Why have class designators when they are unneeded and/or unnecessary? I could easily put
<h2>Chapter One <span class="Rumpelstiltskin-has-a-wart-on-his-nose class-overide-chapter-title-name">Wut?</span></h2>

But this is so much more elegant, does the exact same thing, validates, follows the rules, etc.
<h2>Chapter One <span>Wut?</span></h2>

When I clean up a book, I am able to get it to look just like the original, but at usually half (or less) the original file size. A big chunk of that savings is cutting out unnecessary spans, divs, styles, and classes that are repeated multiple times in a book. I had one 5MB book that I got down to about 600KB!! Don't authors get charged more if their file size is too large?? It seems authors would naturally wish to keep file size down.

OK...time for me to actually get something done around here...
Cheers!

[odamizu]

Originally Posted by Turtle91

... there are really annoying publishers that go empty span crazy for no reason at all...

<p class="first-letter-in-a-new-section-of-text text-overide-party-on-dude">
<span><span><span>I</span></span>'d</span> like to say...</p>

Yes!

The other one that really gets me is when every paragraph is placed in a span:

<p class="indent"><span>This is paragraph one. Does it really need to be in a span?</span></p>
<p class="indent"><span>The answer to that would be a big fat NO.</span></p>
<p class="indent"><span>And yet, every single paragraph in the entire book is in a class-less span.</span></p>

And let's not forget the spans eschwartz points out that Kobo and Google Play adds for bookmarking. This is why I won't buy from Google Play.

Thanks everyone for all the insights on empty <span>! Interesting stuff.