Some perceivable inconsistencies, about whether the embedded worksheets can be viewed.

One of the facts which I did mention in an earlier posting, concern worksheets which I sometimes embedded into my postings as ‘<iframe>s’. In reality, there could be two reasons, why such worksheets fail to display in any one person’s browser:

  1. I could have embedded them, specifying (insecure) URLs that begin with ‘http://’, even though the reader may be visiting my blog, using a (secure) URL that begins with ‘httpS://’. Or,
  2. The posting might suggest that the reader “may need to” enable JavaScript from the domain ‘mathjax.org’, but, in certain cases this is not needed, while in other cases, it is.

‘Problem 1′ above is harder for the reader to fix at their end. It can be solved by fetching my posting using the insecure ‘http://’ URL, or, as I’ve done in a very recent posting, I could decide to embed the ‘<iframe>’ using a URL, which does not specify my domain-name, and just assumes that it’s to be the same, as the domain-name of my site.

‘Problem 2′ above represents a contradiction which may confuse some readers. Sometimes, when I generated an HTML version of a worksheet, I did this by simply clicking on a button, in the GUI of my software. In such cases, the HTML will require that the JavaScript be enabled. But, in certain other cases, all I really did was, to output the worksheet as a LaTeX document, and then to run a custom script on it, to generate other types of documents, one of which would have been an HTML document.

If I ran my custom script on some generic LaTeX document, that generates ‘HTML with equations’, it will do so in the form of ‘a hybrid document’. The resulting document is hybrid, because it can then be viewed in one of two ways:

  1. Using the built-in support for ‘MathML’, that some readers’ browsers have. This is less likely, because I only know of one browser that actually support it: ‘Firefox’. If the reader is using ‘MS Edge’ or the ‘Chrome’ browser to view my posting, I know that they do not support MathML as a built-in feature. But,
  2. Such a hybrid HTML document can also be viewed, by enabling the JavaScript that gets referred to as ‘MathJax’, and which essentially allows other browsers, including ‘MS Edge’ and ‘Chrome’, to view the equations.

I try to accommodate as many possible configurations of the readers’ browsers as I can, but the unfortunate reality is, that merely pressing the GUI button within my application, may generate HTML which is highlighted more nicely, but which is not a hybrid HTML document.

Dirk

 

Just Created a Working Instance of TinyMCE

One of the more-interesting features of JavaScript in years gone by, was the in-browser HTML editor named ‘TinyMCE’. What this scriptlet does, is run on the browser, and allow people to edit the contents of a <textarea>, in WYSIWYG style, for submission to an arbitrary Web-application.

For me, this piece of JavaScript has little use. Other Web-applications of mine, already give me HTML editing which is rich enough, not to depend on TinyMCE. But there has been a facet of this scriptlet, which has irked beginning-users and Web-designers so far, which is that by default, it offers no ‘Save’ Menu-entry. The reason it does not is twofold:

  1. TinyMCE is meant to be integrated into some more-complex Web-page, where its input is also given a defined purpose, and
  2. By itself, this scriptlet just runs on the browser, from where it has no privilege to store its edited contents anywhere, neither on the server, nor on the client-machine running the browser.

And so some people have wondered, how they could exploit this amazing technology, just to save the edited HTML locally, to the hard-drive of the computer running the browser. And there are many possible ways to solve that problem, out of which I’ve just implemented one:

It’s possible to add a ‘Submit’ button, which sends the edited content to the server, which can in turn display it as a Web-page, that the user can save to his hard drive, using the “Save Page As…” Menu-command belonging to his browser. I cannot think of a solution that would be easier. However, if somebody wanted to use this mechanism, then next, he’d also need to open the .HTML-File saved to his hard-drive, and edit out the parts of it, that make it a Web-page, thus editing the saved HTML-File down to just the part that displays between the <body>…</body> tags.

https://dirkmittler.homeip.net/tinymce/plugin/tinymce

Enjoy.

(Update 2018/08/13 : )

Because this example of JavaScript sends the text to my server, which echos it back to the browser, I suppose that in theory I could reprogram my CGI-script, to keep a complete record of all the text-fragments submitted. But in practice, I see no point in doing so, and therefore also keep no record of what has been typed.

In addition, because I’ve suggested the URL as an ‘httpS://’ URL, a Secure Socket Layer gets used, so that No user will need to worry about the communication itself, to and from my server, being monitored by any third party.

Dirk