HTML-Elemente seit HTML5

[TS]

Hallo und guten Morgen,

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

Da gibt es nun zumindest eine Übersichtsseite bei Mozilla
https://developer.mozilla.org/de/docs/Web/HTML/HTML5/HTML5_element_list.

Das Self-Wiki gefäält mir da noch nicht.

Allerdings wirft auch die Mozilla-Seite Fragen auf, z. B.:

<link> 	Wird verwendet, um externe JavaScript- und CSS-Dateien in das aktuelle HTML-Dokument einzubinden.

Ein Beispiel zur EInbindung von extern JavaScript-Sourcen ist alldeings dann schon nicht mehr dabei? Hat es das nun per Link-Element gegeben, oder nicht? Ich gehe davon aus, dass Mozillas Doku hier auch noch fehlerhaft ist, und JavaScript nur noch durch die <script></script>-Tags eingebunden wird.

Grüße
TS

[var]

Guten Morgen TS

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

Da gibt es nun zumindest eine Übersichtsseite bei Mozilla
https://developer.mozilla.org/de/docs/Web/HTML/HTML5/HTML5_element_list.

Da gäbe es auch noch diese Seite vom W3C: HTML5 Differences from HTML4

Über Veränderungen beim link Element im Zusammenhang mit der Einbindung von JavaScript steht da aber auch nichts...

War das nicht schon immer Sache von <script> ?

Gruß,

var

[TS]

Hallo und guten Morgen,

Da gäbe es auch noch diese Seite vom W3C: HTML5 Differences from HTML4

Über Veränderungen beim link Element im Zusammenhang mit der Einbindung von JavaScript steht da aber auch nichts...

War das nicht schon immer Sache von <script> ?

Genau das ist eben die Frage.

Ich kann mich dunkel daran erinnern, dass das auch mal mit

<link rel="JavaScript" type="text/javascript" href="meinjs.js">

funktioniert hat. Aber außer abgemurksten Threads in dubiosen Foren finde ich nichts mehr darüber und an meine uralten Sachen komme ich noch nicht wieder ran. Die liegen noch gepackt in einer Datensicherung.

Grüße
TS

[var]

@TS

Schau mal in die HTML 3.2 Spec: HTML 3.2 Reference Specification

„LINK elements can be used in principle:

[...]

c. for linking associated resources such as style sheets and scripts“

Ging wohl tatsächlich mal. ;-)

Gruß,

var

[Matthias Apsel]

Hallo TS,

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

Das Self-Wiki gefällt mir da noch nicht.

siehe: Forum: umleitung-von-selfhtml-auf-wiki, insbesondere #m1639833 ff. und dort besonders #m1639845

Bis demnächst
Matthias

[TS]

Hallo und guten Morgen,

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

Das Self-Wiki gefällt mir da noch nicht.

siehe: Forum: umleitung-von-selfhtml-auf-wiki, insbesondere #m1639833 ff. und dort besonders #m1639845

verstehe ich jetzt nicht.

Ich suche primär etwas über das link-Element und das script-Element zur Einbindung von Javascript

Grüße
TS

[Matthias Apsel]

Hallo TS,

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

Das Self-Wiki gefällt mir da noch nicht.

siehe: Forum: umleitung-von-selfhtml-auf-wiki, insbesondere #m1639833 ff. und dort besonders #m1639845

verstehe ich jetzt nicht.

Ich suche primär etwas über das link-Element und das script-Element zur Einbindung von Javascript

Ich habe dann auf den anderen Teil deines Beitrages geantwortet:
Nämlich

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

und

Das Self-Wiki gefällt mir da noch nicht.

Bis demnächst
Matthias

[TS]

Hallo und guten Morgen,

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

Das Self-Wiki gefällt mir da noch nicht.

siehe: Forum: umleitung-von-selfhtml-auf-wiki, insbesondere #m1639833 ff. und dort besonders #m1639845

verstehe ich jetzt nicht.

Ich suche primär etwas über das link-Element und das script-Element zur Einbindung von Javascript

Ich habe dann auf den anderen Teil deines Beitrages geantwortet:
Nämlich

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

und

Das Self-Wiki gefällt mir da noch nicht.

Tja, wenn ich das richtig verstehe, gefällt das Anderen auch nicht. Das nützt mir jetzt aber trotzdem nichts, oder sehe ich jetzt den Wald vor lauter Bäumen nicht?

Grüße
TS

[woodfighter]

Tach,

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

http://www.w3.org/TR/html5-diff/

Hat es das nun per Link-Element gegeben, oder nicht? Ich gehe davon aus, dass Mozillas Doku hier auch noch fehlerhaft ist, und JavaScript nur noch durch die <script></script>-Tags eingebunden wird.

Ob das früher funktioniert hat, habe ich keine Ahnung; aber wenn ich die HTML5-Spec richtig verstehe, sollte es funktionieren, wenn du ein passendes type-Attribut mitgibst; allerdings ist es nicht sinnvoll, soweit ich mich entsinne ist es sinnvoll script-Elemente ans Ende der HTML-Datei zu packen und das geht mit link-Elementen nicht.

mfg
Woodfighter

[TS]

Hallo und guten Nachmittag,

ich versuche, mir Überblick über die HTML-Elemente zu verschaffen: was hat sich von HTML4 zu HTML5 verändert.

http://www.w3.org/TR/html5-diff/

Hat es das nun per Link-Element gegeben, oder nicht? Ich gehe davon aus, dass Mozillas Doku hier auch noch fehlerhaft ist, und JavaScript nur noch durch die <script></script>-Tags eingebunden wird.

Ob das früher funktioniert hat, habe ich keine Ahnung; aber wenn ich die HTML5-Spec richtig verstehe, sollte es funktionieren, wenn du ein passendes type-Attribut mitgibst; allerdings ist es nicht sinnvoll, soweit ich mich entsinne ist es sinnvoll script-Elemente ans Ende der HTML-Datei zu packen und das geht mit link-Elementen nicht.

Stimmt auffallend. Danke für den Hinweis.
Die Objekte, auf die sich das JavaScriot beziehen soll, müssen erst vorhanden sein.

Grüße
TS

[woodfighter]

Tach,

soweit ich mich entsinne ist es sinnvoll script-Elemente ans Ende der HTML-Datei zu packen und das geht mit link-Elementen nicht.

Stimmt auffallend. Danke für den Hinweis.
Die Objekte, auf die sich das JavaScriot beziehen soll, müssen erst vorhanden sein.

nein, es geht darum, dass der Parser bei einem Script-Tag anhalten und das Script laden muss, es könnte ja document.write() enthalten sein; macht er das beim Header dauert das Laden für den User gefühlt länger, weil nichts sichtbares passiert.

mfg
Woodfighter

[var]

Hallo Woodfighter

nein, es geht darum, dass der Parser bei einem Script-Tag anhalten und das Script laden muss, es könnte ja document.write() enthalten sein; macht er das beim Header dauert das Laden für den User gefühlt länger, weil nichts sichtbares passiert.

Und die Ausnahme von der Regel ist dann, wenn umgekehrt Inhalte erst dynamisch in JavaScript erstellt werden sollen.

In diesem Fall ist es sinnvoll, das entsprechende Script vor den eigentlichen Dokumentinhalt zu setzen, allerdings aus den von dir genannten Gründen optimalerweise nur den Teil, der das sichtbare Layout auch tatsächlich beeinflusst.

Beste Grüße,

var

[TS]

Hallo und guten Nachmittag,

nein, es geht darum, dass der Parser bei einem Script-Tag anhalten und das Script laden muss, es könnte ja document.write() enthalten sein; macht er das beim Header dauert das Laden für den User gefühlt länger, weil nichts sichtbares passiert.

Und die Ausnahme von der Regel ist dann, wenn umgekehrt Inhalte erst dynamisch in JavaScript erstellt werden sollen.

Das können dann aber nur Inhalte sein, die sich direkt ins html-Element einhängen. Das body-Element ist dann ja noch gar nicht vorhanden.

Grüße
TS

[woodfighter]

Tach,

Das können dann aber nur Inhalte sein, die sich direkt ins html-Element einhängen. Das body-Element ist dann ja noch gar nicht vorhanden.

var meinte etwas wie:

</head>

<body>
  <script>

mfg
Woodfighter

[var]

@Woodfighter

var meinte etwas wie:

</head>

<body>
  <script>

Jein. Das ist zwar auch möglich, aber nach der HTML5 Spec kann das script Element ebenso im head Bereich des Dokuments notiert werden.

Gruß,

var

[Auge]

Hallo

var meinte etwas wie:

</head>

<body>
  <script>

Jein. Das ist zwar auch möglich, aber nach der HTML5 Spec kann das script Element ebenso im head Bereich des Dokuments notiert werden.

Öhhm, wie schon immer™.

Man muss bei der Notation im head halt darauf achten, dass man die Ausführung erst beginnen lässt, wenn das Dokument im Browser angekommen ist, was sich wiederum grundsätzlich verzögert, weil erst der javaScript-Code geladen und analysiert werden muss. Wird der JS-Code erst am Ende des Dokuments aufgerufen, ist das Dokument selbst bereits da.

Was im Einzelfall günstiger ist, muss man von Fall zu Fall jeweils erneut entscheiden. Ich persönlich finde die Notation im head „sinniger“/„logischer“, den Tatsachen z.B. in Hinsicht auf die Performanz beim Aufbau der Seite kann ich mich aber auch nicht entziehen.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Man muss bei der Notation im head halt darauf achten, dass man die Ausführung erst beginnen lässt, wenn das Dokument im Browser angekommen ist,

Also auf das DOMContentLoaded-Event lauschen.

was sich wiederum grundsätzlich verzögert, weil erst der javaScript-Code geladen und analysiert werden muss.

In HTML5 gibt es die Attribute async und defer fürs script-Element, die das Blockieren des Renderns verhindern.

LLAP 🖖

[Auge]

Hallo

Man muss bei der Notation im head halt darauf achten, dass man die Ausführung erst beginnen lässt, wenn das Dokument im Browser angekommen ist,

Also auf das DOMContentLoaded-Event lauschen.

was sich wiederum grundsätzlich verzögert, weil erst der javaScript-Code geladen und analysiert werden muss.

In HTML5 gibt es die Attribute async und defer fürs script-Element, die das Blockieren des Renderns verhindern.

Wenn ich die Beschreibung der genannten Attribute in der Doku betrachte, überschneiden und widersprechen sich deren Anwendungsgebiete teilweise miteinander und mit DOMContentLoaded.

• async: Das Script wird ausgeführt, sobald es geladen ist.
• defer: Das (externe) Script wird erst ausgeführt, wenn die Seite geladen ist.

Das Attribut async sorgt dafür, dass die Ausführung des Skripts erst dann beginnt, wenn es selbst vollständig geladen ist. Das Attribut defer hingegen startet die Ausführung, wenn das Dokument vollständig geladen ist. Die beiden Attribute sollten, wenn ich das richtig deute, nicht zusammen notiert werden, weil sich ihre Aussagen widersprechen. Andererseits scheint mit defer zum selben Zeitpunkt zuzuschlagen, wenn DOMContentLoaded auslösen würde, falls script ohne das Attribut defer notiert ist. Oder liege ich damit falsch?

Tschö, Auge

[TS]

Hallo und guten Nachmittag,

Man muss bei der Notation im head halt darauf achten, dass man die Ausführung erst beginnen lässt, wenn das Dokument im Browser angekommen ist,

Also auf das DOMContentLoaded-Event lauschen.

was sich wiederum grundsätzlich verzögert, weil erst der javaScript-Code geladen und analysiert werden muss.

In HTML5 gibt es die Attribute async und defer fürs script-Element, die das Blockieren des Renderns verhindern.

Wenn ich die Beschreibung der genannten Attribute in der Doku betrachte, überschneiden und widersprechen sich deren Anwendungsgebiete teilweise miteinander und mit DOMContentLoaded.

• async: Das Script wird ausgeführt, sobald es geladen ist.
• defer: Das (externe) Script wird erst ausgeführt, wenn die Seite geladen ist.

Das Attribut async sorgt dafür, dass die Ausführung des Skripts erst dann beginnt, wenn es selbst vollständig geladen ist. Das Attribut defer hingegen startet die Ausführung, wenn das Dokument vollständig geladen ist. Die beiden Attribute sollten, wenn ich das richtig deute, nicht zusammen notiert werden, weil sich ihre Aussagen widersprechen. Andererseits scheint mit defer zum selben Zeitpunkt zuzuschlagen, wenn DOMContentLoaded auslösen würde, falls script ohne das Attribut defer notiert ist. Oder liege ich damit falsch?

Woraus schließt Du jetzt, dass sich die Attribute widersprechen?
Steht das so in der Spezifikation, dass sie nicht gemeinsam verwendet werden dürfen?

Ich würde das sonst so verstehen, dass sie beide gemeinsam dann dafür sorgen, dass sowohl Script als auch Content geladen sein müssen, damit die Interpretation und Ausführung des Scriptes (der Scripte?) vorgenommen wird.

Das würde mir ersparen, einen eigenen Eventlistener dafür einrichten zu müssen und in jeder dämlichen Funktion bzw. Anweisung noch das Semaphor abfragen zu müssen.

Nur was passiert in Browsern, die HTML5 noch nicht interpretieren wollen?

Grüße
TS

[Auge]

Hallo

Wenn ich die Beschreibung der genannten Attribute in der Doku betrachte, überschneiden und widersprechen sich deren Anwendungsgebiete teilweise miteinander und mit DOMContentLoaded.

• async: Das Script wird ausgeführt, sobald es geladen ist.
• defer: Das (externe) Script wird erst ausgeführt, wenn die Seite geladen ist.

Das Attribut async sorgt dafür, dass die Ausführung des Skripts erst dann beginnt, wenn es selbst vollständig geladen ist. Das Attribut defer hingegen startet die Ausführung, wenn das Dokument vollständig geladen ist. Die beiden Attribute sollten, wenn ich das richtig deute, nicht zusammen notiert werden, weil sich ihre Aussagen widersprechen. Andererseits scheint mit defer zum selben Zeitpunkt zuzuschlagen, wenn DOMContentLoaded auslösen würde, falls script ohne das Attribut defer notiert ist. Oder liege ich damit falsch?

Woraus schließt Du jetzt, dass sich die Attribute widersprechen?

Mit dem einen Attribut rennt das Skript los, sobald es selbst geladen ist, egal, ob das Dokument bereits geladen ist. Mit dem anderen Attribut wartet es definitiv, bis das Dokument geladen wurde. Das ist mMn ein Widerspruch.

Steht das so in der Spezifikation, dass sie nicht gemeinsam verwendet werden dürfen?

Kann ich mir nicht vorstellen, auch wenn ich es (so kurz vor Feierabend) nicht nachgeschlagen habe. Wären es zwei sich ausschließende Angaben, würde ich sie als zwei Werte eines gemeinsamen Attributs definieren.

Ich würde das sonst so verstehen, dass sie beide gemeinsam dann dafür sorgen, dass sowohl Script als auch Content geladen sein müssen, damit die Interpretation und Ausführung des Scriptes (der Scripte?) vorgenommen wird.

Ja, auch nach meinem Dafürhalten stellen beide Attribute bei gemeinsamer Verwendung sicher, dass sowohl das Skript, als auch das Dokument geladen ist, aber das riecht mir irgendwie komisch.

Das würde mir ersparen, einen eigenen Eventlistener dafür einrichten zu müssen und in jeder dämlichen Funktion bzw. Anweisung noch das Semaphor abfragen zu müssen.

Hmm. Für sich aus der Bedienung der Seite ergebende Aufrufe brauche ich die Listener sowieso. Für allgemeine Skripte, die im Dokument ständig laufen, brauche ich nur einen weiteren Eventlistener. Der macht den Kohl auch nicht fett.

Nur was passiert in Browsern, die HTML5 noch nicht interpretieren wollen?

Da issa wieder, der Eventlistener. :-)

Tschö, Auge

[woodfighter]

Tach,

Steht das so in der Spezifikation, dass sie nicht gemeinsam verwendet werden dürfen?

Kann ich mir nicht vorstellen, auch wenn ich es (so kurz vor Feierabend) nicht nachgeschlagen habe.

Warum Doku lesen, wenn man stattdessen spekulieren kann? ;-)

There are three possible modes that can be selected using these attributes. If the async attribute is present, then the script will be executed asynchronously, as soon as it is available. If the async attribute is not present but the defer attribute is present, then the script is executed when the page has finished parsing. If neither attribute is present, then the script is fetched and executed immediately, before the user agent continues parsing the page.

[…]

The defer attribute may be specified even if the async attribute is specified, to cause legacy Web browsers that only support defer (and not async) to fall back to the defer behavior instead of the synchronous blocking behavior that is the default.

mfg
Woodfighter

[Auge]

Hallo

Steht das so in der Spezifikation, dass sie nicht gemeinsam verwendet werden dürfen?

Kann ich mir nicht vorstellen, auch wenn ich es (so kurz vor Feierabend) nicht nachgeschlagen habe.

Warum Doku lesen, wenn man stattdessen spekulieren kann? ;-)

There are three possible modes …

Was meine Spekulation bestätigt.

Außerdem, „Feierabend“ war das Zauberwort. :-)

Tschö, Auge

[TS]

Hallo und guten Abend,

Steht das so in der Spezifikation, dass sie nicht gemeinsam verwendet werden dürfen?

Kann ich mir nicht vorstellen, auch wenn ich es (so kurz vor Feierabend) nicht nachgeschlagen habe.

Warum Doku lesen, wenn man stattdessen spekulieren kann? ;-)

Ist zumindest kommunikativer und bei mir festigt sich das dann eher ;-P

There are three possible modes that can be selected using these attributes. If the async attribute is present, then the script will be executed asynchronously, as soon as it is available. If the async attribute is not present but the defer attribute is present, then the script is executed when the page has finished parsing. If neither attribute is present, then the script is fetched and executed immediately, before the user agent continues parsing the page.

[…]

The defer attribute may be specified even if the async attribute is specified, to cause legacy Web browsers that only support defer (and not async) to fall back to the defer behavior instead of the synchronous blocking behavior that is the default.

An dieser Stelle halte ich es aber doch eher noch mit Goethe:

 „Da steh ich nun, ich armer Tor,  
und bin so klug als wie zuvor.“ 

Grüße
TS

[woodfighter]

Tach,

An dieser Stelle halte ich es aber doch eher noch mit Goethe:

 „Da steh ich nun, ich armer Tor,  
und bin so klug als wie zuvor.“ 

wenn async da ist, gilt async; wenn defer da ist und async nicht (oder async nicht unterstützt wird vom UA), gilt defer; sonst wird blockiert.

mfg
Woodfighter

[TS]

Hallo und guten Abend,

An dieser Stelle halte ich es aber doch eher noch mit Goethe:

 „Da steh ich nun, ich armer Tor,  
und bin so klug als wie zuvor.“ 

wenn async da ist, gilt async; wenn defer da ist und async nicht (oder async nicht unterstützt wird vom UA), gilt defer; sonst wird blockiert.

Ist dann doch trotzdem noch unlogisch und Auge hat Recht.

Wenn ich defer benutze, wird die Script-Interpretaion also schon angefangen, nachdem Content geladen wurde, obwohl es selber noch nicht vollständig geladen wurde? Oder wie ist das zu verstehen?

Und wenn man async vorgibt, wird es sofort interpretiert, egal, ob der Content Komplett ist oder es selber vollständig geladen ist.

So verstehe ich das jetzt, obwohl ich auch noch nicht vollständig geladen bin heute ;-P

Grüße
TS

[woodfighter]

Tach,

Wenn ich defer benutze, wird die Script-Interpretaion also schon angefangen, nachdem Content geladen wurde, obwohl es selber noch nicht vollständig geladen wurde? Oder wie ist das zu verstehen?

ob Browser bei teilweise empfangenen Javascript-Ressourcen schon anfangen diese auszuführen, weiß ich nicht, spielt hier aber keine Rolle; defer sorgt dafür, dass der Browser das script-Element sieht, einen HTTP-Request dafür startet aber nicht darauf wartet, dass dieser fertig ist und das Javascript ausgeführt wurde. Das Javascript wird dann ausgeführt, wenn der Browser mit der HTML-Datei fertig ist.

Und wenn man async vorgibt, wird es sofort interpretiert, egal, ob der Content Komplett ist oder es selber vollständig geladen ist.

Nein, async sorgt dafür, dass der Browser das script-Element sieht, einen HTTP-Request dafür absetzt und es dann parallel zum weiteren Rendering der Seite ausführt, falls das Javascript geladen ist, bevor das Rendering fertig ist.

Beide Attribute sorgen also dafür, dass der HTML-Parser nicht blockiert wird; defer sorgt dafür dass das Javascript nach dem Rendern ausgeführt wird, asnyc dafür, dass das potentiell parallel passiert.

mfg
Woodfighter

[var]

@TS

Das können dann aber nur Inhalte sein, die sich direkt ins html-Element einhängen. Das body-Element ist dann ja noch gar nicht vorhanden.

Wenn der Browser ein HTML-Dokument ausführt, erstellt er eine innere Repräsentation des DOM und da die Elemente html, head und body obligatorisch sind, werden sie dabei automatisch eingefügt, weshalb man ihre Deklaration im Dokument theoretisch auch weglassen kann.

Gruß,

var

[TS]

Hallo und guten Nachmittag,

Das können dann aber nur Inhalte sein, die sich direkt ins html-Element einhängen. Das body-Element ist dann ja noch gar nicht vorhanden.

Wenn der Browser ein HTML-Dokument ausführt, erstellt er eine innere Repräsentation des DOM und da die Elemente html, head und body obligatorisch sind, werden sie dabei automatisch eingefügt, weshalb man ihre Deklaration im Dokument theoretisch auch weglassen kann.

Das heißt also, dass die dann immer als erstes vorhanden sind, und nur noch "aufgefüllt" (definiert) werden durch das Dokument?

Grüße
TS

[var]

@TS

Wenn der Browser ein HTML-Dokument ausführt, erstellt er eine innere Repräsentation des DOM und da die Elemente html, head und body obligatorisch sind, werden sie dabei automatisch eingefügt, weshalb man ihre Deklaration im Dokument theoretisch auch weglassen kann.

Das heißt also, dass die dann immer als erstes vorhanden sind, und nur noch "aufgefüllt" (definiert) werden durch das Dokument?

Soweit ich das verstanden habe, ja.

Gruß,

var

[TS]

Hallo und guten Nachmittag,

soweit ich mich entsinne ist es sinnvoll script-Elemente ans Ende der HTML-Datei zu packen und das geht mit link-Elementen nicht.

Stimmt auffallend. Danke für den Hinweis.
Die Objekte, auf die sich das JavaScriot beziehen soll, müssen erst vorhanden sein.

nein, es geht darum, dass der Parser bei einem Script-Tag anhalten und das Script laden muss, es könnte ja document.write() enthalten sein; macht er das beim Header dauert das Laden für den User gefühlt länger, weil nichts sichtbares passiert.

"Nein" weil es falsch ist, oder weil Du das jetzt nicht meintest?

Nun verwirr mich bitte nicht vollständig. Ich übe nämlich gerade daran, das für mein kleines Tool so weit zu formalisieren, wie es geht. da geht es um primär strikte Trennung von HTML, JavaScript, CSS und Datenbeschaffung im Backend. Nachher müssen die natürlich schrittweise wieder zusammengeführt werden, zum größten Teil erst vom Browser.

Grüße
TS

[woodfighter]

Tach,

"Nein" weil es falsch ist, oder weil Du das jetzt nicht meintest?

weil es falsch war; dass man nix mit Elementen anzustellen versucht, verhindert man ja bereits dadurch, dass man sich an das passende Event hängt (domready?).

mfg
Woodfighter

[TS]

Hallo und guten Nachmittag,

"Nein" weil es falsch ist, oder weil Du das jetzt nicht meintest?

weil es falsch war; dass man nix mit Elementen anzustellen versucht, verhindert man ja bereits dadurch, dass man sich an das passende Event hängt (domready?).

... wueder 'was gelernt. Muss ich mir die möglichen Events doch nochmal vornehmen.

Grüße
TS

[Gunnar Bittersmann]

@@woodfighter

nein, es geht darum, dass der Parser bei einem Script-Tag anhalten und das Script laden muss

Außer wenn das Blockieren des Renderns durch async/defer verhindert wird.

Wird bei per link-Element eingebunden Scripten das Rendern auch blockiert?

Und wenn Browser das unterstützen, sollten Stylesheets und Scripte auch per Link-Feld im HTTP-Header eingebunden werden können.

LLAP 🖖

[var]

Hallo Gunnar

Wird bei per link-Element eingebunden Scripten das Rendern auch blockiert?

Du meinst mit HTML 3.2?

Gruß,

var