> Hm, dieselben Daten doppelt? Du hast eine Spezialanwendung und Dateigröße spielt keine Rolle? Ich bastele für einen HTML-Generator an dem optionalen Feature, die Quelldatei(en) mit in das generierte HTML zu schreiben, um sie nicht getrennt vorhalten zu müssen. So ähnlich wie bei Office-Dokumenten, wenn man so will. Möchte man das HTML-Dokument bearbeiten, „entpackt“ man es, modifiziert die Quelldateien und packt es danach wieder zusammen. Ich experimentiere mit derlei Dingen seit einiger Zeit, weil die klassischen, „DIN-A4“-basierten Schreibanwendungen und Formate für das Web nicht optimal sind und weil ich es auch nicht für sinnvoll halte, dass jeder, der ein etwas komplexeres Dokument auf eigenem Space online stellen möchte, dafür erst mal haufenweise HTML- und Serverkram lernen muss. Etwas überspitzt gesagt. Ich hätte gewissermaßen gern eine HTML-basierte „Alternative“ zu Word/Writer (wobei ich da das Format meine, nicht den WYSIWYG-Editor) oder PDF, bei der ich die Dokumente in etwa Markdown schreiben kann und bei der ich dabei nicht für jedes Dokument zwingend ein Verzeichnis mit zig Dateien an Quelldaten vorhalten muss. (Etwa dann, wenn das Dokument Bilder enthält.) Dateigröße ist dabei nicht primär von Bedeutung. > Oder magst du vielleicht nur den Markdown-Text (in einem HTML-Grundgerüst) übertragen und das HTML daraus clientseitig generieren? Erfordert natürlich JavaScript. Das wäre möglich, aber hat, wie du sagst, unter anderem den Nachteil, zwingend JavaScript zu benötigen. Das ist erst mal zu kompliziert. Außerdem ist Markdown auch nicht das einzige denkbare Eingabeformat, und die Generierung der fertigen HTML-Ausgabe könnte theoretisch aufwändiger sein, als nur Markdown zu rendern. Es wäre nicht effizient, das von jedem Client erledigen zu lassen, statt es einmal zentral zu machen. > > Ich nutze derzeit `<meta itemprop="markup2html-source" content="<base64-string>">`. > > Microdata ist für Metadaten da. Und Microdata ist pfui! RDFa ist für Metadaten da. Pfui, aha. ;) Ich habe aber nichts gegen RDF(a). Bei der Variante kann ich es `itemscope`/`itemprop` im Zweifel gern vorziehen. Es hat halt den Anschein, dass mehrere Weg nach Rom (Dublin?) führen. > > Denkbar wäre beispielsweise auch noch so was: > > > > ~~~ > > <script type="application/json" id="markup2html"> > > { > > "source": "<base64-string>" > > } > > </script> > > ~~~ > > Ja, `script` ist wohl das, was du suchst. Aber warum JSON und Base64? > > Willst du nicht einfach den Markdown-Quelltext reinschreiben: > > ~~~ > <script type="text/markdown"> > [...] > </script> > ~~~ Ich war mir einerseits nicht sicher, dass das möglich ist. Das ist nicht das, was ich spontan mit der Semantik von einem Element namens `script` verbinde. Mir geht es andererseits darum, beliebige Daten einzubetten. Markdown war nur mein Beispiel. Ich suche eine allgemeine Lösung, die etwa auch für Bilddaten möglich ist (`<script type="image/jpeg">`?). Sorry, das hätte ich deutlicher erklären können. JSON hat zudem den Vorteil, eine Struktur abbilden zu können. Das ist meines Erachtens recht sinnvoll, sobald ich mehr als eine Datei ablegen möchte und weil ich wahrscheinlich Metadaten (Dateiname, …) brauche. gzip wegen Dateigröße. Die ist zwar sekundär, aber wenn man problemlos sparen kann, kann man das ja trotzdem tun. Base64 müsste wahrscheinlich wirklich nicht zwingend sein, aber ich habe es andererseits auch noch nie wirklich gesehen, dass binary blobs in HTML-Quellcode stehen. Ich habe zugegebenermaßen nie darüber nachgedacht, warum das so ist. (Dass man da mehr Escaping braucht, ist geschenkt.) PS: Dieser Forenpost (ohne das PS ;)) sieht aktuell durch mein Tool generiert so aus: <http://tmp.ermshaus.org/forenpost.html> (Quellcode nach proof-of-concept-Methode enthalten.)

> Hm, dieselben Daten doppelt? Du hast eine Spezialanwendung und Dateigröße spielt keine Rolle? Ich bastele für einen HTML-Generator an dem optionalen Feature, die Quelldatei(en) mit in das generierte HTML zu schreiben, um sie nicht getrennt vorhalten zu müssen. So ähnlich wie bei Office-Dokumenten, wenn man so will. Möchte man das HTML-Dokument bearbeiten, „entpackt“ man es, modifiziert die Quelldateien und packt es danach wieder zusammen. Ich experimentiere mit derlei Dingen seit einiger Zeit, weil die klassischen, „DIN-A4“-basierten Schreibanwendungen und Formate für das Web nicht optimal sind und weil ich es auch nicht für sinnvoll halte, dass jeder, der ein etwas komplexeres Dokument auf eigenem Space online stellen möchte, dafür erst mal haufenweise HTML- und Serverkram lernen muss. Etwas überspitzt gesagt. Ich hätte gewissermaßen gern eine HTML-basierte „Alternative“ zu Word/Writer (wobei ich da das Format meine, nicht den WYSIWYG-Editor) oder PDF, bei der ich die Dokumente in etwa Markdown schreiben kann und bei der ich dabei nicht für jedes Dokument zwingend ein Verzeichnis mit zig Dateien an Quelldaten vorhalten muss. (Etwa dann, wenn das Dokument Bilder enthält.) Dateigröße ist dabei nicht primär von Bedeutung. > Oder magst du vielleicht nur den Markdown-Text (in einem HTML-Grundgerüst) übertragen und das HTML daraus clientseitig generieren? Erfordert natürlich JavaScript. Das wäre möglich, aber hat, wie du sagst, unter anderem den Nachteil, zwingend JavaScript zu benötigen. Das ist erst mal zu kompliziert. Außerdem ist Markdown auch nicht das einzige denkbare Eingabeformat, und die Generierung der fertigen HTML-Ausgabe könnte theoretisch aufwändiger sein, als nur Markdown zu rendern. Es wäre nicht effizient, das von jedem Client erledigen zu lassen, statt es einmal zentral zu machen. > > Ich nutze derzeit `<meta itemprop="markup2html-source" content="<base64-string>">`. > > Microdata ist für Metadaten da. Und Microdata ist pfui! RDFa ist für Metadaten da. Pfui, aha. ;) Ich habe aber nichts gegen RDF(a). Bei der Variante kann ich es `itemscope`/`itemprop` im Zweifel gern vorziehen. Es hat halt den Anschein, dass mehrere Weg nach Rom (Dublin?) führen. > > Denkbar wäre beispielsweise auch noch so was: > > > > ~~~ > > <script type="application/json" id="markup2html"> > > { > > "source": "<base64-string>" > > } > > </script> > > ~~~ > > Ja, `script` ist wohl das, was du suchst. Aber warum JSON und Base64? > > Willst du nicht einfach den Markdown-Quelltext reinschreiben: > > ~~~ > <script type="text/markdown"> > [...] > </script> > ~~~ Ich war mir einerseits nicht sicher, dass das möglich ist. Das ist nicht das, was ich spontan mit der Semantik von einem Element namens `script` verbinde. Mir geht es andererseits darum, beliebige Daten einzubetten. Markdown war nur mein Beispiel. Ich suche eine allgemeine Lösung, die etwa auch für Bilddaten möglich ist (`<script type="image/jpeg">`?). Sorry, das hätte ich deutlicher erklären können. JSON hat zudem den Vorteil, eine Struktur abbilden zu können. Das ist meines Erachtens recht sinnvoll, sobald ich mehr als eine Datei ablegen möchte und weil ich wahrscheinlich Metadaten (Dateiname, …) brauche. gzip wegen Dateigröße. Die ist zwar sekundär, aber wenn man problemlos sparen kann, kann man das ja trotzdem tun. Base64 müsste wahrscheinlich wirklich nicht zwingend sein, aber ich habe es andererseits auch noch nie wirklich gesehen, dass binary blobs in HTML-Quellcode stehen. Ich habe zugegebenermaßen nie darüber nachgedacht, warum das so ist. (Dass man da mehr Escaping braucht, ist geschenkt.)

> Hm, dieselben Daten doppelt? Du hast eine Spezialanwendung und Dateigröße spielt keine Rolle? Ich bastele für einen HTML-Generator an dem optionalen Feature, die Quelldatei(en) mit in das generierte HTML zu schreiben, um sie nicht getrennt vorhalten zu müssen. So ähnlich wie bei Office-Dokumenten, wenn man so will. Möchte man das HTML-Dokument bearbeiten, „entpackt“ man es, modifiziert die Quelldateien und packt es danach wieder zusammen. Ich experimentiere mit derlei Dingen seit einiger Zeit, weil die klassischen, „DIN-A4“-basierten Schreibanwendungen und Formate für das Web nicht optimal sind und weil ich es auch nicht für sinnvoll halte, dass jeder, der ein etwas komplexeres Dokument auf eigenem Space online stellen möchte, dafür erst mal haufenweise HTML- und Serverkram lernen muss. Etwas überspitzt gesagt. Ich hätte gewissermaßen gern eine HTML-basierte „Alternative“ zu Word/Writer (wobei ich da das Format meine, nicht den WYSIWYG-Editor) oder PDF, bei der ich die Dokumente in etwa Markdown schreiben kann und bei der ich dabei nicht für jedes Dokument zwingend ein Verzeichnis mit zig Dateien an Quelldaten vorhalten muss. (Etwa dann, wenn das Dokument Bilder enthält.) Dateigröße ist dabei nicht primär von Bedeutung. > Oder magst du vielleicht nur den Markdown-Text (in einem HTML-Grundgerüst) übertragen und das HTML daraus clientseitig generieren? Erfordert natürlich JavaScript. Das wäre möglich, aber hat, wie du sagst, unter anderem den Nachteil, zwingend JavaScript zu benötigen. Das ist erst mal zu kompliziert. Außerdem ist Markdown auch nicht das einzige denkbare Eingabeformat, und die Generierung der fertigen HTML-Ausgabe könnte theoretisch aufwändiger sein, als nur Markdown zu rendern. Es wäre nicht effizient, das von jedem Client erledigen zu lassen, statt es einmal zentral zu machen. > > Ich nutze derzeit `<meta itemprop="markup2html-source" content="<base64-string>">`. > > Microdata ist für Metadaten da. Und Microdata ist pfui! RDFa ist für Metadaten da. Pfui, aha. ;) Ich habe aber nichts gegen RDF(a). Bei der Variante kann ich es `itemscope`/`itemprop` im Zweifel gern vorziehen. Es hat halt den Anschein, dass mehrere Weg nach Rom (Dublin?) führen. > > Denkbar wäre beispielsweise auch noch so was: > > > > ~~~ > > <script type="application/json" id="markup2html"> > > { > > "source": "<base64-string>" > > } > > </script> > > ~~~ > > Ja, `script` ist wohl das, was du suchst. Aber warum JSON und Base64? > > Willst du nicht einfach den Markdown-Quelltext reinschreiben: > > ~~~ > <script type="text/markdown"> > [...] > </script> > ~~~ Ich war mir einerseits nicht sicher, dass das möglich ist. Das ist nicht das, was ich spontan mit der Semantik von einem Element namens `script` verbinde. Mir geht es andererseits darum, beliebige Daten einzubetten. Markdown war nur mein Beispiel. Ich suche eine allgemeine Lösung, die etwa auch für Bilddaten möglich ist (`<script type="image/jpeg">`?). Sorry, das hätte ich deutlicher erklären können. JSON hat zudem den Vorteil, eine Struktur abbilden zu können. Das ist meines Erachtens recht sinnvoll, sobald ich mehr als eine Datei ablegen möchte und weil ich wahrscheinlich Metadaten (Dateiname, …) brauche. gzip wegen Dateigröße. Die ist zwar sekundär, aber wenn man problemlos sparen kann, kann man das ja trotzdem tun. Base64 müsste wahrscheinlich wirklich nicht zwingend sein, aber ich habe es andererseits auch noch nie wirklich gesehen, dass binary blobs in HTML-Quellcode stehen. Ich habe zugegebenermaßen nie darüber nachgedacht, warum das so ist.

> Hm, dieselben Daten doppelt? Du hast eine Spezialanwendung und Dateigröße spielt keine Rolle? Ich bastele für einen HTML-Generator an dem optionalen Feature, die Quelldatei(en) mit in das generierte HTML zu schreiben, um sie nicht getrennt vorhalten zu müssen. So ähnlich wie bei Office-Dokumenten, wenn man so will. Möchte man das HTML-Dokument bearbeiten, „entpackt“ man es, modifiziert die Quelldateien und packt es danach wieder zusammen. Ich experimentiere mit derlei Dingen seit einiger Zeit, weil die klassischen, „DIN-A4“-basierten Schreibanwendungen und Formate für das Web nicht optimal sind und weil ich es auch nicht für sinnvoll halte, dass jeder, der ein etwas komplexeres Dokument online stellen möchte, dafür erst mal haufenweise HTML- und Serverkram lernen muss. Etwas überspitzt gesagt. Ich hätte gewissermaßen gern eine HTML-basierte „Alternative“ zu Word/Writer (wobei ich da das Format meine, nicht den WYSIWYG-Editor) oder PDF, bei der ich die Dokumente in etwa Markdown schreiben kann und bei der ich dabei nicht für jedes Dokument zwingend ein Verzeichnis mit zig Dateien an Quelldaten vorhalten muss. (Etwa dann, wenn das Dokument Bilder enthält.) Dateigröße ist dabei nicht primär von Bedeutung. > Oder magst du vielleicht nur den Markdown-Text (in einem HTML-Grundgerüst) übertragen und das HTML daraus clientseitig generieren? Erfordert natürlich JavaScript. Das wäre möglich, aber hat, wie du sagst, unter anderem den Nachteil, zwingend JavaScript zu benötigen. Das ist erst mal zu kompliziert. Außerdem ist Markdown auch nicht das einzige denkbare Eingabeformat, und die Generierung der fertigen HTML-Ausgabe könnte theoretisch aufwändiger sein, als nur Markdown zu rendern. Es wäre nicht effizient, das von jedem Client erledigen zu lassen, statt es einmal zentral zu machen. > > Ich nutze derzeit `<meta itemprop="markup2html-source" content="<base64-string>">`. > > Microdata ist für Metadaten da. Und Microdata ist pfui! RDFa ist für Metadaten da. Pfui, aha. ;) Ich habe aber nichts gegen RDF(a). Bei der Variante kann ich es `itemscope`/`itemprop` im Zweifel gern vorziehen. Es hat halt den Anschein, dass mehrere Weg nach Rom (Dublin?) führen. > > Denkbar wäre beispielsweise auch noch so was: > > > > ~~~ > > <script type="application/json" id="markup2html"> > > { > > "source": "<base64-string>" > > } > > </script> > > ~~~ > > Ja, `script` ist wohl das, was du suchst. Aber warum JSON und Base64? > > Willst du nicht einfach den Markdown-Quelltext reinschreiben: > > ~~~ > <script type="text/markdown"> > [...] > </script> > ~~~ Ich war mir einerseits nicht sicher, dass das möglich ist. Das ist nicht das, was ich spontan mit der Semantik von einem Element namens `script` verbinde. Mir geht es andererseits darum, beliebige Daten einzubetten. Markdown war nur mein Beispiel. Ich suche eine allgemeine Lösung, die etwa auch für Bilddaten möglich ist (`<script type="image/jpeg">`?). Sorry, das hätte ich deutlicher erklären können. JSON hat zudem den Vorteil, eine Struktur abbilden zu können. Das ist meines Erachtens recht sinnvoll, sobald ich mehr als eine Datei ablegen möchte und weil ich wahrscheinlich Metadaten (Dateiname, …) brauche. gzip wegen Dateigröße. Die ist zwar sekundär, aber wenn man problemlos sparen kann, kann man das ja trotzdem tun. Base64 müsste wahrscheinlich wirklich nicht zwingend sein, aber ich habe es andererseits auch noch nie wirklich gesehen, dass binary blobs in HTML-Quellcode stehen. Ich habe zugegebenermaßen nie darüber nachgedacht, warum das so ist.

> Hm, dieselben Daten doppelt? Du hast eine Spezialanwendung und Dateigröße spielt keine Rolle? Ich bastele für einen HTML-Generator an dem optionalen Feature, die Quelldatei(en) mit in das generierte HTML zu schreiben, um sie nicht getrennt vorhalten zu müssen. So ähnlich wie bei Office-Dokumenten, wenn man so will. Möchte man das HTML-Dokument bearbeiten, „entpackt“ man es, modifiziert die Quelldateien und packt es danach wieder zusammen. Ich experimentiere mit derlei Dingen seit einiger Zeit, weil die klassischen, DIN-A4-basierten Schreibanwendungen und Formate für das Web nicht optimal sind und weil ich es auch nicht für sinnvoll halte, dass jeder, der ein etwas komplexeres Dokument online stellen möchte, dafür erst mal haufenweise HTML- und Serverkram lernen muss. Etwas überspitzt gesagt. Ich hätte gewissermaßen gern eine HTML-basierte „Alternative“ zu Word/Writer (wobei ich da das Format meine, nicht den WYSIWYG-Editor) oder PDF, bei der ich die Dokumente in etwa Markdown schreiben kann und bei der ich dabei nicht für jedes Dokument zwingend ein Verzeichnis mit zig Dateien an Quelldaten vorhalten muss. (Etwa dann, wenn das Dokument Bilder enthält.) Dateigröße ist dabei nicht primär von Bedeutung. > Oder magst du vielleicht nur den Markdown-Text (in einem HTML-Grundgerüst) übertragen und das HTML daraus clientseitig generieren? Erfordert natürlich JavaScript. Das wäre möglich, aber hat, wie du sagst, unter anderem den Nachteil, zwingend JavaScript zu benötigen. Das ist erst mal zu kompliziert. Außerdem ist Markdown auch nicht das einzige denkbare Eingabeformat, und die Generierung der fertigen HTML-Ausgabe könnte theoretisch aufwändiger sein, als nur Markdown zu rendern. Es wäre nicht effizient, das von jedem Client erledigen zu lassen, statt es einmal zentral zu machen. > > Ich nutze derzeit `<meta itemprop="markup2html-source" content="<base64-string>">`. > > Microdata ist für Metadaten da. Und Microdata ist pfui! RDFa ist für Metadaten da. Pfui, aha. ;) Ich habe aber nichts gegen RDF(a). Bei der Variante kann ich es `itemscope`/`itemprop` im Zweifel gern vorziehen. Es hat halt den Anschein, dass mehrere Weg nach Rom (Dublin?) führen. > > Denkbar wäre beispielsweise auch noch so was: > > > > ~~~ > > <script type="application/json" id="markup2html"> > > { > > "source": "<base64-string>" > > } > > </script> > > ~~~ > > Ja, `script` ist wohl das, was du suchst. Aber warum JSON und Base64? > > Willst du nicht einfach den Markdown-Quelltext reinschreiben: > > ~~~ > <script type="text/markdown"> > [...] > </script> > ~~~ Ich war mir einerseits nicht sicher, dass das möglich ist. Das ist nicht das, was ich spontan mit der Semantik von einem Element namens `script` verbinde. Mir geht es andererseits darum, beliebige Daten einzubetten. Markdown war nur mein Beispiel. Ich suche eine allgemeine Lösung, die etwa auch für Bilddaten möglich ist (`<script type="image/jpeg">`?). Sorry, das hätte ich deutlicher erklären können. JSON hat zudem den Vorteil, eine Struktur abbilden zu können. Das ist meines Erachtens recht sinnvoll, sobald ich mehr als eine Datei ablegen möchte und weil ich wahrscheinlich Metadaten (Dateiname, …) brauche. gzip wegen Dateigröße. Die ist zwar sekundär, aber wenn man problemlos sparen kann, kann man das ja trotzdem tun. Base64 müsste wahrscheinlich wirklich nicht zwingend sein, aber ich habe es andererseits auch noch nie wirklich gesehen, dass binary blobs in HTML-Quellcode stehen. Ich habe zugegebenermaßen nie darüber nachgedacht, warum das so ist.