why does every tag have a class?

[hobnail]

Books I get from amazon, and probably elsewhere, always have a class on every p tag and even on the i tag. For the books I've uploaded here I go the opposite way and have some css for the unclassed/base tags and then have classes when I want to modify the base tag. I thought that's what the cascade in CSS was all about.

Am I missing something? Is there some good reason to put a class on every tag?

[Karellen]

Yes, I also wondered why <i> and <em> tags have a class, and when checking the css, that class uses font-style: italic;. Are they aiming for double italic, with the letters almost lying down flat?

[phillipgessert]

I'd assume something autogenerated, especially if not human-readable. Or if they are human-readable, perhaps an attempt at higher CSS precedence to prevent device/user/etc overrides.

[JSWolf]

It's because whoever is making these eBooks is using some program to help make the eBooks. I can take these poorly made eBooks and when I'm done, the code is much cleaner and the formatting much nicer.

[slm]

John
<i> displays as font-style:italic on most browsers, but it not required to do so--see https://developer.mozilla.org/en-US/...TML/Element/i:

In earlier versions of the HTML specification, the <i> element was merely a presentational element used to display text in italics, much like the <b> element was used to display text in bold letters. This is no longer true, as these tags now define semantics rather than typographic appearance. A browser will typically still display the contents of the <i> element in italic type, but is, by definition, no longer required to do so. To display text in italic type, authors should use the CSS font-style property.

[Jellby]

Originally Posted by slm

To display text in italic type, authors should use the CSS font-style property.

That's an argument for styling, not an argument for a class. Whether you have <i> or <i class="foo">, you can style them equally well.

The only difference, as phillipgessert mentioned, is that the style defined for <i> could be overridden by some user/software preference, while <i class="foo"> would have higher priority and be less likely to be overridden.

[JSWolf]

Originally Posted by slm

John
<i> displays as font-style:italic on most browsers, but it not required to do so--see https://developer.mozilla.org/en-US/...TML/Element/i:

In earlier versions of the HTML specification, the <i> element was merely a presentational element used to display text in italics, much like the <b> element was used to display text in bold letters. This is no longer true, as these tags now define semantics rather than typographic appearance. A browser will typically still display the contents of the <i> element in italic type, but is, by definition, no longer required to do so. To display text in italic type, authors should use the CSS font-style property.

The only way to make <i> not be italic is if I change it in CSS, Otherwise, <i> is italic. So really, using CSS to define italic is not needed. It's excess code.

<i>, <em>, <b>, <strong> all do not need a class if all you are doing is italic and/or bold. I strip useless classed from there as again, not needed. I cannot stand a <span> to italicize or bold.

[JSWolf]

Originally Posted by Jellby

That's an argument for styling, not an argument for a class. Whether you have <i> or <i class="foo">, you can style them equally well.

The only difference, as phillipgessert mentioned, is that the style defined for <i> could be overridden by some user/software preference, while <i class="foo"> would have higher priority and be less likely to be overridden.

Of course, you could define <i> in CSS for most uses of <i> and then only have a class when you want to do something different.

I prefer <p> to be mostly just <p> so I have CSS to define the most used definition of <p>. Again, I cannot stand something like <p class="indent"> when <p> would do instead.

[Turtle91]

I’m not sure that using a class to avoid the device overriding the styling would be all that effective?? It seems that if the device is going to ignore the included css in favor of its own, then the device would override css classes as well. Has anyone seen this behavior in the wild where the technique actually works??

[Karellen]

Originally Posted by JSWolf

Of course, you could define <i> in CSS for most uses of <i> and then only have a class when you want to do something different.

I prefer <p> to be mostly just <p> so I have CSS to define the most used definition of <p>. Again, I cannot stand something like <p class="indent"> when <p> would do instead.

I am happy to read this. It is the argument I took when I first started editing ebooks a year and a bit ago, when I was still on my (persistent) learning curve.. "why do I need all this code?"

I asked a similar question in another thread of mine, why is everthing class= calibre1, calibre2, calibre3, calibre_1, calibre_2. It used to annoy me so I started to strip everything out and style the base tags in the css and only add a class when I needed something different to what the base tags were styled to.

[phillipgessert]

Originally Posted by Turtle91

I’m not sure that using a class to avoid the device overriding the styling would be all that effective?? It seems that if the device is going to ignore the included css in favor of its own, then the device would override css classes as well. Has anyone seen this behavior in the wild where the technique actually works??

Yeah, I’m not sure it would be particularly reliable, was just a thought. Folks gambling that a device might override some styling on default p, but does it by playing with precedence for a lighter touch than just completely trashing a stylesheet. It’s honestly the only thing I can think of that would make an actual human define something like p.paragraph or something.

It kind of makes sense if you figure that’s how all the devices work, really. They display however they want, apart from whatever we set that they feel like honoring. If you bump something up in precedence via something like p.center, odds are it will center. Set some rule on p.center that they don’t honor, and it usually falls back to whatever the default value is. Then you just kinda draw that same thinking all the way out to p.myfavoritesettings and roll the dice. I don’t do it, I don’t like the sound of it, but I can sort of understand the thinking. It’s like excessively-defined p rules are in the first place, just with a “pretty please” on top.

[Turtle91]

I suppose that would work if the device just overrides the base class. I was thinking it just ignores the css sheet altogether. If .para is defined on the sheet, and the sheet is ignored, then it would ignore the .para as well. If I were a developer it seems like it would be easier to just give the user selected setting - like margin, font-size, etc. - an !important tag to override just those parts of the base tag.

Oh well. Thanks for the brain exercise!

[phillipgessert]

An original CSS contributor recently tweeted some info about the origin of !important. He said it was only added in order to force adherence to governmental regulation on font size. I always knew it was a bit naughty but it really kind of reconfigured my perspective on it at a time when I happened to be thinking about precedence more anyway, and this topic coming along was oddly relevant as well in that regard.

https://mobile.twitter.com/stevenpem...39184287870981

Bit off topic but hopefully of some interest.

[DNSB]

Personally, I've pretty much given up on having a epub look close to the same on different renderers. The final straw for me was a few years back when an acquaintance complained about how epubs were boring and all of them looked the same. Oddly, the Android program he used and regarded as "the best ebook reader program ever" was configured out of the box to disregard any publisher styles whether applied through a stylesheet or inline. If you could be bothered to dig down through multiple levels of menus, you could find the multiple checkbox options to enable using publisher CSS and show publisher formatting. At that point, you got coverage for about 50% of the epub2 standard.

[JSWolf]

Originally Posted by Karellen

I am happy to read this. It is the argument I took when I first started editing ebooks a year and a bit ago, when I was still on my (persistent) learning curve.. "why do I need all this code?"

I asked a similar question in another thread of mine, why is everthing class= calibre1, calibre2, calibre3, calibre_1, calibre_2. It used to annoy me so I started to strip everything out and style the base tags in the css and only add a class when I needed something different to what the base tags were styled to.

Yes, that's the way to do it. The rule is to keep it simple. But some do not. The CSS used by Standard Ebooks is a right mess. There's a thread someplace here about it. I've had a look and even posted an eBook of theirs that I've cleaned up and the code in mine works in all cases where theirs not so.