Feature requested for Sigil 1.7

[RbnJrg]

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

[arakish]

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

adeg

[KevinH]

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.

[KevinH]

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.

[RbnJrg]

Originally Posted by KevinH

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.

[KevinH]

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.

[RbnJrg]

Originally Posted by KevinH

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:

<script src="../Misc/The_script_file.js" type="text/javascript"></script>

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.

[KevinH]

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

[RbnJrg]

Originally Posted by KevinH

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

Of course

[KevinH]

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.

[RbnJrg]

Originally Posted by KevinH

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!

[RbnJrg]

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.

[KevinH]

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.

[DiapDealer]

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.

[RbnJrg]

Originally Posted by KevinH

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.

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.