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.

Veröffentlicht in:  on 11. Februar 2009 at 22:41 Kommentar schreiben
Tags: , ,

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.

Veröffentlicht in:  on 5. Februar 2009 at 22:44 Kommentar schreiben
Tags: ,

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.

Veröffentlicht in:  on 27. November 2008 at 14:46 Kommentar schreiben
Tags: , ,

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.

Veröffentlicht in:  on 20. November 2008 at 01:20 Kommentar schreiben
Tags: , ,

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.

Veröffentlicht in:  on 4. November 2008 at 22:11 Kommentar schreiben
Tags: ,

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;
}

Veröffentlicht in:  on 18. Oktober 2008 at 13:25 Kommentar schreiben
Tags: ,

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.

Veröffentlicht in:  on 22. September 2008 at 23:09 Kommentar schreiben
Tags: ,

alle wollen schneller

Wenige Stunden nachdem ich das Post über die neue Javascript-Engine für den Firefox gelesen habe, die natürlich viel viel viel schneller als alles Bisherige ist, legen die Redmonder nach und beschreiben, warum ihr Browser der schnellste und produktivste sein wird. Aufgeschreckt durch so viel Ehrgeiz habe ich schnell für die Nachwelt einen Snapshot angefertigt. Hier also der Stand vom 27.8.2008, eine Selector-Speed-Messung mit gängigen Frameworks im Firefox3 und IE8beta.
Firefox3:

Firefox3

Firefox3

IE8beta:

IE8-Performance

IE8-Performance

Abgesehen davon, dass die Dojo/Unterstützung für den IE8 noch nicht ganz ausgereift ist, wird ganz schnell deutlich, dass der Firefox die Tests zur Zeit deutlich schneller absolviert, als sein Microsoft-Konkurrent. Da existiert Nachholbedarf.

Bremse Design

Aus dem IE-Post wird aber auch deutlich, dass, gemessen am Gesamtaufwand eine Webseite anzuzeigen, Javascript ein eher unbedeutender Posten zukommt, verglichen mit CSS. Wow. Seit Tagen beschäftige ich mich damit, zu messen, wie unterschiedliches Markup die Rendergeschwindigkeit beeinflusst, bin aber noch zu keinem vorzeigbaren Ergebnis gekommen. Der Selector-Speed-Test erscheint mir ungeeignet, weil zumindest mein geliebtes jQuery beim Zugriff auf DOM-Knoten nicht immer die getElement-Methode, sondern häufig auch RegEx benutzt, was in Zukunft übrigens viel viel viel schneller vor sich gehen wird, wenn John Reisigs neue Selector-Engine Sizzle zum Einsatz kommen wird.
Aber das ist schonwieder ein ganz anderer Post….

via

Veröffentlicht in:  on 27. August 2008 at 10:22 Kommentar schreiben
Tags: , , ,

css, und wie man richtig benamst

Hier soll es ganz kurz mal um sinnvolle Benamung von Klassen und IDs gehen. Hintergrund dieser Betrachtung ist, dass Webseiten heute meistens nicht aus einer Datei bestehen, die man von vorne bis hinten durchlesen kann, sondern aus vielen vielen kleinen Schnipseln, die zu tausenden in ein CMS kopiert werden. Darum ist es bei Stylesheets, genau, wie in Javascript, in php und in all den anderen Sprachen, die wir hier noch behandeln wollen sehr sehr wichtig, wie man etwas nennt:

Sprechend klassifizieren

Wie schon hier beschrieben, beschreibt eine css-Klasse nicht, wie etwas aussieht, sondern was es ist. Darüber hinaus sollten Klassen von vornherein so eindeutig sein, dass man nicht schon während des Entwurfs seine Konvention ändern muss:
Falsch:
h2.title
Besser:
h2.teaser-listing
Denn es ist absehbar, dass im restlichen Dokument noch weitere Titel folgen werden.

Im vorigen css-Post habe ich schon beschrieben, wie man grid und Typographie, aber natürlich auch Farbgebung und Linkverhalten voneinander trennen kann, das erspart übrigens auch, ständig neue Deklarationen für immer dasselbe erfinden zu müssen. Angenommen, wir haben eine vertikal dreigeteilte Seite (Header, Body, Footer), die horizontal zweigeteilt ist. Dann wäre es doch sinnvoll, die Elemente so zu benamsen und zu deklarieren:
.column-left {
    float: left;
}
.column-right {
    float: right;
}
#header .column-left {
    margin: 0 5px;
}
#header .column-right {
    margin: 0;
}
#content .column-left {
    border: 1px solid;
}
#content .column-right {
    background: #f2f2f2;
}
#footer .column-left {
    background: #cccccc;
}
#footer .column-right {
    background: #f2f2f2;
}

Spare IDs

Eine ID sollte im html-Dokument etwas besonderes sein. Es sollte eine Ehre sein, eine ID zu bekommen. Hier ist es sinnvoll, xhtml einfach mal zu xml zu abstrahieren und zu überlegen, welches Element einer Seite so wichtig ist, dass ich ein eigenes xml-Element dafür deklarieren würde. Da IDs also nur höchst selten anzutreffen sind, ist es umso wichtiger, aber auch einfacher, sie sprechend zu benennen. Einzige Ausnahme sind hier Elemente, auf die mit Javascript über document.getElementById zugegriffen werden muss. Wie sich das vermeiden lässt, soll ein nächster Post erklären.

Veröffentlicht in:  on 21. August 2008 at 11:00 Kommentar schreiben
Tags: , , , ,

css optimieren

Tony White hat im Smashing Magazine einen ziemlich guten Überblick über sauberes und optimiertes css geschrieben.
Besonders erwähnenswert erscheint mir einerseits der Satz mit den Hacks:

Hacks against dead browsers are safe, but hacks against the living aren’t. None of them. Ever.

Das Entwickeln von css ist immernoch eine hohe Kunst die konzentriert in einem Texteditor gefummelt wird. Daher halte ich es für eine wichtige Regel, lesbar zu arbeiten, Abstände sinnvoll einzusetzen und wie bei Nico beschrieben auch Kommentare zu normieren. Das Einrücken allerdings halte ich für übertrieben, da es sich ganz sicher nicht über ein ganzes Projekt durchhalten lässt – und nur dann ist es auch sinnvoll.

Beim Schreiben meines ersten css-Posts hatte ich überlegt, wo ich den Artikel über wrapper gelesen haben könnte. Wrapper, also das Einschließen eines Elementes in ein zusätzliches Elternelement:
<div class=“img-wrapper“>
        <img />
</div>
dient vor allem dem multiplen Einsatz eines Design-Elementes an unterschiedlichen Stellen im Layout. Tony White zeigt aber noch einen schönen Grund für den Einsatz für Wrapper-Elemente. Ausgehend von der hier noch nicht beschriebenen Regel, css-Dateien sinnvoll zu gliedern oder am besten in mehrere Dateien aufzusplitten, müssten Elemente mehrfach deklariert werden:
grid.css
#content {
width: 200px;
height: 200px;
}
article.css
#content {
color: blue;
font-size: 1.2em;
}
nämlich einmal im grid-Teil und einmal im Typographie-Teil. Hier nun bietet sich aber auch wunderbar ein zusätzliches Element an, das wir vor das Element mit der ID „content“ setzen und das die grid-Informationen erhält. Noch viel besser finde ich hier allerdings die Verwendung mehrerer Klassen:
<div class=“content content-column“>
weil ich so sicherstellen kann, dass ich die typographischen Eigenschaften der Content-Spalte auch auf Elemente anwenden kann, die nicht automatisch auch Breite und Höhe dieser Spalte übernehmen sollen – ohne zusätzliche html-Elemente.

Veröffentlicht in:  on 19. August 2008 at 23:52 Kommentar schreiben
Tags: , ,