Sigil - is there a setting for behaviour after h6?

[parvatiquinta]

I'm suddenly having an issue with Sigil and the h6 header.
I'm using 9.14 with book view, but I tried PageEdit 9.5 (from 9.17 portable) and I'm having the same issue there.
The issue happens both with the file I was working on when I first noticed it, and with new files.

The issue is that unlike all the other headers, if I hit new line at the end of an h6 line, the new line created is not a div (as is the case with all others from h1 to h5) but another h6, and to make matters worse, if the previous h6 has an ID, the new line will inherit the same ID which then can only be removed by manually editing the code.

I'm baffled as I use h6 often and never noticed this behaviour before.

Is there an editable setting somewhere that defines what Sigil is supposed to do when creating a new text line after h6?

[KevinH]

Hit return and use the Heading toolbutton to set the line to p or any other heading.

[parvatiquinta]

Thank you for the reply, but that was not what I was looking for. (I also kind of knew that much, and I also know how to fix the ID proliferation. I am here looking for ways to prevent it in the first place.)

Is that working as intended then? That h6 behaves differently from all other h's?

[DNSB]

You are likely to be running into one of the reasons that BookView was dropped and Page Edit is not my choice for editing -- the code generated can have some rather odd glitches. CodeView and a preview pane are a better choice, IMNSHO.

I am wondering how you made it down to using the h6 tag. The furthest I've managed was one anthology where I ended up with h5 tags (h1 was for books in the anthology, h2 was for parts within the books, h3 was for chapters, h4 was for sub-chapters and h5 was for sections within the subchapters). The author was unhappy with the ToC in nav.xhtml being so many pages but life is tough. This was also the only ebook I've done cleanup on where the footnotes took up more space than the text. The original books were vanity published westerns and he had dreams of hitting it big as an indie.

[KevinH]

I checked the format block javascript code, and h6 is handled exactly the same way as h1-h5, so any differences are internal to QWebEngine and are a quirk of editing in BookView/PageEdit.

There may be some way to clear the internal state but ... it is not obvious.

[parvatiquinta]

I have tried the new version of Sigil now and it's not for me. I know that Book View isn't perfect, but it's like an old shoe, it fits well so I want to keep it despite a hole or two.

Then again when I replicated the issue in Page Edit I started to think that it might be my computer, but then I tried firing Sigil on the laptop (v 0.9.10 portable) and I replicated the issue there too. And yet I am baffled that I didn't notice this happening before since I do use h6 a lot.
Shame there is no long-term solution! Oh well, what's one more regex to the fixit list.

As for how I manage to get down to h6, partly it's because I'm dealing mostly with gaming material which is a bit more technical than your average text and partly it's because I have come up with a CSS that I like the look of and I keep pasting in that one. So if I do have a shallower structure I would rather skip h3 and h5 than change the CSS; you never know what you're going to add later. Also, in my files, h1 is for the title and nothing else ever.

(no, I don't really keep wearing shoes with holes. )

[Tex2002ans]

Originally Posted by parvatiquinta

And yet I am baffled that I didn't notice this happening before since I do use h6 a lot.

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.

[KevinH]

I may be able to work around it but that will take some experimentation. I am travelling now but will look to see if there is any way to force a p state after every h6 when I get back. The issue is we are not making more Sigil 0.9.14 style releases so any workaround would just be for a future PageEdit release.

Originally Posted by parvatiquinta

I have tried the new version of Sigil now and it's not for me. I know that Book View isn't perfect, but it's like an old shoe, it fits well so I want to keep it despite a hole or two.

Then again when I replicated the issue in Page Edit I started to think that it might be my computer, but then I tried firing Sigil on the laptop (v 0.9.10 portable) and I replicated the issue there too. And yet I am baffled that I didn't notice this happening before since I do use h6 a lot.
Shame there is no long-term solution! Oh well, what's one more regex to the fixit list.

As for how I manage to get down to h6, partly it's because I'm dealing mostly with gaming material which is a bit more technical than your average text and partly it's because I have come up with a CSS that I like the look of and I keep pasting in that one. So if I do have a shallower structure I would rather skip h3 and h5 than change the CSS; you never know what you're going to add later. Also, in my files, h1 is for the title and nothing else ever.

(no, I don't really keep wearing shoes with holes. )

[Tex2002ans]

Originally Posted by KevinH

I may be able to work around it but that will take some experimentation. I am travelling now but will look to see if there is any way to force a p state after every h6 when I get back.

I attached a test EPUB:

  <h1 id="Test1">Heading 1</h1>
  <h2 id="Test2">Heading 2</h2>
  <h3 id="Test3">Heading 3</h3>
  <h4 id="Test4">Heading 4</h4>
  <h5 id="Test5">Heading 5</h5>
  <h6 id="Test6">Heading 6</h6>

(I tested this in Sigil 0.9.14, Book View. Not sure about PageEdit + latest.)

It's as parvatiquinta says.

1. If you place the cursor after "Heading 1-5" and press Enter:

<h1 id="Test1">Heading 1</h1>
<div><br/></div>

(Should <div> be changed to <p>? This is similar to how Word/LibreOffice/GoogleDocs works.)

2. If you place cursor after "Heading 6" and press Enter:

<h6 id="Test6">Heading 6</h6>
<h6 id="Test6"><br/></h6>

it creates an <h6>, and also carries over the id="Test6".

Both get the same exact id. Not sure if that should be intended... same id is invalid... but not sure on what the best solution should be.

3. If you place a cursor between heading text + press Enter:

<h1 id="Test1">Head</h1>
<h1 id="Test1">&nbsp;ing 1</h1>

Should the extra &nbsp; be added?

* * *

Should Case 2 create a <p><br/></p> and Case 3 create a <h1 id="Test1Unique">?

[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).

PageEdit is not going to be completely immune to the "we don't like the html that it generates in wysiwyg editing mode" issues that factored in to our decision to remove wysiwyg editing from Sigil. We have a hard time fixing that which we're not actually doing.

[KevinH]

Yes, to see that simply fire up a Google Chrome browser and use the Inspector/Developer Tools to enable contenteditable and try the same thing. How chrome decides to modify the internal DOM tree when editing is done is simply not up to us.

And yes, this is why we removed BookView and promote PageEdit more for proofing and minor edits.

[Vroni]

Originally Posted by parvatiquinta

Ibut it's like an old shoe, it fits well

If you think a shoe fits now well he is worn out and will soon start to muffle

[KevinH]

Okay, I have run some tests and yes h6 is handled internally differently than any other heading, and in fact how it is handled is *against* the recommended spec for editing found here:

https://w3c.github.io/editing/execCo...raph-command-0

Which clearly states:

If the local name of the container is "h1", "h2", "h3", "h4", "h5", or "h6" and end-of-line is true, let the new container name be the default single-line container name.

which in this case is either a "p" or a "div".

Both Webkit and WebEngine (Chrome) ignore this for "h6" only and in fact clone the h6 node and add it as a sibling so that the heading itself is continued. So there is no way to use "enter" to break out of an "h6".

In addition, as there is no way for PageEdit to detect this case (know if it is at the end of the line with h6 and that you hit enter at that point) so there will be no "fix".

That said, instead of putting the cursor at the end of the h6 line before hitting enter, you can of course put your cursor at the beginning of the following line and hit enter achieving what you want.

Of course, you can also use the PageEdit's interface including the Inspector's right click menu to delete and fix the html5 code directly.

Or highlight the new line and use the heading tool to change it to a normal paragraph as well.

And hopefully using h6 happens so rarely naturally that this whole issue will generally not come up much.

On a side note, I was able to change the defaultParagraphSeparator for the next version of PageEdit to use "p" instead of "div" since that makes more sense in ebooks.

[Tex2002ans]

Originally Posted by KevinH

Okay, I have run some tests and yes h6 is handled internally differently than any other heading, and in fact how it is handled is *against* the recommended spec for editing found here:

https://w3c.github.io/editing/execCo...raph-command-0

Interesting. Never knew that existed. Thanks for the link.

Originally Posted by KevinH

On a side note, I was able to change the defaultParagraphSeparator for the next version of PageEdit to use "p" instead of "div" since that makes more sense in ebooks.

[KevinH]

Just for the record, the bug in qtwebengine is here:

qtwebengine/src/3rdparty/chromium/third_party/blink/renderer/core/editing/commands/insert_paragraph_separator_command.cc

In these specific routines which leaves out "h6" in two key places:

void InsertParagraphSeparatorCommand::ApplyStyleAfterInsertion(
    Element* original_enclosing_block,
    EditingState* editing_state) {
  // Not only do we break out of header tags, but we also do not preserve the
  // typing style, in order to match other browsers.
  if (original_enclosing_block->HasTagName(h1Tag) ||
      original_enclosing_block->HasTagName(h2Tag) ||
      original_enclosing_block->HasTagName(h3Tag) ||
      original_enclosing_block->HasTagName(h4Tag) ||
      original_enclosing_block->HasTagName(h5Tag)) {
    return;
  }

...

bool InsertParagraphSeparatorCommand::ShouldUseDefaultParagraphElement(
    Element* enclosing_block) const {
  DCHECK(!GetDocument().NeedsLayoutTreeUpdate());

  if (must_use_default_paragraph_element_)
    return true;

  // Assumes that if there was a range selection, it was already deleted.
  if (!IsEndOfBlock(EndingVisibleSelection().VisibleStart()))
    return false;

  return enclosing_block->HasTagName(h1Tag) ||
         enclosing_block->HasTagName(h2Tag) ||
         enclosing_block->HasTagName(h3Tag) ||
         enclosing_block->HasTagName(h4Tag) ||
         enclosing_block->HasTagName(h5Tag);
}

So this is clearly a bug and the fix would be quite easy to make but getting anyone at Apple or Google to actually fix this code to include h6 as it is obviously a heading element would be next to impossible.

Sad really....

If anyone knows someone on the Webkit or Blink teams ....


ps: found by grepping the blink editing code for files with h1-h5 without h6. This is the only place that occurs.