CSS Social Buttons

They are not another „pure CSS3“ or „HMTL5 canvas“ icons. These icons use the basic traditional background-image technique. The purpose of these icons is to provide a cross-browser, consistent and versatile CSS that can be applied in any design, app or theme.

Ist das nicht Unsinn?

… habe ich gestern noch gedacht, als ich den dramatischen Aufruf von Daniel Glazman gelesen und verlinkt habe. Das was Glazman in ernsthaftester Browserwarrhetorik an die Wand malt, die Beerdigung des CSS-Webstandards durch -webkit, ist das wirklich die Realität?

Zunächst einmal die Fakten. Scheinbar ist es so, dass Webentwickler weltweit zu dämlich oder zu faul sind, die für neue und experimentelle Funktionen vorgesehenen Browserprefixe richtig einzusetzen. Offenbar ist bei vielen mit dem Einsatz von -webkit Schluss, dass es auch noch -o, -moz, -khtml und -ms gibt, wissen sie nicht, oder es interessiert sie nicht. Zunächst mal: das müssen ja ein paar schöne Deppen sein, die sowas tun. Nur für einen Browser zu entwickeln, das wäre ja ziemlicher Schwachsinn.

Tatsächlich ist es so, dass viele denken, dass Webkit-Browser die einigen Browser sind, für die man im mobilen Web entwickeln muss. das ist natürlich falsch. Und Webkit ist ja nicht mal ein Browser. Oder ein Browserhersteller (schließlich heissen die Kürzel vendor-prefixex). Eigentlich gibt es gar nicht den einen Webkit:

There are, to my latest count, Safari desktop, Safari iOS, Chrome desktop, Chrome Android, Android WebKit (in various flavours), BlackBerry WebKit, Nokia WebKit (in various flavours), Samsung Dolfin, LG WebKit, Palm Webkit, NetFront WebKit, Obigo WebKit, and UC WebKit. Thirteen browsers, eleven vendors — or fourteen, if you count the Android vendors separately. PPK

Womit Glazman nun droht ist, dass die anderen Browserhersteller anfangen werden, auch -webkit als Präfix zu benutzen (so sie die entsprechende Funktionalität denn anbieten können). Das wäre nun das Ende des Webstandards CSS. Ist es das? Wirklich? Oder ist es vielmehr das Ende der Idee Hersteller-Präfix, die sich in der Praxis offenbar nicht bewährt hat. Der Himmel wird uns wohl nicht auf den Kopf fallen. Und Webkit wird auch nicht die Weltherrschaft an sich reissen.

Vielleicht ist es einfach Zeit, die vendor-prefixes zumTeufel zu jagen und ein beta-Präfix einzufühen, wie PPK es vorschlägt?

Nebenbei bemerkt: das im Laufe der Debatte Lea Verou fälschlicherweise beschuldigt wurde der Präfixfaulheit Vorschub zu leisten… das ist ja fast schon lächerlich.

Leselinks, Fronteers CSS Edition

Das habe ich an anderer Stelle schon erwähnt, aber die Slides der Amsterdamer Konferenz, hat Darius Kruythoff zusammengetragen. Alle sehr lesenswert. Dabei funktionieren ohne Talk wahrscheinlich Lea Verous CSS3 Secrets, Divia Manians (Opera) The new developer Workflow (bitte mit Pfeiltasten bedienen) und Jake Archibalds In your font-face am besten.

Lea Verou bedient sich ihres eigenen Online-Präsentationssystems, das er hier als Demo zu sehen gibt und hier da zugehörige Github-Projekt. Unter cubic-bezier.com hat Lea übrigens ein Tool zur Verfügung gestellt, um die CSS3-Funktion cubic-berzier() mit Leben zu füllen. Sehr cool. Was die Funktion macht steht widerum in ihrer Präse. Lea kennt man übrigens von ihrer CSS Patters Demo, zum Beispiel.

Aus den Slides von Divia Manians ist mir ganz dringend compass im Ohr geblieben, ein Framework, das auf SASS aufsetzt.

Ebenfalls auf der fronteers wurde mir dieser hervorragende Link mit incredibly useful CSS snippets zugespielt. Was mehr als zutreffend ist: bitte sofort ausdrucken!

Wer viel mit Browsern und Tests zu tun hat, der kann sich ja mal Browserstack anschauen, für das John Resig die Werbetrommel rührt. Dort bekommt man Testbrowser in virtuellen Maschinen in der Cloud…

The state of CSS

Da ist ein Eisbär im Raum?

Im Moment gibt es wieder viel zu lernen, in Sachen CSS. Da sind zunächst die vielen neuen Dinge, die CSS3 bringt. Durch die derzeit rasante Browserentwicklung, Polyfills oder einfache Fallbacklösungen kann man vieles davon schon heute oder wenigstens morgen gebrauchen. Dazu kommen die Learnings aus einigen Jahren intensiven Einsatzes von CSS, seit der internationalen Ächtung des Tabellenlayout ist viel passiert.

Seit CSS dem style-Attribut entwachsen ist, unterlag es lange Zeit einer eher langsamen Entwicklung. Gehemmt durch den Internet Explorer hat es ewig gedauert, bis sich CSS 2(.1) überhaupt durchgesetzt hat. Man hat lange Zeit eher mit den gegebenen Umständen hantiert, anstatt CSS weiter zu entwickeln. Die floats lösten die Tabellen ab, die CSS Hacks beherrschten die Szene lange, machten zweigleisige Entwicklung für potente und für beschränkte Browser möglich. Das Set an Techniken hat sich aber in der Menge kaum verändert, vielmehr lernten wir immer besser damit umzugehen. Dabei sind aber auch viele Standardlösungen entstanden, die heute einer genaueren Prüfung unterzogen werden müssen.

Our best practices are killing us!

Nicole Sullivan (die, nicht die) tritt derzeit mit einem Vortrag unter diesem Titel auf, den ich sehr beeindruckend finde, weil er so sehr das trifft, was ich derzeit selbst in der Praxis feststelle. Viele der best practices, die in den letzten Jahren ersonnen, gepaukt und umgesetzt wurden, klingen gut, haben sich aber in den Jahren ihres Einsatzes vielleicht gar nicht bewährt. Andere wurden von der Entwicklung überholt, wurden zur Angewohnheit. Um mal ein klassisches Beispiel aus einem anderen Bereich zu bringen: wenn Sie <script>-Blöcke in einem HTML-Document nutzen, umgeben sie den Code dann auch noch mit HTML-Kommentarzeichen? Eine Technik, die heute lange nicht mehr nötig ist. Trotzdem sieht man sie immer wieder. So geht es auch mit vielen Angewohnheiten in CSS.

Nicole Sullivan nennt viele Beispiele. Unter anderem findet sie:

  • die Angabe von Schriftgrößen nicht in Pixel sei kontraproduktiv,

  • etwas mehr Klassizitis wäre gar nicht so schlecht, da so lange Selektorketten vermieden würden,

  • durch semantische Klassennamen würde der Codewiederholung der Weg bereitet,

  • der Mythos, kein zusätzliches Markup für das Layout einführen zu dürfen, sei mehr als schädlich, da durch Container Layoutprobleme auf festgelegte Bereiche beschränkt werden könnten.

In der Praxis nicht bewährt

Da geht es ihr genau wie mir. Wenn man betrachtet, wie wirklich große Website-Projekte entstehen, stellt man fest, dass durch die genannten best practices Nötiges nur von einer Ecke des Projekts in die andere verschoben wurde. So kann man wunderbares, absolut semantisch reines HTML schreiben, ohne jegliche Layout-Divs, so klein wie nur irgend möglich, ob die Seite dadurch wirklich schneller wird? Oder übersichtlicher? Nun, das HTML natürlich schon, aber wenn wir uns anschauen, wieviel sich gegenseitig überschreibendes CSS benötigt wird, merkt schnell, das man die Komplexität nur verlagert hat. Miss Sullivans Beispiel: bei Facebook hatte man vor einem umfassenden CSS-Relaunch 706 CSS Dateien, in denen 261 Mal die gleiche Farbe blau definiert war. Do not repeat yourself?

Und dabei geht’s nicht mal darum, sich gegenseitig den schwarzen Peter zuzuschieben: Komplexität im CSS schadet allen Beteiligten, denn sie drückt auf die Performance. Mein Beispiel ist die tägliche Praxis. Bei einem großen Projekt wurden nahezu nach Lehrbuch beim Schreiben von HTML-Code (und Javascript[1]) auf auf eine ganze Reihe best practices geachtet. Das hat zunächst mal dazu geführt, dass wir zwar schlankes HTML, aber ziemlich viel CSS (und Javascript) über die Leitungen schicken. Dabei ist die Menge an CSS und seine Komplexität eine direkte Folge der semantischen Strukturen im HTML. Aber wo im HTML bspw. nur wenige Klassen stehen, muss im CSS mit unendlich langen Selektorketten auf Elemente zugegriffen werden, was die Menge an CSS erhöht, die Geschwindigkeit des Renderings aber herabsetzt. Nach einigen Jahren ist diese Situation immer schlimmer geworden. Sie ist dabei kaum noch überschaubar, weil man praktisch nur noch mit dem Firebug entscheiden kann, welche CSS-Regel auf ein Element greift. Und die schiere Menge an Code macht es nicht besser. Abhilfe schafft da oft, einfach mal eine Klasse ins HTML zu schreiben, die direkt angesteuert wird. Und die darf dann vielleicht auch mal „blue“ heissen, naja, vielleicht besser „main-color“.

CSS Refactoring?

Will man sich aber, mindestens in Teilen nun aber von dieser Praxis abwenden, dann hat man jetzt den GAU, den man eigentlich vermeiden wollte: Änderungen an der Codebasis und am CSS. Zumindest kann man das Nutzen, um die IE6-Unterstützung endgültig zu droppen und so das ganze CSS etwas zu modernisieren. So stehen nun vieler Orten viele Änderungen in Sachen CSS an. Neues hinzufügen, alte Zöpfe abschneiden. Alte Projekte auf den aktuellen Stand heben.

[1] Noch ein Nebensatz zur Rolle von Javascript: dies wurde erstaunlicherweise viel zu oft genutzt, um die selbst gesetzten Grenzen bei HTML und CSS zu überwinden oder umgehen. Hüstel…

Word-Wrap

A CSS3 Property That Works in Every Browser. Muss man sich einfach mal merken.

Specify a text colour for img elements

I think most people will agree that it is a good thing for web browsers to display the contents of an image’s alt attribute when the image is missing or broken, or image rendering has been disabled. However, many web professionals forget to check what the alternative text will actually look like in those cases.