Feature requested for Sigil 1.7
 

Sigil has a dialog to link/unlink stylesheets to .xhtml files. Would it be possible for you, Kevin and Diap, to add a dialog (to the next version of Sigil) with a similar function to link/unlink .js files?

Many thanks for your consideration.
Rubén

Wow. Link/Unlink .js files would be absolutely great...

adeg

The issue is so few epub3 readers support javascript (support for scripting is not a requirement for epub3 compliance), and even fewer epub3 epubs use it, especially commercial ones. So I doubt there is truly much of a need.

Why don't up you instead use a Find/Replace Saved Search to remove your standard js insertions and a create a Clip specific to each to insert them easily. That way insertion and removal can become quite fast.

Upon further consideration, I will add this to my future "To-Do" list but it will not be for Sigil-1.7.0 as that release will primarily be a bug fix release with a restricted new feature set.

Thank you very much Kevin! Yes, no matter when you are going to include this feature; for me is enough to know that in a future version Sigil will be able to link/unlink .js files. Thanks again. :thanks:

Thinking about this, it would need to be more complex than linking in stylesheets.

It would only operate on script tags in head that have type text/javascript with a src attribute with a relative link.

It would *not* operate on:
- script tags in the body
- script tags that do not have javascript media types
- script tags that do not have src attributes.

And we would still have to figure out how to deal with "defer", "async" and origin attributes of the script tag which complicates things even more.

So if I do implement this, it would only work on a very restricted subset of vanilla cases.

Yes, the javascript world is huge. But if your implementation can write/erase in the SELECTED .xhtml files something like this:

is ok to me. When the tags are written then the .js will be linked and when the tags are cleared, then the .js files will be unlinked.

With the additional restriction that the script tag is a child of the head tag.

Of course :)

Okay, this was a bit more invasive than I thought. It took creating dialogs, support code, forms, the ability to identify resources that are javascripts, modifying the gumbo interface, etc.

Preliminary (only lightly tested) support for linking javascripts via the BookBrowser (ala Link Stylesheets) is now part of master and unless it causes problems, will be part of the next release of Sigil.

Thank you very much Kevin for your hard work! :thanks:

Would it be too much asking that after linking (unlinking) a .js file Sigil runs by itself the command Epub3 Tools > Update Manifest Properties?

Many thanks for your consideration.

As script tags do exist outside of head and inline scripts are possible in both head and body, linking and unlinking javascripts can not account for these, so there really is no way to just add or remove script manifest properties without parsing the entire xhtml file. And it would have to do that for each and every xhtml file.

Normally, a user should run that update manifest properties tool only once as the very last thing before the final save or epubcheck when editing an epub3. To do so earlier really does not accomplish anything as nothing in Sigil itself requires those properties to actually function.

Running it multiple times seems to be a waste.

What is the use case that requires it immediately after linking or unlinking javascript files and not just once before the final save as is needed/expected now? It is not required for Preview to run any javascripts.

We don't run the update Manifest Properties tool (or any other tool with the exception of the minimum Mend necessary) automatically for other reasons. Those tools exist in the state they do because there is little point in running them repeatedly and/or automatically.

Because many times I forget to add/remove the property "scripted" for items in the content.opf file and I realize of that after running epubcheck. Yes, it's not required for anything but to pass epubcheck.

In this case, not so automatically and not so repeatedly, only when a js file were added and linked (unlinked) because the property "scripted" must be added (or removed) to the respective item in content.opf. How much time can waste Sigil running that command? One second, two perhaps? :) And that ONLY when a .js file is added (or removed). Of that way, the linking (unlinking) process will be completed because the property "scripted" will have been written (deleted) also in content.opf.

Adding any svg or adding an link to an external resource, adding an inline script even moving code via copy and paste may require updating manifest properties but there is no way for Sigil to determine that since they were introduced by text editing.

So if you are editing epub3s, there really is a good reason to use the Update Manifest Properties tool last, right before running epubcheck and doing the final save. Having link javascript do it is no guarantee is has been done properly until after all text editing is done.

Sorry but this is not a good idea as it may lead the user into thinking their manifest properties are correct when they are actually not.

As I explained you can not remove the script manifest property just because you unlinked a javascript. There can still be mathml scripts, inline javascripts in head, and links to external javascripts inside the body.

It is important for epub3 devs to get into the habit of running it once before the final run of epubcheck and final save as it could be needed due to other text edits/changes.

All that said ... the actual change in Sigil's code to do this is quite easy to do.

It is basically a one line change in MainWindow.cpp in the routine to link/unlink javascripts to call the opf's UpdateManifestProperties routine with the list of impacted resources.

I would be happy to post a diff with that small change if you do build your own.

No problem Kevin :) I just wanted to be free from the worry of updating the .opf file. But as you say, it just a couple of mouse clicks or a key shortcut.

Okay, I see that in other places in the Sigil source code I already call:

on a limited set of resources.

So I was being a big hypocrite saying "we should not" when we already do in two other places in the source code. I had forgotten about them. And I hate being a hypocrite.

So I have decided to run UpdateManifestProperties on just the resources touched by linking of the javascripts in that routine.

**BUT** [climbs back on to my soapbox!]
I still think it is really really important to run UpdateManifestProperties on *all* xhtml resources as one of the final steps since just text editing can create the need for it and there is no way for Sigil to easily tell if it is needed.

Of course Kevin and thanks a lot, thanks a lot! :thanks:

Seeing Flightcrew in this list: I've often encountering errors from flightcrew coming from non-sigil-structured ebboks where FC has problems of finding the file. Its present, but i guess FC has some hardcoded paths where it assumes the files but the structure of the ebook does not contain the folder FC is trying to look at. Restructering the epug to Sigils default structure resolves those error.

I will try to create a sample. Or is FC more or less dead and will not be maintained any more?

More likely FC is detecting an incorrect case in a path that just seems to work due to testing on case insensitive file system. If you have a testcase that shows the error with FC please post it.