HTML noch zeitgemäß?

[Sven Venger]

Hallo,

betrachte ich mir die Entwicklung von Auszeichnungssprachen, so stellt sich für mich die Frage, ob HTML überhaupt noch zeitgemäß ist. Aus meiner Sicht schleppt es unnötigen overhead mit sich rum. Aber die Frage die sich mir auch aufdrängt, ich mir aber keine schlüssige Antowrt geben kann: Ist (X)HTML bzw. XML nicht auch ein Nachteil wenn man die CPU-Entwicklung bei Mobilgeräten anschaut - viele Kerne/Threads und Aufteilung der Arbeit. Wurde das irgendwo schon einmal diskutiert? Zum Beispiel ob etwa XML-konforme Formate bzw. ähnliche Formate nachteilig sind - Stichwort Serialization. Oder bin ich da auf dem Holzweg?

Gruss, Sven

[klawischnigg]

Hi there,

betrachte ich mir die Entwicklung von Auszeichnungssprachen, so stellt sich für mich die Frage, ob HTML überhaupt noch zeitgemäß ist.

Die Frage stellt sich dann, wenn man a) etwas besseres hat oder b) etwas besseres braucht. Beides scheint mir nicht wirklich der Fall zu sein.

Aus meiner Sicht schleppt es unnötigen overhead mit sich rum.

Welchen?

Aber die Frage die sich mir auch aufdrängt, ich mir aber keine schlüssige Antowrt geben kann: Ist (X)HTML bzw. XML nicht auch ein Nachteil wenn man die CPU-Entwicklung bei Mobilgeräten anschaut

(X)HTML ist tot und XML macht ganz woanders Sinn. Das hat mit Mobilgeräten einmal gar nichts zu tun. Der Vorteil von XML liegt in der Möglichkeit der automatisierten Verarbeitung der Ausgabe, ein Feature, das von einer Million Webseiten vermutlich nur eine halbe benötigt. Verbesserungsmöglichkeiten gibt's immer, aber die seh' ich (und andere, die davon mehr verstehen) vor allem eher beim Protokoll als bei der Seitenbeschreibungssprache…

[Regina Schaukrug]

so stellt sich für mich die Frage, ob HTML überhaupt noch zeitgemäß ist. Aus meiner Siht schleppt es unnötigen overhead mit sich rum.

Das kommt doch ganz darauf an, wer oder was das HTML erzeugt hat. Das geht von ultraschlank bis ultrafett.

[beatovich]

hallo

Hallo,

betrachte ich mir die Entwicklung von Auszeichnungssprachen, so stellt sich für mich die Frage, ob HTML überhaupt noch zeitgemäß ist. Aus meiner Sicht schleppt es unnötigen overhead mit sich rum. Aber die Frage die sich mir auch aufdrängt, ich mir aber keine schlüssige Antowrt geben kann: Ist (X)HTML bzw. XML nicht auch ein Nachteil wenn man die CPU-Entwicklung bei Mobilgeräten anschaut - viele Kerne/Threads und Aufteilung der Arbeit. Wurde das irgendwo schon einmal diskutiert? Zum Beispiel ob etwa XML-konforme Formate bzw. ähnliche Formate nachteilig sind - Stichwort Serialization. Oder bin ich da auf dem Holzweg?

Am sogenannten Overhead liesse sich sicher etwas ändern, wenn HTML endlich seine eigene import Methode kennen würde.

Ohne diese findet halt einiges an Arbeit entweder auf dem Server oder auf dem Client statt.

[Regina Schaukrug]

wenn HTML endlich seine eigene import Methode

Naja... muss es eine eigene haben? Das würde nur zu mehr Requests führen, bei denen dann womöglich jeweils nur kleinste Datenmengen übertragen werden. Folge: Mächtig gewaltiger Overhead, langsamer Seitenaufbau. Die eigene include-Methode würde nur ein Problem auf eine schlechte Weise lösen, welches längst weitaus besser gelöst ist.

Es gibt:

• Server Side Includes
• und natürlich jede Menge Skriptsprachen (PHP ist nur eine), die serverseitig eine Seite zusammensetzen können.

[beatovich]

hallo

wenn HTML endlich seine eigene import Methode

Naja... muss es eine eigene haben? Das würde nur zu mehr Requests führen, bei denen dann womöglich jeweils nur kleinste Datenmengen übertragen werden. Folge: Mächtig gewaltiger Overhead, langsamer Seitenaufbau. Die eigene include-Methode würde nur ein Problem auf eine schlechte Weise lösen, welches längst weitaus besser gelöst ist.

Es gibt:

• Server Side Includes
• und natürlich jede Menge Skriptsprachen (PHP ist nur eine), die serverseitig eine Seite zusammensetzen können.

Das ist ja was ich sagte: So musst du halt einen Overhead auf Server-Seite in Kauf nehmen. Verneint wird schliesslich der Cache.

[Regina Schaukrug]

Das ist ja was ich sagte: So musst du halt einen Overhead auf Server-Seite in Kauf nehmen.

Ja. Aber der ist in "summa summarum" geringer. Wohl auch bei Verwendung von HTTP/2.

Verneint wird schliesslich der Cache.

Kommt drauf an.

[Robert B.]

Hallo Regina,

wenn HTML endlich seine eigene import Methode

Naja... muss es eine eigene haben? Das würde nur zu mehr Requests führen, bei denen dann womöglich jeweils nur kleinste Datenmengen übertragen werden.

Dafür gäbe es dann ja HTTP/2 😉

Viele Grüße
Robert

[Robert B.]

Moin beatovich,

Am sogenannten Overhead liesse sich sicher etwas ändern, wenn HTML endlich seine eigene import Methode kennen würde.

Das spräche natürlich durchaus für XHTML mit XInclude 😝

Viele Grüße
Robert

[Henry]

Hallo Sven,

Interessante Frage. Was wäre die Alternative, leicht zu erstellen, für jedes Device zu verarbeiten?

Wenn man tatsächlich nur HTML und Webseiten , sind die meisten reine Präsentationsseiten ohne große Interaktion. Wenn Interaktion, meist jquery-spielereien oder Werbeeinblendungen.

Jetzt könnte man etwas machen, was früher auch schon Leute probiert haben, die wenige bis gar kein HTML konnten, sie verwendeten Bilder. Damals, infolge der geringen Bandbreite, natürlich absolut untauglich, heutzutage eigentlich kein Problem, man brächte also nur noch ein geeignetes Grafikprogramm und erstellt wirklich wysiwyg. Durch die automatische Browserskalierung auch noch ansehnlich, wenn richtig gemacht. Dürfte für die reinen Grafikdesigner das Paradies sein.

Theoretisch natürlich nur, Barrierefrei bliebe komplett auf der Strecke. Aber warum eigentlich? Eine geeignete OCR-Software könnte automatisiert aus den Bildern wieder Text auslesen und zur Verfügung stellen. Hmmm... oder (spinnen wir mal weiter), das Grafikprogramm produziert direkt eine PDF, auch von jedem zugänglich (erschreckender Gedanke sich von Adobe abhängig zu machen). Je mehr ich darüber nachdenke… Neee… Dank Baukästen, CSM, etc. kriegen auch Grafikdesigner das heute hin, was eine Richtungsänderung unwahrscheinlich macht.

Somit zurück zu deiner Frage, JA HTML 100% zeitgemäß, auch wenn immer mehr das nutzen ohne es zu wissen. 😉

Gruss
Henry

[beatovich]

hallo

Dürfte für die reinen Grafikdesigner das Paradies sein.

... bis man ihn mit der Möglichkeit von Animationen und Transition Effekten konfrontiert.

Der Albtraum für statisches OCR.

[Sven Venger]

Na ja, wenn ich mir immer anschaue, wie langsam ein Mobiltelefon so eine Webseite aufbaut, dann frage ich mich immer. ob man dass nicht besser machen könnte. Sicher, man kann es mit Javascript zum beispiel umgehen, in dem man nun einen leere Korpus als HTML seite laden lässt und dann die Daten nachlädt, aber irgendwie doch auch ein Gammelweg.

Wenn ich es richtig verstehe. Kann ja die Rendering-Enige erst dann anfangen, wenn das letzte Byte eingetröpfelt ist. Das muesste man doch besser lösen können, indem der der request datenblöcke erhält die schon parallel abgearbeitet werden können. Es muss also nicht gewartet werden, bis alles da ist.

Desweiteren finde ich die closing tag names ziemlich überflüssig. Zudem könnte man darüber nachdenken, ob man nicht eine teil der Webseite gleich komprimiert verschickt. Damit könnte man eine weiteres Nadelöhr stopfen und wertvolle Bandbreite bei Mobiltelefonen sparen. Auch das kann man natürlich über Umwege durch nachladen von komprimierten Daten heute schon umgehen. Aber wenn das standardisiert wäre, da könnten die Browserhersteller reagieren und das besser implementieren.

Kurzum, in einer Zeit, in der die Kerne/Thread einer CPU zunehmen, müsste man sich auch mal Gedanken machen, ob von dieser Entwicklung nicht auch die Webseiten profitieren sollten.

[beatovich]

hallo

Desweiteren finde ich die closing tag names ziemlich überflüssig.

Vom Aspekt der Syntax her mögen sie in xml überflüssig erscheinen. In html ist das aber anders, da manche Elemente mit oder ohne Entdtag geschrieben werden können.

Vom Aspekt des Authoring her sind sie alles andere als überflüssig.

Zudem könnte man darüber nachdenken, ob man nicht eine teil der Webseite gleich komprimiert verschickt.

Die meiste Nutzlast ist schon komprimiert. HTML Code macht oft nur 5-10% des Volumens aus.

[Henry]

Hallo Sven,

Na ja, wenn ich mir immer anschaue, wie langsam ein Mobiltelefon so eine Webseite aufbaut, dann frage ich mich immer. ob man dass nicht besser machen könnte.

Dass Seiten langsam sind liegt nie an HTML, sondern an denen die das vermurksen, bzw. unnötige Scripte reinhauen, externe Resourcen und Trackingtools aller Coleur einbinden.

Wenn ich es richtig verstehe. Kann ja die Rendering-Enige erst dann anfangen, wenn das letzte Byte eingetröpfelt ist. Das muesste man doch besser lösen können, indem der der request datenblöcke erhält die schon parallel abgearbeitet werden können. Es muss also nicht gewartet werden, bis alles da ist.

Bin nicht mal sicher ob das so ist, weil mit PHP muss ich den final Output manchmal sogar erzwingen, wenn ich das brauche. Ach ja und dann gibt's da ja noch das Lazy-Loading (inkl.Pro/Contra).

Kurzum, in einer Zeit, in der die Kerne/Thread einer CPU zunehmen, müsste man sich auch mal Gedanken machen, ob von dieser Entwicklung nicht auch die Webseiten profitieren sollten.

Wie gesagt, Schnelligkeit einer Seite hat nie damit zu tun, dass HTML schwierig zu rendern wäre. Schau dich doch mal um, dieses Forum hier ist blitzschnell, genauso das Wiki oder auch das normale Wikipedia und jetzt schau dir mal Seiten wie chip.de oder andere Zeitungsseiten an, oder ganz böse DUDEN.de an. Das hat nichts mit HTML zu tun.

Eine Sache die Yahoo nie verstanden hat und darum auch zu Recht kaputt (mehr oder weniger) gegangen sind. Voller Scripte, endlos langsam.

Gruss
Henry

[Gunnar Bittersmann]

@@Sven Venger

Na ja, wenn ich mir immer anschaue, wie langsam ein Mobiltelefon so eine Webseite aufbaut, dann frage ich mich immer. ob man dass nicht besser machen könnte.

Kann man. Sollte man.

Wenn ich es richtig verstehe. Kann ja die Rendering-Enige erst dann anfangen, wenn das letzte Byte eingetröpfelt ist.

Nein. Die Rendering-Engine kann anfangen, wenn alles, was zur Darstellung nötig ist, eingetröpfelt ist. Dazu zählt das Stylesheet. CSS blockiert das Rendern. Was man machen kann: initial nur das nötigste CSS einbinden (critical path), den Rest per JavaScript nachladen.

Synchrones JavaScript blockiert das Rendern. Deshalb Scripte asynchron ausführen lassen oder als letztes im body einbinden.

Das Laden von Webfonts blockiert evtl. das Rendern. FOIT (flash of invisible content) vermeiden.

Was nicht das Rendern blockiert: das Laden von HTML. Die Seite wird bereits angefangen zu rendern, bevor alles HTML geladen ist.

Was du zurecht beklagst, dass manche Webseiten ewig laden, rührt wohl allermeistens von Scripten her, die vor dem Seiteninhalt geladen und ausgeführt werden. Und das sind wohl allermeistens Scripte, die der Nutzer überhaupt nicht will: Tracking, Werbung, …

Zudem könnte man darüber nachdenken, ob man nicht eine teil der Webseite gleich komprimiert verschickt.

Die Übertragung erfolgt immer komprimiert (sollte jedenfalls) – meist (noch) gezippt, bei manchen auch schon mit Brotli oder Zopfli.

LLAP 🖖

[Sven Venger]

@@Sven Venger

Nein. Die Rendering-Engine kann anfangen, wenn alles, was zur Darstellung nötig ist, eingetröpfelt ist. Dazu zählt das Stylesheet. CSS blockiert das Rendern. Was man machen kann: initial nur das nötigste CSS einbinden (critical path), den Rest per JavaScript nachladen.

Da muss ich mal nachhaken. Mein Verständnis war/ist, dass eine Rendering-Engine nicht so einfach loslegt, sondern wartet, bis der DOM geladen wurde

Zum Beispiel

<body>
  <section/>
  <section/>
  <section/>
  <section/>
...
  <section/>
</body>

Mein Verständnis ist, dass die Rendering-Engine erst alle <section/> Elemente einliest, bevor damit angefangen wird, die zu rendern. Ist mein Verständnis falsch?

[beatovich]

hallo

Da muss ich mal nachhaken. Mein Verständnis war/ist, dass eine Rendering-Engine nicht so einfach loslegt, sondern wartet, bis der DOM geladen wurde

Ich glaube mit solchem Verhalten wäre zu Modem Zeiten HTML kaum Erfolg beschieden gewesen.

Ich empfehle dir einfach, einen Test zu machen.

[Robert B.]

Hallo Sven,

betrachte ich mir die Entwicklung von Auszeichnungssprachen, so stellt sich für mich die Frage, ob HTML überhaupt noch zeitgemäß ist.

Welche Auszeichnungssprache, die seit HTML entstanden oder weiter entwickelt worden sind, sind denn deiner Meinung nach zeitgemäßer als HTML? Gut, für reinen Text könnte man auch Markdown verwenden, für komplexen Text LaTeX und für Web-Apps XUL oder XAML – oder man nimmt eben alles in einem 😉

Aus meiner Sicht schleppt es unnötigen overhead mit sich rum.

Durchaus, ich sage nur iframe, img, source, video, audio und object zum Einbinden von Dokument-externen Inhalten oder die „Legalisierung“ missbilligter Elemente wie b, s und i. Welchen Overhead meinst du?

Aber die Frage die sich mir auch aufdrängt, ich mir aber keine schlüssige Antowrt geben kann: Ist (X)HTML bzw. XML nicht auch ein Nachteil wenn man die CPU-Entwicklung bei Mobilgeräten anschaut - viele Kerne/Threads und Aufteilung der Arbeit.

Das HTML-Dokument wird zwar linear übertragen und geparst, aber das Nachladen der weiteren Ressourcen findet IMHO durchaus parallel statt. Und mehrere Kerne hast du auch im Desktop.

Wurde das irgendwo schon einmal diskutiert?

Wenn ich die Browser-Entwicklertools (Zugriff via F12-Taste) richtig deute, kannst du dort sehen, was parallel verarbeitet wird.

Viele Grüße
Robert

[Gunnar Bittersmann]

@@Robert B.

Durchaus, ich sage nur iframe, img, source, video, audio und object zum Einbinden von Dokument-externen Inhalten

Von denen manche eigene Steuerungselemente (im Shadow DOM) mitbringen, also durchaus ihre Daseinsberechtigungen haben.

oder die „Legalisierung“ missbilligter Elemente wie b, s und i.

In welcher Spec wären b, s und i missbilligt gewesen?

Für diese Elemente gibt es durchaus sinnvolle Anwendungen:

• <p>statt <s>12,99&nbsp;€</s> jetzt nur 8,99&nbsp;€</p>
• Verwendung von b- und i-Elementen

LLAP 🖖

[pl]

Moin,

wenn es um den Transport von Daten geht, war HTML/XML noch nie zeitgemäß. Von daher gibt es einen Trend dahingehend, nur noch die Datenstruktur zu transportieren wobei die Semantik als Solche beim Transport keine Rolle mehr spielt sondern erst wieder wenn es um die Darstellung der Daten geht.

War hier im Übrigen auch schon mal Thema. MfG

[klawischnigg]

Hi there,

Moin,

wenn es um den Transport von Daten geht, war HTML/XML noch nie zeitgemäß.

WTF??? Hypertransport-Markup-Language???

[Regina Schaukrug]

WTF??? Hypertransport-Markup-Language???

So völlig abwegig ist sind PLs Ausführungen nicht. Grund: Es gibt das DOM. Das Dokument ist also ein Objekt. Folge: Man kann es serialisieren und also serialisiert übertragen.

Freilich ist eine Aussage wie

wenn es um den Transport von Daten geht, war HTML/XML noch nie zeitgemäß.

auch ziemlich "mutig". Denn was 'zeitgemäß' ist, ist eine Frage des Zeitgeistes, der Mode, des Standes der Technik, den Zwängen der Ökonomie, sonstwas - und unterliegt also einem Wandel. HTML war und ist zeitgemäß - ob es das in 20 oder 200 Jahren noch ist, ist eine ganz andere Frage. Vielleicht sind unsere Nachfahren dann froh zu wissen, dass man nicht aus Pfützen trinkt, die nachts leuchten - und haben also ganz andere Sorgen.

[Robert B.]

Moin Regina,

Es gibt das DOM. Das Dokument ist also ein Objekt. Folge: Man kann es serialisieren und also serialisiert übertragen.

Ist HTML keine serialisierte Darstellung des Objekts?

Viele Grüße
Robert

[Regina Schaukrug]

Ist HTML keine serialisierte Darstellung des Objekts?

Du machst es mir nicht einfach, weil ja jede Text-Repräsentation (Folge, also Serie von Zeichen) zwingend eine "serielle Darstellung" ist. Aber dieses ist vorliegend nicht gemeint, weil sich PL (beachte seine bekannten Vorlieben) auf eine schlanke Serialisierung ohne den Overhead von XML/[X]HTML bezieht.

[Robert B.]

Moin Regina,

Ist HTML keine serialisierte Darstellung des Objekts?

Du machst es mir nicht einfach, weil ja jede Text-Repräsentation (Folge, also Serie von Zeichen) zwingend eine "serielle Darstellung" ist. Aber dieses ist vorliegend nicht gemeint, weil sich PL (beachte seine bekannten Vorlieben) auf eine schlanke Serialisierung ohne den Overhead von XML/[X]HTML bezieht.

Also ich verstehe Serialisierung so, dass ich ein Objekt aus dem Arbeitsspeicher irgendwie persistieren und später wiederherstellen kann. In welchem Format das passiert, ist doch erst einmal egal. Zumindest ich bin so alt, dass mich eine Serialiserung in einem XML-Dialekt nicht schockt 😉

Viele Grüße
Robert

[pl]

Ist HTML keine serialisierte Darstellung des Objekts?

Du machst es mir nicht einfach, weil ja jede Text-Repräsentation (Folge, also Serie von Zeichen) zwingend eine "serielle Darstellung" ist. Aber dieses ist vorliegend nicht gemeint, weil sich PL (beachte seine bekannten Vorlieben) auf eine schlanke Serialisierung ohne den Overhead von XML/[X]HTML bezieht.

Hier geht es doch nicht um meine Vorlieben!

.

[Regina Schaukrug]

Ist HTML keine serialisierte Darstellung des Objekts?

Du machst es mir nicht einfach, weil ja jede Text-Repräsentation (Folge, also Serie von Zeichen) zwingend eine "serielle Darstellung" ist. Aber dieses ist vorliegend nicht gemeint, weil sich PL (beachte seine bekannten Vorlieben) auf eine schlanke Serialisierung ohne den Overhead von XML/[X]HTML bezieht.

Hier geht es doch nicht um meine Vorlieben!

Ich meine natürlich um jene, welche die Art und Weise des Serialisierens betreffen.

[pl]

WTF??? Hypertransport-Markup-Language???

So völlig abwegig ist sind PLs Ausführungen nicht. Grund: Es gibt das DOM. Das Dokument ist also ein Objekt. Folge: Man kann es serialisieren und also serialisiert übertragen.

Freilich ist eine Aussage wie

wenn es um den Transport von Daten geht, war HTML/XML noch nie zeitgemäß.

auch ziemlich "mutig".

HTML ist Transport und Darstellung in Einem. Das heißt, daß das DOM so transportiert wird wie es in der Datei abgebildet ist. Im Grunde genommen ist die Datei das Ergebnis eines serialisierten DOM. Das mag solange zeitgemäß sein, wie ein DOM ohne Multimediakomponenten auskommt. Diese nämlich, also Audio, Video, Grafiken usw. müssen extra übertragen werden.

Zeitgemäß wäre also, sich mal Gedanken darüber zu machen, wie im Zeitalter von Multimedia eine Datenstruktur aussehen könnte in welcher ebendiese Multimediakomponenten ins DOM eingebettet sind und alles zusammmen übertragen werden kann.

Und ja, das Multimedia Zeitalter hat schon längst begonnen. In der Entwicklung gibt es keinen Stillstand. Mutig ist, wer diesen Fakt ignoriert!

MfG

[Robert B.]

Moin pl,

HTML ist Transport und Darstellung in Einem.

Aha. Dann brauchen wir ja kein HTTP mehr.

Zeitgemäß wäre also, sich mal Gedanken darüber zu machen, wie im Zeitalter von Multimedia eine Datenstruktur aussehen könnte in welcher ebendiese Multimediakomponenten ins DOM eingebettet sind und alles zusammmen übertragen werden kann.

Das Multimediazeitalter hat spätestens Ende der 1990er begonnen: RFC 2397 und RFC 2557 zeugen davon.

Viele Grüße
Robert

[pl]

hi,

HTML ist Transport und Darstellung in Einem.

Aha. Dann brauchen wir ja kein HTTP mehr.

Wie kommst Du denn darauf!? Natürlich brauchen wir ein Protokoll für den Transport aber hallo! Im Übrigen transportiert HTTP nicht nur Text. Oder was glaubst Du wie eine Grafik in den Browser kommt!?

MfG

[Robert B.]

Moin pl,

merkst du eigentlich, was du hier gerade geschrieben hast? Ich hebe mal etwas hervor:

hi,

HTML ist Transport und Darstellung in Einem.

Aha. Dann brauchen wir ja kein HTTP mehr.

Wie kommst Du denn darauf!? Natürlich brauchen wir ein Protokoll für den Transport aber hallo! Im Übrigen transportiert HTTP nicht nur Text. Oder was glaubst Du wie eine Grafik in den Browser kommt!?

Viele Grüße
Robert

[pl]

Was verstehst Du daran nicht? Daß man mit HTTP nicht nur HyperText sondern auch Grafiken und beliebige Dateien übertragen kann, ist ja nun wirklich nichts Neues.

Und daß HTML die Grafiken nur referenzieren aber nicht einbetten kann auch nicht.

MfG

[Gunnar Bittersmann]

@@pl

Und daß HTML die Grafiken nur referenzieren aber nicht einbetten kann auch nicht.

Hm, <img src="data:image/jpeg;base64,…" alt="…"/>?

LLAP 🖖

[pl]

@Gunnar Bittersmann

Und daß HTML die Grafiken nur referenzieren aber nicht einbetten kann auch nicht.

Hm, <img src="data:image/jpeg;base64,…" alt="…"/>?

Wäre eine Möglichkeit. Ist aber Base64 und da sind die Grenzen sehr schnell erreicht. Deswegen ja, gibt es Überlegungen hinsichtlich geeigneter Datenstrukturen die binary safe serialisiert werden können. Vor allem auch mit geringer Bandbreite.

Im Übrigen bin ich nicht der Erste und auch nicht der Einzige der diesbezügliche Entwicklungen geleistet und Pionierarbeit betrieben hat. Und was draußen auf dem Markt passiert bestimmen sowieso ganz Andere.

Ansonsten macht eine weitere Diskussion hier keinen Sinn.

.

[Gunnar Bittersmann]

@@pl

Im Übrigen bin ich nicht der Erste und auch nicht der Einzige der diesbezügliche Entwicklungen geleistet und Pionierarbeit betrieben hat.

Ähm … immer bereit!

LLAP 🖖

[Gunnar Bittersmann]

@@pl

Hm, <img src="data:image/jpeg;base64,…" alt="…"/>?

Wäre eine Möglichkeit. Ist aber Base64 und da sind die Grenzen sehr schnell erreicht.

?? Von was für Grenzen sprichst du?

Ich wollte übrigens lediglich die Möglichkeit von data-URIs aufzeigen. Das soll nicht heißen, dass man das so machen sollte. Caching und Performanz sprechen oftmals dagegen.

LLAP 🖖

[Regina Schaukrug]

und daß HTML die Grafiken nur referenzieren aber nicht einbetten kann auch nicht.

Hehe PL. … Was ist heute nur los mit Dir? Laus-Leber-Syndrom?

• Du hast bekommen: RFC 2397 und RFC 2557
• Du bekommst dazu ein augenscheinliches Beispiel.

[pl]

und daß HTML die Grafiken nur referenzieren aber nicht einbetten kann auch nicht.

Hehe PL. … Was ist heute nur los mit Dir? Laus-Leber-Syndrom?

• Du hast bekommen: RFC 2397 und RFC 2557
• Du bekommst dazu ein augenscheinliches Beispiel.

Das ist aber nicht das was ich meinte. Und guck Dir mal an wie alt diese RFCs sind, 1998, 1999, das fällt ja ins Präkambrium.

Oder möchtest Du hier weiter Torf stechen!?

MfG

[Robert B.]

Moin,

das war der Kontext für die RFCs.

Viele Grüße
Robert

[Regina Schaukrug]

Oder möchtest Du hier weiter Torf stechen!?

Nönö. Ich war, als noch die Sowjetsterne am realsozialistischen Firmament leuchteten, auch mal in einem Braunkohletagebau. Wer braucht da so geologisch junges Zeug wie dieses Torf?

[Robert B.]

Moin pl,

Was verstehst Du daran nicht?

Ich verstehe nicht, wie man so zielsicher auf Dinge antworten kann, die nicht geschrieben worden sind.

Viele Grüße
Robert

[klawischnigg]

Hi there,

So völlig abwegig ist sind PLs Ausführungen nicht.

Das wär' das erste Mal...

Grund: Es gibt das DOM. Das Dokument ist also ein Objekt. Folge: Man kann es serialisieren und also serialisiert übertragen.

Ja eh. Aber das sind Spitzfindigkeiten die nichts daran ändern, daß HTML immer noch eine Markup-Language ist und kein Übertragungsprotokoll, somit seinem Wesen nach mit dem Transport von Daten genausoviel zu tun hat wie ich - nämlich gar nichts. Und auch wenn man noch so viel Multimedia einbettet (was idR ohnehin eher vor allem nur auf den Nerv geht und ausser längeren Ladezeiten nix bewirkt) wird eine Seitenbeschreibungssprache nicht zu einem Fernlaster für Datenmüll…

[Robert B.]

Moin @@klawischnigg,

wenn es um den Transport von Daten geht, war HTML/XML noch nie zeitgemäß.

WTF??? Hypertransport-Markup-Language???

Mit Lichtgeschwindigkeit.

Viele Grüße
Robert

[Robert B.]

Moin pl,

[ ] du berücksichtigst die Bedeutung des Terms Markup Language.

Viele Grüße
Robert

[encoder]

Ich nehme an schon die einzelne Existenz und erst recht Kobination von Werbeindustrie, schlechtem Seiteninhalt und ahnungslosen Gestaltern kriegt jedes noch so kompakte Datenformat wieder bis ins unsinnigste aufgeblasen 😉