Harry - Currently, the Content View in version 2.9Plus does not allow local, self-contained CSS stylesheets and therefore user-defined styling does not work offline.

In version 3.0, the new Custom View does support self-contained CSS style sheets in custom JavaScript visualizations that will work offline.

Depending on your timeframe, you could use the Custom View in version 3.0 …

We will probably preserve the Content View as well as the Custom View in version 3.0, but whether we can back-port support for local CSS stylesheets into the version 2.9Plus Content View requires some study….

The difference between behavior in the Web and Content view scenarios is down to standard rules of web browsers, which are outside of everyone's control..

In Omniscope 2.9, we use a Chromium (aka Chrome) embedded (native) browser for both views. (Anyone installing the free Viewer therefore also has this embedded modern browser to supplement their default browser, which may not be modern, and therefore is not used for any browser rendering defined inside the IOK file).

When you have a native browser Content view, you copy paste the HTML file into Omniscope. Then the (hidden) web address for the embedded browser is generated internally by Omniscope and is http://client_ip_address/..., since Omniscope runs its own little web server internally for this purpose. We don't reference the file on disk, the IOK is now standalone.

When you have a Web view, even inside the same IOK file in this case the file IS still referenced, so the main page for the embedded browser has a file:// URL in the the address bar.

If you have a page whose main address is http://... then that page cannot reference file:// resources such as CSS, JS, images.

ONLY if the main page address is file:// can you access file:// resources. This is an obvious security restriction of browsers in general; you can't be visiting web sites that reach out to the client's hard disk.

3.0's custom views entirely solve this since you are effectively creating a webserver folder into which you can upload arbitrary resources.

The solution in 2.9 / 2.9+ is to either require the file to be online and have remote http resources, OR to embed everything inline inside the main page HTML. This should be entirely possible (though perhaps tedious) by converting all LINK and SCRIPT remote tags to be STYLE and SCRIPT inline tags, but will only fail if some JS libraries themselves trigger dynamic loading of remote JS (unlikely).

Hi Thomas, that is much clearer now, thank you.

I am now having an issue when trying to publish the content view to our demo web server. Although all the links in it are now http://.. and the viewer works as an .iok, on the web server it does not appear to be able to download the stylesheets.

Could you shed some light as to why this might be happening? Is it likely to be a server problem our end?

Are you mixing http and https? This isn't allowed by browsers if the main page is https.
To be sure use the Chrome dev console and look at the network tab, you'll see precisely which HTTP requests for CSS etc. are failing and why.

You are exactly right, Steve, thank you. I am a bit of a novice when it comes to this.

Trying to find a solution now.

See continuation of this thread here:

http://forums.visokio.com/discussion/2991/content-view-access-to-css-stylesheets-from-https-server-v2.9s