Sigil TOC breaks internal links

[LarsEighner]

I could be wrong, but appears to me that when Sigil generates a TOC it 1) changes all existing ids to classes and 2) substitutes its own id, without adjusting existing internal links.

This breaks all internal links. I find it hard to call this anything other than a bug.


In addition there is a remote the risk that the class will coincide with a class that is already being used for something else in the stylesheet, so the element will appear with a style that is not intended.

[theducks]

Originally Posted by LarsEighner

I could be wrong, but appears to me that when Sigil generates a TOC it 1) changes all existing ids to classes and 2) substitutes its own id, without adjusting existing internal links.

This breaks all internal links. I find it hard to call this anything other than a bug.


In addition there is a remote the risk that the class will coincide with a class that is already being used for something else in the stylesheet, so the element will appear with a style that is not intended.

Not true on many levels unless you go out of your way to cause the clash in selectors.


Sigil selectors have:
1) SGC in their name
2) Toc Selectors (sigil 6+) have a separate SGC_TOC stylesheet that only links to the HTML TOC. The selectors are sigil_toc_id_N


Generating a TOC (NCX) leaves id='s as they were and only assigns new (Sigil) ones if they were missing. The before and after of generating both TOC

 <h2 class="calibre5"><span class="ts"><a href="../Text/inline_toc40.xhtml#13">Chapter 3</a></span></h2>

There is 1 case I have found that does cause (always has) if you split off a file with one:
<h2 class="calibre5"><span class="ts"><a href="../Text/#13">Chapter 3</a></span></h2>

Relative references after a split will leave orphans in all other locations.

This could be avoided by 'precleaning' the files to change all relative references to absolute references (insert the full file name)

This is not an issue if that form is not ever used