TS: HTML-Elemente seit HTML5

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

  1. 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

    1. 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

      1. @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

  2. 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

    --
    Signaturen sind bloed (Steel) und Markdown ist mächtig.
    1. 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

      1. 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

        --
        Signaturen sind bloed (Steel) und Markdown ist mächtig.
        1. 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

  3. 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

    1. 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

      1. 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

        1. 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

          1. 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

            1. 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

              1. @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

                1. 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

                  --
                  Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
                  Terry Pratchett, „Gevatter Tod“
                  1. @@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 🖖

                    --
                    Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
                    1. 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

                      --
                      Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
                      Terry Pratchett, „Gevatter Tod“
                      1. 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

                        1. 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

                          --
                          Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
                          Terry Pratchett, „Gevatter Tod“
                          1. 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

                            1. 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

                              --
                              Es schimmerte ein Licht am Ende des Tunnels und es stammte von einem Flammenwerfer.
                              Terry Pratchett, „Gevatter Tod“
                            2. 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

                              1. 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

                                1. 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

                                  1. 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

            2. @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

              1. 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

                1. @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

        2. 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

          1. 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

            1. 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

        3. @@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 🖖

          --
          Ist diese Antwort anstößig? Dann könnte sie nützlich sein.
          1. Hallo Gunnar

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

            Du meinst mit HTML 3.2?

            Gruß,

            var