Abro, Oktober 2008

CSS – Tips für ein valideres und professionelleres Stylesheet

Heute zwang mich der SEOnaut kurz auf eine gruselige Webseite, welche sich da “Sackstark” schimpft. Irgendwie gehts um Bayern, Mauerposten und Pro-Raucherinitiativen… olé. Als ich dann aber auf Carolus’ Seite über Browserupdates & Empfehlungen stoße, komme ich nicht umher Goethes Erben zu zitieren “Ton um Ton wird alles grau, Ton um Ton verstummt”. Ich möchte hier nicht unbedingt diffamieren, aber Halbwissen sollte man doch bitte für sich behalten. Vielleicht wird ja auf diesen Hinweis folgend nocheinmal das CSS überarbeitet. Ich fand keine Resets oder vergleichbares. Wir schweigen und genießen – Wer meinen Humor teilt, darf anschließend gern kommentieren :

Screenshot FireFox3 CSS-Bug von Sackstark

Ok, ich surfe normalerweise mit der Schriftart Lucia Sans Unicode bei 16pt, die ist schon etwas größer, aber das ist doch kein grund ? Zumal ich ja “Myriad Pro, Arial, sans-serif” benutzen dürfen soll …

Ergo möchte ich einmal wieder versuchen zufällige Fetzen aus meinem Bildungspool zu streuen. Wie macht man sich die Arbeit mit CSS einfacher, wie erhält man konsistente, möglichst valide Ergebnisse?


Layouttypen

Zuerst ist zu überlegen um welchen Layouttyp es sich handeln soll. Man hat Grundlegend die Wahl zwischen statisch (fixed), elastisch und flüssig (fluid).

Fixed bedeuted meist nur “feste Breite”. Standartmäßig ist das heute 960px. Dies ergibt sich aus Nutzungsstatistiken, die mit Hilfe von JavaScript erstellt wurden. Der Grundgedanke dieser Zahl ist, dass nur noch ein verschwindend geringer Teil der Nutzer eine Auflösung von < 1024×768 fährt. Der Viewport des Browsers ist natürlich etwas kleiner aufgrund von Browserfensterrändern, Scrollbars und möglicherweise geöffneten Browsersidebars (z.B. History), oder Applikationen wie ICQ. Nachteile, die diese Herangehensweise mit sich bringt, werden abgemildert durch eine interessante Nutzungsmöglichkeit der Sicherheit. Manch einer mag seinen Content am linken Bildschirmrand festtackern, unwichtigeres wie Widgets oder Werbung dagegen rechts anordnen und letzteres nur den Usern mit großer Auflösung zeigen. Wird das aber nicht richtig austariert, kann es sehr unprofessionell wirken.

Vorteile:

  • Schlechte Lesbarkeit durch lange Zeilen wird vermieden
  • Wenig Rechnerei beim CSS schreiben
  • Elemente bleiben eher da, wo man sie haben will

Nachteile:

  • Für mobile Endgeräte muss ein zweites Stylesheet geschrieben werden (und mobil ist im kommen!)
  • Sollte doch mal jemand mit kleiner Auflösung vorbeikommen, muss er horizontal Scrollen
  • Bei großen Auflösungen bleibt viel Platz ungenutzt und der Content sieht ggf. etwas verloren aus
  • Es ist eine denkbar schlechte Basis für Barrierefreie Webseiten
  • Hat der user eine zu große Schrift verschwindet Text unter dem Rand seines Layers
  • Die Spaltenzahl im Content wird limitiert (siehe oben und vergleiche Fluid)

Ergo:

  • Genügend Padding um Text setzen.
  • Möglichst viele Tests bei verschiedenen Auflösungen machen. Browsershots ist da ganz hilfreich.
  • Vielleicht unterstützend per JQuery in kleinen Auflösungen unwichtige Spalten löschen

Elastisch meint, dass sich die Größen aller Elemente an der Schriftgröße des Browsers orientieren. Die Angaben sind dann ausnahmslos in der Einheit “em” auszuzeichnen, wobei 1em per default meist 16px sind. Das bringt einiges mit sich. Primär ist hier auf die Vererbung zu achten. Schreibt man div{ font-size:0.8em }, ist in einem Div zweiter Ebene die schrift 0.8em von 0.8em groß. Bei der Standartschriftgröße also für das erste Div 0.8em*16px= 12,8px und für das zweite 0.8em*12,8px=10,24px. Aber BITTE rechnet nicht so viel rum, denkt einfach in em!

Vorteile:

  • Es sieht verdammt Cool aus wenn man die eigene Schriftgröße umstellt
  • Fast unkaputtbar, wenn es richtig gemacht wird
  • Leicht zu testen
  • Eine Super Basis für Barrierefreiheit

Nachteile:

  • Wenn keine maximale Breite eingestellt wird, haben wir wieder H-Scrollbalken
  • Bilder machen wie auch bei Fluiden Layouts Probleme wenn sie mitskalieren sollen

Ergo:

  • Überlegen das CSS2-Attribut max-width zu nutzen. (Im IE erst ab Version 7 möglich!)
  • Überlegen ob es nicht kompatibler ist dieses mit Fluidem Layout zu kombinieren

Fluid und voll flexibel wird es dann, wenn man alle größenangaben in Prozent machen will. Die Arbeitsweise verhält sich hier ähnlich wie für elastische Layouts. Ansonsten sind bei Fluiden Layouts meist sehr viele Elemente Floatend. Das heisst wenn das Browserfenster verkleinert wird, rutschen einige Elemente automatisch vom Rand aus nach unten, um den anderen mehr Platz zum ausdehnen zu verschaffen.

Vorteile:

  • Keine Horizontalen Scrollbalken
  • User kann immer alle Elemente sehen
  • Die Seite sieht immer gleich groß aus
  • Auch ziemlich stabil, wenn richtig umgesetzt

Nachteile:

  • Elemente können Sehr klein werden
  • Viel Bastelei, wenn ein einzelnes floatendes Element im Raum umherrutscht und doof aussieht.

Ergo:

  • Das Attribut min-width nutzen
  • Font-Size Hack gegen zu kleine Schriftgrößen verwenden (siehe unten)

Einbindungsarten

Inline : Vergesst Inline (das selbe gillt für onclick-JavaScript)! Ihr macht euch nur unglücklich und aus dem XHTML ein einziges unwartbares Kuddelmuddel. Zudem müsst ihr doch noch auf die CSS-Datei zurückkommen, wenn auf einmal Hoverstyles oder ähnliches definiert werden sollen.

1
2
3
4
5
  <!-- Auch bei Inline-Styles muss ein Typ angegeben werden !! -->
  <meta http-equiv="Content-Style-Type" content="text/css" />
</head>
<body>
  <h1 style="color:#008; text-decoration:underline;">Eine Überschrift</h1>

Eingebettet : Ganz nett wenn es einmal schnell gehen soll. Ist aber schnell ernüchternd wenn die eine Datei länger und länger wird. Hier gibt es auch wieder ein Browserkompatibelitätsproblem. Alte Browser unterstützen keine Styles, das ist bekannt und darum setzt man alle Angaben in einen HTML-Kommentar-Tag. Allerdings muss man sich fragen “Welches HTML schreibe ich, wer sind meine Nutzer ?”. Die optimale Lösung ist heute leider immernoch XHTML zu schreiben und dieses NICHT mit dem dafür vorgesehenen Datentyp “application/xhtml+xml” auszuliefern, sondern per “text/html“, da dieses als einzig möglicher Datentyp mit HTML 4.01 Kompatibel ist und somit auch von Browsern die nur HTML 4 verstehen interpretiert werden kann. Würden wir echtes XHTML schreiben, hätten die Dateien auch die Endung .xml statt .html *zwinker* Wenn XML ausgeliefert wird, muss man im gegensatz zum Plaintext-HTML den Style-Inhalt nicht auskommentieren, da alle Browser die XML-Webseiten parsen können, so neu sind, dass sie auch die Styles verstehen.

1
2
3
4
5
6
<!-- Einbettung eines Stylesheets in Non-XML-HTML: -->
<style type="text/css">
  <!--
    element{ attr : value; }
  -->
</style>
1
2
3
4
5
6
<!-- Einbettung eines Stylesheets in XML-HTML: -->
<style type="text/css">
  <![CDATA[
    element{ attr : value; }
  ]]>
</style>
1
2
3
4
5
6
<!-- Ein hübscherer aber nicht so kompatibler Mittelweg wie der folgende: -->
<style type="text/css">
  /* <![CDATA[ */
    element{ attr : value; }
  /* ]]> */
</style>
1
2
3
4
5
6
<!-- Einbettung eines Stylesheets in gemischten Umgebungen (z.B. bei Browserweichen): -->
<style type="text/css">
  <!--/*--><![CDATA[/*><!--*/
    element{ attr : value; }
  /*]]>*/-->
</style>

Extern : Die einzig wahre Lösung für die professionelle Webentwicklung. So kann man sauber modularisieren und wenn man Conditional Comments verwendet, wird das Haupt-Stylesheet komplett IE-Hackfrei, soll heißen valide.

1
2
<!--einbindung in html -->
<link rel="stylesheet" type="text/css" href="base.css" />
1
2
<!--zusätzliche möglichkeit der einbindung in x(ht)ml -->
<?xml-stylesheet type="text/css" href="base.css" ?>

Conditional Comments sind ziemlich einfach in der Handhabung, eine Referenz findet ihr in Microsofts MSDN. Aber: Nutzt sie niemals im HTML-Body!

1
2
3
<!--[if lt IE 7]>
  <link rel="stylesheet" type="text/css" href="ie.css" />
<![endif]-->

Reset – die Basis

Der CSS-Reset wird von mir in der üblichen Form überhaupt nicht genutzt, weil es einfach viel zu viel Overhead hat. Wer sich dafür interessiert, dem empfehle ich Tripoli oder ein Gridsystem wie 960gs oder Blueprint. Statt dessen kann man schon eine ganz gute Basis mit folgenden Zeilen erreichen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
  *
  {
    background      : transparent;
    border          : 0;
    content         : none;
    font-family     : inherit;
    font-size       : 100%;    /* or 1em */
    margin          : 0;
    padding         : 0;
    quotes          : none;
    text-decoration : none;
  }
  :before, :after
  { content         : none; }
  :focus
  { outline         : none; }
  html
  {
    font-size       : 100.01%; /* or 1.01em */
    height          : 100%;
  }
  body
  {
    font-size       : 80%;      /* or .8em */
    height          : 100%;
    line-height     : 140%;    /* or 1.4em */
  }

Natürlich habe ich nocheinmal drübergearbeitet zum publizieren *hust* Über text-decoration mag man sich streiten, für mich ist diese Art aber die simpelste. Ich will eh alles stylen, auch Formulare etc. pp.

Das einzige was mir an obigem Code wohl zu erläutern bleibt ist Zeile 19. Sie setzt in weitgehend allen Browsern die Startschriftgröße gleich. Bei 100% würden einige Opera-Browser zu kleine Ausgaben liefern, bei 101% vergrößert Safari die Schrift zu stark. Die gegebene Auszeichnung sollte von Teilzeit-CSS-Schreibern beibehalten werden, selbst wenn alle anderen Angaben in em gemacht werden. Sie gillt als Standard und jeder professionelle Designer weiss sofort um was es geht. Zudem soll es einen Vererbungsfehler im IE umgehen.

Alles was dort steht, kann so belassen werden. Darum vergesst um Himmels Willen nicht die Hintergrund- und Schriftfarbe im Body zu setzen. Viele Browser verwenden einen grauen Hintergrund, außerdem kann man das ziemlich einfach im OS und in den Browsersettings umstellen.

Des Weiteren fällt euch möglicherweise mein Codingstil auf: Man kann es ja händeln wie man mag, wichtig ist, dass man im Projekt feste Vorschriften setzt welcher Stil verwendet werden soll. Ich nehme aus PHP meinen BSD/East Coast -Stil eigentlich überal hin mit. So auch nach CSS. Dabei hat es sich als gute praxis herausgestellt zwei Spaces statt eines Tabs zu benutzen (und eine Monospace Schriftart), damit sich nichts verschiebt und immer alles gleich aussieht, wenn man mal sein Notebook nicht zu Hand hat. Was ich aber noch seltener sehe ist meine Angewohnheit alle Doppelpunkte untereinander in eine Linie auszurichten. Das schafft mir eine noch bessere Lesbarkeit der Attribute und es zwingt mich den Code stark zu modularisieren. Denn bei Konstrukten wie -khtml-border-radius-bottomright wird die Einrücktiefe -ich geb’s ja zu- schon pervers. Jeder Stil hat ja seine Schwächen. Ich mag gar nicht auf “Single Line CSS” zu sprechen kommen. *schüttel*

Darum nur noch meine abschließenden Empfehlungen sich vor größeren Projekten einmal CSSDoc, YAML, ServerSide-CSS und Conditional-CSS anzuschauen.


Kommentare sind geschlossen.
Aufgrund interner Umstrukturierungsmaßnahmen ist es uns z.Zt. leider nicht
möglich auf neue Kommentare zu reagieren. Wir bitten dies zu entschuldigen.
Bei dringenden Rückfragen suchen Sie bitten den direkten Kontakt zu uns.
Das Unternehmen Lucido Media GbR wurde am 31.12.2013 stillgelegt. Diese Website existiert weiterhin zu Archivzwecken. Der Gesellschafter Daniel Abromeit führt seine Arbeit ab sofort unter dem Dach der Agentur Koch Essen fort. Für entsprechende Anfragen wenden Sie sich daher bitte an http://koch-essen.de/kontakt/