Arbiträre (Meta-)Daten in ein HTML-Dokument einbetten
mermshaus
0 
dedlfix
2 
Gunnar Bittersmann
-2 HTTP: Daten an Response anhängen
0 dedlfix
0
Arbiträre (Meta-)Daten in ein HTML-Dokument einbetten
mermshaus
Hallo.
Ich generiere ein HTML-Dokument aus einer Markdown-Datei. In dieses HTML-Dokument möchte ich diese Markdown-Quelldatei miteinbetten. Sie soll nicht visuell auf der Seite erscheinen, sie soll nur mit ausgeliefert werden, um sie später mit einem Tool wieder auslesen zu können.
Wie mache ich das möglichst semantisch korrekt?
Meine erste Idee war, den Inhalt (gepackt, base64-kodiert) in ein data-Attribut vom html-Element zu schreiben. Das wird aber nicht praktikabel sein, weil die Quelldaten länger als die $x Bytes sein können, die Clients bis zum Finden des <meta charset="…">-Eintrags auslesen.
Ich nutze derzeit <meta itemprop="markup2html-source" content="<base64-string>">. „markup2html“ ist der Name meines Tools bzw. einfach ein Namespace. Diesen Tag platziere ich am Ende des <head>-Bereichs. Zusätzlich habe ich <html> das Attribut itemscope hinzugefügt, weil anscheinend Items immer einen Scope brauchen. Glücklich bin ich damit aber auch nicht, weil ich das Gefühl habe, dass es eine bessere Lösung gibt, die ich bisher noch nicht gefunden habe. Mir ist insgesamt etwas unwohl dabei, potenziell größere Datenmengen in meta-Elementen abzulegen.
Denkbar wäre beispielsweise auch noch so was:
<script type="application/json" id="markup2html">
{
"source": "<base64-string>"
}
</script>
Für Erfahrungen, Vorschläge, Links und dergleichen zu dem Thema bedanke ich mich. :)
Viele Grüße
Marc
-
Tach!
Mir ist insgesamt etwas unwohl dabei, potenziell größere Datenmengen in
meta-Elementen abzulegen.Wie wäre es als Kommentar?
dedlfix.
-
@@dedlfix
Wie wäre es als Kommentar?
Der von irgeneinem Dingens, das so man in der Toolchain hat, entfernt wird?
Gefragt war:
Wie mache ich das möglichst semantisch korrekt?
Daten sind keine Kommentare.
LLAP 🖖
--
“I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl-
Tach!
Wie wäre es als Kommentar?
Der von irgeneinem Dingens, das so man in der Toolchain hat, entfernt wird?
Vielleicht - vielleicht aber auch nicht. Vielleicht macht ja die Toolchain auch die ordentlich ausgezeichneten Daten durch Uglifizierung kaputt.
Gefragt war:
Wie mache ich das möglichst semantisch korrekt?
Ja, aber das muss ja nicht unbedingt mit dem übereinstimmen, was der Frager eigentlich haben möchte oder was ebenfalls für ihn zielführend sein könnte, ohne dass ihm das bei seiner Frageformulierung bewusst war.
dedlfix.
-
@dedlfix, @Gunnar Bittersmann:
Danke für die Antworten.
Wie wäre es als Kommentar?
Der von irgeneinem Dingens, das so man in der Toolchain hat, entfernt wird?
Vielleicht - vielleicht aber auch nicht. Vielleicht macht ja die Toolchain auch die ordentlich ausgezeichneten Daten durch Uglifizierung kaputt.
Gefragt war:
Wie mache ich das möglichst semantisch korrekt?
Ja, aber das muss ja nicht unbedingt mit dem übereinstimmen, was der Frager eigentlich haben möchte oder was ebenfalls für ihn zielführend sein könnte, ohne dass ihm das bei seiner Frageformulierung bewusst war.
Es stimmt, dass ich an Kommentare noch nicht gedacht hatte. Die wären in gewisser Weise schon eine Option, um den Aspekt Semantik erst mal zu umgehen, bis irgendwann vielleicht mal Probleme oder ein komplexerer Anwendungsfall auftreten. Das finde ich aktuell gar nicht so schlecht, weil es sämtliche Fragestellungen im Stile von „Wie interpretieren verschiedene Clients bestimmte Tags?“ löst – na ja, vermeidet. Kommentare dürften in der Hinsicht relativ seiteneffektfrei sein. Auch in Hinblick auf meinen derzeit maßgeblichen Anwendungsfall fände ich es nicht übermäßig tragisch, wenn sie etwa auf dem Weg vom Server zum Client durch Proxies oder dergleichen entfernt würden.
Hintergrund: Ich speichere den „Quellcode“ der Dokumente mit im Dokument, um sie nachträglich bearbeiten zu können, ohne den Quellcode gesondert vorhalten zu müssen. Von der Funktionsweise her so ähnlich wie Office-Dokumente. Da ist es wichtiger, dass das die Person kann, die die Daten auf den Server lädt, als dass es jemand kann, der lediglich das HTML-Dokument übers Web betrachtet. Außerdem hält man bei so was in der Regel ohnehin eine lokale Version vor.
Der Einwand, dass das nicht die sauberste Lösung ist, ist aber sicherlich richtig.
Daten sind keine Kommentare.
Auch das.
-
-
-
-
@@mermshaus
Ich generiere ein HTML-Dokument aus einer Markdown-Datei. In dieses HTML-Dokument möchte ich diese Markdown-Quelldatei miteinbetten. Sie soll nicht visuell auf der Seite erscheinen, sie soll nur mit ausgeliefert werden, um sie später mit einem Tool wieder auslesen zu können.
Hm, dieselben Daten doppelt? Du hast eine Spezialanwendung und Dateigröße spielt keine Rolle?
Oder magst du vielleicht nur den Markdown-Text (in einem HTML-Grundgerüst) übertragen und das HTML daraus clientseitig generieren? Erfordert natürlich JavaScript.
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.
Denkbar wäre beispielsweise auch noch so was:
<script type="application/json" id="markup2html"> { "source": "<base64-string>" } </script>Ja,
scriptist wohl das, was du suchst. Aber warum JSON und Base64?Willst du nicht einfach den Markdown-Quelltext reinschreiben:
<script type="text/markdown"> # The Universal Declaration of Human Rights # ## Preamble ## […] __Now, Therefore the *General Assembly* proclaims *this Universal Declaration of Human Rights*__ as a common standard of achievement for all peoples and all nations, to the end that every individual and every organ of society, keeping this Declaration constantly in mind […] </script>--
“I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl-
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/itempropim 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,
scriptist 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
scriptverbinde. 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.)
-
@@mermshaus
<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
scriptverbinde.Die HTML-Spec ist sich da aber ziemlich sicher:
“The
scriptelement allows authors to include dynamic script and data blocks in their documents. […] Setting the [type] attribute to any other value [than a JavaScript MIME type or"module"] means that the script is a data block, which is not processed.”LLAP 🖖
--
“I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl-
@Gunnar Bittersmann
Die HTML-Spec ist sich da aber ziemlich sicher:
“The
scriptelement allows authors to include dynamic script and data blocks in their documents. […] Setting the [type] attribute to any other value [than a JavaScript MIME type or"module"] means that the script is a data block, which is not processed.”Okay, dann scheint
scriptein generischer Daten-Container sein zu können. Mit der Einschränkung, dass das Ablegen von unbehandelten Binärdaten nicht möglich ist und dass auch bei Textformaten wie Markdown Escaping erforderlich ist.Ich denke, ich werde vorerst ein einziges
script-Element mitapplication/jsonfür alle Daten wählen und Binärdaten in Feldern der JSON-Struktur mit gzip und base64 behandeln. Letzteres deshalb, weil auch das JSON-Format in dem Sinne kein Ablegen von Binärdaten unterstützt.Danke für die Antworten!
-
-
ich habe es andererseits auch noch nie wirklich gesehen, dass binary blobs in HTML-Quellcode stehen.
Einfügen geht schon aber spätestens beim Zugriff mit $(el).html() oder $(el).text() geht die Binary kaputt weil sie weder text noch html ist sondern Oktetten beliebiger Wertigkeiten enthalten kann.
<script type="text/plain" id="data">base64==ASCII</script>Wäre meine Lösung und hier hab ich Base64 Daten noch in einen <div>. Eine andere Variante bestünde darin, hinter Deiner Seite einen Webservice zu verstecken, der beim Aufruf dieser mit einem bestimmten Parameter die Binary direkt ausliefert.
Oder Du zentralisierst einen solchen Service in einer zentralen Location und deklarierst diese in einem Custom-Header, damit wird das Abfischen auch automatisierbar.
Schönen Sonntag!
-
Eine andere Variante bestünde darin, hinter Deiner Seite einen Webservice zu verstecken, der beim Aufruf dieser mit einem bestimmten Parameter die Binary direkt ausliefert.
Es dürfte ja kein Problem sein, Seiten/URLs so zu erweitern, dass sie Parameter verarbeiten und beim entsprechenden Request beliebigen Content ausliefern können. Zumal die Klasse die das Markdown erzeugt, die Daten-Quelle ja bereits kennt.
-
@pl
Einfügen geht schon aber spätestens beim Zugriff mit $(el).html() oder $(el).text() geht die Binary kaputt weil sie weder text noch html ist sondern Oktetten beliebiger Wertigkeiten enthalten kann.
Ich habe es gerade mal versucht (in PHP):
<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>data-block-test</title> </head> <body> <script type="image/jpeg"><?=file_get_contents(__DIR__ . '/demo.jpg')?></script> </body> </html>Das daraus generierte HTML ist laut Validator tatsächlich ungültig. @dedlfix hat es hier genauer erklärt. (Deshalb fällt auch so was wie
<script type="image/jpeg">wahrscheinlich allein prinzipbedingt als Option weg. Vielleicht könnte man die Bytes zwar mit numerischen HTML-Entities maskieren. Aber in der Richtung werde zumindest ich jetzt nicht weiterforschen.)<script type="text/plain" id="data">base64==ASCII</script>Ich werde wahrscheinlich auf
application/jsonsetzen, aber die Binärdaten darin base64-kodieren.Eine andere Variante bestünde darin, hinter Deiner Seite einen Webservice zu verstecken, der beim Aufruf dieser mit einem bestimmten Parameter die Binary direkt ausliefert.
Das ist keine Option, da es darum geht, mehr oder weniger eigenständige Dokumente zu erzeugen, die keine weitere serverseitige Software zur Darstellung benötigen.
Oder Du zentralisierst einen solchen Service in einer zentralen Location und deklarierst diese in einem Custom-Header, damit wird das Abfischen auch automatisierbar.
Das verstehe ich nicht genau, aber auch das wird nicht in die Richtung dessen gehen, was mir vorschwebt. Das Tool soll am Ende jeder nutzen können, ohne sich weitere Abhängigkeiten zu Webservices oder dergleichen einzuhandeln.[1]
Danke für die Antworten.
Abgesehen von der externen Einbindung von Libraries wie jQuery, MathJax oder Bootstrap. Auch die würde ich generell lieber bundlen, aber da wird es dann irgendwann ziemlich unpraktikabel. ↩︎
-
-
Tach!
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.)
Zum einen braucht es Escaping, sonst erkennt der Browser bestimmte Werte als Zeichen mit besonderer Bedeutung und verheddert sich womöglich in seinem Parse-Vorgang. Zum anderen kannst du dann nur Dokumente mit Ein-Byte-Kodierungen generieren, sonst werden die Binärdaten als fehlerhaft kodierte Zeichen erkannt, was dann auch zu Folgefehlern führen kann. Du brauchst eine Kodierung, die eine gültige Zeichenfolge in Bezug auf die Kodierung des Dokuments erzeugt. HTML ist nach wie vor noch ein zeichenbasiertes Format. Eine lediglich ASCII-Zeichen verwendende Kodierung ist zumindest (zuzüglich Maskierung) sicher in ISO-8859-* und UTF-8-Dokumente einzubetten, ohne dass man da noch dokumentkodierungsspezifisch umkodieren muss. Base64 hat sich halt durchgesetzt als ein in der Hinsicht problemloses Format. (Für UTF-16 beispielsweise müsste man man auch Base64 nochmal umkodieren (0-Bytes einfügen).)
dedlfix.
-
Danke für die Antworten. Ich werde nun wohl erst mal so vorgehen, wie hier beschreiben: https://forum.selfhtml.org/self/2016/nov/12/arbitraere-meta-daten-in-ein-html-dokument-einbetten/1680054#m1680054
-
-
-
-
Eine andere Lösung setzt auf HTTP: Wenn es einen Response-Header
Content-Lengthgibt, liest der Browser die Response bytegenau am Stück in dieser Länge.Das heißt, Du kannst beliebige Daten anhängen, sie spielen keine Rolle im Browser. Um an diese angehängten Daten heranzukommen, braucht es einen Low-Level-Client, ist aber auch kein Problem eine Solchen zu bauen.
MfG
-
Tach!
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.
dedlfix.
-
Tach!
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).
Schönen Tach noch.
-
@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[1], 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 generiert.[2]
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
bodyaktuell 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.mdin 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.htmloder so.
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. :) ↩︎
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. ↩︎
-
-
-
Hallo pl,
Eine andere Lösung setzt auf HTTP: Wenn es einen Response-Header
Content-Lengthgibt, liest der Browser die Response bytegenau am Stück in dieser Länge.Das heißt, Du kannst beliebige Daten anhängen, sie spielen keine Rolle im Browser.
Das ist kein Standard-konformes Verhalten und dürfte sich mit Features wie Pipelining beissen. Das würde ich nicht empfehlen.
LG,
CK-
@@Christian Kruse
Das ist kein Standard-konformes Verhalten und dürfte sich mit Features wie Pipelining beissen.
Das beißt im Auge. Wenn du das richtig™ schreibst, beißt dich deine Frau? (Das ist kein Standard-konformes Verhalten.)
LLAP 🖖
--
“I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl-
Hallo Gunnar,
Das ist kein Standard-konformes Verhalten und dürfte sich mit Features wie Pipelining beissen.
Das beißt im Auge. Wenn du das richtig™ schreibst, beißt dich deine Frau? (Das ist kein Standard-konformes Verhalten.)
LG,
CK-
Tach!
Das beißt im Auge. Wenn du das richtig™ schreibst, beißt dich deine Frau? (Das ist kein Standard-konformes Verhalten.)
Aus demselben Grunde: Hoch leben die "Anführungszeichen"!
dedlfix.
-
@@Christian Kruse
Ah ja, wr sbbrachen drüber. Mir fällt’s wie Schubbbben aus den Haaren.
LLAP 🖖
--
“I love to go to JS conferences to speak about how to avoid using JavaScript. Please learn CSS & HTML to reduce your JS code bloat.” —Estelle Weyl
-
-
-
-