"noscript"-Bereich für head

[trunx]

Hallo Forum,

ich hab mal ne sog. blöde Frage :p
Das noscript-Tag gilt ja nur für den body; gibt es etwas analoges für den head-Bereich eines html-Dokuments? Ich möchte eine css-Datei für diesen Fall einbetten...

bye trunx

[Olaf Schneider]

Hallo trunx,

Vielleicht hilft Dir der Absatz „Javascript mehrstufig zünden“ im Webkrauts-Artikel http://www.webkrauts.de/2008/12/14/sehr-sehr-schnelle-seiten-website-performance-best-practice-teil-2/. Ein ganz anderer Ansatz als Deiner, aber vielleicht mit ähnlichem Ziel.

Gruß
Olaf

[Gunnar Bittersmann]

@@Olaf Schneider:

nuqneH

Vielleicht […]

Mit „Vielleicht“ untertreibst du – vielleicht.

[…] hilft Dir der Absatz „Javascript mehrstufig zünden“ im Webkrauts-Artikel http://www.webkrauts.de/2008/12/14/sehr-sehr-schnelle-seiten-website-performance-best-practice-teil-2/.

Siehe auch Cheatahs Einwand.

Qapla'

[Cybaer]

Hi,

Das noscript-Tag gilt ja nur für den body;

Ich kenne allerdings keinen Browser,der NOSCRIPT im HEAD nicht akzeptieren würde.

gibt es etwas analoges für den head-Bereich eines html-Dokuments? Ich möchte eine css-Datei für diesen Fall einbetten...

Du kannst sie einbetten und direkt dahinter ein JS plazieren, das den LINK-Knoten wieder entfernt.

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Ich kenne allerdings keinen Browser,der NOSCRIPT im HEAD nicht akzeptieren würde.
--8<--
Du kannst sie einbetten und direkt dahinter ein JS plazieren, das den LINK-Knoten wieder entfernt.

Warum sollte man die eine oder anderer dreckige Lösung verwenden, wenn es doch eine saubere gibt?

Qapla'

[Cybaer]

Hi,

Warum sollte man die eine oder anderer dreckige Lösung verwenden, wenn es doch eine saubere gibt?

AFAIR habe ich auch eine "saubere" Möglichkeit genannt, bei der zudem die CSS-Datei erst gar nicht geladen wird.

Falls Du einfach nur generell der Meinung bist, man solle erst gar nicht auf etwas hinweisen, was nicht "sauber" wäre,und das nicht bei dir beiahlten konntest: Ich mag es lieber "schmutzig" ... ;->

... und überlasse ansonsten dem Fragesteller die Wahl.

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

AFAIR habe ich auch eine "saubere" Möglichkeit genannt, bei der zudem die CSS-Datei erst gar nicht geladen wird.

?? 'noscript' im 'head' ist nicht „sauber“. (Über den Sinn, warum das so spezifiziert wurde, mag man natürlich streiten.)

Ein 'link[@rel="stylesheet"]'-Element, welches per JavaScript gelöscht wird, ist auch deshalb unsauber, weil es ein Extra-Stylesheet fürs Rendering bei deaktviertem JavaScript vorsieht, anstatt dass sämtliche Regeln in einem Stylesheet zusammengefasst sind.

Aber gegen Klassen für 'body' und Nachfahren-Selektoren hast du wohl eine generelle Abneigung, sonst hättest du deine Spatzenkanone längst deinem Heimatmuseum gespendet. ;-)

Qapla'

[Cybaer]

Hi,

Ein 'link[@rel="stylesheet"]'-Element, welches per JavaScript gelöscht wird, ist auch deshalb unsauber, weil es ein Extra-Stylesheet fürs Rendering bei deaktviertem JavaScript vorsieht,

Ach so, das ist für dich schon "unsauber"?

Also "umständlich" hätte ich ja vielleicht noch verstanden ...

Aber gegen Klassen für 'body' und Nachfahren-Selektoren hast du wohl eine generelle Abneigung, sonst hättest du deine Spatzenkanone längst deinem Heimatmuseum gespendet. ;-)

Das kommt schon deswegen nicht in Frage, weil ich ungerne auf die Lizenzgebühren verzichten würde, die dafür immer mal wieder eintrudeln ... :)

... auch wenn Du nach wie vor nicht zu verstehen in der Lage zu sein scheinst, daß man mit Echtzeit-Änderung von CSS Dinge machen kann, die man mit dem Ändern von Nachfahrenselektoren nunmal nicht bewerkstelligen kann.

Aber Du weißt ja: "Manche Menschen haben einen Gesichtskreis vom Radius 0 und nennen dies ihren Standpunkt." (David Hilbert, Mathematiker) >;->

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

... auch wenn Du nach wie vor nicht zu verstehen in der Lage zu sein scheinst, daß man mit Echtzeit-Änderung von CSS Dinge machen kann, die man mit dem Ändern von Nachfahrenselektoren nunmal nicht bewerkstelligen kann.

?? Es werden nicht Nachfahrenselektoren geändert, sondern die Klassenzugehörigkeit eines Elements.

Und ja, ich weiß, dass man mit der dynamischen Änderung von CSS-Regeln noch mehr machen kann.

Genauso weiß ich auch, dass dies in der Mehrheit der Fälle, wo du deine Spatzenkanone aufgefahren hast, gar nicht notwendig war.

Qapla'

[Cybaer]

Hi,

Genauso weiß ich auch, dass dies in der Mehrheit der Fälle, wo du deine Spatzenkanone aufgefahren hast, gar nicht notwendig war.

Ja, deine hellseherischen Fähigkeiten habe ich schon immer bewundert! Deinen Unwillen, einfach alle Möglichkeiten aufzuzeigen, hingegen weniger. :->

Aber Null-Radien müssen auch nicht erweitert werden. Es reicht ja, wenn man das überschaut, was man sehen kann, gell?! >:->

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Deinen Unwillen, einfach alle Möglichkeiten aufzuzeigen, hingegen weniger. :->

Siehste, ich bin bescheiden. Ich will gar nicht alles haben; das Beste genügt mir.

Dein Grund, zu einer guten Lösung noch eine weniger gute hinzuzufügen, wäre welcher?

Aber Null-Radien müssen auch nicht erweitert werden. Es reicht ja, wenn man das überschaut, was man sehen kann, gell?! >:->

[ZITAT904]

Qapla'

[Cybaer]

Hi,

[ZITAT904]

Du bist natürlich ein "Profi"? :))

(rhetorische Frage)

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

»» Ein 'link[@rel="stylesheet"]'-Element, welches per JavaScript gelöscht wird, ist auch deshalb unsauber, weil es ein Extra-Stylesheet fürs Rendering bei deaktviertem JavaScript vorsieht,

Ach so, das ist für dich schon "unsauber"?

Ich sagte: „auch deshalb“.

Und auch deshalb, weil das bei aktiviertem JavaScript nicht notwendige Stylesheet angefordert und übertragen wird. Sinnloser Netztraffic.

Welches sollte denn nun die „"saubere" Möglichkeit […], bei der zudem die CSS-Datei erst gar nicht geladen wird“ gewesen sein? Die mit invalidem HTML?

Qapla'

[Cybaer]

Hi,

Und auch deshalb, weil das bei aktiviertem JavaScript nicht notwendige Stylesheet angefordert und übertragen wird. Sinnloser Netztraffic.

Ach, bei anderen Varianten werden keine Daten übertragen, die nicht notwendig sind? Interessant! :-) Du solltest das Verfahren unbedingt patentieren lassen, bei dem CSS-Daten die nicht benutzt werden, erst gar nicht übertragen werden (was bei dir ja wohl der Fall ist, auch wenn ich es nicht verstehe =%-)) ...

... nicht, daß das Netz noch kollabiert, von dem vielen CSS, und wir keine HD-Flilme mehr streamen können! =:-)))

Welches sollte denn nun die „"saubere" Möglichkeit […], bei der zudem die CSS-Datei erst gar nicht geladen wird“ gewesen sein? Die mit invalidem HTML?

Fuck off! :-)

Aber solange bei HTTP die Zahl der parallelen Requests beschränkt ist (und alles, was darüber hinausgeht, seriell abgearbeitet wird), würde ich das doch mal als Ansatz nehmen. AFAIR haben die Webkrauts ja in eben dem verlinkten Artikel sich darüber ausgelassen? :)

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

»» Und auch deshalb, weil das bei aktiviertem JavaScript nicht notwendige Stylesheet angefordert und übertragen wird. Sinnloser Netztraffic.

Ach, bei anderen Varianten werden keine Daten übertragen, die nicht notwendig sind?

Daten schon, aber keine Dateien. :-b

... nicht, daß das Netz noch kollabiert, von dem vielen CSS, und wir keine HD-Flilme mehr streamen können! =:-)))

*g*

Qapla'

[molily]

?? 'noscript' im 'head' ist nicht „sauber“. (Über den Sinn, warum das so spezifiziert wurde, mag man natürlich streiten.)

Validität ist kein Wert an sich. Eine Lösung wird nicht per se besser oder schlechter, nur weil sie valide bzw. nicht valide ist. Bei HTML 5 ist noscript im head erlaubt. Unterstützt ist es ohnehin.

Mathias

[trunx]

Hallo Mathias,

Bei HTML 5 ist noscript im head erlaubt...

diese Aussage habe ich nicht gefunden, kannst du vllt eine Quelle posten? Das wäre nett, danke.

bye trunx

[molily]

diese Aussage habe ich nicht gefunden, kannst du vllt eine Quelle posten?

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-noscript-element

»Contexts in which this element may be used:
In a head element of an HTML document«

Mathias

[trunx]

Hallo,

http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-noscript-element

»Contexts in which this element may be used:
In a head element of an HTML document«

vielen Dank
bye trunx

[Cybaer]

Hi,

»Contexts in which this element may be used:
In a head element of an HTML document«

Wobei man vielleicht extra betonen sollte, daß damit auch wirklich nur *HTML* 5 gemeint ist, *nicht* aber *X*HTML 5.

Gruß, Cybaer

[molily]

Wobei man vielleicht extra betonen sollte, daß damit auch wirklich nur *HTML* 5 gemeint ist, *nicht* aber *X*HTML 5.

Außer der Tatsache, dass das so ist, wird leider kein Grund dafür angegeben. Ich verstehe ohnehin nicht »all these contortions«, die für HTML-Parser beim Verarbeiten von noscript definiert werden. Ich verstehe demnach nicht, wieso ein XML-Parser noscript nicht korrekt verarbeiten können soll?

Mathias

[ChrisB]

Hi,

Ich verstehe demnach nicht, wieso ein XML-Parser noscript nicht korrekt verarbeiten können soll?

The element is not allowed in XML, because in XML the parser is not affected by [if scripting was enabled or not], and thus the element would not have the desired effect.

Ich denke mal, dass sich das darauf bezieht, dass ein XML-Parser nicht unbedingt etwas mit einem "Browser" resp. der Anzeige eines X(HT)ML-Dokumentes zu tun haben muss.
Wenn ich ein XHTML-Dokument aber nur parse, um es weiter zu verarbeiten, nicht um es darzustellen - dann kann dies durchaus in einem Kontext passieren, in dem "Scripting" überhaupt nicht bekannt ist. Was soll dann mit dem Content des Noscript-Elementes geschehen - drin lassen, oder rauswerfen?
Wobei die Logik ja dann andererseits auch an dem Punkt scheitert, wo ich die gleiche Frage für das Script-Element stelle ...

MfG ChrisB

[Christoph]

Moin.

Ich verstehe ohnehin nicht »all these contortions«, die für HTML-Parser beim Verarbeiten von noscript definiert werden. Ich verstehe demnach nicht, wieso ein XML-Parser noscript nicht korrekt verarbeiten können soll?

Bei deaktiviertem Skripting wird der Inhalt von noscript-Elementen erst gar nicht dem DOM hinzugefügt: FF z.B. generiert einen einzelnen Textknoten. Ein XML-Parser müsste die Elemente korrekt einhängen.

Ein mögliches Szenario, das erklären könnte, warum auf diese Weise verfahren wird:

Angenommen, wir erzeugen bei aktiviertem Skripting dynamisch ein Element mit einer bestimmten ID. Für Clients ohne Skripting findet sich ein Element entsprechender ID im noscript-Block. Würde der Inhalt von noscript-Blöcken wie gewohnt geparst worden (und z.B. einfach die display-Eigenschaft auf none gesetzt), hätten wir zwei Element gleicher ID.

Christoph

[molily]

Würde der Inhalt von noscript-Blöcken wie gewohnt geparst worden (und z.B. einfach die display-Eigenschaft auf none gesetzt), hätten wir zwei Element gleicher ID.

Stimmt, das leuchtet ein. Danke für die Erklärung. Allerdings halte ich das für einen sehr abseitigen Fall und kann nicht so recht nachvollziehen, wieso man deshalb einen radikalen Bruch macht, indem man plötzlich sagt: noscript darf bei XHTML nicht funktionieren! Nun, das tut es schon in allen XHTML-fähigen Browsern. Weil es nicht möglich ist, dass sich HTML und XHTML in dem Punkt gleich verhalten können, verbietet man noscript in XHTML einfach komplett. Sorry, das ist auch eine dumme Idee. Ich finde die aktuell schon umgesetzte Regelung besser. Klar, da muss man in manchen Fällen aufpassen und darauf achten, dass die Elemente in noscript ganz normaler Teil des DOM-Baums sind - und z.B. händisch selbst alle Kindelemente von noscript killen, wenn man vorhat, ein Element mit einer ID zu erzeugen, die bereits von einem Element im noscript-Element verwendet wird.

Ich kann mir nicht vorstellen, dass die Browser ihr bisheriges Verhalten plötzlich ändern und noscript-Elemente in XHTML plötzlich ignorieren, d.h. deren Inhalt auch bei aktiviertem Scripting anzeigen. Das wäre das genaue Gegenteil von Kompatibilität mit dem existierenden Web. Don't break the Web, hatte sich die WHATWG mal auf die Fahnen geschrieben. *Das* würde garantiert einige Sites kaputtmachen.

Mathias

[molily]

auch deshalb unsauber, weil es ein Extra-Stylesheet fürs Rendering bei deaktviertem JavaScript vorsieht

Gut, aber irgendwo muss ich Abstriche machen. Wenn ich alle Styles in ein Sheet schreibe, dann werden bei deaktiviertem JavaScript auch ggf. massenhaft irrelevante Styles geladen. Dass zählt weniger nur unter der Annahme, dass JavaScript meistens aktiviert ist und man sich für eine Optimierung des Regelfalls entschieden hat - auf Kosten des Sonderfalls. Anders herum: Bei aktiviertem JavaScript werden möglicherweise unzählige Regeln überschrieben, sodass letztlich auch unnötig Daten übertragen wurden.

Der Weisheit letzter Schluss ist diese Methode nicht, weil man ggf. hunderte Selektoren hintereinander mit ».js «-Präfixen versehen muss. Das ist schwer wartbar und greift sogar in die Funktionsweise der Styles ein, indem es die Spezifität der Selektoren verändert. So pauschal würde ich daher separate Stylesheets nicht verdammen - auch wenn ich sie erfahrungsgemäß in den meisten Fällen für unnötig halte.

Mathias

[trunx]

Hallo,

Du kannst sie einbetten und direkt dahinter ein JS plazieren, das den LINK-Knoten wieder entfernt.

das finde ich eine gute Idee, die andere ist sicher auch gut aber für mich mit zu viel Aufwand verbunden...doch wie genau löscht man den diesen Link-Knoten? ich hab's mit removeChild() versucht, aber da kommt die Fehlermeldung, dass er diesen Knoten nicht kennt - ich hab das jetzt erstmal so gelöst, dass ich href="" gesetzt hab, naja suboptimal :p ich weiß

trotzdem erstmal vielen Dank
trunx

[Cybaer]

Hi,

ich hab's mit removeChild() versucht, aber da kommt die Fehlermeldung, dass er diesen Knoten nicht kennt

Wie hast Du den Knoten denn vorher ermittelt? Ein document.getElementsByTagName("link")[document.getElementsByTagName("link").length-1]  enthält das letzte LINK-Element(oder LINK bekommt eine ID), und removeChild() muß natürlich als Methode des HEAD-Elements angewandt werden: document.getElementsByTagName("head")[0].removeChild...

Gruß, Cybaer

[trunx]

...document.getElementsByTagName("head")[0].removeChild...

grrr...hatte [0] vergessen...

oki, jetzt klappt's und ist valide...

danke trunx

[Gunnar Bittersmann]

@@trunx:

nuqneH

»» ...document.getElementsByTagName("head")[0].removeChild...
oki, jetzt klappt's und ist valide...

Da haste dir ja die schlechteste Variante rausgepickt. Da würde ich ich – wie Cybaer und molily sagten – doch lieber auf Validität verzichten und 'noscript' im 'head' verwenden.

Aber was hast du gegen die von Olaf und mir präferierte Variante?

Qapla'

[trunx]

Hallo,

Aber was hast du gegen die von Olaf und mir präferierte Variante?

diese Variante habe ich ja auch als Erstes ausprobiert, es geht darum, dass ich in der Seite den Ausschnitt eines Bildes zeige, das Bild selbst ist aus verschiedenen Bildern zusammen gesetzt, das erste davon ist 540px breit, weitere folgen daneben...der Aufbau ist jetzt der:

• alte Browser zeigen nur das erste Bild an, der Ausschnitt hat 540px
• moderne Browser sollen alles anzeigen können, hier ist der Ausschnitt 65% mit einer Mindestbreite von 540px
• Browser mit deaktiviertem javascript zeigen wiederum nur das erste Bild.

das nur mit dem Zufügen einer neuen Klasse zu lösen hat bei mir leider nicht funktioniert. Vllt hab ich zu früh aufgegeben, die andere Lösung brachte einfach schneller einen Erfolg.

Aber mal ne Frage: nun ist ja removeChild() eine gültige Methode, was genau ist deiner Meinung daran unsauber? Die Datenmenge die "zuviel" geladen wird, ist sowohl bei Olafs Variante als auch der von Cybaer ähnlich groß - in jedem Fall aber verschwindend klein, einige Byte...wann hälst du removeChild() für angebracht?

bye trunx

[Gunnar Bittersmann]

@@trunx:

nuqneH

das nur mit dem Zufügen einer neuen Klasse zu lösen hat bei mir leider nicht funktioniert.

Was genau hast du versucht? Was hat nicht funktioniert?

Die Datenmenge die "zuviel" geladen wird, ist sowohl bei Olafs Variante als auch der von Cybaer ähnlich groß - in jedem Fall aber verschwindend klein, einige Byte...

Nein.

Bei Olafs Variante stehen die überflüssigen Regeln in dem einen sowieso vorhandenen Stylesheet.

Bei Cybaers Variante stehen die überflüssigen Regeln in einem separaten Stylesheet. Zu den Daten kommt also noch überflüssiger HTTP-Overhead (Request und Response) hinzu.

wann hälst du removeChild() für angebracht?

Zum Nichteinbinden von Stylesheets gar nicht.

Qapla'

[Cybaer]

Hi,

Bei Cybaers Variante stehen die überflüssigen Regeln in einem separaten Stylesheet. Zu den Daten kommt also noch überflüssiger HTTP-Overhead (Request und Response) hinzu.

Während bei der all-together-Variante vor jede der Regel ein ".js " kommt. Also meine Stylesheets haben i.d.R. so einige Regeln ... ;-)

»» wann hälst du removeChild() für angebracht?
Zum Nichteinbinden von Stylesheets gar nicht.

Wenn NOSCRIPT im HEAD bei HTML 5 erlaubt ist, dann spricht wirklich nichts mehr gegen NOSCRIPT als die Variante der Wahl ...

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Wenn NOSCRIPT im HEAD bei HTML 5 erlaubt ist, dann spricht wirklich nichts mehr gegen NOSCRIPT als die Variante der Wahl ...

Doch: das zusätzliche Stylesheet. S.a. [Meiert]

Qapla'

[Detlef G.]

Hallo Gunnar, hallo Cybaer

»» Wenn NOSCRIPT im HEAD bei HTML 5 erlaubt ist, dann spricht wirklich nichts mehr gegen NOSCRIPT als die Variante der Wahl ...

Doch: das zusätzliche Stylesheet. S.a. [Meiert]

Meiner Meinung nach diskutiert ihr viel zu absolut, es sollte von Fall zu Fall betrachtet werden.
Bei einem relativ kleinen Stylesheet oder/und, wenn nur wenige zusätzliche Regeln dafür erforderlich sind, dann würde ich kein zusätzliches Stylesheet verwenden.
Wenn ich aber KByte an zusätzlichen Regeln einfügen müsste, dann halte ich ein zusätzliches Stylesheet für effektiver.

Auf Wiederlesen
Detlef

[Cybaer]

Hi,

Meiner Meinung nach diskutiert ihr viel zu absolut, es sollte von Fall zu Fall betrachtet werden.

Dem kann ich mich nur vorbehaltlos anschließen! :)

Zumindest mir geht es auch nicht (nie) um *die* "wahre" Lösung. Derjenige, der ein Problem hat, sollte möglichst alle Wege kennen(lernen) - und es gibt ja meistens mehrere -, und dann den wählen, der für sein konkretes Problem der passende ist. Und wenn er das nächste Mal vor einem ähnlichen Problem steht, wo der bereits angewandte Weg nicht gangbar oder optimal ist, dann erinnert er sich hoffentlich gleich an die anderen Wege - oder zumindest daran, daß es welche gibt, und wo man sie suchen kann ... ;-)

Und ich fände es sehr schön, wenn das einige hier im Forum mal so langsam auch so sehen würden. Das hier ist keine Konkurrenzveranstaltung der Webdesignereitelkeiten (oder sollte es zumindest nicht sein), kein Schwanzvergleich (oder Körbchengrößenvergleich ;-)) und auch kein Schönheitswettbewerb, sondern eine Anlaufstation, um Codern zu helfen die noch nicht soviel Erfahrung haben.

Gruß, Cybaer

[Gunnar Bittersmann]

@@Detlef G.:

nuqneH

Bei einem relativ kleinen Stylesheet oder/und, wenn nur wenige zusätzliche Regeln dafür erforderlich sind, dann würde ich kein zusätzliches Stylesheet verwenden.

ACK.

Wenn ich aber KByte an zusätzlichen Regeln einfügen müsste, dann halte ich ein zusätzliches Stylesheet für effektiver.

Dieser Fall sollte eigentlich nicht eintreten. Wenn man für IE „KByte an zusätzlichen Regeln einfügen müsste“, hat man wahrscheinlich schon was falsch gemacht – z.B. ihn in den Quirksmodus geschickt.

Qapla'

[Cybaer]

Hi,

Dieser Fall sollte eigentlich nicht eintreten. Wenn man für IE „KByte an zusätzlichen Regeln einfügen müsste“, hat man wahrscheinlich schon was falsch gemacht – z.B. ihn in den Quirksmodus geschickt.

Du redest aus Erfahrung? ;->

Wenn ja (warum sonst), dann deckt sie sich jedenfalls nicht mit meiner.

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Du redest aus Erfahrung? ;->

Noch so eine rhetorische Frage. ;-)

Wenn ja (warum sonst), dann deckt sie sich jedenfalls nicht mit meiner.

Bsp: Statt
  foo {float: left}
schreibt man gleich an Ort und Stelle
  foo {float: left; display: inline}
Damit erschlägt man den doubled float-margin bug und was weiß ich noch alles – ohne Extra-IE-Styelsheet und ohne dass dies Nicht-IEs stört. Und ohne dass das „Prinzip der Nähe“ verletzt wird. [Meiert too]

Und nein, sooo viele Anpassungen für IE, dass da mehrere Kilobyte zusammenkommen, sind bei mir eigentlich nicht notwendig. Ein kleines Ärgenis ist, dass ich für IE 6 und 7 gleiche Anpassungen doppelt notieren muss:
  ~~~css

• html foo (bar: baz}
    *:first-child+html foo (bar: baz}

IMHO gegenüber Extra-IE-Styelsheet in einer weiteren zu bearbeitenden Datei aber das kleinere Übel.  
  
Qapla'

-- 
Bildung lässt sich nicht downloaden. (Günther Jauch)

[trunx]

Hallo Gunnar,

ich verstehe deine Empfehlung und die Lenkung der Aufmerksamkeit auf viele http-Requests, für größere Projekte ist dies sicher ein ernst zunehmender Faktor bei der Server-Auslastung, aber ich denke, dass viele Bilder in einer Webseite ebenfalls für viele Requests verantwortlich sind - in der Folge müßtest du also inline-Grafiken empfehlen...oder?

bye trunx

[Gunnar Bittersmann]

@@trunx:

nuqneH

aber ich denke, dass viele Bilder in einer Webseite ebenfalls für viele Requests verantwortlich sind - in der Folge müßtest du also inline-Grafiken empfehlen...oder?

Nö. (Aber Sprites.)

Auch keine CSS-Code und JavaScript-Code im HTML. Aber eben idealerweise ein eingebundenes Stylesheet, ein eingebundenes Script.

Qapla'

[Cybaer]

Hi,

dies sicher ein ernst zunehmender Faktor bei der Server-Auslastung,

Nein, die Serverauslastung spielt dabei nicht die mal entscheidende Rolle.

aber ich denke, dass viele Bilder in einer Webseite ebenfalls für viele Requests verantwortlich sind - in der Folge müßtest du also inline-Grafiken empfehlen...oder?

Das Problem ist, daß Stylesheets geladen und interpretiert werden, bevor das HTML interpretiert und dargestellt wird. Man hat bei AFAIK *allen* halbwegs aktuellen Browsern auch sinnvollerweise mit JS bereits Zugriff auf das CSS, bevor das BODY-Element überhaupt existiert.

Gleiches gilt (i.d.R. und momentan noch) für externe JavaScripts im HEAD: Sie blockieren den Browser.

Bilder werden hingegen erst geladen, *nachdem* das HTML gerendert wurde. Der User kann also schon eher loslesen, wenn der Browser zu Anfang möglichst wenig laden muß ...

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

nuqneH

Gleiches gilt (i.d.R. und momentan noch) für externe JavaScripts im HEAD: Sie blockieren den Browser.

Weshalb man externe JavaScripts zweckmäßigerweise als letztes im 'body' einbindet. [PERFORMANCE-BP2]

Hat zudem den Vorteil, dass man zu dem Zeitpunkt das DOM verfügbar hat und sich das Warten auf "domready"- oder "load"-Events sparen kann.

Qapla'

[Cybaer]

Hi,

Hat zudem den Vorteil, dass man zu dem Zeitpunkt das DOM verfügbar hat und sich das Warten auf "domready"- oder "load"-Events sparen kann.

Na ja, "domready" bedeutet ja "DOM is ready". Zumindest wenn JS am Ende als externe Resource eingebunden wird, dürfte einiges an ggf. nicht erwünschter Zeit verstreichen zw. "DOM is ready" und "JS ist auch endlich vorhanden, um das DOM zu manipulieren". =:-)

Dazu kommt noch, daß ggf. dann erstmal die Bilder geladen werden, weil die im Quelltext halt vorher stehen.

Und wenn man es wagen sollte, JS intern zu verwenden, dann schreien wieder viele auf, man solle doch gefälligst Content und Programmlogik trennen! >;->

Gruß, Cybaer

[molily]

Meiner Meinung nach diskutiert ihr viel zu absolut, es sollte von Fall zu Fall betrachtet werden.

Ich sehe das aus einer anderen Perspektive. In unserer Firma™ sind Konventionen wichtig, was den Aufbau von Projekten angeht. So kann sich jeder, dem dieser Aufbau bekannt ist, im Projekt zurechtfinden und ein neues Projekt kann anhand eines festen Gerüsts an Backend-Code, Templates und Stylesheets gebaut werden. Dieses Grundgerüst muss ausbaubar sein. Deshalb habe ich dabei den CC-Ansatz gewählt. Dass gerade das die Wartbarkeit, also »die Leichtigkeit, mit der ein System verändert oder erweitert werden kann«, verschlechtert, habe ich nicht feststellen können. Im Gegenteil.

Meiert spricht aus einer Perspektive von High-Performance-Websites wie Google, Yahoo, Amazon. Da machen ein oder zwei Stylesheets vielleicht einen Unterschied. Ich baue zwar nicht nur Kaninchenzüchterverein-Websites, aber auch keine Alexa Top-100-Sites. Ob ich nun ein oder zwei Stylesheets einbinde, war bei den bisherigen Projekten nicht entscheidend für die Performance. Bzw. es würde sie zwar minimal verbessern, aber der Aufwand stände in keinem Verhältnis zur erzielten Verbesserung. Optimierungspotenzial gibt es woanders genauso. Sich auf den Kampf gegen CCs einzuschießen verschleiert das Thema eher und lässt andere Möglichkeiten außer Acht.

Dafür, dass wir hier im SELFHTML-Forum meistens (no offense) über Kleingartenverein-Websites reden, bei denen so gut wie gar nichts optimiert wurde (und das die Site auch nicht substanziell verbessern würde, weil die Schwächen ganz woanders liegen), werden hier arglosen Fragende viel zu oft an unangebrachten Maßstäben gemessen.

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

Meiert spricht aus einer Perspektive von High-Performance-Websites wie Google, Yahoo, Amazon.

Auch.

Aber auch vor allem von Wartbarkeit. Vom „Prinzip der Nähe“ der Anpassungen für IE zu den Regeln für andere Browser.

IMHO sollte beides auf einen Blick erkennbar sein, nicht auf verschiedene Dateien verteilt.

Darin sehe ich den (für den Webautor!) entscheidenden Vorteil gegenüber CCs und Extra-Stylesheets, nicht in den eingesparten HTTP-Requests und Responses.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

IMHO sollte beides auf einen Blick erkennbar sein, nicht auf verschiedene Dateien verteilt.

Aus dem Grund fand ich es auch blöd, CSS-Expressions à la

selector {property: expression( [code lang=javascript](function(element) { element.style.property = value; })(this) ); [/code]

wegen Webkits am Ende des Stylesheets – also nicht in der Nähe der anderen Regeln – schreiben zu müssen, und war froh, dass

selector {property: expression( [code lang=javascript](new Function("element", "element.style.property = value;"))(this) ); [/code]

dort stehen kann, wo es hingehört.

Selbst, wenn 'new Function("foo", "bar")' nicht so effizient sein sollte wie 'function(foo) { bar }'. (Ist dem so?)

Qapla'

[Cybaer]

Hi,

IMHO sollte beides auf einen Blick erkennbar sein, nicht auf verschiedene Dateien verteilt.

Ja, IYHO! IMHO ist es so, daß ich die wenigen IE-Anpassungen gerne übersichtlich in einer Extra-Datei habe. Ich nutze allerdings auch Editoren, mit denen ich mehrere Dateien gleichzeitig offen haben kann ... ;)

Gruß, Cybaer