Hallo Bernd, der Browser liest das HTML Dokument von oben nach unten ein. <script> darf innerhalb von head und body überall vorkommen, wo auch ein anderes Tag stehen darf. Es mag Ausnahmen geben, die müsste ich jetzt aber recherchieren. Die Spec sagt zum script-Element: „Permitted parents: Any element that accepts metadata content, or any element that accepts phrasing content.“ Sobald der Browser ein Script-Tag antrifft, unterbricht er die HTML Verarbeitung und führt das Script aus. Wenn es ein externes Script ist, wird es erstmal geladen, und der Browser wartet. Das liegt daran, dass das Script ein document.write ausführen kann und das, was da geschrieben wird, nach Script-Ende so verarbeitet wird, als hätte es an Stelle des Script-Bereichs gestanden. D.h. man muss schon genau wissen, was man da tut, um den Seitenaufbau nicht zu ruinieren. Ein Inlinescript, dass mal schnell eine Klasse nachträgt, ist technisch kein Problem. Es widerspricht zwar der Idee des "unobtrusive javascript", und vermutlich könnte man das Problem auf unaufdringliche Weise mit einem MutationObserver lösen, der jede Änderung am body überwacht, dafür handelt man sich dann aber eine kräftige Performancebremse beim Laden der Seite ein (weil der Observer für jedes neue HTML Element im Body aufgerufen wird). Puristen mögen über meine Lösung die Nase rümpfen, aus meiner Sicht ist sie sinnvoll. Der gestern gezeigte Vorschlag ist auch nicht mein erster Anlauf gewesen. Meine Annahme war nämlich, dass das gallery-widget erst im DOM verfügbar ist, wenn das schließende div Tag verarbeitet wurde. Deshalb hatte ich das Script zunächst hinter dem schließenden Tag des gallery-widget stehen. Daraufhin zuckte es kürzer, aber es zuckte immer noch. Danach kam ich auf die folgende, abstruse Idee: ~~~html,bad <script> // Demo, ergänze für produktiven Einsatz eine Prüfung, ob localStorage vorhanden ist! document.write("<div class='gallery-widget "+ (localStorage.toggle || "") + "'>"); </script> <noscript> <div class='gallery-widget'> </noscript> ~~~ Aber sowas als vorbildlich zu präsentieren, das widerstrebte mir. Und dann habe ich die gestern gezeigte Lösung einfach mal ausprobiert und - siehe und staune! - das Widget ist tatsächlich schon nach dem öffnenden Tag im DOM. Ist auch eigentlich logisch, wie sollen sonst die Kind-Elemente hineinkommen 🤦‍♂️[^1]. [^1]: [falls dein Browser das Emoji falsch anzeigt oder es zu klein ist](https://emojipedia.org/man-facepalming/) @Christian Kruse: Deine Emoji-Logik scheint bei Emojis, die aus zwei Zeichen kombiniert werden, nicht zu funktionieren. Im Editor sehe ich das richtige Emoji, im gespeicherten Beitrag das Basis-Emoji und das kombinierte Zeichen separat. Und du haust auch noch ein span dazu, damit es auf keinen Fall versehentlich richtig kombiniert wird 😉 _Rolf_ -- sumpsi - posui - clusi

Hallo Bernd, der Browser liest das HTML Dokument von oben nach unten ein. <script> darf innerhalb von head und body überall vorkommen, wo auch ein anderes Tag stehen darf. Es mag Ausnahmen geben, die müsste ich jetzt aber recherchieren. Die Spec sagt zum script-Element: „Permitted parents: Any element that accepts metadata content, or any element that accepts phrasing content.“ Sobald der Browser ein Script-Tag antrifft, unterbricht er die HTML Verarbeitung und führt das Script aus. Wenn es ein externes Script ist, wird es erstmal geladen, und der Browser wartet. Das liegt daran, dass das Script ein document.write ausführen kann und das, was da geschrieben wird, nach Script-Ende so verarbeitet wird, als hätte es an Stelle des Script-Bereichs gestanden. D.h. man muss schon genau wissen, was man da tut, um den Seitenaufbau nicht zu ruinieren. Ein Inlinescript, dass mal schnell eine Klasse nachträgt, ist kein Problem. Der gestern gezeigte Vorschlag ist auch nicht mein erster Anlauf gewesen. Meine Annahme war nämlich, dass das gallery-widget erst im DOM verfügbar ist, wenn das schließende div Tag verarbeitet wurde. Deshalb hatte ich das Script zunächst hinter dem schließenden Tag des gallery-widget stehen. Daraufhin zuckte es kürzer, aber es zuckte immer noch. Danach kam ich auf die folgende, abstruse Idee: ~~~html,bad <script> // Demo, ergänze für produktiven Einsatz eine Prüfung, ob localStorage vorhanden ist! document.write("<div class='gallery-widget "+ (localStorage.toggle || "") + "'>"); </script> <noscript> <div class='gallery-widget'> </noscript> ~~~ Aber sowas als vorbildlich zu präsentieren, das widerstrebte mir. Und dann habe ich die gestern gezeigte Lösung einfach mal ausprobiert und - siehe und staune! - das Widget ist tatsächlich schon nach dem öffnenden Tag im DOM. Ist auch eigentlich logisch, wie sollen sonst die Kind-Elemente hineinkommen 🤦‍♂️[^1]. [^1]: [falls dein Browser das Emoji falsch anzeigt oder es zu klein ist](https://emojipedia.org/man-facepalming/) @Christian Kruse: Deine Emoji-Logik scheint bei Emojis, die aus zwei Zeichen kombiniert werden, nicht zu funktionieren. Im Editor sehe ich das richtige Emoji, im gespeicherten Beitrag das Basis-Emoji und das kombinierte Zeichen separat. Und du haust auch noch ein span dazu, damit es auf keinen Fall versehentlich richtig kombiniert wird 😉 _Rolf_ -- sumpsi - posui - clusi

Hallo Bernd, der Browser liest das HTML Dokument von oben nach unten ein. <script> darf innerhalb von head und body überall vorkommen, wo auch ein anderes Tag stehen darf. Es mag Ausnahmen geben, die müsste ich jetzt aber recherchieren. Die Spec sagt zum script-Element: „Permitted parents: Any element that accepts metadata content, or any element that accepts phrasing content.“ Sobald der Browser ein Script-Tag antrifft, unterbricht er die HTML Verarbeitung und führt das Script aus. Wenn es ein externes Script ist, wird es erstmal geladen, und der Browser wartet. Das liegt daran, dass das Script ein document.write ausführen kann und das, was da geschrieben wird, nach Script-Ende so verarbeitet wird, als hätte es an Stelle des Script-Bereichs gestanden. D.h. man muss schon genau wissen, was man da tut, um den Seitenaufbau nicht zu ruinieren. Ein Inlinescript, dass mal schnell eine Klasse nachträgt, ist kein Problem. Der gestern gezeigte Vorschlag ist auch nicht mein erster Anlauf gewesen. Meine Annahme war nämlich, dass das gallery-widget erst im DOM verfügbar ist, wenn das schließende div Tag verarbeitet wurde. Deshalb hatte ich das Script zunächst hinter dem schließenden Tag des gallery-widget stehen. Daraufhin zuckte es kürzer, aber es zuckte immer noch. Danach kam ich auf die folgende, abstruse Idee: ~~~html,bad <script> // Demo, ergänze für produktiven Einsatz eine Prüfung, ob localStorage vorhanden ist! document.write("<div class='gallery-widget "+ (localStorage.toggle || "") + "'>"); </script> <noscript> <div class='gallery-widget'> </noscript> ~~~ Aber sowas als vorbildlich zu präsentieren, das widerstrebte mir. Und dann habe ich die gestern gezeigte Lösung einfach mal ausprobiert und - siehe und staune! - das Widget ist tatsächlich schon nach dem öffnenden Tag im DOM. Ist auch eigentlich logisch, wie sollen sonst die Kind-Elemente hineinkommen 🤦‍♂️[^1]. [^1]: [falls dein Browser das Emoji falsch anzeigt oder es zu klein ist](https://emojipedia.org/man-facepalming/) _Rolf_ -- sumpsi - posui - clusi

Hallo Bernd, der Browser liest das HTML Dokument von oben nach unten ein. <script> darf innerhalb von head und body überall vorkommen, wo auch ein anderes Tag stehen darf. Es mag Ausnahmen geben, die müsste ich jetzt aber recherchieren. Die Spec sagt zum script-Element: „Permitted parents: Any element that accepts metadata content, or any element that accepts phrasing content.“ Sobald der Browser ein Script-Tag antrifft, unterbricht er die HTML Verarbeitung und führt das Script aus. Wenn es ein externes Script ist, wird es erstmal geladen, und der Browser wartet. Das liegt daran, dass das Script ein document.write ausführen kann und das, was da geschrieben wird, nach Script-Ende so verarbeitet wird, als hätte es an Stelle des Script-Bereichs gestanden. D.h. man muss schon genau wissen, was man da tut, um den Seitenaufbau nicht zu ruinieren. Ein Inlinescript, dass mal schnell eine Klasse nachträgt, ist kein Problem. Der gestern gezeigte Vorschlag ist auch nicht mein erster Anlauf gewesen. Meine Annahme war nämlich, dass das gallery-widget erst im DOM verfügbar ist, wenn das schließende div Tag verarbeitet wurde. Deshalb hatte ich das Script zunächst hinter dem schließenden Tag des gallery-widget stehen. Daraufhin zuckte es kürzer, aber es zuckte immer noch. Danach kam ich auf die folgende, abstruse Idee: ~~~html,bad <script> // Demo, ergänze für produktiven Einsatz eine Prüfung, ob localStorage vorhanden ist! document.write("<div class='gallery-widget "+ (localStorage.toggle || "") + "'>"); </script> <noscript> <div class='gallery-widget'> </noscript> ~~~ Aber sowas als vorbildlich zu präsentieren, das widerstrebte mir. Und dann habe ich die gestern gezeigte Lösung einfach mal ausprobiert und - siehe und staune! - das Widget ist tatsächlich schon nach dem öffnenden Tag im DOM. Ist auch eigentlich logisch, wie sollen sonst die Kind-Elemente hineinkommen 🤦‍♂️ [^1]. [^1]: [falls dein Browser das Emoji falsch anzeigt oder es zu klein ist](https://emojipedia.org/man-facepalming/) _Rolf_ -- sumpsi - posui - clusi

Hallo Bernd, der Browser liest das HTML Dokument von oben nach unten ein. <script> darf innerhalb von head und body überall vorkommen, wo auch ein anderes Tag stehen darf. Es mag Ausnahmen geben, die müsste ich jetzt aber recherchieren. Die Spec sagt zum script-Element: „Permitted parents: Any element that accepts metadata content, or any element that accepts phrasing content.“ Sobald der Browser ein Script-Tag antrifft, unterbricht er die HTML Verarbeitung und führt das Script aus. Wenn es ein externes Script ist, wird es erstmal geladen, und der Browser wartet. Das liegt daran, dass das Script ein document.write ausführen kann und das, was da geschrieben wird, nach Script-Ende so verarbeitet wird, als hätte es an Stelle des Script-Bereichs gestanden. D.h. man muss schon genau wissen, was man da tut, um den Seitenaufbau nicht zu ruinieren. Ein Inlinescript, dass mal schnell eine Klasse nachträgt, ist kein Problem. Der gestern gezeigte Vorschlag ist auch nicht mein erster Anlauf gewesen. Meine Annahme war nämlich, dass das gallery-widget erst im DOM verfügbar ist, wenn das schließende div Tag verarbeitet wurde. Deshalb hatte ich das Script zunächst hinter dem schließenden Tag des gallery-widget stehen. Daraufhin zuckte es kürzer, aber es zuckte immer noch. Danach kam ich auf die folgende, abstruse Idee: ~~~html,bad <script> // Demo, ergänze für produktiven Einsatz eine Prüfung, ob localStorage vorhanden ist! document.write("<div class='gallery-widget "+ (localStorage.toggle || "") + "'>"); </script> <noscript> <div class='gallery-widget'> </noscript> ~~~ Aber sowas als vorbildlich zu präsentieren, das widerstrebte mir. Und dann habe ich die gestern gezeigte Lösung einfach mal ausprobiert und - siehe und staune! - das Widget ist tatsächlich schon nach dem öffnenden Tag im DOM. Ist auch eigentlich logisch, wie sollen sonst die Kind-Elemente hineinkommen 🤦‍♂️ [^1]. [^1]: [falls dein Browser das Emoji falsch anzeigt oder es zu klein ist](https://emojipedia.org/man-facepalming/) _Rolf_ -- sumpsi - posui - clusi