Ach Menno…

Wenn man sich vorstellt, dass grün gut ist und rot schlecht, dass grüner entsprechend besser und roter schlechter ist, dann wird man folgende Grafik ganz gut interpretieren können:

worst

Erzeugt wird diese Grafik von der Seite wann kann ich …. Hier kann man ganz schnell nachsehen, wann man endlich Schriftarten einbinden oder Layouts mit runden Ecken bauen können wird. Die Grafik fasst das auch ganz gut zusammen: neuere Techniken lassen sich nicht nativ mit dem IE, egal welcher Version bis weit ins Jahr 2010 hinein nutzen – Microsoft schickt also die Webentwicklung in die Warteschleife. Ich hoffe, dass einfach mehr Entwickler den Mut haben, den IE nicht vollständig zu unterstützen.

Andererseits – und das muss man einfach wirklich auch nochmal hervorheben, geht es in dieser Liste um Features aus CSS3 und HTML5. Standardlayouts mit abgehangenen Methoden herkömmlichen Mitteln lassen sich inzwischen und vor allen Dingen dann im IE8 schon ganz gut umsetzen.

7 Sachen

gmail
Gestern hat google in google-mail/google-reader neue schöne Knöpfe eingebaut. Sowas lässt sich ja mit einem Hintergrundbild lösen – vielleicht mit zwei. Weil einfach aber manchmal zu einfach ist, besteht jeder dieser Knöpfe aus sieben! verschachtelten divs. Warum, und vor allen Dingen wie man soetwas baut, steht hier.

Wozu html

Beim Betrachten unzähliger Quelltexte fällt mir häufig das Fehlen unterschiedlicher Tags auf. Der Quelltext ist eine Häufung von divs. Das ist grundsätzlich nicht verkehrt, div bedeutet letztlich Abschnitt, und hey, eine Zwischenüberschrift ist schließlich ein neuer Abschnitt. Divs sind cool, man kann sie unendlich oft verschachteln, und wenn man müde vom Kästchenbauen ist, definiert man im Stylesheet einfach display: inline.

HTML bietet aber einen deutlich bunteren Artenreichtum an Tags. Wenn ich weit ausholen würde, käme jetzt semantisches Webdesign, kurz lässt sichs aber auch so formulieren:
Baut Euren HTML-Quelltext so, dass der ureigentliche Sinn Eurer Seite auch ohne Stylesheet sofort ersichtlich ist.

Jedem seine Schicht

Websites bestehen heute aus mehreren Schichten: Contentschicht, Präsentationsschicht, Applikationsschicht. Das gilt selbst für eine simple HTML-Seite. Typischerweise sind diese Schichten auf unterschiedliche Dateien aufgeteilt. Das HTML-Dokument enthält Content, das Stylesheet die Formatierung und im Javascript ist Dynamisierung.
Wichtig ist hier die Ausschließlichkeit. So, wie im Sylesheet wenig Content zu finden sein wird, sollte andersherum im HTML-Quelltext keine Formatierung zu finden sein.
Logisch.
Dynamischer Content – dynmaische Regeln?
Wie aber sieht das aus, wenn der Content dynamisiert wird? Wenn bei der Eingabeprüfung per Javascript die Fehlermeldung ausgegeben werden soll? Hier verschwimmen schnell Grenzen und schnell steht im Javascript:

var fehler = „Das ist keine valide E-Mail-Adresse!“;
document.getElementById(„fehlermeldung“).insertData(0, fehler);

also Content. Hier sollte am Besten die Validierung serverseitig stattfinden, wo sie ohnehin implementiert sein muss, und das Ergebnis per AJAX abgeholt und dargestellt werden.
Weit häufiger aber gerät Formatierung ins Javascript. Zu einfach sind Elemente mit:

document.getElementById(„fehlermeldung“).style.display = „none“;

mal schnell zu verändern.
Auch diese Formatierung gehört ins Stylesheet. Soll ein Element dynamisch verschwinden, benötigen wir im Stylesheet:

.hidden {
display: none
}

und im Javascript:

document.getElementById(„fehlermeldung“).className = „hidden“;

Um nicht immer sämtliche Klassen eines Elementes zu überschreiben, habe ich mal schnell ein Script geschrieben, das Klassen an ein Element hinzufügt, löscht, oder einfach nur hin- und herschaltet:

var className = {
add: function(el, newClass) {
var classNames = el.className;
if (classNames.indexOf(newClass)==-1)
el.className = classNames + “ “ + newClass;
},
remove: function(el, newClass) {
var classNames = el.className;
var classNameArray = classNames.split(“ „);
var newClassNamesArray = [];
for(var i = 0; i <  classNameArray.length; i++)
if (classNameArray[i].indexOf(newClass)==-1)
newClassNamesArray.push(classNameArray[i]);
classNames = newClassNamesArray.join(“ „);
el.className = classNames;
},
toggle: function(el, newClass) {
var classNames = el.className;
if (classNames.indexOf(newClass)>-1)
this.add(el, newClass);
else
this.remove(el, newClass);
}
};

Ein Element verschwindet nun, indem man einfach

className.add(document.getElementById(„fehlermeldung“), „hidden“);

aufruft.

css-Tipp #735

Ich habe mal wieder ein paar Templates durchgesehen und will hier nun das Ergebnis ausbreiten:
Vermeidet Padding
paddingPadding ist für viele eine Elementeigenschaft, die auch irgendwie Platz macht. Padding sollte aber nur benutzt werden, wenn ein Element seine Kind-Elemente ein wenig vom Rand weg halten soll.
Initialisiert Elemente
Am Anfang des Stylesheets sollten alle Elemente, die Ihr benutzen wollt, auf Euren Standard gesetzt werden, um browserspezifische Styles zu überschreiben. Wichtig sind hier alle Listentypen, das Form- und alle Input-Elemente, alle Header und Paragraphs.
Aber
formatiert Klassen, keine Elemente
Wenn Ihr ein Element formatieren wollt, es also anders aussehen soll, als Eure initialisierten Elemente, dann ist seine Funktion im Kontext aller anderen Elemente so herausragend, dass es eine Klasse bekommen sollte. Der Killer ist sowas wie

.text a {
font-size: 16px;
display: block;
margin: 9px;
}

bleibt sauber
Fehler macht jeder mal. Du ganz sicher nicht. Also brauchst Du auch keine Angst davor zu haben, HTML und Stylesheet mal von einem Validator durchsehen zu lassen.
Sowohl Stylesheet als auch Quelltext sollten valide sein.

css: richtig benamsen

In den letzten Tagen habe ich mir wieder ein paar HTML-Templates angesehen. Drum hier noch ein paar Tipps, wie man seine CSS-Klassen sprechend benamst, und ein wenig Verschachtelung. Immer wieder predige ich ja, dass eine CSS-Klasse nicht aussagt, was sie macht, sondern welche Funktion das benamste Element im Gesamtkontext hat. Immer wieder bin auch ich daran gescheitert, bei einem mehrspaltigen Layout die Spalten so zu benennen, dass es einerseits schlüssig ist, andererseits aber nicht column-left dabei rauskommt.

Da man bei der Strukturierung von Content, also auch bei der Vergabe der Klassen, aber nicht vom Design, sondern ausschließlich vom Inhalt gelenkt wird, sollten die Spalten also gemäß ihrer Wichtigeit und infolgedessen auch der Reihenfolge im Quelltext durchnummeriert sein. Die Klassen könnten also content1, content2 usw heißen. Column lehne ich damit auch gleich ab.

Verschachtelung

Ein gern eingestztes Designelement sind Boxen. Man organisiert seinen Inhalt in Kästchen auf der Seite, schafft damit eine klare Abgrenzung und vielleicht die Möglichkeit, den User seinen Content umorganisieren zu lassen. Oft sollen sich diese Boxen nun auch in Farbe und Form voneinander unterscheiden. Haben aber trotzdem ähnliche Merkmale.

Hier sollte um Gottes Willen niemals jede Eigenschaft über eine Klasse gesteuert werden (Bordercolor, Farbe der Überschrift und der Links) sondern es empfiehlt sich folgendes Vorgehen.

Angenommen, wir unterscheiden bei unseren Boxen die Zustände voll, leer, aufgeklappt und zugeklappt. Dann könnte unser html ungefähr so aussehen:

<div class=“box“>
<h3>unsere Box</h3>
<p>ne Menge interessanter Inhalt, der aber erst […]</p>
</div>

Angenommen, unsere Box ist gerade blau, oben hat sie eine kleine Leiste mit einem (+)-Symbol um zu signalisieren, dass man sie aufklappen kann, die Rahmenfarbe ist ebenfalls blau, Titel und Text sind Dunkelgrau. Nun reicht:

<div class=“box aufgeklappt“>
<h3>unsere Box</h3>
<p>ne Menge interessanter Inhalt, der aber erst in der aufgeklappten Box sichtbar wird</p>
</div>

um unsere Box zu vergrößern, sämtliche Farben aller Elemente zu verändern usw.

Im Stylesheet sähe das in etwa so aus:

div.box {
padding: 10px 0 0 0;
background: url(balkensprite.png) no-repeat 0 0; /* justiert auf Zustand (+) */
border: 1px solid blue;
}

div.box h3, div.box p {
color: grey;
}

div.box.aufgeklappt {
padding: 10px 0 0 0;
background: url(balkensprite.png) no-repeat 0 30px; /* justiert auf Zustand (-) */
border: 1px solid red;
}

div.box.aufgeklappt h3, div.box.aufgeklappt p {
color: #000;
}

css – übers Ziel hinaus…

Wenige Projekte haben einen einzelnen Webentwickler. Meistens teilen sich die Entwicklung mehrere Menschen – oder gar unterschiedlichste Firmen. Dadurch besteht in hohem Maße Normierungsbedarf. Das beweisen unzählige Posts über perfektes Markup.
Das genau ist auch der Grund, warum ich mich hier immer wieder damit befasse. Auch, wenn wir schon lange dabei sind – und auch, wenn wir glauben, dass wir das bis jetzt eigentlich ganz gut hinbekommen haben, ja, auch, wenn wir glauben, dass wir das aus irgendeinem Grund perfekt können – auch dann sage ich:
Wir stehen erst am Anfang!
Wir haben hier noch keine Microformats behandelt, keine komplexen AJAX-Transformationen, nicht die autonomen Agenten – wir betrachten HTML und Markup immer eindimensional – so, als wäre es allein dazu da, Buchstaben in einem Browser bunt zu machen.
So auch Andreas Dölling mit seinem Post im Pisto. Einsprachigkeit mahnt er an und Semantik und auch er streift, was ich für immer wichtiger halte: Die Hervorhebung von Funktionalität im Markup. Unabhängig davon, dass es vielleicht im Moment genügt, zu schreiben:

<div class=“post-footer“>
    postet by <i>cyberer</i> on <span>September, 22th at 23:00</span>, 0 comments, Tags: css, HTML, Klugscheißerei
</div>

würde dieses Markup:

<div class=“post-footer“>
    postet by <span class=“author“>cyberer</span> on
    <span class=“date“>September, 22th at 23:00</span>,
    <span class=“comment-counter“>0 comments</span>,
    Tags: <ul class=“keywords“>
        <li>css</li>
        <li>HTML</li>
        <li>Klugscheißerei</li>
    </ul></span>
</div>

unbeschadet einen Relaunch überstehen.
Danach schießt Andreas Dölling aber etwas übers Ziel hinaus. Er schlägt vor, die Reihenfolge der Eigenschaften im Style nach einer Hirearchie zu bestimmen. Zuerst grobe Grid-Funktionen, zum Schluss Farbe und Schrift. Oft schreibe ich meine Styles in genau dieser Reihenfolge, außer, ich kopiere sie zwischenzeitlich aus Firebug, dann nämlich sind sie alphabetisch, und genau so, wie Nico es fordert. Ich sage: egal! Alphabetisch ist ebenso umständlich, wie, sich bei jeder Eigenschaft aufs neue ihrer Wichtigkeit zu entsinnen.
Danach gehen sie allerdings mit Dölling durch. Er fordert, alle Eigenschaften für ein Element in eine Zeile zu schreiben. Das mag zwar gut aussehen, weil einzelne Blöcke leichter zu überschauen sind – ist aber schlichtweg nicht wartbar. Mit fällt auch kein Editor an, der soetwas sinnvoll anzeigen könnte. Und selbst, wenn meine Augen endlich auf einem 27-Zöller ruhen dürften, würde ich keine halbmeterlangen Zeilen lesen müssen wollen.

Im Markup stehen wir erst am Anfang.