@pl, @dedlfix: > > > Eine andere Lösung setzt auf HTTP: > > > > Das ist aber eine Lösung für eine hier nicht vorliegende Aufgabenstellung. Es geht darum, gültige HTML-Dokumente zum lokalen Ablegen und späterem Bearbeiten zu erzeugen. Es ist nicht gefragt, lediglich während einer Übertragung etwas hinzuzufügen. Das Szenario war sogar so beschrieben, dass diese Zusatzinformationen für Clientsysteme nicht benötigt werden und beim Übertragen wegfallen können. > > HTTP-Trailer machen HTML nicht invalid. Im Übrigen würde ich in keinem Fall Daten ins DOM/HTML einbauen die dort unmittelbar gar nicht benötigt werden. Vielmehr würde ich das grundsätzlich und immer sauber voneinander trennen über Request-Parameter womit ein anderes View bzw. eine andere Sicht auf die Daten und ggf. ein anderer Content-Type ausgegeben wird (MVC Grundwissen). Ich habe es hier glaube ich schon mal irgendwo geschrieben, aber ich versuche noch mal schnell, den „Fokus“ des Tools zu erklären. Prinzipiell geht es darum, HTML als *statisches* und *abhängigkeitsfreies* Ausgabeformat zu nutzen. Die Begriffe sind nicht so ganz exakt[^einwand], aber man soll das fertige HTML-Dokument letztlich zum Beispiel auf dem eigenen Rechner problemlos mit einem Browser öffnen und betrachten können. Man soll auch die HTML-Datei verschicken oder auf irgendeinen beliebigen Webspace hochladen können, um sie an andere Leute zu verteilen. So ähnlich wie ein Textverarbeitungs- oder ein PDF-Dokument. Der eigentliche Schreibvorgang soll nicht in HTML erfolgen, sondern beispielsweise in Markdown. Ich schreibe also etwa eine Markdown-Datei `hallo.md`: ~~~ # Hallo Welt Dies ist ein Beispiel zum Thread [Arbiträre (Meta-)Daten in ein HTML-Dokument einbetten](https://forum.selfhtml.org/self/2016/nov/12/arbitraere-meta-daten-in-ein-html-dokument-einbetten/1679941#m1679941). ~~~ Das schicke ich durch das Tool… ~~~ $ markup2html hallo.md ~~~ ..., das daraus [diese HTML-Datei](https://jsfiddle.net/t0cr5akr/) generiert.[^sinn] Es soll nun *optional* möglich sein, die Quelldaten (das kann potenziell mehr sein als nur eine Markdown-Datei) mit in das fertige Dokument zu schreiben. Dazu dient derzeit ein JSON-Prolog mit einem einfachen Switch drin. Das ist aber alles noch nicht zwingend finalisiert. `hallo2.md`: ~~~ --- { "includeSource": true } --- # Hallo Welt Dies ist ein Beispiel zum Thread [Arbiträre (Meta-)Daten in ein HTML-Dokument einbetten](https://forum.selfhtml.org/self/2016/nov/12/arbitraere-meta-daten-in-ein-html-dokument-einbetten/1679941#m1679941). ~~~ Das fügt der Ausgabe im `body` aktuell das hier hinzu: ~~~ <script id="markup2html-meta" type="application/json">{"source":"eNo9jT1uAjEQhXufYgQNFLNmESJaOtAWFFAFKUVEYdiBtfAPGo9TJMptcpNcLGuE0r2n9\/MhovqCkQ1nlzt6jZnPNFqBcCb4VjikY9ga5yK8kROlWksJbBIgG2BDNt0tOfjMHg49k+ngfc0nK\/z7wwSTPYnBaWuEAgz9stke9jts4y17Co+XE8kQHye9yD2ttL5Ezr5K5C69eFdFvupi9HxWL3WIH7qea\/NgGGJCXxBdIaANOPxhmWH3JOA\/QdfLl6ZZ1GP\/FNNK\/QGHGFVr"}</script> ~~~ (Base64-kodiertes gzip von `hallo2.md` in einem JSON-Container.) Über den Sinn und Zweck, das direkt ins Dokument zu schreiben, kann man meinetwegen diskutieren. Es ist ein optionales Feature, aber ich denke, dass man durchaus Vorteile benennen kann. Der Aufruf, die Quelldaten zu entpacken, wäre dann halt irgendwie `markup2html unpack hallo2.html` oder so. [^einwand]: Man könnte beispielsweise argumentieren, dass eine mögliche externe Einbindung von JS-Libs wie MathJax oder jQuery eben nicht „abhängigkeitsfrei“ ist. Eigentlich geht es aber nur darum, dass das HTML-Dokument mit jedem Browser von überall her angezeigt werden kann, ohne dass ich auf dem Client oder auf einem möglichen Webspace irgendwelche speziellen Dinge installiert haben muss. „Optimalerweise“ würde ich auch die MathJax- oder jQuery-Quellen mit in das fertige Dokument schreiben, aber das ist einfach überhaupt nicht praktikabel. Zumindest bei MathJax nicht. Das soll hier aber alles eigentlich nicht der Punkt sein. :) [^sinn]: Der Sinn oder Unsinn, so viele JS-Libs standardmäßig einzubinden, obwohl sie nicht annähernd benötigt werden, soll hier auch nicht das Thema sein. Es ist klar, dass das nicht optimal ist, aber das ist ein Problem für später.

@pl, @dedlfix: > > > Eine andere Lösung setzt auf HTTP: > > > > Das ist aber eine Lösung für eine hier nicht vorliegende Aufgabenstellung. Es geht darum, gültige HTML-Dokumente zum lokalen Ablegen und späterem Bearbeiten zu erzeugen. Es ist nicht gefragt, lediglich während einer Übertragung etwas hinzuzufügen. Das Szenario war sogar so beschrieben, dass diese Zusatzinformationen für Clientsysteme nicht benötigt werden und beim Übertragen wegfallen können. > > HTTP-Trailer machen HTML nicht invalid. Im Übrigen würde ich in keinem Fall Daten ins DOM/HTML einbauen die dort unmittelbar gar nicht benötigt werden. Vielmehr würde ich das grundsätzlich und immer sauber voneinander trennen über Request-Parameter womit ein anderes View bzw. eine andere Sicht auf die Daten und ggf. ein anderer Content-Type ausgegeben wird (MVC Grundwissen). Ich habe es hier glaube ich schon mal irgendwo geschrieben, aber ich versuche noch mal schnell, den „Fokus“ des Tools zu erklären. Prinzipiell geht es darum, HTML als *statisches* und *abhängigkeitsfreies* Ausgabeformat zu nutzen. Die Begriffe sind nicht so ganz exakt[^einwand], aber man soll das fertige HTML-Dokument letztlich zum Beispiel auf dem eigenen Rechner problemlos mit einem Browser öffnen und betrachten können. Man soll auch die HTML-Datei verschicken oder auf irgendeinen beliebigen Webspace hochladen können, um sie an andere Leute zu verteilen. So ähnlich wie ein Textverarbeitungs- oder ein PDF-Dokument. Der eigentliche Schreibvorgang soll nicht in HTML erfolgen, sondern beispielsweise in Markdown. Ich schreibe also etwa eine Markdown-Datei `hallo.md`: ~~~ # Hallo Welt Dies ist ein Beispiel zum Thread [Arbiträre (Meta-)Daten in ein HTML-Dokument einbetten](https://forum.selfhtml.org/self/2016/nov/12/arbitraere-meta-daten-in-ein-html-dokument-einbetten/1679941#m1679941). ~~~ Das schicke ich durch das Tool… ~~~ $ markup2html hallo.md ~~~ ..., das daraus [diese HTML-Datei](https://jsfiddle.net/t0cr5akr/) generiert.[^sinn] Es soll nun *optional* möglich sein, die Quelldaten (das kann potenziell mehr sein als nur eine Markdown-Datei) mit in das fertige Dokument zu schreiben. Dazu dient derzeit ein JSON-Prolog mit einem einfachen Switch drin. Das ist aber alles noch nicht zwingend finalisiert. `hallo2.md`: ~~~ --- { "includeSource": true } --- # Hallo Welt Dies ist ein Beispiel zum Thread [Arbiträre (Meta-)Daten in ein HTML-Dokument einbetten](https://forum.selfhtml.org/self/2016/nov/12/arbitraere-meta-daten-in-ein-html-dokument-einbetten/1679941#m1679941). ~~~ Das fügt der Ausgabe im `body` aktuell das hier hinzu: ~~~ <script id="markup2html-meta" type="application/json">{"source":"eNo9jT1uAjEQhXufYgQNFLNmESJaOtAWFFAFKUVEYdiBtfAPGo9TJMptcpNcLGuE0r2n9\/MhovqCkQ1nlzt6jZnPNFqBcCb4VjikY9ga5yK8kROlWksJbBIgG2BDNt0tOfjMHg49k+ngfc0nK\/z7wwSTPYnBaWuEAgz9stke9jts4y17Co+XE8kQHye9yD2ttL5Ezr5K5C69eFdFvupi9HxWL3WIH7qea\/NgGGJCXxBdIaANOPxhmWH3JOA\/QdfLl6ZZ1GP\/FNNK\/QGHGFVr"}</script> ~~~ (Base64-kodiertes gzip von `hallo2.md` in einem JSON-Container.) Über den Sinn und Zweck, das direkt ins Dokument zu schreiben, kann man meinetwegen diskutieren. Es ist ein optionales Feature, aber ich denke, dass man durchaus Vorteile benennen kann. Der Aufruf, die Quelldaten zu entpacken, wäre dann halt irgendwie `markup2html unpack hallo2.html` oder so. [^einwand]: Man könnte beispielsweise argumentieren, dass eine mögliche externe Einbindung von JS-Libs wie MathJax oder jQuery eben nicht „abhängigkeitsfrei“ ist. Eigentlich geht es aber nur darum, dass das HTML-Dokument mit jedem Browser von überall her angezeigt werden kann, ohne dass ich auf dem Client oder auf einem möglichen Webspace irgendwelche speziellen Dinge installiert haben muss. „Optimalerweise“ würde ich auch die MathJax- oder jQuery-Quellen mit in das fertige Dokument schreiben, aber das ist einfach überhaupt nicht praktikabel. Zumindest bei MathJax nicht. Das soll aber hier aber alles eigentlich nicht der Punkt sein. :) [^sinn]: Der Sinn oder Unsinn, so viele JS-Libs standardmäßig einzubinden, obwohl sie nicht annähernd benötigt werden, soll hier auch nicht das Thema sein. Es ist klar, dass das nicht optimal ist, aber das ist ein Problem für später.