Code bloat. What is it?

[paperwhite13]

Originally Posted by KevinH

The answer is no, there is no appreciable code loading or execution differences 99% of the time.

And an epub publisher who uses a standard css across a number of books, is much more likely to make fewer errors of omission or design, thus improving quality.

JSWolf has simply overstated/over claimed things as usual. He makes unneeded changes for no valid reason other than he thinks it should be so and gets irrationally upset when explained otherwise.

Making code simpler when possible is always a good thing, but simplifying classes when css inheritance is in effect (and with some css injected by the reader) itself is fraught with errors and really is not a good idea.

Removing unused id attributes is another one of those short sighted mistakes people make as external cfi references by scholars and others into locations inside the epub, page boundaries, and etc are often lost or destroyed.

And as a practical rule, anything that does not significantly impact loading or execution speed should generally be left alone is probably a good idea.

What JSWolf does with his own books is up to him, but advocating his views to everyone else as a "law" is not. Simpler is better until it is not. Be careful making changes not fully understood. Adding or removing default css from a class can and does impact inheritance and can cause errors when reader injected css exists that needs to be overridden, etc.

Thank you. In my case, he did tell me "Your ID's do nothing so you don't need them." when I posted a snippet from my code, even if I did need at least one of them for the index to work.

[JSWolf]

Originally Posted by KevinH

The answer is no, there is no appreciable code loading or execution differences 99% of the time.

And an epub publisher who uses a standard css across a number of books, is much more likely to make fewer errors of omission or design, thus improving quality.

JSWolf has simply overstated/over claimed things as usual. He makes unneeded changes for no valid reason other than he thinks it should be so and gets irrationally upset when explained otherwise.

Making code simpler when possible is always a good thing, but simplifying classes when css inheritance is in effect (and with some css injected by the reader) itself is fraught with errors and really is not a good idea.

Removing unused id attributes is another one of those short sighted mistakes people make as external cfi references by scholars and others into locations inside the epub, page boundaries, and etc are often lost or destroyed.

And as a practical rule, anything that does not significantly impact loading or execution speed should generally be left alone is probably a good idea.

What JSWolf does with his own books is up to him, but advocating his views to everyone else as a "law" is not. Simpler is better until it is not. Be careful making changes not fully understood. Adding or removing default css from a class can and does impact inheritance and can cause errors when reader injected css exists that needs to be overridden, etc.

Removing the unused IDs can speed up the ePub. It's been proven that if your ToC used IDs to go to then it gets slower.'

So if I have <h2 id="chapter01">Chapter 01</h2> and I have the ToC reference the ID instead of just going to the start of the HTML file, it will be slower. The only time an ID is needed in the ToC is when you are going to someplace that's not the top of the HTML.

There is nothing wrong with removing unused IDs. You don't see them. They don't do anything. They are not referenced for anything. You can't referenced them. You cannot go to a specific ID or page number (based on some pBook version). They don't do anything. If someone can show how to reference an unused ID in an eBook while viewing it, please do so. IDs do not reference anything external. They either there for a reason and they get used or they are extraneous and have no need to be there.

I've seen errors in a house CSS. The problem then becomes that they keep using it and the error stays because it could be in a not often used class.

Removing code you don't need is not a bad idea. But it is up to you to do so or not. When editing an eBook to be published, it's a good idea not to have any extra code. In calibre or Sigil, it's trivial to remove unused CSS.

CSS is there to override defaults if needed. But there's no need to 0 out all sorts of tags. You set them as they are needed.

Adding in your own CSS is not an issue. I don't add in all that much CSS. If it clashes with the existing CSS, I'll fit it so that's not an issue. You do not have to worry about any sort of inherited values. None of the CSS I add has any errors.

The changes I make are my choice. But they are not wrong. The format of the eBook is based on the publisher's format and it works to be the way I prefer. I don't like large space in chapter headers, like the based font size to be the default size. I don't like a smaller font size in offset text, I don't like large indents. I don't like paragraph spaces. I don't like space for section breaks. I don't like large first letter or drop-cap. I don't like large margins or large line-height. Some emendded fonts I don't want so I remove the embedded fall or some of the embedded fonts. for example, Adobe Garamond Pro is used a lot of the base font to emulate the pBook. It's too light and I don't to read with it. So I remove it and use the font of my choice. Stripping or changing code that does some of these things is not wrong. I have a Kobo and it has settings for font, font-size, margins, and line height. So I have to remove code for the font size if it makes the base font size smaller then 1em. Overall L/R margins get removed and left at 0. Line-height gets removed so I can set it how i like.

When I am done, the code is very clean and works as expected. Nothing I do is incorrect.

[JSWolf]

Originally Posted by paperwhite13

Thank you. In my case, he did tell me "Your ID's do nothing so you don't need them." when I posted a snippet from my code, even if I did need at least one of them for the index to work.

You did not say you had an index. Nobody would know that without you saying so. But you don't need two IDs right after each other. If you need to go to that location via an ID, you can use just one of them.

[KevinH]

Yes removing ids can in fact break external links into the epub (see the cfi spec used by most Readium based platforms and calibre as well). They can be used in toc's, pagelists, references for internal javascript, and of course references used for linking.

As a page is loaded, a hash table of ids to dom nodes is created faster than the io of the file on the disk can be done. Jumping to an id is basically instantaneous in epub readers unless the page itself is absolutely huge (entire book all in one file).

Please cite the exact speed test for loading a page you talked about. There would have to be an excessive number of ids and tons of images to load to make even a slight difference.

[paperwhite13]

Originally Posted by JSWolf

There is nothing wrong with removing unused IDs. You don't see them. They don't do anything. They are not referenced for anything. You can't referenced them. You cannot go to a specific ID or page number (based on some pBook version)

You told me to remove the id, without asking what it does, even though the index stops working without it.

Lorem ipsum <a id="_idTextAnchor005"></a> dolor sit amet
...
<p>Term<a href="part1.xhtml#_idTextAnchor005">5</a></p>

[paperwhite13]

Originally Posted by JSWolf

You did not say you had an index. Nobody would know that without you saying so. But you don't need two IDs right after each other. If you need to go to that location via an ID, you can use just one of them.

And you assume, sight unseen, that an id is unused.

[paperwhite13]

Originally Posted by JSWolf

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

That’s exactly what some IDs are for -- to correlate physical book numbering with the ebook. Building a pagelist is a basic requirement for accessibility.

[KevinH]

Just for the record, if I am developing an epub for someone (ie. have complete control of the design and layout that has not been made publicly available yet) then I do follow the KISS principle advocated by JSWolf, and do not in general add complexities that may not be well supported by any number of older epub e-readers out there. Of course Accessibility must still be thought about and supported as fully as possible.

I just do not modify other people epub designs and layout without very good reason.

[nabsltd]

Originally Posted by paperwhite13

You told me to remove the id, without asking what it does, even though the index stops working without it.

Lorem ipsum <a id="_idTextAnchor005"></a> dolor sit amet
...
<p>Term<a href="part1.xhtml#_idTextAnchor005">5</a></p>

I generally remove IDs, but before I do that, I run my search for a elements where the href attribute points to a file in the EPUB. Those target elements get an attribute (one that isn't part of the HTML standard) added, then I remove the id attribute from every element that doesn't have my special attribute. Then, I remove my special attribute from every element. Since this is just 3 saved searches, it goes pretty fast.

[Quoth]

Originally Posted by KevinH

Just for the record, if I am developing an epub for someone (ie. have complete control of the design and layout that has not been made publicly available yet) then I do follow the KISS principle advocated by JSWolf, and do not in general add complexities that may not be well supported by any number of older epub e-readers out there. Of course Accessibility must still be thought about and supported as fully as possible.

I just do not modify other people epub designs and layout without very good reason.

I agree with all of that.

Also I don't edit bought books unless they are too irritating on the ereader, or cause it to "crash" (both actually rare). I do leave drop caps, small caps etc alone if they are working.

I have some automatic transforms of a minor nature on conversions and for PD like Gutenberg use the automatic paragraph style swap (which usually only affects body) and puctuation smarten of Calibre.

[KevinH]

@nabsltd,

That approach would miss or break ids used by the epub2 toc.ncx which use <content src="blah#fragment">, and of course break the opf guide urls if they used fragments, and any ncx pagelists or adobe pagmap.xml use of fragments.

Not to mention epub3 external cfi urls that use fragments, external bookmarks that use fragments, javascript uses to dentify nodes in the dom, etc.

[DNSB]

Originally Posted by JSWolf

Text-align: justify;. It does belong in the <body>. It makes the eBook justified. Software that does not allow the alignment to be changed, it will be justified. Software that does allow the alignment to be changed, it will work. It works with my Libra 2 to change the alignment. But it can only be in <body> or it won't work.

Jon, you really should quit trying to force your preferences on other people.

Edit: As for complaining about the stylesheet in Random in Death, like most stylesheets in ebooks published by major publishers, that stylesheet is used for many different books so unused stylesheet entries are to be expected. Much like in the Vellum stylesheets that you love grumbling about.

[JSWolf]

Originally Posted by KevinH

Yes removing ids can in fact break external links into the epub (see the cfi spec used by most Readium based platforms and calibre as well). They can be used in toc's, pagelists, references for internal javascript, and of course references used for linking.

The IDs I remove do not link to anything except maybe the ToC and if they are at the top of the HTML, I can remove them from the HTML and the ToC. They do not link to anything external, no endnotes, no pagelists, no javascript, and no indexes. Nothing at all. So they don't need to be there.

As a page is loaded, a hash table of ids to dom nodes is created faster than the io of the file on the disk can be done. Jumping to an id is basically instantaneous in epub readers unless the page itself is absolutely huge (entire book all in one file).

Please cite the exact speed test for loading a page you talked about. There would have to be an excessive number of ids and tons of images to load to make even a slight difference.

I read this a while ago. It was about the current Sony Reader (at the time) being slower to go to an ID then to go to the top of the HTML and it was correct. I've not tested on Kobo. But It was correct about the Sony Reader.

[DNSB]

Originally Posted by JSWolf

I read this a while ago. It was about the current Sony Reader (at the time) being slower to go to an ID then to go to the top of the HTML and it was correct. I've not tested on Kobo. But It was correct about the Sony Reader.

Are those the same Sony readers that crapped out if the file size was over 250KB?

I did a quick test with a epub that has multiple subchapters within it's mass of chapters using a Kobo Sage. To the naked eyeball, going from the ToC to chapter 103 did not take any more time than going from the ToC to a subchapter in chapter 103. The chapter 103 link is to the xhtml file, the subchapters links are to an id. Using my iPhone to record the process, both took the same number of frames at 30fps from when the link went dark to when the text was displayed (averaged over 5 tests of chapter and subchapter) so any differences in timing were less than 30ms.

Doing this test did reinforce my wish that you could collapse the ToC.

[JSWolf]

Originally Posted by paperwhite13

And you assume, sight unseen, that an id is unused.

If I had the eBook in front of me, I'd have seen what's going on.