[Mister L]

Originally Posted by Doitsu

As a stop-gap, I created a quick & dirty BeautifulSoup-based plugin that adds title attributes to h1..h6 entries. (It doesn't check the TOC and it doesn't merge successive h1..h6 entries.)

Thank you Doitsu, I will try it out.

Originally Posted by DiapDealer

I'm not interested. There's just too many finicky bits to overcome when going ncx/nav to html (as opposed to going html to ncx/nav).

No worries, I'm grateful to have Sigil already. Those are all really good questions so I'll try to answer them the way *I* think is logical, in case anyone does want to try their hand at this.


1. Mainly the situation where the h tag doesn't exist and needs to be created. What level does it get created as (3,4,5,6)?
=> Keep it simple: all toc entries are created as h1 and any modification of levels, if necessary, can be done by hand later on. This seems like a completely reasonable solution to me especially since most situations where the h tag doesn't exist would be "top level" pages anyway rather than subsections, and the level of the h is much less important than the text of the title.

Edit 3: if you are a coding psychopath who enjoys pain you could match h levels to ol levels of the toc. But that would definitely not be *necessary* for the plugin to be useful.

Edit 4(?): Or leave that choice to the user as well, and in that case you could even propose that the title would be inserted in an html comment rather than a tag; then you are safe from any conflict with existing the code but the title text is still available in the file to be added via regex to whatever is appropriate.


2. Where in the html will it go (outside/inside an adjacent div/span)? Can't put it at the top because not all chapters begin with a brand-new file.
=> I would say put it exactly where the link sends it: above (outside) the element containing the toc id if there is one, or at the top of the html file if there isn't an id. I don't expect this to be the end of the process, just a way to easily take care of several annoying and very time-consuming intermediary steps.

3. Does it need a class name for styling purposes (display: none)?
=> Maybe an option to choose between naked h1 and <h1 style="display:none;">, or adding a class chosen by the user. Adding styles seems way beyond the scope of this plugin. Alternatively it could use a style like the split markers use, "sigil_toc_marker" or something; that is very unlikely to clash with local styles.

4. If so, will I have to parse all css classnames (after determining which external css files are linked) to determine I'm not reusing an existing class? I'd also need to check any css that might be included in the header of the html file to be sure. Otherwise, I'd have to resort to using uuids for class names (after making sure they start with a valid character). And in my opinion, that gets uglier than the issue said plugin is trying to fix--only very occasionally.
=> Definitely not. Any styles should be handled by the person making the book, either via an option in the plugin or afterwards.

Originally Posted by Doitsu

Breakage is not an option if I'm to create a plugin. And unfortunately, there's too much that can go wrong when attempting to reverse the automatic toc generation process. Especially if doing so requires generating html that doesn't exist. There's waaay to much to account for (properly) for all the more it would be used.

Someone's free to use all of the problem areas I mentioned to work on it if they like, though.

Understood. As I'm not a dev I realise I may not be fully understanding how complicated this could be... I do think sticking to the absolute simplest solutions would limit the possibilities for breakage though. Thanks for the discussion points anyway, they are helpful.



Edit: Doitsu, I tried to give you karma for the plugin, but it says I must "spread it around" first, so instead I'll just repeat publicly my gratitude.


Edit 2:

Originally Posted by Mister L

It's funny, I find that most often, no matter how abominable the xhtml code is, the ncx / toc is usually okay. Weird eh? I do wish I could magically overwrite all the html and css with my own clean, beautiful code though.

Also, thinking about this, it actually makes sense to me. The TOC is visible to the publisher, and so they check it and will complain if there is a problem. Whereas most of them have no idea what good code is, never mind semantic anything, and wouldn't know how to look at it at all or what to look for, so they never say anything about that unless it's so bad it actually breaks somehow.