<div> instead of <p>?

[JSWolf]

Originally Posted by Sarmat89

DIV is a generic block type. It works as good as P, but requires less work to generate.

<div> requires less work then <p>? Are you daft? That's rubbish.

[DNSB]

Originally Posted by Sarmat89

DIV is a generic block type. It works as good as P, but requires less work to generate.

Where the <expletive deleted> did you get that well aged bovine excreta from? Perhaps you could share exactly how a div takes less work to generate?

[Moonbase59]

Originally Posted by Sarmat89

DIV is a generic block type. It works as good as P, but requires less work to generate.

Read <div>: The Content Division element.

• The <div> HTML element is the generic container for flow content.
• As a "pure" container, the <div> element does not inherently represent anything, i.e., it has no semantic meaning.
• Instead, it's used to group content so it can be easily styled using the class or id attributes.
• Usage note: The <div> element should be used only when no other semantic element (such as <article> or <nav> [or <p>!]) is appropriate.

[ElMiko]

I was trying to be circumspect in my annoyance at the div/p switcharoo, but I'm gratified to see I'm not alone in this.

@Sarmat89 - I'm curious what you mean by divs "requir[ing] less work to generate"... Are you referring to defining margins in css? If so, I suppose you're technically right, but I'd also think that typing "margin: 0;" isn't all that onerous. Or is there some other idiosyncratic workflow to which you are referring?

@Quoth - archive's epubs are a travesty. It doesn't help that their OCR is pretty crummy to begin with, but the epubs are basically just a straight pdf to epub conversion, complete with headers, footers, about a gajillion forced line breaks, and more OCR-based artifacts than you can shake a stick at. Without an ounce of exageration, the end result is flatout unreadable. I don't know why they even offer the epub file.

But at least it's not all <div> tags, I guess...

@Jellby - that's EXACTLY it... I've seen this now multiple times: the whole document is just <div>s and <span>s! I thought that maybe someone out there had a really unique workflow; I didn't realize that this is autogenerated. Although it invites the question: what kind of sociopath would design software that exclusively uses those two tags for text conversions...?

[JSWolf]

Originally Posted by ElMiko

@Jellby - that's EXACTLY it... I've seen this now multiple times: the whole document is just <div>s and <span>s! I thought that maybe someone out there had a really unique workflow; I didn't realize that this is autogenerated. Although it invites the question: what kind of sociopath would design software that exclusively uses those two tags for text conversions...?

It seems nobody knows what program does <div> instead of <p> for ePiub creation. Whatever program it is, it's a steaming pile.

[RbnJrg]

Regarding <div> in place of <p> (or <h*> tags) I must say that many times I had to do that because of bugs in Thorium an PocketBook. PB has issues with especial margins and paddings (it doesn't honor them) so when I want a <p> with margins (or paddings) different from what I declared in the stylesheet for "p", I must replace the tag for a <div>

The same happens with Thorium regarding <h*> tags. The program doesn't honor the font-size set in the stylesheet. It's awful but if I want compatibility with Thorium , I have to replace for example <h1> with <div class="header1"> to get a proper font-size.

[ElMiko]

@RbnJrg - I knew I could count on you for some decent outlier cases!!

Now, I'm curious in the case of the <p> margins not being honored, does that mean that even if you wrap them in a div (with margins), no margins will be reflected? Or simply that margin attributes directly at the <p> level aren't honored. Does this wonkiness extend to blockquotes?

@JSWolf - Yeah, I'd be curious to know who is the criminal responsible for this, too. Frankly, the books I've seen with this not only are guilty of the div/span coding, but also the css is usually ridiculously bloated. Like, multiple classes that are different from eachother only in the most marginal sense—think "margin: 0 1px;" vs "margin 0 2px;" or "font-size: 1.0em;" vs "font-size: 1.00012583em". In retrospect, those ridiculous decimals should have been a dead giveaway that it was a program, not a person. (although the designer presumably WAS a person, and deserves a jail sentence)

[RbnJrg]

Originally Posted by ElMiko

@RbnJrg - I knew I could count on you for some decent outlier cases!!

Now, I'm curious in the case of the <p> margins not being honored, does that mean that even if you wrap them in a div (with margins), no margins will be reflected? Or simply that margin attributes directly at the <p> level aren't honored. Does this wonkiness extend to blockquotes?

PB behaves extremely unusual regarding specific margins applied to a <p> tag. It doesn't even respect them if I declare a style inline. For example, <p style="margin: 2em 0">...</p> isn't honored if, for example, I have declared this in my stylesheet:

p {
  margin: 0;
  ...
}

Regarding to have:

<div style="margin: 2em 0">  /* This is honored */
    <p style="margin: 1.5em 0">This is my test</p> /* This isn't */
</div>

but for only one line, you never will write something so. Instead you'll write:

<div style="margin: 3.5em 0">
    This is my test
</div>

OTOH, if you have:

<div class="bigMargin">
    <p>This is my test</p>
    <p>This is my test</p>
    <p>This is my test</p>
</div>

and

.bigMargin {
   margin: 2em 0;  /* PB will honor this */
}

.bigMargin p {
   margin: 0.5em 0; /*PB won't honor this */
}

The opposite also occurs (that is, I have big margins and I want smaller ones for a particular <p>). The best way to understand what happens with PB is to install the app and test different particular margins for the <p> tag.

[theducks]

Originally Posted by Moonbase59

What really annoys me is that you see more and more of this crap in expensive e-books from large publishers. The code often looks like machine-generated, or at least done by complete idiots. Also, there’s often stuff in it to fight deficiencies of single readers.

I mean, hey, in what market are we? Pay $10–30 for a book and then have to invest hours to repair it?! It really, really sucks.

Besides, not everybody has the tools or the knowledge.

Hours? If it is just messy code (but it works), Maybe 10 minutes. with Saved searches and 'clips' to paste into the replace.
Diaps toolbag (Sigil PI) is a start. I wish it could have a bit more helpers
(inventory Tags and THEIR classes.
You select a Tag type, The the value pulldown allows a choose list of the classes (and the tick to keep those is default) Helps eliminate typo retries)

[Moonbase59]

@RbnJrg: Couldn’t really believe what you said about the Pocketbook, because I always found their renderer rather compatible. I own a Pocketbook Era (PB700), Firmware U700.6.8.4183.

I took an older test file and quickly put your ".bigMargin" example in, setting the "div" background to green so we can see what’s happening. As far as I can see, all is as intended. I enclose the test EPUB so you can try for yourself.

Sigil, Thorium, Foliate and the actual device show it works fine. Oh, and KOReader, too.

Just in case anyone wonders: Block element vertical margins usually collapse, that’s why we don’t see "more margin" in the example.

[RbnJrg]

Originally Posted by Moonbase59

@RbnJrg: Couldn’t really believe what you said about the Pocketbook, because I always found their renderer rather compatible. I own a Pocketbook Era (PB700), Firmware U700.6.8.4183.

I took an older test file and quickly put your ".bigMargin" example in, setting the "div" background to green so we can see what’s happening. As far as I can see, all is as intended. I enclose the test EPUB so you can try for yourself.

Sigil, Thorium, Foliate and the actual device show it works fine. Oh, and KOReader, too.

Just in case anyone wonders: Block element margins usually collapse, that’s why we don’t see "more margin" in the example.

Sorry, my mystake. I was referring to the Android version of PB. It's possible that the physical device has a different rendering engine, but the app has the bug I described.

Download the app; open the epub I attach with PB and you'll be able to check that the app doesn't honor especial margins.

Here you have how it looks under Sigil:



And here you have a screenshoot of PB:



As you can see, margins are not honored And here we don't have an issue due to margins collapse; according to css rules, the margin to take is the bigger one, and in the present case, the bigger margin is 1em. You need in PB to replace that <p> with a <div> and apply .bigMargin to this last one if you want to have the proper margins.

You can also try it with Thorium by trying to increase the font size in an <h*> tag; it doesn't accept it. Instead, it uses the program's default size.

[Moonbase59]

@RbnJrg: There must be something odd with your setup (or settings?).

I admit I never before used the Android Pocketbook App but installed it now, out of curiosity (v5.59.0.22307.release). Here are screenshots of the two EPUBs, mine and yours. All seems good.

But, tbh, we’re getting a little off-topic… ;-)

[ElMiko]

@Moonbase - actually, this very on topic! As much as I deeply enjoy griping about crummy code (and although it appears that 99.9% of the div/p substitution is just that), I really did want to know if it EVER makes sense to write epubs like that. So if you guys can get to the bottom of this weird PB behavior I'll consider the thread entertaining AND useful!

(I'm also still curious to hear clarification on what makes div "easier" than p for Sarmat's workflow)

[Slevin#7]

Originally Posted by Moonbase59

@RbnJrg: There must be something odd with your setup (or settings?).

I admit I never before used the Android Pocketbook App but installed it now, out of curiosity (v5.59.0.22307.release). Here are screenshots of the two EPUBs, mine and yours. All seems good.

That's odd^^. I can confirm RbnJrg's observation that PocketBook seems to have issues with margins and paddings in their applications. For iOS the current version is 5.15.5 592939 and over a year old. So maybe they have updated the Android app?

Originally Posted by ElMiko

@Moonbase - actually, this very on topic! As much as I deeply enjoy griping about crummy code (and although it appears that 99.9% of the div/p substitution is just that), I really did want to know if it EVER makes sense to write epubs like that. So if you guys can get to the bottom of this weird PB behavior I'll consider the thread entertaining AND useful!

I agree. This here seems to be the one and only real serious ebook forum for creators and developers. And since there are not that many active members participating in communication it is imo perfectly fine to use each of the topics to go at least a bit sideways. This helps to broaden perspective and brings every now and then valuable information to all the readers. The moment a topic dies it gets old anyways and the intinsic value dies at well.

Thus, keep the community alive and let all who wanna sing a little song just give their best

[Terisa de morgan]

Originally Posted by ElMiko

(I'm also still curious to hear clarification on what makes div "easier" than p for Sarmat's workflow)

I've got a weird idea about this: if you write a code automatically, and don't have to chose between div and p, and only write div class=..., yes, it can be much easier. But it's a weird idea, as I say.