Why so complicated?

[foosion]

I found this at the top of chapter 1 of a book and I'm wondering why all of this is needed. Wouldn't it be simpler to just label everything that is to go into the TOC with h#s? Sect1 could be a higher h# so it wouldn't get put into the TOC.

If the page should have a few lines, but the TOC only one line per chapter, use the title attribute.

Text:
Chapter One
Words words
Some more words

TOC:
Chapter One: Words words "Some more words"

<section aria-labelledby="hd-chapter001" epub:type="bodymatter chapter" id="chapter001" role="doc-chapter">

      <h1 class="chapter-number" id="hd-chapter001"><span epub:type="pagebreak" id="page12" role="doc-pagebreak" title="12"></span><a href="toc.xhtml#toc-chapter001"><span epub:type="pagebreak" id="page13" role="doc-pagebreak" title="13"></span>CHAPTER ONE</a></h1>

      <h1 class="chapter-title"><a href="toc.xhtml#toc-chapter001">Words words</a></h1>

      <h2 class="chapter-subtitle"><a href="toc.xhtml#toc-chapter001">“SOME MORE WORDS.”</a></h2>

      <h1 class="sect1" id="a001">1.</h1>

Also, what does the "section" part accomplish?

Given no index and the ability to generate a TOC from major Hs, what does "id" accomplish?

Why an href to the TOC in an epub?

Finally, why epub:type="pagebreak" or ="bodymatter chapter" or role="doc-pagebreak"?

[DNSB]

Section is similar to a div but used to group related content. You will notice that the section in your quoted text has no classes but does include identifiers, roles, epub-type, etc.

The ID is likely used in the ToC instead of pointing to the chapter file, you would get href="part0007.html#hd-chapter001". Add further ids for subchapter entries.

The href to the ToC allows you to go back to the ToC by tapping on that entry. A vestige of old practices. Remember when you would see Last:Next:ToC at the top and bottom of chapters?

An epub-type is part of ePub3 attributes allowing improved semantics. Originally, it was hoped/hyped that epub-type would improve accessibility but other than some limited success with footnotes, this did not happen.

OTOH, a role is an ARIA attribute used to expose information to assistive technology. There is a lot of overlap which is why it was originally hoped to use epub-type but support never materialized.

See the EPUB Type to ARIA Role Authoring Guide for more information.

[foosion]

That's very helpful. Thank you!

It appears that if I'm editing a commercial work for personal use, want to make the appearance more pleasing to me and don't use assistive technology, I could just enclose each part of the text in bare h# tags, style those as desired in the CSS and delete the rest. I could then generate a ToC from the h# tags, using a title attribute if desired, without needing any href or id.

Deleting the "excess" would make things simpler and easier to understand for me.

[Terisa de morgan]

If you want to remove different elements in different files in an easy way, I recommend this plugin.

[DNSB]

Originally Posted by foosion

That's very helpful. Thank you!

It appears that if I'm editing a commercial work for personal use, want to make the appearance more pleasing to me and don't use assistive technology, I could just enclose each part of the text in bare h# tags, style those as desired in the CSS and delete the rest. I could then generate a ToC from the h# tags, using a title attribute if desired, without needing any href or id.

Deleting the "excess" would make things simpler and easier to understand for me.

It is not all that difficult using regex/TagMechanic/etc. to remove the unwanted elements. For me, it is more if they do not interfere with viewing the text, I do not worry about them. After all, I am not going to be looking at the innards of an ePub while reading it.

I also tend to use regex to combine the various elements of a multi-part header into a single title element. At the same time, I prefer to use one header tag and change the rest to <p> tags.

I do prefer simplicity but, at this time, I prefer not to trade the ability to use assistive technology for simplicity.

One recent book used h1, h2 and h3 for the chapter title information and yes, the author loved using all caps all too often:

<h1>CHAPTER ONE</h1>
<h2>IN WHICH WE SPEAK</h2>
<h3>OF THE VARIOUS NAMES OF GOD</h3>

becomes

<h3 title="Chapter One: In Which We Speak of the Various Names of God">CHAPTER ONE</h1>
<p class=subhead1>IN WHICH WE SPEAK</p>
<p class=subhead2>OF THE VARIOUS NAMES OF GOD</p>

My standard for header tags is <h1> is for books in a omnibus, <h2> is for parts in a book and <h3> is used for chapters. I have occasionally used h4 for subsections of a chapter. Only once have I used <h5> and <h6> and that was a fun bit of work on a university textbook where the author had lost his original manuscript and we had to convert and cleanup a PDF copy.

[foosion]

Originally Posted by Terisa de morgan

If you want to remove different elements in different files in an easy way, I recommend this plugin.

I prefer just using regex, perhaps because I'm more familiar with it.

[foosion]

Originally Posted by DNSB

<h3 title="Chapter One: In Which We Speak of the Various Names of God">CHAPTER ONE</h1>
<p class=subhead1>IN WHICH WE SPEAK</p>
<p class=subhead2>OF THE VARIOUS NAMES OF GOD</p>

Yes, actually making the changes is easy. I do find it easier to change the text I posted in the OP to something similar to what you posted above than to parse out what all of its elements are doing. I have been a bit hesitant to remove things I don't fully understand (a motivation for this thread).

I don't use assistive technology and am not editing for others.

<p class=subhead2> seems to be good semantics as well as syntax.

[JSWolf]

Originally Posted by foosion

I prefer just using regex, perhaps because I'm more familiar with it.

I use Diaps Editing Toolbag a lot. It really does work well.

[foosion]

Originally Posted by JSWolf

I use Diaps Editing Toolbag a lot. It really does work well.

It does work well and I'm glad Terisa recommended it, but regex seems to allow for more detailed control and, as noted, I'm more familiar with it. De gustibus ...

[Terisa de morgan]

Originally Posted by foosion

It does work well and I'm glad Terisa recommended it, but regex seems to allow for more detailed control and, as noted, I'm more familiar with it. De gustibus ...

Yes, I agree it gives more control.

[JSWolf]

Originally Posted by foosion

It does work well and I'm glad Terisa recommended it, but regex seems to allow for more detailed control and, as noted, I'm more familiar with it. De gustibus ...

You can use regex for the search parameter(s) with the plugin.

[Terisa de morgan]

Originally Posted by JSWolf

You can use regex for the search parameter(s) with the plugin.

It's not the same to use a regex expression to define the tag parameter than using a regex expression to find the tags. I've had had to change the plugin, for example, to add more tags. With regex, you can do it on the fly.

[JSWolf]

Originally Posted by Terisa de morgan

It's not the same to use a regex expression to define the tag parameter than using a regex expression to find the tags. I've had had to change the plugin, for example, to add more tags. With regex, you can do it on the fly.

What tags have you added in? I know I could use some more tags.

[DiapDealer]

Using regex alone to do this sort of work is certainly anyone's prerogative (and I'm not hyping my own plugins for more usage). Just know that regex alone is more prone to break things -- especially where nested tags are concerned. Hence the reason I created my plugins in the first place. It uses an a html parser to eliminate the possibility of breaking nested situations. Whereas regex alone will happily crash through nested spans and divs like a bull in a china shop--because it doesn't parse.

[foosion]

Originally Posted by DiapDealer

Using regex alone to do this sort of work is certainly anyone's prerogative (and I'm not hyping my own plugins for more usage). Just know that regex alone is more prone to break things -- especially where nested tags are concerned. Hence the reason I created my plugins in the first place. It uses an a html parser to eliminate the possibility of breaking nested situations. Whereas regex alone will happily crash through nested spans and divs like a bull in a china shop--with no concern with whether or not it's breaking anything.

That is an issue and one has to be careful. Nested tags will result in, for example, <div>(.*?)</div> matching the first closing </div> it encounters rather than the matching </div>. It's easier if you're eliminating all of the divs (or spans) in a file.

There may be a complicated regex that avoids the problem.

BTW, if I wanted to eliminate all <section epub:type="bodymatter chapter"> or the like, how would I set the plugin? I could use regex to add a, for example, id tag, then match the id with the plugin, but that would seem to defeat the purpose.