nicht angemeldet Mo
Patrick Andrieu
Mo
Gunnar Bittersmann
Mo
Mo
Mo
Gunnar Bittersmann
Gunnar Bittersmann
Guten Abend,
ich möchte bestimmte Elemente (z.B. Formularbuttons) nur angezeigt haben, wenn JavaScript nicht aktiviert ist. Dabei möchte weder im HTML-Code um jedes dieser Elemente ein <noscript> setzen, noch jedem dieser Elemente eine eindeutige ID zuweisen (dafür gäbe es dann ein jQuery-Plugin). Ich möchte diesen Elementen einfach eine Klasse zuweisen können, sodass jedes dieser Element dann, sobald es geladen wird (möglichst sofort und nicht erst, wenn das Dokument fertig geladen ist), display='none' zugewiesen bekommt. Lässt sich das realisieren?
Danke im voraus,
Mo
Guten Abend,
(dafür gäbe es dann ein jQuery-Plugin). Ich möchte diesen Elementen einfach eine Klasse zuweisen können, sodass jedes dieser Element dann, sobald es geladen wird (möglichst sofort und nicht erst, wenn das Dokument fertig geladen ist), display='none' zugewiesen bekommt. Lässt sich das realisieren?
und was hindert dich daran, das mit jquery zu machen?
Gruß Gunther
Hallo Mo!
ich möchte bestimmte Elemente (z.B. Formularbuttons) nur angezeigt haben, wenn JavaScript nicht aktiviert ist. Dabei möchte weder im HTML-Code um jedes dieser Elemente ein <noscript> setzen, noch jedem dieser Elemente eine eindeutige ID zuweisen (dafür gäbe es dann ein jQuery-Plugin). Ich möchte diesen Elementen einfach eine Klasse zuweisen können, sodass jedes dieser Element dann, sobald es geladen wird (möglichst sofort und nicht erst, wenn das Dokument fertig geladen ist), display='none' zugewiesen bekommt. Lässt sich das realisieren?
Vielleicht hilft Dir das Beispiel, das ich einst mit Cybaers Denkschubs gebastelt habe:
http://forum.de.selfhtml.org/archiv/2007/6/t153467/#m999846
Viele Grüße aus Frankfurt/Main,
Patrick
Hallo Patrick,
ich habe mir das aus deinem Beispiel und dem folgenden Post nun folgendermaßen zusammengestöpselt:
<script type="text/javascript">
window.onload = function () {
document.documentElement.className = 'hasJs';
}
</script>
<style type="text/css">
html.hasJs .noscript {
display: none;
}
</style>
Danke für die Hilfe!
Mo
Hi,
document.documentElement.className = 'hasJs';
<style type="text/css">
html.hasJs .noscript {
Fuer html ist ein class-Attribut nicht definiert - es mag trotzdem "funktionieren", aber korrekt ist es nicht.
Warum bist du nicht bei der Variante mit body geblieben, die ich vorgeschlagen habe?
MfG ChrisB
Hi.
Fuer html ist ein class-Attribut nicht definiert - es mag trotzdem "funktionieren", aber korrekt ist es nicht.
Warum bist du nicht bei der Variante mit body geblieben, die ich vorgeschlagen habe?
Disclaimer: Was ich jetzt sage, basiert auf Halbwissen.
Ich ging immer davon aus, per JS könne man recht viel zuweisen. Wenn ich einen Strict-Dokumenttyp verwende und per JS Links target='new' zuweise, verletze ich doch auch keinen Standard? Falls entsprechende Standards nun vorsehen würden, dass man html einen Klassennamen zuweisen kann, wäre das doch kein Problem, oder? Das müsste man jetzt nachprüfen...
Zurück zum konkreten Problem: Wie würde denn dein Code aussehen und kann man davon ausgehen, dass die zu versteckenden Elemente dann auch nicht kurz aufblitzen?
Gruß,
Mo
Hi.
Zurück zum konkreten Problem: Wie würde denn dein Code aussehen und kann man davon ausgehen, dass die zu versteckenden Elemente dann auch nicht kurz aufblitzen?
Gruß,
Mo
Nachtrag: Habe das eben in Firefox und Opera getestet. Scheint so, als würde das genauso zuverlässig arbeiten wie vorher; egal wie oft ich auf meinem recht alten PC auf F5 hämmere, es erscheint einfach nicht. IE und Safari stehen zum Testen noch aus.
Sauberer ist es auf jeden Fall, deswegen werde ich das jetzt einfach so verwenden. Danke für den Hinweis.
Mo
Hi,
Falls entsprechende Standards nun vorsehen würden, dass man html einen Klassennamen zuweisen kann, wäre das doch kein Problem, oder? Das müsste man jetzt nachprüfen...
Du kannst nicht wissen, ob das ein Problem ist, geschweige denn, ob es mal zu einem Problem wird, wenn es jetzt tatsächlich keines sein sollte.
Denn Du kannst nicht sagen, ob zukünftige Browser sich in diesem fehlerhaften Zustand genauso fehlertolerant verhalten.
Theoretisch ist auch ein DIV- in einem P-Element verboten. Trotzdem kannst in vielen Browsern das mit JS machen. Aber auch nicht in allen.
Und es gibt weitere Beispiele dafür ...
Gruß, Cybaer
Hi,
Falls entsprechende Standards nun vorsehen würden, dass man html einen Klassennamen zuweisen kann, wäre das doch kein Problem, oder? Das müsste man jetzt nachprüfen...
Du kannst nicht wissen, ob das ein Problem ist, geschweige denn, ob es mal zu einem Problem wird, wenn es jetzt tatsächlich keines sein sollte.
Denn Du kannst nicht sagen, ob zukünftige Browser sich in diesem fehlerhaften Zustand genauso fehlertolerant verhalten.
Wenn der Standard spezifiziert, dass man das per JS so zuweisen kann, sollte ein standardkonformer Browser auch mit dem daraus resultierenden Zustand umgehen können, oder liege ich da falsch?
Die Frage ist natürlich, ob das so spezifiziert ist...
Mo
Wenn der Standard spezifiziert, dass man das per JS so zuweisen kann, sollte ein standardkonformer Browser auch mit dem daraus resultierenden Zustand umgehen können, oder liege ich da falsch?
Per JavaScript kann man allen möglichen Objekten irgendwelche Eigenschaften zuweisen. Verboten ist da nichts, das bedeutet aber nicht, dass ein Browser diese Eigenschaftszuweisung in irgendeiner Weise zur Kenntnis nimmt, sie also eine Funktion erfüllt.
Die Frage ist natürlich, ob das so spezifiziert ist...
Nein. DOM HTML regelt, welche Elementobjekte welche Eigenschaften haben. Und da das html-Element im HTML-Standard kein class-Attribut hat, hat das html-Elementobjekt im HTML-DOM auch keine Eigenschaft className.
Mathias
Die Frage ist natürlich, ob das so spezifiziert ist...
Nein. DOM HTML regelt, welche Elementobjekte welche Eigenschaften haben. Und da das html-Element im HTML-Standard kein class-Attribut hat, hat das html-Elementobjekt im HTML-DOM auch keine Eigenschaft className.
Kann sein, dass ich falsch liege, aber meiner Meinung nach ist der Knackpunkt folgende Zeile:
interface HTMLHtmlElement : HTMLElement {
HTMLElement hat aber eine Eigenschaft className.
Mo
Hi,
Kann sein, dass ich falsch liege, aber meiner Meinung nach ist der Knackpunkt folgende Zeile:
Nein, der Knackpunkt ist die HTML-DTD. Dort kann man nachschlagen, bzw. hier. Dort sind alle erlaubten Attribute aufgelistet (lang, dir und, deprecated, version). Alles andere ist der Beliebigkeit der Browserprogrammierer unterworfen ...
Gruß, Cybaer
Hi.
Nein, der Knackpunkt ist die HTML-DTD. Dort kann man nachschlagen, bzw. hier. Dort sind alle erlaubten Attribute aufgelistet (lang, dir und, deprecated, version). Alles andere ist der Beliebigkeit der Browserprogrammierer unterworfen ...
Einigen wir uns auf: Ob der CSS-Selektor funktioniert, ist der Beliebigkeit der Browserprogrammierer unterworfen, wobei mit hoher Wahrscheinlichkeit davon ausgegangen werden kann, dass in der internen Repräsentation des Dokuments <html> keine so große Sonderrolle einnimmt, dass mein Selektor nicht funktioniert. ;) Die Zuweisung ist aber definitiv gültig, da DOM diese Eigenschaft für <html> vorsieht.
Mo
Hi,
Die Zuweisung ist aber definitiv gültig,
S. molily: Auch eine Zuweisung stussName ist in JS gültig.
Was HTML dann damit anfängt, ist eine andere Geschichte ...
Gruß, Cybaer
interface HTMLHtmlElement : HTMLElement {
Oh, stimmt, diese Vererbung habe ich übersehen.
Sinn ergibt die aber nicht, da in HTML keine dementsprechenden Attribute existieren; ich halte das eher für einen Fehler in der DOM-HTML-Spezifikation.
Mathias
window.onload = function () {
War deine Aufgabenstellung nicht »möglichst sofort und nicht erst, wenn das Dokument fertig geladen ist«?
Mathias
window.onload = function () {
War deine Aufgabenstellung nicht »möglichst sofort und nicht erst, wenn das Dokument fertig geladen ist«?
Prinzipiell habe ich leider zu wenig Erfahrung mit JavaScript, um zu wissen, wann genau welches Event ausgelöst wird; ich habe das unverändert aus dem Beispiel übernommen und meine Tests suggerieren, dass die Zuweisung »rechtzeitig« erfolgt (d.h. kein »Aufblitzen«). Für einen Alternativvorschlag wäre ich immer dankbar.
Mo
meine Tests suggerieren, dass die Zuweisung »rechtzeitig« erfolgt (d.h. kein »Aufblitzen«).
Das ist aber nicht der Fall. Der load-Event wird durch externe Scripte, Stylesheets, Bilder, iframes, Plugins etc. verzögert. Je nachdem, wie groß die Seite ist und ob externe Ressourcen wie Stylesheets und Bilder schon im Cache liegen, wird es ein »Aufblitzen« geben, denn der load-Event feuert u.U. erst sehr spät, wenn das Dokument schon zumindest teilweise sichtbar ist.
Für einen Alternativvorschlag wäre ich immer dankbar.
Na wie Cybaer schreibt bist du auf den load angewiesen und könntest höchstens auf DOMContentLoaded bzw. browserübergreifende Helferscripte ausweichen.
Aus dem Grund hatte dir Cybaer ja auch den Alternativvorschlag gemacht.
Mathias
Für einen Alternativvorschlag wäre ich immer dankbar.
Na wie Cybaer schreibt bist du auf den load angewiesen und könntest höchstens auf DOMContentLoaded bzw. browserübergreifende Helferscripte ausweichen.
Aus dem Grund hatte dir Cybaer ja auch den Alternativvorschlag gemacht.
Jetzt verstehe ich erst denn tieferen Sinn seines Vorschlags, danke. Muss ich, um das »Aufblitzen« zu vermeiden, entsprechendes Script und Style-Anweisungen in dieselbe Datei packen oder kann ich das als externes Script einbinden? Tut mir leid, falls das eine dumme Frage ist.
Mo
Hi,
Muss ich, um das »Aufblitzen« zu vermeiden, entsprechendes Script und Style-Anweisungen in dieselbe Datei packen oder kann ich das als externes Script einbinden?
Das kannst Du in dieselbe Datei packen. Aber wenn Du ohnehin ein externes Script einbindest, dann auch dorthin. Wichtig ist nur, daß das Script im HEAD ausgeführt wird, denn nur dort dürfen LINK- & STYLE-Elemente stehen.
Und wichtig: CSS mit write() ausgeben geht nur bei HTML-Dokumenten. Bei XHTML wird es komplizierter ...
Gruß, Cybaer
@@Cybaer:
Und wichtig: CSS mit write() ausgeben geht nur bei HTML-Dokumenten. Bei XHTML wird es komplizierter ...
Du solltestes es besser wissen.
'document.write()' geht bei als 'text/html' verarbeiteten XHTML-Dokumenten.
Live long and prosper,
Gunnar
Du solltestes es besser wissen.
'document.write()' geht bei als 'text/html' verarbeiteten XHTML-Dokumenten.
Mir war auch so klar, was er gemeint hat.
In diesem Fall wird das Dokument übrigens je nach Accept-Header auch als application/xhtml+xml ausgeliefert, weswegen document.write() nicht eingesetzt werden kann.
Mo
'document.write()' geht bei als 'text/html' verarbeiteten XHTML-Dokumenten.
Und in solchen Fällen ist es unnötig, weil DOM immer geht:
<head>
...
<script type="text/javascript">
[code lang=javascript]function addStylesheet (uri) {
var stylesheet = document.createElement("link");
stylesheet.rel = "stylesheet";
stylesheet.href = uri;
var head = document.documentElement.firstElementChild || document.getElementsByTagName("head").item(0);
if (head) {
head.appendChild(stylesheet);
}
}
addStylesheet("javascript-enabled.css");
</script>
</head>[/code]
Und ein allgemeines document.write für XHTML ist auch nicht schwer nachzubauen (auch wenn ich das nicht empfehlen würde - DOM und innerHTML erfüllen ihren Zweck, und sowieso kann man die üblichen document.write-Aufrufe durch Unobtrusive JavaScript ersetzen).
Mathias
Hi,
'document.write()' geht bei als 'text/html' verarbeiteten XHTML-Dokumenten.
Das ist dann kein XHTML mehr, sondern ein "wir nennen es XHTML, bestehen aber darauf, es als HTML zu behandeln".
Oder anders: XHTML zu coden, daß gar nicht als XHTML funktioniert, ist nun wirklich das allerdümmste, was man machen kann ...
Gruß, Cybaer
@@Cybaer:
Oder anders: XHTML zu coden, daß gar nicht als XHTML funktioniert, ist nun wirklich das allerdümmste, was man machen kann ...
Auch das solltest du besser wissen und nicht solchen Schwachsinn von dir geben.
Du solltest unbedingt mal in der Spezifikation nachlesen, was XHTML ist. [XHTML10 §1] „Es ist für die Verwendung als Sprache für Inhalte vorgesehen, die sowohl zu XML konform sind, und die auch, falls sie einigen einfachen Richtlinien folgen, in zu HTML 4 konformen Benutzerprogrammen eingesetzt werden können.“
Einige Vorteile von XHTML sind auch dort genannt, andere kannst du in Archiv nachlesen, falls du die unzähligen Diskussionen darüber schon wieder vergessen oder verdrängt haben solltest.
Live long and prosper,
Gunnar
Hi,
Oder anders: XHTML zu coden, daß gar nicht als XHTML funktioniert, ist nun wirklich das allerdümmste, was man machen kann ...
Auch das solltest du besser wissen und nicht solchen Schwachsinn von dir geben.
Ich bleibe bei meiner Aussage.
Wie Du Texte interpretierst, bleibt dafür dir überlassen.
Ich würde dir aber raten, vorzuschlagen, den Hinweis des W3Cs in der FAQ, warum write() in XHTML nicht funktioniert, um den Zusatz "Wenn sie write() dennoch in XHTML nutzen möchten, liefern sie es einfach als HTML aus" ergänzen zu lassen. Mal sehen, wie weit Du kommst ...
Gruß, Cybaer
Hi,
Ich möchte diesen Elementen einfach eine Klasse zuweisen können, sodass jedes dieser Element dann, sobald es geladen wird (möglichst sofort und nicht erst, wenn das Dokument fertig geladen ist), display='none' zugewiesen bekommt. Lässt sich das realisieren?
body direkt beim Laden per JavaScript eine Klasse wie bspw. "hasJS" verpassen, und Nachfahrenselektor nutzen:
body.hasJS .klasseFuerElementeDieBeiAktiviertemJSNichtSichtbarSeinSollen { display:none; }
MfG ChrisB
body direkt beim Laden per JavaScript eine Klasse wie bspw. "hasJS" verpassen, und Nachfahrenselektor nutzen:
Hi,
danke, das war die elegante Lösung, die ich gesucht habe!
Mo
Hi,
body direkt beim Laden per JavaScript eine Klasse wie bspw. "hasJS" verpassen, und Nachfahrenselektor nutzen:
danke, das war die elegante Lösung, die ich gesucht habe!
Eleganter dürfte sein, eine passendes Stylesheet noch *vor* dem BODY einfach mittels JS auszugeben (HTML) bzw. zu erzeugen (XHTML).
Gruß, Cybaer
@@Cybaer:
Eleganter dürfte sein, eine passendes Stylesheet noch *vor* dem BODY einfach mittels JS auszugeben (HTML) bzw. zu erzeugen (XHTML).
Deine Abneigung gegenüber Nachfahrenselektoren und deine Vorliebe für dynamisches Gefrickel an Stylesheets ist ja fast schon sprichwörtlich.
Live long and prosper,
Gunnar
Hi,
Deine Abneigung gegenüber Nachfahrenselektoren und deine Vorliebe für dynamisches Gefrickel an Stylesheets ist ja fast schon sprichwörtlich.
Meine (theoretische) Ablehnung (und deswegen Vorchlag einer Alternative) hat so rein gar nichts mit Nachfahrenselektoren zu tun (ich wüßte jedenfalls wirklich nicht, warum).
Denn ob ich *im HTML-Code* *nach* Existenz des BODY-Starttags den Klassennamen für eine Regel mit Nachfahrenselektor vergebe, oder nach der Existenz des eigentlich auszublendenden Teils direkt eine Klasse vergebe, spielt doch überhaupt keine Rolle.
Aber schön, daß man dir ein Tuch in irgendeiner Farbe vorhalten kann, und Du gehst da gleich drauf, wie der Stier aufs sprichwörtliche rote ... :)
Und ansonsten bleibt es dabei: Alternativen zu kennen, ist nie verkehrt. Was man letztlich auswählt, ist eine andere Sache (und dann im Bewußtsein geschehen, aus versch. Möglichkeiten die jeweils beste wählen zu können). Das Verständnis dafür mag dir abgehen, aber das ist ja wohl eher dein Problem, und sollte nicht auf dem Rücken der Fragesteller ausgetragen werden ...
Gruß, Cybaer
Hi.
body direkt beim Laden per JavaScript eine Klasse wie bspw. "hasJS" verpassen, und Nachfahrenselektor nutzen:
danke, das war die elegante Lösung, die ich gesucht habe!Eleganter dürfte sein, eine passendes Stylesheet noch *vor* dem BODY einfach mittels JS auszugeben (HTML) bzw. zu erzeugen (XHTML).
1. Wenn nun jemand anders (oder ich nach einiger Zeit) das Design ändern wollte, würde aus dem CSS nicht ersichtlich, dass diese Elemente normalerweise nicht angezeigt werden. Finde ich daher eher unelegant.
2. Würde man dann mit ziemlicher Sicherheit davon ausgehen können, dass die entsprechenden Buttons nicht doch kurz aufblitzen? Fände ich störend.
Gruß,
Mo
Hi,
- Wenn nun jemand anders (oder ich nach einiger Zeit) das Design ändern wollte, würde aus dem CSS nicht ersichtlich, dass diese Elemente normalerweise nicht angezeigt werden.
Das ist richtig. Der Aufwand, nur dafür das CSS selbst zu bemühen, wäre für dich bzw. dieses kleine Problem, eigentlich zu hoch (also CSS selbst zu ändern). Und der Nachteil einer eigenen js_only.css (die man dann mittels JS einbindet) wäre, daß bei JS-Surfern immer ein zusätzlicher Request erforderlich wäre, wobei der (allerdings i.d.R. einmalige) HTTP-Overhead praktisch in keinem Verhältnis zu den Nutzdaten stünde.
Finde ich daher eher unelegant.
Mit Eleganz beziehe ich mich auf die Trennung von Content, Layout und Scripting. Bei ChrisBs Lösung kann man auf den OnLoad-Event warten, was aber ein aufblitzen bedeutet. Oder man packt das JS direkt in den BODY, was aber dann bedeutet, Scripting und Content nicht getrennt zu haben. Oder man bemüht Zusatzfuntionen, die einem so etwas wie OnDomReady bescheren.
- Würde man dann mit ziemlicher Sicherheit davon ausgehen können, dass die entsprechenden Buttons nicht doch kurz aufblitzen?
Wenn das CSS vor dem BODY (anwendbar) definiert wird, blitzt gar nichts ...
Gruß, Cybaer
Finde ich daher eher unelegant.
Mit Eleganz beziehe ich mich auf die Trennung von Content, Layout und Scripting.
Hm, da kann man geteilter Meinung sein, was von diesem Standpunkt aus besser ist (und ich möchte mich selbst auch nicht festlegen). Das Verstecken der Elemente ist zwar einerseits ein wichtiger Teil des Layouts (besonders wenn man davon ausgeht, dass dies der Normalfall ist), andererseits entscheidet das Script darüber, ob das Verstecken tatsächlich stattfindet.
Bei ChrisBs Lösung kann man auf den OnLoad-Event warten, was aber ein aufblitzen bedeutet. Oder man packt das JS direkt in den BODY, was aber dann bedeutet, Scripting und Content nicht getrennt zu haben. Oder man bemüht Zusatzfuntionen, die einem so etwas wie OnDomReady bescheren.
Bei meinen Tests hat nichts aufgeblitzt, was aber auch nur an meinen Testdokumenten liegen kann. Leider habe ich zu wenig Erfahrung und Hintergrundwissen, um mir eine andere Lösung als die mit window.onload auszudenken. Für Vorschläge wäre ich dankbar.
Mo
Hi,
Das Verstecken der Elemente ist zwar einerseits ein wichtiger Teil des Layouts (besonders wenn man davon ausgeht, dass dies der Normalfall ist), andererseits entscheidet das Script darüber, ob das Verstecken tatsächlich stattfindet.
Nach dieser Lesart wäre es genug getrennt, wenn Du den CSS-Code direkt ins (externe?) JS packst, und dort einfach mittels write() ausgibst - wobei das JS natürlich im HEAD stehen muß, und es sich um eine HTML-Seite handeln muß (XHTML beherrscht kkein write().
Bei meinen Tests hat nichts aufgeblitzt, was aber auch nur an meinen Testdokumenten liegen kann.
Jep. Wenn der OnLoad-Event feuert, ist das Dokument i.d.R. bereits sichtbar. Und wenn Grafiken enthalten sind, dann ist es oft auch schon lange vorher sichtbar.
Leider habe ich zu wenig Erfahrung und Hintergrundwissen, um mir eine andere Lösung als die mit window.onload auszudenken. Für Vorschläge wäre ich dankbar.
Um Elemente beeinflussen zu können, müssen diese Elemente ja bereits existieren (deswegen onLoad). Alternativ kann man das Script direkt hinter den BODY-Starttag packen (Klasse für Regel mit Nachfahrenselektor) oder direkt in/oder zumindest hinter die konkret auszublendenden Objekte (um sie selbst einer passenden Klasse zuzuweisen, bzw. sie z.B. direkt mit style auszublenden).
Oder eben, was ich vorschlug, man gibt das CSS bereits im HEAD mit JS selbst aus/legt es an. Da muß man nicht auf die Existenz der Elemente warten, sondern erledigt das vorher ...
BTW: Davon abgesehen: Ist hier ausblenden überhaupt richtig, oder wäre es nicht sinnvoller, die Elemente selbst zu löschen? JS kann man deaktivieren, aber CSS auch. Und wenn die Ellemente nur bei JS nicht sichtbar sein sollen, wäre es zumindest logisch, sie auch wirklich rauszuschmeißen (das geht aber wirklich erst nachdem die Elemente existieren - und sei es, daß man sie nur nicht sieht, und dann im OnLoad-Event wirklich entfernt ...).
Gruß, Cybaer
Um Elemente beeinflussen zu können, müssen diese Elemente ja bereits existieren (deswegen onLoad). Alternativ kann man das Script direkt hinter den BODY-Starttag packen (Klasse für Regel mit Nachfahrenselektor) oder direkt in/oder zumindest hinter die konkret auszublendenden Objekte (um sie selbst einer passenden Klasse zuzuweisen, bzw. sie z.B. direkt mit style auszublenden).
Die beiden letztgenannten Alternativen wollte ich ja gerade eben vermeiden ;)
Oder eben, was ich vorschlug, man gibt das CSS bereits im HEAD mit JS selbst aus/legt es an. Da muß man nicht auf die Existenz der Elemente warten, sondern erledigt das vorher ...
Nach längerem Überlegen ist das wohl der sinnvollste Vorschlag, auch wenn er am Anfang etwas exotisch klang.
BTW: Davon abgesehen: Ist hier ausblenden überhaupt richtig, oder wäre es nicht sinnvoller, die Elemente selbst zu löschen? JS kann man deaktivieren, aber CSS auch. Und wenn die Ellemente nur bei JS nicht sichtbar sein sollen, wäre es zumindest logisch, sie auch wirklich rauszuschmeißen (das geht aber wirklich erst nachdem die Elemente existieren - und sei es, daß man sie nur nicht sieht, und dann im OnLoad-Event wirklich entfernt ...).
Das ist natürlich ein guter Tipp und wäre sauberer, danke.
Mein größtes Problem war, dass mir die vorgeschriebene bzw. verwendete »Abarbeitungsreihenfolge« für Browser sowie Details dazu, wann genau bestimmte Events ausgelöst werden, alles andere als klar war. Die Spec selbst ermutigt auch nicht unbedingt zum Durchlesen.
Jetzt bin ich um eine Erfahrung reicher: Externe Scripte werden wohl vor der Anzeige geladen und noscript lässt sich wunderbar und standardkonform ersetzen (was angesichts der Tatsache, dass es in XHTML5 nicht mehr erlaubt sein soll, nicht ganz unwichtig ist). Unterschiede HTML/XHTML sind mir klar, trotzdem danke für den Hinweis. Den Rest sollte ich dann doch allein schaffen. :)
Grüße und nochmal danke,
Mo
@@Cybaer:
und es sich um eine HTML-Seite handeln muß (XHTML beherrscht kkein write().
Live long and prosper,
Gunnar
@@ChrisB:
body direkt beim Laden per JavaScript eine Klasse wie bspw. "hasJS" verpassen,
Ergänzung: Anstelle von „eine Klasse verpassen“ sollte man besser von „um eine Klasse erweitern“ sprechen:
document.body.className = "hasJS"; würde schon im HTML gesetzte Klassen für 'body' ja löschen.
Also besser:
document.body.className = (document.body.className ? document.body.className + " hasJS" : "hasJS");
Wenn ein Framework verwendet wird, das sowas wie 'addClass' bereitstellt, dann auch gern damit.
Live long and prosper,
Gunnar