Chart jsons not loaded when opening the html file in broswser directly, because ajax calls to local files are not allowed

[nvn-nil]

Expected
Opening an html file in browser loads the charts and displays correctly

What happens
Opening an html in a browser (right click > open with > chrome, for eg.) does not load the chart jsons.

Reason
Chrome (and Edge, haven't tested other) doesn't allow ajax calls to be made to local files.

Workarounds
To get the setup to work, launch Chrome with the flag --allow-file-access-from-files.

Possible solution

• Embed the json data directly in the html (if its small)
• Embed data in a script file and load the file with 'defer' or 'async'
• Use the script tag data import work around (if its large)

[thclark]

Embedding the chart data right into the HTML, or affecting the Time To First Contentful Render, may heavily penalise such documents in web search results, as well as make things very difficult for users in remote locations.

As you say, it might be possible to get around this with the embed in another script file loaded with the defer parameter, instead of in JSON files, so that would be the approach to choose if we did address this.

Use case

Downloading PDFs is usually favoured over downloading HTML (from a user experience perspective, downloading HTML really sucks) so I'd consider #21 to be much higher priority than this from the perspective of providing downloadable outputs to the end user.

So if it's not an end user use case, what is the actual use case here? Webarchiving is the only thing I can think of, but if you're running a webarchive and not able to use a light HTML server there's something wrong!

My perspective

This significantly violates some element of the FAIR data principle, because presently the chart data is written into its own JSON, and available on the web by any client. So the charts and their underlying data can be directly accessed and re-rendered elsewhere with their data. Embedding them in scripts would somewhat violate this, in that they'd need a highly customised web scraping tool to make them Interoperable and Reusable.

I also think that sphinx docs are primarily served anyway, whether from a bucket somewhere or on readthedocs itself.... but this perhaps could be disproven.

Accepting a PR

I think I'd accept a PR that implemented this as an option which was turned off by default. But, I probably won't work on this myself unless a clearer use case comes up.

[nvn-nil]

At the time I was working on a single-page HTML generator plugin for sphynx to make the docs self-contained. You don't need a server when it's only the HTML file (no server HTML was the final result) but I couldn't get the plots to work with it so this issue.

I too think generating pdfs is the better solution (fine with closing this in favor of #21) but single page HTMLs preserve the navigations and page structure better.