Heading/Subtitle html coding best practice

[ElMiko]

The longer I do this, the more I find myself second guessing years of habit... I'm curious what best practice is for headings/subheadings: should the heading be in a separate element or should style differences be offset by a <br /> and the use of <span>s? Or does it not really matter?

For example:

1.
The End of the Beginning

My instinct would be to render this as:

<p class="a"><span class="x">1.</span><br />
The End of the Beginning</p>

where "a" establishes the alignment/margins of the element and the style of the subheading, and "x" extablishes the style of the heading.

Ironically, this flies in the face of most of my html instincts in almost any other context, as I tend not to use <span>s if I can just style the next largest element (e.g. <p>)... This inconsistency is inspiring my sudden moment of self-doubt...

(Edit: to be clear, generally I'd be using an <h#> element, not <p>...)

[Karellen]

I use the following format.
It allows me to style the heading and sub heading individually without the use of spans to divide the different values.

  <h2 title="16 - Target List">16.</h2>
  <p class="chapterh2">Target List</p>

[DNSB]

For my purposes, if the chapter number and the subheading use similar CSS, I will use a <br/><span>...</span>. Otherwise, I will use the chapter number in it's own header and the subheader with it's own CSS and then use a title="" to have both in the ToC. If I don't use a subheader, the title would be used to add Chapter ( i.e. title="Chapter 1">1.< ) since I prefer to not have naked numbers in the ToC.

<h3 title="Chapter 1">1.</h3>

<h3 title="1: The End of the Beginning">1.</h3>
<p class="subheader">The End of the Beginning</p>

If necessary, regex is very helpful in generating the title element.

[KevinH]

And most importantly, using a h1-h6 tag to create the header tells accessibility software that it is in fact a header and not a normal paragraph. Use the right tags to properly indicate structure so that screen reading software can actually detect the structure.

[ElMiko]

Yup... this is what my gut is telling me, too. Damn all of you...

The TOC isn't quite as easy when they are separate elements, but that should be manageable with some regex. That moment of "Replace All", though, is always slightly anxiety-inducing...

@KevinH: If I hide a sub-sub heading from TOC, but it uses <h#> element, does that negatively affect accessibility?

[KevinH]

With newer versions of Sigil to can click to create a checkpoint (snapshot) in case you need to revert. Plus there are additional ReplaceAll tools that create a table showing you all of the proposed changes with some before and after context soyou knw wheter to keep each change or not.

[ElMiko]

@KevinH – So what you're saying is that maybe variable lookbehinds are not the only reason for me to abandon 0.7.2 and join the future?

*grumble, grumble, grumble*

[KevinH]

Originally Posted by ElMiko

@KevinH: If I hide a sub-sub heading from TOC, but it uses <h#> element, does that negatively affect accessibility?

You control what is in TOC and can select which heading to include or not via the TOC Editor. Using the title attribute in heading tags controls the title.

Using a heading tag to indicate something is a header helps A cessibility even if not part of the TOC.

[KevinH]

Originally Posted by ElMiko

@KevinH – So what you're saying is that maybe variable lookbehinds are not the only reason for me to abandon 0.7.2 and join the future?

*grumble, grumble, grumble*

As long as you are not heavily reliant of BookView and can use Sigil's Preview (and PageEdit) then updating Sigil should be a huge improvement. Just one that will have a learning curve as you have waited so long.

Just the ability to run plugins like epubcheck and have it fill the Validation Window, is worth it to me but to each their own.

[DNSB]

Personally, I could never go back to the earlier versions of Sigil. I have gotten too used to the improvements over the years. If nothing else, I was burned several times by BookView's ability to generate garbage code before I just stopped using it.

[ElMiko]

Originally Posted by DNSB

Personally, I could never go back to the earlier versions of Sigil. I have gotten too used to the improvements over the years. If nothing else, I was burned several times by BookView's ability to generate garbage code before I just stopped using it.

Overwhelmingly, I edit in html...

...except...

...when I'm editing verse.

In that case, I break stanzas in WYSIWYG. It's basically the only thing I use ye olde Book View for (other than as another preview window for the css effects), but it's a big enough feature (either when editing a poetry collection or simply engaging with blockquoted poetry/music in prose) that breaking those lines in a pure html editor would be a drag. What's more, I've NEVER run into issues with it messing up the html—probably because my use-case, while critical to my workflow, is very, very narrow.

From what I can see from scanning the User Guide, it looks like Page Edit fully replaces Book View and it's functionality... is that more or less right?

[KevinH]

Yes, same basic functionality as the old BookView for live editing visually.

[ElMiko]

I've made the plunge. Someone please hold me...

[DNSB]

Be calm and edit on...

[theducks]

I use the with <br /> method as it Generates the TOC with both the # and the text.
It also meets the accessibility reason to use <h# tags instead of P or Div

If you want the text part Larger or smaller, just wrap that in a Span with the styling wanted.