Code bloat. What is it?

[JSWolf]

Originally Posted by Turtle91

Ahhh, ok...It's a bug in Kobo that you use the work-around of putting text-align in the body to fix.

Has this been brought up with Kobo so they can work on a fix??

I don't think it's a bug It's how it is.

[JSWolf]

Originally Posted by Turtle91

Here is an example of what I would call code bloat:

<p style="margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0;
          font-size:1.0rem"> <span style=" font-size:1.0rem">We weren’t.</span> </p>
<p style="margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0;
          font-size:1.0rem"> <span style=" font-size:1.0rem">We’d planned the general
          strategy weeks ago, and confirmed it days before.</span> </p>

Excerpted from On the Shoulders of Titans by Andrew Rowe, Published in 2018. I added line-breaks so you could easily see it here.

Inline styling makes me shudder anyway, but the fact that the same styling is put on EVERY FREAKING LINE... that is totally unnecessary...and bloats the code. The same goes for putting a span, with inline styling, around every paragraph simply to tell it to use the standard font size.... which it already told it in the first set of styling!

Here is what I would reduce it to:

CSS:
p {margin:0.00% 0.00%; text-indent:1.2em; line-height:110%; widows:0; orphans:0;
   font-size:1.0rem}

HTML:
<p>We weren’t.</p>
<p>We’d planned the general strategy weeks ago, and confirmed it days before.</p>

Yes Jon, we know you don't like that styling and would change it. The point here is that it doesn't change the author's/publisher's styling at all...it just reduces code bloat.

Which is easier to read? If you needed to edit the way all your paragraphs looked you would need to change every single paragraph the way it currently stands. Reducing the code bloat and using css, as in the second example, I only need to make the change in one place and it updates the whole book.

I don't really expect the code bloat to change the file size all that much...certainly not as much as fixing the images/fonts...although I have reduced massive books by a couple of megabytes. I would rather not put ANY renderer, no matter how capable, through the constant headache of crunching through all that bloat just to determine what and how it should be displayed... my phone seems to stay cooler and the battery lasts longer. (That's my story and I'm sticking to it! )


Cleaning up the unused css styles is automagically done for me when I use the Sigil plugin cssRemoveUnusedSelectors, so I don't spend too much time and energy cleaning up that "bloat".

I've seen some eBooks with CSS yet an inline style for indent is used. I have no idea why that is.

[JSWolf]

Originally Posted by paperwhite13

Nothing happens, that ebook is safe and sound on your ereader. Because now probably only your modified ebooks have broken pagelists, it's already best practice. What will happen in the future is probably that more ebooks will adopt the more "bloated" <span aria-label=" Page 145. " epub:type="pagebreak" id="pg_145" role="doc-pagebreak"/> technique, like Random in Death correctly uses, instead of the non-recommended <a id="page145"/> technique (which I also used).

Most of the time, there is no pagelist. But, even if there was, it's OK for me to rip it out for my eBooks if I desire. Most of what I read are novels and they are not for any sort of school. I don't need a pagelist.

If there is no pagelist, then the internal pBook page numbers have no use unless you want to build a pagelist.

[paperwhite13]

Originally Posted by JSWolf

Most of the time, there is no pagelist. But, even if there was, it's OK for me to rip it out for my eBooks if I desire. Most of what I read are novels and they are not for any sort of school. I don't need a pagelist.

It's ok for you to do anything with your books, but your personal preferences or mine are completely irrelevant to a general discussion. And in the context of general advice, it's incorrect to suggest deleting id's because, and I quote:

Originally Posted by JSWolf

You cannot go to a specific ID or page number (based on some pBook version). They don't do anything.

Just like it’s incorrect to suggest that a behaviour a particular e-reader was displaying 15 years ago is how readers work today.

[paperwhite13]

Originally Posted by JSWolf

Nothing I do is incorrect.

I don't know why it's so important to you to never be wrong, and I don't want to speculate. I am often wrong and I hope you sometimes admit, even if it's only to yourself, that you are indeed wrong, I don't see how there could be any room left for learning and growth otherwise.

[KevinH]

Originally Posted by JSWolf

When I remove IDs, I make sure that they are either not used or at the top of the HTML and only used in the ToC. Then I can remove them from the HTML and the ToC (if they are in the ToC).

Still can break things if you do not make sure the OPF guide section does not use fragments (at least with epub2)

[KevinH]

I do not disagree with you about pushing boundaries and improving things.
And I am not advocating against epub3 or using epub3 features in any way (especially if still backwards compatible with epub2). But as a starting point keeping things simple is for me always the right way to form the basic nucleus. Then you can build off of that when your experience and expertise allows.

But again this is just my opinion and advice for people starting out in epub development.

Just like my advice for people editing every epub they own to remove "bloat" is to not do it unless the "bloat" actually makes a negative impact on performance.

But if a person does decide to remove "bloat", they need to be very very careful with css (due to inheritance and some readers injecting their own stylesheet) and they should not remove id attributes unless they have a full understanding of all of the places and ways ids/fragment can be used under both epub2 and epub3.

Hope that makes my comments clearer.

Originally Posted by RbnJrg

Ok

With all respect, I disagree. The KISS rule is deprecated, maximun if we have the complete control of the layout and design. The modern epub must be a perfect epub3 ebook, with all the epub3 features, plus a perfect epub2 inside (epub2 ereaders can open epub3 ebooks and you know that more than anyone Kevin). Of that way, if the ereader (the device) supports the epub3 protocols, then the human reader will have the best reading experience; on the other hand, if the device is an old one, then the epub2 code will take place. The KISS rule is an old rule (of course, we have to work more but results are optimal).

And there is a big notice; the epub2 protocol is next to be deprecated. Why? Because KOBO have added practically full epub3 supports to its reades (in my tests, the only thing seems not to be implemented yet are popup footnotes/endnotes and there are issues with MathML). Anyone can test that with the Kobo readers for Android and iOS. I don't know if all eink models of Kobo have been uptades with the last version of the rendering engine but what I saw in android and ios is amazing! To read, for example, "Alice in Wonderland" (illustrated version) with epub3 code, compared with an epub2 version, is like to compare a Ferrari with a bike.

[JSWolf]

Originally Posted by KevinH

Still can break things if you do not make sure the OPF guide section does not use fragments (at least with epub2)

I've not see fragments in the OPF in a very long time. I do check that the IDs are not needed before removing them.

[JSWolf]

Originally Posted by paperwhite13

It's ok for you to do anything with your books, but your personal preferences or mine are completely irrelevant to a general discussion. And in the context of general advice, it's incorrect to suggest deleting id's because, and I quote:

If the ID does nothing, do you need it? If you do say you need it, why do you need it?

Just like it’s incorrect to suggest that a behaviour a particular e-reader was displaying 15 years ago is how readers work today.

If you have an ID or something showing a pBook page number in the HTML, show me how you display them. If the ID doen't link to anything or anything doesn't link to it and there is no pagelist, then what is the pBook page number good for? What can you do with it if you are not building a pagelist? I don't know of any software that can display the ID or the page number.

[JSWolf]

Originally Posted by paperwhite13

I don't know why it's so important to you to never be wrong, and I don't want to speculate. I am often wrong and I hope you sometimes admit, even if it's only to yourself, that you are indeed wrong, I don't see how there could be any room left for learning and growth otherwise.

Being wrong is when the eBook either does not work correctly or the formatting is not correct. Just because I am not wrong does not mean you have to agree with everything I do.

The worst way of making a mistake is when you do an incorrect search/replace and it really screws things up. I've done that plenty of times. But most of the time I've saved bforehand.

Nobody knows everything. But I'm wondering why you want/need to have code that doesn't do anything?

[KevinH]

Originally Posted by JSWolf

I don't know of any software that can display the ID or the page number.

Under epub3 the nav can and does show a page list. The epub developer controls if it is hidden or not.

[Turtle91]

I’ll be the first to admit that I don’t have any experience USING accessibility software, so I don’t know exactly what it does, or doesn’t, do.
I am pretty sure, however, that accessibility software has the ability to scan the book and find IDs (of whatever type). The user also has the ability to find/search on the better readers/apps…. So there doesn’t really need to BE an existing link for such IDs to be potentially useful.

[JSWolf]

Originally Posted by KevinH

Under epub3 the nav can and does show a page list. The epub developer controls if it is hidden or not.

I'm meaning when there is no reference to an ID or the pBook page number. That means no pagelist. How would you display the ID or the pBook page number?

I'm saying it's OK to delete IDs and pBook page numbers in the HTML when they don't do anything.

[paperwhite13]

Originally Posted by JSWolf

But I'm wondering why you want/need to have code that doesn't do anything?

Your advice to a newbie, like I’d just declared myself to be, was "You don’t need those id's, delete them". It wasn't "Check that they’re unused, maybe you've a pagelist, maybe you've got an index; look out for this and that". What if I didn’t know, as a newbie using InDesign generated code and asking for help about it, that an index uses the id's? You want me, the newbie, to check and understand the code just so that you can then give me the expertly advice "delete the unused ids"? How about, if you're not really willing to truly help, just abstain?

Then with the double id's you told me to delete one of them because the page slows down etc. (15 year old behaviour on an old Sony reader). Yes, the code would be cleaner, but it takes more time to delete the double ids and fix the TOC reference, with zero consequence on performance vs. the time it took to generate them (no time at all, since it came out of InDesign like that).

All in all, just bad or incomplete advice.

[paperwhite13]

And to answer your question, if there is still code in there and it truly doesn't do anything (as in it doesn't impact performance either), I have no reason to remove it, if it takes time (therefore money, since I'm doing this professionally) to do it.