NoLabel: Extern oder im Quellcode?

Hallo,

mal ne kurze Frage zum besseren Verständnis.
Ist es sinnvoll eine vorhandene externe CSS-Datei mit Styles zu erweitern, die nur dann und wann benötigt werden, oder sollte man die zusätzlichen dann lieber in den head-Teil der entsprechenden HTML-Seite setzen?

Zum Beispiel meine ich damit farbige Eingabefelder mit festen Pixelgrößen und farbige Buttons.
Diese werden ja nun nicht auf jeder Seite verwendet und derzeit lege ich die halt im head-Bereich der Seite in der sie benötigt werden mit dazu.

Oder sollte man so etwas dann wenn benötigt eventuell mittels:

<style type="text/css">
<![CDATA[
@import url(../css/weiterestyles.css);
]]>
</style>

einbinden.

Ich frage wegen Ladezeiten, oder fallen 50 Zeilen Quellcode in einer immer wieder ladenden CSS-Datei zu unwesentlich ins Gewicht als das man sich da Gedanken drüber machen sollte?

Viele Grüße und allen einen guten Rutsch ins neue Jahr,
Michael

  1. Hi NoLabel,

    viel ausmachen tut's sicher nicht, denn die Seite wird ja gecacht. Aber die andere Lösung finde ich auch gut, wenn die externe Datei ansonsten zu groß und unübersichtlich wird.

    Viele Grüße
    Mathias Bigge

    1. Hallo Mathias,

      Dir ist ja schon vor einiger Zeit aufgefallen [1], dass wir oft fast zeitgleich auf bestimmte Threads antworten - aber langsam wirds mir wirklich unheimlich... gleich 2x kurz hintereinander. Vielleicht sollte ich meinen ablehnende Einstellung zu Psi- und sonstigem Kram überdenken...?

      Grüße,

      Christian

      [1] </archiv/2002/12/31039/#m167639>

      --
      Ich wünsche allen frohe Weihnachten!
      Ich bitte darum, dass ein Themenbereich (BARRIEREFREIHEIT) eingerichtet wird.
  2. Hallo Michael,

    Ich frage wegen Ladezeiten, oder fallen 50 Zeilen Quellcode in einer immer wieder ladenden CSS-Datei zu unwesentlich ins Gewicht als das man sich da Gedanken drüber machen sollte?

    Wie groß ist Deine CSS-Datei? Ist sie schon an der "Schmerzgrenze" oder nicht? (wobei man noch definieren müsste, was die Schmerzgrenze ist...)

    Es gibt dann noch die Frage nach dem Verhalten Deiner Besucher - laden die oft nur die Startseite oder bewegen sie sich länger auf Deiner Seite? (ich weiß, das kann man eigentlich nicht rausfinden, aber zumindest annäherungsweise Daten lassen sich aus den Logfiles herausholen) Wenn sie oft nur die Startseite ansehen, dann definitiv in eigene Stylesheets auslagern. (Kopfbereich ist deswegen "blöd", weil wenn Du was ändern willst, musst Du alle Dateien ändern) Wenn sie aber mehrere Seiten anschauen, dann alles in ein Stylesheet. IMHO natürlich.

    Grüße,

    Christian

    --
    Ich wünsche allen frohe Weihnachten!
    Ich bitte darum, dass ein Themenbereich (BARRIEREFREIHEIT) eingerichtet wird.
    1. Hallo Christian,

      Wie groß ist Deine CSS-Datei? Ist sie schon an der "Schmerzgrenze" oder nicht? (wobei man noch definieren müsste, was die Schmerzgrenze ist...)

      Sie ist derzeit, Achtung festhalten knapp 2Kbyte. ;-) Gut, Defintion Schmerzgrenze. Das ist die Frage. Da ich, was Stylesheets betrifft doch eher mal dazu neige den Rahmen zu sprengen und gerne halt mal dann und wann ne Schriftgröße doch lieber etwas kleiner oder größer hätte, müsste ich das künftig auch vorher mit in die CSS-Datei packen und somit wird sie wohl wesentlich größer.

      Es gibt dann noch die Frage nach dem Verhalten Deiner Besucher - laden die oft nur die Startseite oder bewegen sie sich länger auf Deiner Seite? (ich weiß, das kann man eigentlich nicht rausfinden, sie aber mehrere Seiten anschauen, dann alles in ein Stylesheet. IMHO natürlich.

      Sowohl als auch, denn gerade die Hauptseite enthält einen Messageticker, der auch immer wieder nachgeladen wird und die Unterseiten werden wegen den Anzeigen auch angesehen.

      Als wäre wohl wirklich die klügste Variante eine zweite CSS-Datei einzubinden wenn sie halt von der Seite benötigt wird?!

      Gruß,
      Michael

      1. Hallo Michael,

        Sie ist derzeit, Achtung festhalten knapp 2Kbyte. ;-)

        Naja, dann kannst ja noch was reinpacken, ich denke bis 5-7 KB sind akzeptabel, ab dann sollte man versuchen zu optimieren (Kommentare weglassen, etc.)

        Da ich, was Stylesheets betrifft doch eher mal dazu neige den Rahmen zu sprengen

        Ach was, es gibt durchaus Stylesheets mit 32 KB da draußen, aber das ist _eindeutig_ zu viel. ;-)

        Als wäre wohl wirklich die klügste Variante eine zweite CSS-Datei einzubinden wenn sie halt von der Seite benötigt wird?!

        Ja. Das wäre in Deinem Fall wirklich die beste Variante.

        Grüße,

        Christian

        --
        Ich wünsche allen frohe Weihnachten!
        Ich bitte darum, dass ein Themenbereich (BARRIEREFREIHEIT) eingerichtet wird.
  3. hi

    Ist es sinnvoll eine vorhandene externe CSS-Datei mit Styles zu erweitern, die nur dann und wann benötigt werden, oder sollte man die zusätzlichen dann lieber in den head-Teil der entsprechenden HTML-Seite setzen?

    ich würd' die dann auch nur in der Datei einbauen, wo man sie braucht - aber auch nur bei welchen, wo man sich relativ sicher sien kann, die nicht später nochmal woanders zu brauchen!
    Besonders die Start-Seite hat ja öfters mal eigene Styles...

    Grüße aus Bleckede

    Kai

  4. Hi NoLabel,

    Ist es sinnvoll eine vorhandene externe CSS-Datei mit Styles zu erweitern, die nur dann und wann benötigt werden, oder sollte man die zusätzlichen dann lieber in den head-Teil der entsprechenden HTML-Seite setzen?
    Ich frage wegen Ladezeiten, oder fallen 50 Zeilen Quellcode in einer immer wieder ladenden CSS-Datei zu unwesentlich ins Gewicht als das man sich da Gedanken drüber machen sollte?

    wenn ich ein HTML-Dokument in meine site einbaue, dann muß ich mir zunächst einmal Gedanken darüber machen, wohin damit. Dies hängt für mich wesentlich davon ab, ob das Dokument in struktureller Hinsicht ein Unikat ist oder zu einer Sorte von Dokumenten gehört.

    Und wenn ich diese Frage entscheiden kann, dann kann ich diese Erkenntnis für die CSS-Formatierung mit verwenden: Unikate haben bei mir CSS im HTML-Dokument drin, Sorten-Dokumente importieren externes CSS. Wobei alle Dokumente in gewisser Weise zur Sorte "meine Dokumente" gehören und eine gewisse Grundformatierung, die in allen bzw. sehr vielen Dokumenten benötigt wird, immer importieren. Zusätzliche Formatierungen, die nur für eine bestimmte Sorte von Dokumenten verwendet wird, kommt in eine CSS-Datei dieser Dokument-Sorte - und falls es innerhalb der Dokument-Sorte noch eine Untergruppierung geben sollte, kann auch diese wiederum eine eigene CSS-Datei rechtfertigen.

    Bei meinen Dokumenten kann es also vorkommen, daß ein Dokument sowohl mehrere (etwa 2-3) CSS-Dateien importiert als auch lokale CSS-Definitionen im Dokument selbst besitzt.
    Ich versuche, mich dabei von der Idee einer entsprechenden Informations-Kapselung leiten zu lassen: Jede Formatierung wird so global wie nötig, aber so lokal wie möglich definiert - Duplikate von CSS-Code sind zu vermeiden, wenn sie durch die Überlagerung mehrerer CSS-Dateien ersetzt werden können.

    Der Preis, den ich dafür zahle, ist, daß ich nur unter erheblichem Zusatzaufwand meine CSS-Definitionen warnungsfrei validiert bekomme. Denn ich verwende innerhalb einer "Sorte" oftmals inkrementelle Überlagerungen bestimmter Definitionen - und das mag der CSS-Validator nicht, weil er mir nicht glaubt, daß ich weiß, was ich tue.
    Ich wollte, ich könnte in CSS ausdrücken: "Ja doch, ich weiß, daß ich hier eine globale Dokumentation überschreibe, aber genau das ist doch der Sinn von kaskadierenden Definitionen, also vertrau mir einfach ...".
    Ich könnte dies vermeiden, indem ich für jede zusätzliche Formatierung lokale Klassen einführe ... aber das würde meinen HTML-Code unnötig aufblähen. Also lebe ich mit den CSS-Validator-Warnungen und habe dafür eine minimale und redundanzfreie Informationsrepräsentation - das reicht mir so.

    Ach ja: CSS-Code innerhalb von HTML-Dateien kann gefahrlos zusammen mit dem HTML-Code in komprimierter Form ausgeliefert werden, während eine komprimierte Auslieferung von separaten CSS-Dateien immerhin Netscape 4 völlig überfordert.
    Falls Du also um die Größe Deiner Dateien besorgt bist, denke über Komprimierung nach ... und über "aggressives" Browser-Caching, das Du durch Mitliefern entsprechender HTTP-Header fördern kannst.

    Viele Grüße
          Michael

    --
    T'Pol: I apologize if I acted inappropriately.
    V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
    1. Hi,

      die Frage, ob man CSS bedarfsweise ins HTML-Dokuemnt importiert oder gleich dort platziert, ist ausser einer "Performance-Sicht" m.E. hauptsaechlich unter einer "Organisations-Sicht" zu betrachten.

      Michael Schroepl hat da schon einige entwickelte Kriterien genannt, (und "Preise", die ggf. zu zahlen sind). - Meine dulle und ideologiefreie (stimmt natuerlich nicht ganz) ist, dass Formatierungen mithilfe von CSS-Dateien grundsaetzlich ausgelagert werden sollten.

      Und zwar damit im Einzelfall nicht jeweils entschieden werden muss.

      IT ist zu 70% Kommunikation, zu 25% Organisation (siehe o.), zu 4% Produktwissen und zun 1% Intelligenz.

      Frohes neues Jahr!
      Lude

    2. Hi Michael,

      ich nutze schon lange CSS für Formatierungsaufgaben, stehe aber zur Zeit vor der Aufgabe, eine umfangreiche Site zu reformieren und dabei auch die Positionierung von Tabellen auf CSS umzustellen und komme dadurch automatisch in das unübersichtliche kaskadierende Kaskadensystem hinein, das Du so schön geschildert hast. Natürlich ist die Aufgabe, ein bestehendes System umzustellen, anspruchsvoller als etwas ganz neu zu entwickeln, weil man sich bestimmte Dinge einfach ersparen würde, aber dass es so komplex sein würde, die Seite in allen Browsern halbwegs auf einen Nenner zu bringen, habe ich nicht einkalkuliert. Vor allem der vielgerühmte Effekt, dass die Layouts sich flexibler unterschiedlichen Fenstergrößen anzupassen, ist schwerer zu erreichen, als ich dachte. Wenn man alles einfach mit absolut-positionierten DIVs auf den Bildschirm nagelt, kann man es ja auch gleich bei Tabellen lasse, oder?

      Na ja, vielleicht fehlt mir einfach noch die Übung, aber die klare Verbesserung, die einige hier im Forum seit längerem predigen, sehe ich noch nicht. Plötzlich übernimmt der Mozilla eine in einer zentralen CSS-Datei angegebene Listenformatierung nicht, die alle anderen Brauser klaglos schlucken und nimmt die Systemschrift und so weiter. Saublöde Effekte. Überhaupt die Listen, überhaupt die Positionierungen, das sind ja Urzeiteffekte wie dereinst der berüchtigte Browserversatz, und auch die Komplexität von verschachtelten CSS-Fromatdateien mit eingebauten diversen Browserweichen find ich irre hoch.

      Na ja, macht euch nur lustig, die ihr den Frust vor einem Jahr durchgestanden habt, und es heute drauf habt, aber ob es für ein Großprojekt wirklich sinnvoll ist, seine Seiten komplett auf diese Weise vorzuhalten, wage ich zu bezweifeln. Wie sollten ein Assistent und ein Tenplate für den Selfraum aussehen, wenn dahinter ein ganzer Wahn von verschachtelten CSS-Dateien plus interne Browserdifferenzierungen hängen müsste?

      Huach, aus lauter Ärger hab ich eine der neuen Seiten in 10 Minuten auf die traditionelle Weise mit Tabellen positioniert. Zeitaufwand: 10 Minuten und alles sitzt in allen Browsern an der gleichen Stelle. Mal sehen, wie lange ich für die Realisierung mit CSS-Positionierung  brauche *g*

      Machst Du mir eher Mut, Michael, dass ich es noch hinkriege, oder ist es wirklich so nervig?

      Viele Grüße
      Mathias Bigge

      1. Moin!

        Natürlich ist die Aufgabe, ein bestehendes System umzustellen, anspruchsvoller als etwas ganz neu zu entwickeln, weil man sich bestimmte Dinge einfach ersparen würde, aber dass es so komplex sein würde, die Seite in allen Browsern halbwegs auf einen Nenner zu bringen, habe ich nicht einkalkuliert. Vor allem der vielgerühmte Effekt, dass die Layouts sich flexibler unterschiedlichen Fenstergrößen anzupassen, ist schwerer zu erreichen, als ich dachte. Wenn man alles einfach mit absolut-positionierten DIVs auf den Bildschirm nagelt, kann man es ja auch gleich bei Tabellen lasse, oder?

        Da hast du durchaus Recht.

        Bedenke, welche Elemente du mit CSS formatierst: Im Prinzip hast du immer Blöcke vorliegen. Diese Blöcke sind auf der Seite untereinander gestapelt und nehmen immer die volle zur Verfügung stehende Breite ein. Von _was_ das die Breite ist, kann sich abwechseln, generell ist es erstmal die Breite des Browserfensters. Wenn du ein Menü-DIV absolut positioniert und in der Breite festgelegt hast, sind die Blöcke darin eben so breit wie das Menü.

        Im Prinzip ist auch das Layouten mit CSS genau wie das Layouten mit Tabellen ein Suchen nach den richtigen Blöcken - nur sehen die Blöcke jetzt anders aus.

        Obendrein kann man Blöcke dann auch in enthaltenen Blöcken links oder rechts fließen lassen (float:left/right), was nochmal eine weitere Ebene von Möglichkeiten eröffnet.

        Insgesamt macht man mit CSS-Layouts den Seiteninhalt wieder mehr so, wie man HTML 2.0 mal geschrieben hat: Ganz viele semantisch wertvolle <H1>, <P>, <UL> etc. als Block, und fast gar keine Tabellen (außer es handelt sich um Tabellendaten). Die Anordnung hingegen sieht dann nicht so langweilig aus, wie das typische <H1>-Times-groß-fett-Layout von anno dazumal, sondern die Blöcke werden schon durcheinandergewürfelt - nein, eigentlich werden sie an die passende Stelle im Browserfenster verschoben. Sowas klappt eigentlich so gut, dass man nur noch für Netscape 4 eine Browserweiche benötigt, weil der z.B. nicht vom rechten Rand aus positionieren kann. Ergo erhält der eine Formatierung mit fester Bildschirmauflösung (was dann erlaubt, auch Elemente am rechten Rand von links aus auszurichten), während alle besseren Browser dann dynamisch agieren können.

        Na ja, vielleicht fehlt mir einfach noch die Übung, aber die klare Verbesserung, die einige hier im Forum seit längerem predigen, sehe ich noch nicht.

        Wenn du erstmal Übung hast, dann siehst du die Verbesserung. :)

        Plötzlich übernimmt der Mozilla eine in einer zentralen CSS-Datei angegebene Listenformatierung nicht, die alle anderen Brauser klaglos schlucken und nimmt die Systemschrift und so weiter. Saublöde Effekte. Überhaupt die Listen, überhaupt die Positionierungen, das sind ja Urzeiteffekte wie dereinst der berüchtigte Browserversatz, und auch die Komplexität von verschachtelten CSS-Fromatdateien mit eingebauten diversen Browserweichen find ich irre hoch.

        Ich habe eigentlich noch keine solchen Bekanntschaften gemacht. Naja, mag sein, dass du CSS ein wenig ultrastark ausnutzen willst, obwohl du noch keine großen Erfahrungen gemacht hast. Vielleicht lasse ich gewisse Dinge einfach weg, weil ich sie entweder nicht kenne, oder weiß, dass sie Probleme verursachen.

        Na ja, macht euch nur lustig, die ihr den Frust vor einem Jahr durchgestanden habt, und es heute drauf habt, aber ob es für ein Großprojekt wirklich sinnvoll ist, seine Seiten komplett auf diese Weise vorzuhalten, wage ich zu bezweifeln. Wie sollten ein Assistent und ein Tenplate für den Selfraum aussehen, wenn dahinter ein ganzer Wahn von verschachtelten CSS-Dateien plus interne Browserdifferenzierungen hängen müsste?

        Der Assistent wäre sehr einfach. Er müßte lediglich das oder die vorhandenen Stylesheets mit einbinden, ansonsten könnte er sich strikt auf semantisch wertvolle Auszeichnung des darzustellenden Contents beschränken. Es müßte also kein Formatierungs-Assistent geschrieben werden, sondern eigentlich nur ein "Mach wertvolles HTML"-Assistent. Änderungen in den zentralen Stylesheets wirken sich dann sofort auf alle Seiten aus - und das ist dann die wirkliche Stärke von CSS (naja, eine davon). Allerdings ist nicht davon auszugehen, dass das Gesicht von SelfHTML sich in der nächsten Zeit nennenswert verändern würde.

        Huach, aus lauter Ärger hab ich eine der neuen Seiten in 10 Minuten auf die traditionelle Weise mit Tabellen positioniert. Zeitaufwand: 10 Minuten und alles sitzt in allen Browsern an der gleichen Stelle. Mal sehen, wie lange ich für die Realisierung mit CSS-Positionierung  brauche *g*

        Machst Du mir eher Mut, Michael, dass ich es noch hinkriege, oder ist es wirklich so nervig?

        Nein, es ist nicht so nervig. Natürlich, wenn du ein Tabellen-Design als Vorlage hast, ist es wesentlich einfacher, daraus eine HTML-Tabelle zu machen. Aber wenn du ein vernünftiges, modernes Design hast, dann kannst du wahlweise eine Tabelle draus machen, oder mit CSS auf die neue Art rangehen. Übung macht den Meister.

        - Sven Rautenberg

        --
        "Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)
      2. Hi Mathias,

        ich nutze schon lange CSS für Formatierungsaufgaben, stehe aber zur Zeit vor der Aufgabe, eine umfangreiche Site zu reformieren und dabei auch die Positionierung von Tabellen auf CSS umzustellen und komme dadurch automatisch in das unübersichtliche kaskadierende Kaskadensystem hinein, das Du so schön geschildert hast.

        so "unübersichtlich" finde ich das gar nicht. Insbesondere lagern die CSS-Dateien der diversen "Kaskaden" in verschiedenen Verzeichnisebenen - eine CSS-Datei liegt bei mir immer im Wurzelverzeichnis aller möglichen Anwendungsdateien, also so tief drin im Baum wie möglich. Am Ablageort einer Datei möchte ich deren Einfluß auf das Layout sofort erkennen - das ist eine zusätzliche implizite Dokumentationsmethode. (Eine nachträgliche Verlagerung einer solchen Datei "nach oben", weil plötzlich doch mehr Anwendungszwecke vorhanden sind als erwartet, wäre natürlich lästig, aber wenn man vorher gründlich nachdenkt, dann kommt das praktisch nicht vor.)

        Natürlich ist die Aufgabe, ein bestehendes System umzustellen, anspruchsvoller als etwas ganz neu zu entwickeln, weil man sich bestimmte Dinge einfach ersparen würde,

        Ja - aber ich habe noch nie eine große site so entwickelt, wie sie am Ende aussah. Auch meine Regeln und Erfahrungen sind erst mit den Jahren entstanden. Und bei CSS bin ich selbst ein "Spätgeborener", der lange an Netscape 4 geklebt und deshalb CSS nur mit sehr spitzen Fingern angefaßt hat.

        aber dass es so komplex sein würde, die Seite in allen Browsern halbwegs auf einen Nenner zu bringen, habe ich nicht einkalkuliert. Vor allem der vielgerühmte Effekt, dass die Layouts sich flexibler unterschiedlichen Fenstergrößen anzupassen, ist schwerer zu erreichen, als ich dachte. Wenn man alles einfach mit absolut-positionierten DIVs auf den Bildschirm nagelt, kann man es ja auch gleich bei Tabellen lasse, oder?

        Damit machst Du ein neues Faß der Diskussion auf. Bisher ging es ja um die Verteilung der Informationen, nicht um deren konkrete Inhalte und deren Interpretation durch die Browser.

        Na ja, vielleicht fehlt mir einfach noch die Übung, aber die klare Verbesserung, die einige hier im Forum seit längerem predigen, sehe ich noch nicht.

        Ich bin bei jeder Datei, die ich von HTML- auf CSS-Formatierung umgestellt habe, glücklich - weil sie anschließend der erwünschten Trennung von Inhalt und Formatierung sehr viel näher kommt als zuvor. Schon die zentrale Formatierung von Tags und die Existenz von CSS-Klassen sind Dinge, die HTML alleine nicht leisten kann. Die HTML-Dateien werden dadurch kleiner und besser lesbar.
        Selbst wenn ich CSS nur innerhalb jeder einzelnen Datei verwenden dürfte, wäre das eine Verbesserung gegenüber der Formatierung jedes einzelnen Tags, um beispielsweise die Borders bei den Links um Buttons-Graphiken weg zu bekommen etc.

        Huach, aus lauter Ärger hab ich eine der neuen Seiten in 10 Minuten auf die traditionelle Weise mit Tabellen positioniert. Zeitaufwand: 10 Minuten und alles sitzt in allen Browsern an der gleichen Stelle. Mal sehen, wie lange ich für die Realisierung mit CSS-Positionierung  brauche *g*

        Ich habe gerade meine HTML-Validierungsliste ein bißchen aufgewertet: Meine Homepage ist jetzt zu knapp 90% XHTML 1.1, also dort praktisch HTML-formatierungs-frei.
        Die restlichen 10% sind allerdings zu einem gewissen Teil sehr wohl noch Tabellen-Layouts - diese auf CSS umzubasteln dauert in der Tat sehr viel länger, als z. B. einen Artikel von Transitional auf Strict umzustellen. Deshalb habe ich zuerst alle Artikel umgestellt ... ach ja, und Framesets habe ich auch eine ganze Menge.

        Machst Du mir eher Mut, Michael, dass ich es noch hinkriege, oder ist es wirklich so nervig?

        Definiere "es". ;-)

        Wenn Du CSS über die Grenzen der existierenden Browser hinaus ausreizen willst, dann ist das nervig, ja (finde ich).
        Willst Du CSS nur verwenden, um HTML durch etwas Besseres zu ersetzen, was Dir eine bessere Verwaltung der Formatierungsinformationen ermöglicht, dann ist CSS hierfür m. E. sehr praktisch.

        Ich selbst bin bei meiner Homepage zu faul, Netscape 4 noch zu berücksichtigen (deshalb nehme ich auch schon XHTML 1.1, obwohl Netscape4 da nicht mal mehr die Link-Targets kapiert) ... und da ich von CSS eh nur eine relativ überschaubare Teilmenge ausnutze, ist mein Szenario möglicherweise sehr viel primitiver als Deines.
        Im Büro sieht das anders aus - da müssen wir die 20% Netscape4-Kunden unterstützen, so gut es irgendwie geht ... zum Glück macht _das_ ein Kollege von mir. ;-)

        Viele Grüße
              Michael

        --
        T'Pol: I apologize if I acted inappropriately.
        V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.