Sigil - is there a setting for behaviour after h6?

[KevinH]

FWIW - I filed the following bug in Qt's bug reporting system. But the code in question is actually upstream at Google Chrome and it may take years to see the light of day if ever.

QtWebengine does not follow the w3c editing spec
https://bugreports.qt.io/browse/QTBUG-79778

[parvatiquinta]

Originally Posted by DiapDealer

We had very, very little control over the html that QtWebkit generated when editing in BookView, and we still have very little control over the html that QtWebEngine generates in PageEdit. I'm not certain everyone fully realizes this (no matter how many times we try to tell them).

That is fine, when I started this topic I was mostly looking to see if this was fixable by, say, editing some .ini or .dll - my skills at that are limited and so I only tend to do that on the advice of someone more knowledgeable than me.

Originally Posted by KevinH

FWIW - I filed the following bug in Qt's bug reporting system. But the code in question is actually upstream at Google Chrome and it may take years to see the light of day if ever.

Now I know what causes the strange behaviour. Thanks for taking the time to check and even report the bug!
Even if it never gets fixed at least I know I'm not crazy. Or do I?

Bottom line, to anyone who encounters this issue: beware, if the h6 had an ID, when you hit enter from that line, the ID gets duplicated and the only way to get rid of it is by editing the actual code. Converting the line to p with the tools won't delete the duplicated ID and remaking the TOC will simply change the numbers if it can, potentially leading to bloating.

[parvatiquinta]

Originally Posted by Tex2002ans

Complete Side Note: Like DNSB, I'm wondering what the exact structure of your documents are if you're reaching h6. Anything below subchapters is usually a sign of a poorly structured document.

And if you use them consistently? Now you've piqued my interest.

Not all documents were created equal. This is the second time that someone implies that my use of h6 is "wrong" and, if I may be honest, I find this a little rude.

The epub files that I have in mind when thinking of such deep structure are role-playing game books.
An RPG book, a rules book especially, is not a text meant to be read sequentially; rather, it is a collection of items to reference. These items are grouped into categories, sections, chapters, etc.

Now, the way I like to work, I will put h6 as my "minimal unit that needs to be referenced". I then work my way back, assigning higher h to its parent sections, chapters etc.
Some of the game books I am tinkering with do not actually need six layers of structure, however, even then I'd rather start deep and skip some higher-level h (such as h3) than risk having to restructure later, which would likely introduce errors.

Here is an example of a minimal unit, taken from the most complex of the games that I am currently tinkering with, Dungeons & Dragons (TM), with all its parents:
Title (h1)
Part 1: Character Rules (h2)
Chapter 2: Races (h3)
Dwarf (h4)
Dwarf Traits (h5)
Hill Dwarf Traits (h6)
"Hill Dwarf Traits" is the title of a section containing a number of individual items, the "traits"; however these items do not need to be referenced separately, so they remain p or lists.

In this case we can compare my work to that of others: here is another epub.
You can see that this conversion identifies the same minimal unit as I do in my example, however it skips Title and Part layers and has each chapter as an h1. So their structure from my example would only go down to h4.
I do think the guys who made this version did a terrific job (if only because tweaking their work took me way less time than making my own epub from the official PDF ). Their choice of structure is probably the best to use the file on an ereader; mine allows me to collapse large swathes of TOC when I look for a rule.

It is not just rule books where I find that a deep structure helps.
When I write an RPG adventure, I like to put every single character, location, organisation, or other entity I might refer to as an h6, so that it will go in the TOC with one button press.

An example structure:
Campaign title (h1)
Part 3: Adventures (h2)
Chapter 1: Free Town (h3)
Episode 1: Prison Escape (h4)
Scene 1: We Are In Prison! (h5)
Non-Player Character: the Mysterious Demon (h6)

(in my actual notes the Mysterious Demon has a name, but my players don't know it yet, and even though the chances of any of them happening upon this very topic are a million to one, well, you know what Terry Pratchett had to say about million-to-one chances).

If this was a novel, marking every episode and every scene would be overdoing it - never mind every character or place description. However, this is not a novel, but a role-playing adventure, in which scenes may actually happen at the table in a different order than I had anticipated, or I may need to quickly reference details while in the middle of another scene. So every little h6 helps.

I admit that using h1 for the title of the whole book and having everything else as its child is unnecessary. Call it my quirk.

[DNSB]

Originally Posted by parvatiquinta

Not all documents were created equal. This is the second time that someone implies that my use of h6 is "wrong" and, if I may be honest, I find this a little rude.

My original question was why you needed to use all 6 levels of h tags and you answered my question when you described the type of book you were creating/editing. Nothing about right or wrong, rather simple curiosity as to what you creating that needed that many levels.

Admittedly, I tend to think that little in creating epubs is wrong other than using InDesign or Vellum (the stylesheets from Hades).

[KevinH]

FWIW, the next version of PageEdit will be built with Qt 5.12.6 with our own patch to fix the broken h6 behaviour. Qt itself has still not decided whether to include this fix or not even though it is an obvious bug.

With our own Qt patch in place the strange h6 behaviour is fixed for macOS and Windows users which embed Qt into the PageEdit app itself. Users on Linux will have to build their own Qt if they want to include this patch.