F-LOG-GE

Linkfutter 14

Jens Grochtdreis — Tue, 03 Apr 2012 16:30:50 +0000

Im heutigen Linkfutter geht es nur um jQuery. Mir sind ein paar Links untergekommen, die ich für teilenswert erachte. Auch wenn nicht alle von ihnen brandneu sind.

Rodney Rehm zeigt in einem längeren Posting, wie man ein im wesentlichen undokumentiertes Feature von jQuery für sich nutzen kann: jQuery Hooks.
In einem weiteren Posting kümmert sich Rodney darum, dass Click-Events auch dann getriggert werden, wenn man eigentlich nicht klicken, sondern ziehen (draggen) will.
In einem mir bislang noch unbekannten Blog wird die Erstellung von jQuery-Plugins erläutert.
In der Serie “Decoding jQuery” wird ein Blick in den Code der beliebten Bibliothek geworfen. Einzelne Bestandteile werden erklärt. Wer also beispielweise schon immer wissen wollte, welcher JavaScript-Voodoo hinter dem OOP-Konzept von jQuery steckt, sollte in dieser Serie herumstöbern. Alle anderen nutzen jQuery einfach weiter.
Schon im Juni 2010 schrieb Paul Irish 10 Things I Learned from the jQuery Source.
Im Januar 2011 schob er dann 11 weitere Details nach.

Dr. Web praktiziert wieder richtig

Jens Grochtdreis — Mon, 02 Apr 2012 06:56:51 +0000

Am Wochenende war ich unterwegs und hatte nur sporadischen Webzugang. Ich konnte aber dennoch erfreut zur Kenntnis nehmen, dass die düsteren SEO-Zeiten von Dr. Web wieder vorbei sind. Ende 2010 hatte Sven Lennartz, Gründer und Herausgeber von Dr. Web und Smashing Magazine, ohne Vorwarnung mit nur einer kleinen Notiz sein altes Projekt “Dr. Web” eingestellt. Kurze Zeit später wurde das Projekt an einen Vermarkter verkauft. Dessen Kalkül, das große Geld zu verdienen, ging offenbar und verständlicherweise nicht auf. Die Inhalte wandelten sich rapide zum Schlechten, die Seite war fast unbedienbar. Nun kümmert sich Lennartz wieder um sein “Baby”. Neuer Partner im Boot ist die ebenfalls in Freiburg ansässige “commindo media“. Ich bin gespannt, welche inhaltliche Ausrichtung wir erleben werden. Aktuell fällt mir kein ernstzunehmendes, deutschsprachiges Magazin für Entwickler und Designer. T3N, das als gedrucktes Magazin ganz okay ist, hat sich in den letzten Monaten immer mehr durch die Online-Inhalte für Profis diskreditiert. Da könnte Dr. Web eine Lücke füllen.

rgba auch für den IE6

Jens Grochtdreis — Thu, 29 Mar 2012 06:55:29 +0000

Eine der segensreichen Neuerungen von CSS3 ist Vergabe von Transparenz über das Farbmodell rgba. Die sonst nutzbare opacity wirkt sich leider auch auf Kindelemente aus, sodass nicht nur eine Box einen halbtransparenten Hintergrund hat, sondern leider auch jeglicher Text oder Bilder in ihr. Bei rgba passiert dies nicht. Nur das Objekt, dem eine Farbe mittels rgba zugewiesen wurde, zeigt diese auch in der gewünschten Form.

Leider hat Microsoft diese Technik wie alle anderen guten und wichtigen Techniken erst in Version 9 des Internet Explorers integriert. Doch es gibt Abhilfe mit dem Microsoft-eigenen Gradient-Filter. Dieser Filter transportiert nicht nur Farbinformationen, sondern auch Transparenzinformationen. Also weist man einem Objekt einfach einen Verlauf von einer Farbe auf sich selbst zu und vergibt zusätzlich noch einen Alphawert, schon hat man rgba auch für den alten IE bis Version 6 (oder sogar tiefer) nachgestellt.

Doch wie kommt man auf den Transparenzwert “7f”? Der Farbwert des Filters ist in hexadezimaler Schreibweise verfasst. Im Falle der Farbe wird aus rgb(0,0,0) einfach #000000. Für den heexadezimalen Transparenzwert multipliziert man 255 (der maximale RGB-Wert) mit der Transparenz (also 255*0.5). In diesem Falle bekommen wir 127.5 als Ergebnis. Wir benötigen eine ganze Zahl und müssen uns deshalb für Auf- oder Abrunden entscheiden. Dann suchen wir einen Zahlenkonverter auf und lassen uns den Dezimalwert in einen Hexadezimalwert wandeln. “127″ wird dann zu “7f”, 128 wird zu “80″. Diesen Wert stellen wir an den Anfang des Hexadezimalwertes im MS-Filter.

Nutzer von Präprozessoren wie Sass haben hier natürlich die Nase vorn, denn sie können diesem die Rechenarbeit überlassen.

Anhand der Formatierung einer Überschrift und eines über einem Bild liegenden Textes kann man den grossen Vorteil von rgba sehr gut ermessen. Die jeweils erste Version ist mit opacity, die zweite dann mit rgba formatiert.

Eine Tabelle mobil-freundlich machen

Jens Grochtdreis — Tue, 27 Mar 2012 16:54:00 +0000

Innerhalb kurzer Zeit sprach ich mit zwei Menschen darüber, wie man tabellarische Daten optimal auf Smartphones transportieren könnte. Breitere Tabellen machen auf den kleinen Displays ja nicht unbedingt Spaß. Schnell ging die Diskussion darum, welche Listenform man denn nehmen solle und ob das ein Fall für eine Definitionsliste sei.

Ich bin in solchen Situationen sehr grundsätzlich, man kann es auch altmodisch nennen. Ich gebe nicht so schnell auf, für die anstehende Aufgabe die korrekten semantischen Elemente zu nutzen. Für die Darstellung nimmt man dann schliesslich immer CSS. Aber gerade Tabellen sind natürlich in jeglicher Hinsicht ein Grenzfall. Tabellen haben ein eigenes Tabellenmodell. Es ist zudem nicht immer intuitiv und einfach entscheidbar, ob man Informationen als Tabelle oder Liste umsetzen sollte. Aber im heutigen konkreten Fall lagen die Daten auch richtigerweise als Tabellen vor.

Um den Arbeitsaufwand so gering als möglich zu halten, war eine Transformation der Struktur ohne erneute Eingriffe erwünscht. Natürlich kann man mit jQuery nachhelfen und für Smartphones aus einer Tabelle eine Liste machen. Doch die Beispielseite hatte so umfangreiche Tabelleninformationen, dass ein Einsatz von jQuery das Smartphone schnell zum Glühen bringen könnte.

Ein nur mittels CSS funktionierender Ansatz (siehe unten) fiel mir recht schnell ein. Man muss für die alten IE (oldIE) nur von CSS3-Selektoren auf Klassenselektoren umstellen, dann funktioniert es bis zum IE7 reibungslos (den IE6 habe ich nicht getestet). Da es sich bei der Aufgabe aber darum handelt, eine Tabelle für Smartphones nutzbar zu machen, können wir oldIE getrost vergessen.

Für die Wandlung von einer Tabelle in eine Liste und später (weiter unten im CSS) als Floats brauchen wir nur wenige Regeln, nur eine Zeile. Der überwiegende Teil des folgenden CSS wird für die Aufhübschung genutzt. Der Ansatz funktioniert auf alle Fälle bei Tabellen mit wenigen Spalten. Ich kann mir aber auch vorstellen, dass er bei Tabellen mit mehr als zehn Spalten gut funktioniert.

Speziell die Nutzung moderner CSS3-Selektoren macht hier die Arbeit leicht. Chris Coyer hat zu dem Thema eine Übersicht verschiedener Techniken erstellt.

Dirk Jesse merkte noch an, dass er die Optik genau anders erwarten würde, als ich es in meinem Beispiel demonstrierte. Der Anfangszustand soll erst kommen, wenn man die Grundfläche verkleinert (unbedingt das Fenster mal kleiner schieben!). Also habe ich eine zweite Version gemacht, in der ich die Optik umgedreht habe.

Idee für Modularisierung von SASS-Projekten

Jens Grochtdreis — Tue, 27 Mar 2012 06:52:13 +0000

John W. Long beschreibt im Blog “The Sass Way” seinen modularen Ansatz mit Sass. In meinen aktuellen Schulungen gehe ich auch immer darauf ein, dass man eine Webseite als Ansammlung von Modulen betrachten sollten. Präprozessoren wie Sass helfen uns dann dabei, die für die Module passenden Regeln auch wieder in einzelne Dateien zu splitten.

Ohne Präprozessoren muss man entweder mit Projekten wie dem CSS-JS-Booster alle CSS-Dateien zusammenfassen oder in einem einzigen, immer größer und unübersichtlicher werdenden Stylesheet arbeiten. Da ich Letzteres über die letzten Jahre gemacht habe, weiss ich es mittlerweile zu schätzen, mit Sass-Partials meine Arbeit wieder übersichtlicher und strukkturierter zu gestalten.

Meine Vorgehensweise ist gar nicht so weit von der in dem Text beschriebenen entfernt. Nur die Benamung realisiert er konsequenter. Mal schauen, ob ich das demnächst in meinen Workflow integriere. Für den Workflow im Team sind kleine Modul-CSS-Dateien auch hilfreich. Dadurch können sich die Teammitglieder auf einzelne Aufgaben konzentrieren. Man sollte dann zu einem festgelegten Zeitpunkt – bspw. immer zur vollen Stunde – alle Dateien in das hoffentlich genutzte Versionierungssystem spielen. Danach haben alle Teammitglieder wieder einen einheitlichen Stand.

Lehrreicher Quiz

Jens Grochtdreis — Tue, 27 Mar 2012 06:23:54 +0000

Ende April letzten Jahres veröffentlichte Thierry Koblentz einen Quiz. Er zeigte eine CSS-Regel mit einer Menge Eigenschaften. Die Teilnehmer sollten nun die Eigenschaften entfernen, die sie gefahrlos löschen konnten, weil sie beispielsweise auf das Element keine Auswirkung haben.

Auch für Profis empfiehlt es sich, den Test zu machen und danach die knappen Erklärungen der Lösung zu lesen. Ich finde den Quiz sehr lehrreich. Mal schauen, dass ich ihn in meine nächsten Schulungen einbinde.

Am Ende ist doch alles HTML

Jens Grochtdreis — Tue, 20 Mar 2012 07:50:31 +0000

Am Montag Abend war ich in München zu Gast auf dem PHPSummit und durfte den versammelten Backendentwicklern einen kleinen Vortrag halten. Ich entschied mich für einen Rundumschlag in Frontendtechniken. Mein Ziel war, den Zuhörern klar zu machen, dass HTML und CSS nur auf den ersten Blick banal sind. Frontendentwicklung ist komplex.

Ich denke, es ist mir in 98 Slides gelungen, dies zu kommunizieren. Da das PDF zu gross für meinen Slideshare-Account ist, habe ich diesmal Speakerdeck genutzt. Auch ein empfehlenswerter Dienst.

Vortrag beim SmashingMeetup – A Period of Transition

Jens Grochtdreis — Thu, 01 Mar 2012 15:19:43 +0000

Am 27. Februar habe ich einen ganztägigen Workshop in Frankfurt gegeben. Veranstalter war das Smashing Magazine. Insgesamt 20 Teilnehmer wurden von mir in Sachen “Workflow im Team, YAML4 und CSS3 in der Praxis” geschult.

Abends fand dann zusätzlich noch das fünfte SmashingMeetup in der Frankfurter Brotfabrik statt. In dessen Rahmen hielt ich meinen ersten englischsprachigen Vortrag. Die Slides zum Vortrag gibt es wie immer bei Slideshare bzw. hier zur Ansicht.

A Period of Transition

Meine weiteren Präsentationen

Compass und Sass haben was

Jens Grochtdreis — Tue, 14 Feb 2012 18:43:27 +0000

In den letzten Monaten gab es eine Reihe Artikel zu diversen Präprozessoren, vor allem Sass und Less. Um mich herum stiegen immer mehr Entwickler auf diese Systeme um. Ich konnte den Systemen lange nichts abgewinnen, waren doch viele Beispiele für mich relativ unnütz, weil ich ein vernünftiges CSS-Framework nutze und deshalb keine Grids selber ausrechne oder überall einen clearfix-Hack einfüge. Allerdings hatte ich in der Vergangenheit ein paar Seiten, die mit Themes versehen wurden. Hinzu kam eine Seite, bei der ich viele unterschiedliche Farben und Verläufe nutzte. Das CSS war allein wegen der vielen vendor-prefixes extrem aufgeblasen. Also gab ich Compass und Sass eine Chance, als ich an einem neuen, etwas kleineren Projekt sass. Und ich muss sagen, ich habe Blut geleckt.

Ich möchte hier nicht die x-te Einführung geben. Dafür wurde schon im letzten Webkrauts-Adventskalender (Teil 1 und Teil 2) von Mathias Schäfer und im CSS3-Adventskalender bei Sven Wolfermann ausreichendes geschrieben. Abseits der grundsätzlichen Einführungen gibt es aber Erfahrungen, die selten zu lesen sind.

Dass die Wahl auf Sass fiel hatte seine Gründe. Es ist in meinen Augen das bekannteste System mit einer großen Community. Zudem hat Less einen Konstruktionsfehler: es wurde anfangs im Browser gerendert. Es soll wohl auch eine serverseitige Version geben, doch dieser Konstruktionsfehler hat mich gegen das System eingenommen. Die gleichen Vorbehalte habe ich gegen prefixfree von Lea Verou. Ich möchte nicht, dass Tools, die ich für meine Bequemlichkeit nutze, auf dem Rücken meines Endproduktes, also der Nutzer ausgeführt werden. Jedes CSS-Rendering mittels JavaScript zieht die Performance der Seite unnötig herunter und macht die Seite ohne Javascript unbenutzbar. Die Syntax von Sass und Less unterscheidet sich nicht allzusehr.

Da ich viel mit CSS3 arbeite, lag für mich die Nutzung von Compass nahe. Denn dieses Zusatzframework bringt eine Masse mixins für CSS3 mit. Die Praxis zeigte mir schnell, dass diese mixins für meine Ansprüche zu schlecht waren. Ich arbeite nun also mit Compass, ohne ein einziges mixin davon zu nutzen. Ich fand die Ausgabe von Compass schlecht, weil bspw. bei der Ausgabe von IE-Filtern meist die -ms-filter-Variante fehlt. Zudem bekommen die Elemente kein hasLayout mittels zoom:1 zugewiesen, was die Filter evtl. unsichtbar macht.

Bislang habe ich im Wesentlichen Farbvariablen genutzt, habe Elemente verschachtelt und mixins für border-radius (ich will noch ganz alte Browser mitnehmen), gradients und box-shadow genutzt. Ausserdem habe ich mir selber ein mixin geschrieben, mit dem ich über :before oder :after Pfeile erzeugen kann.

Für meine Bedürfnisse reichen ein paar CSS3-mixins, die ich in den unendlichen Weiten von github gefunden habe. Ich habe sie mir mittlerweile bearbeitet und in zwei mixins gesplittet. Die eine Version ist für die alten IE, die andere für moderne Browser. Ich muss so nur irgendwann im Zuge der Bearbeitung die CSS3-Regeln für eine IE-Version herausziehen. Da die Namen der mixins identisch bleiben, erzeugen sie dann im IE-spezifischen CSS genau den passenden Code – und nur den.

Leider gibt es bislang noch keine Möglichkeit, diesen Vorgang aus dem SCSS-File zu automatisieren. Aber wenn ich den dazugehörigen Thread in github richtig verstanden habe, wird zumindest darüber nachgedacht, das Aufsplitten von Regeln aus einer Datei in zwei Zieldateien entweder in Compass oder in Sass zu integrieren. Ich bin gespannt. Aber auch ohne diese weitere Erleichterung ist mein Workflow mittlerweile schon besser geworden. Meine Arbeitdatei ist übersichtlicher und ich kann viel einfacher mit Farben hantieren. Ich werde mit der Zeit sicher noch ein paar weitere Highlights entdecken. Aber der erste Schritt ist getan und ich möchte das Tool nicht mehr missen. Irgendwann teste ich auch die Erzeugung von Sprites aus. Das kann Compass nämlich auch. Ich werde mir auch mal die Compass-recipes anschauen. Das scheint mir eine interessante Sammlung zu sein.

Wer wie ich im Laufe eines Projektes entscheidet, Compass zu verwenden, der hat ein Problem. Sowohl die Doku als auch alle Einführungen, als auch das im Entstehen befindliche Buch bei Manning erklären immer nur, wie man in einem leeren Verzeichnis mittels Compass eine Grundstruktur erzeugt. Das war aber gar nicht mein Wunsch. Nach längerem Suchen bin ich auf folgende Zeile gestossen, die man im Terminal im betreffenden Verzeichnis ausführen muss:

Ich bin mal gespannt, welche Details mir mit der Zeit noch so auffallen. Aktuell splitte ich mein CSS und meine mixins in viele unterschiedliche Dateien, am Ende kommt eine Datei bzw. noch eine weitere IE-Datei heraus. Während der Entwicklung kann ich hingegen in kleinen, übersichtlichen Dateien arbeiten. Auch meine Variablen habe ich ausgelagert. So werden sie von der normalen und der IE-spezifischen Datei erfasst und verarbeitet.

Die Sache mit den vendor-prefixes

Jens Grochtdreis — Fri, 10 Feb 2012 18:27:53 +0000

Es gibt mal wieder eine gehörige Portion Aufregung unter Frontendentwicklern. Auslöser sind die Mitschriften einer Sitzung der CSS-Workinggroup und eine von Tantek Celik recht offensiv geführte Diskussion um vendor-prefixes. Kurz gefasst möchte Tantek unbedingt das vendor-prefix “-webkit” auch bei Mozilla implementieren. “-webkit” und “-moz” würden dann einträchtig nebeneinander existieren. Es gab sogar die Idee, “-webkit” als offiziellen Standard zu übernehmen, sodass alle anderen Browserhersteller diese Prefixes auch implementieren.

Egal wie lange ich darüber nachdenke, ich finde die Idee schlecht. Vendor-prefixes waren eine gute Idee. Sie sollten den Browserherstellern ermöglichen, neue Features zu implementieren, bevor die endgültige Syntax feststeht. Doch leider haben sich alle Beteiligten nicht so richtig auf ein Vorgehen geeinigt. So scheint es mir jedenfalls. Es gibt eine Menge Eigenschaften, die schon lange erfolgreich in Benutzung sind und deshalb endlich ohne Prefix implementiert werden können. Bei den runden Ecken ist dies nun endlich der Fall. Aber bei den meisten anderen nicht. Die Hersteller sind da in der Pflicht, sich zu beeilen. Microsoft und Apple lassen wir mal aussen vor. Deren Entwicklungszyklen sind so lang und langsam, dass sie nicht zählen.

Aber auch das W3C hat (mal wieder) versagt. Die Working Group schafft es einfach nicht, endlich mal einen Strich unter die schon seit einer gefühlten halben Ewigkeit diskutierten Techniken zu ziehen. Im Gegenteil: im Falle der Hintergrundverläufe haben sie nach Jahren der Stabilität die vorgeschlagene Implementierung wieder geändert.

Ein dritter Schuldiger sind faule Entwickler. In meinen Augen sind dies die wahren Schuldigen. Denn egal was die Browserhersteller und das W3C so tun, am Ende müssen wir Webentwickler Seiten mit den vorgeschlagenen und implementierten Techniken bauen. Wenn wir dabei nur an “-webkit” denken und alle anderen Browser ignorieren, dann ist das unser Fehler. Dieser Fehler ist leicht behebbar. Durch Information, durch gute Tools wie Präprozessoren.

In den letzten Monaten hatte ich den Eindruck, ein Großteil der veröffentlichenden Entwickler steht Kopf, wenn das Webkit-Team mal wieder eine neue Technik implementiert hat. Es las sich dann in Weblogs gerne so, als könne man die neue Technik X, die gerade in einem Webkit-Nightly implementiert wurde, sofort produktiv nutzen. Ich erinnere mich noch gut an einen Blogartikel, der Teaser mit 3D-Transforms vorstellte. Dabei fiel kein Wort darüber, dass alle anderen Browser nur seltsamen Kram darstellten.

Es ist ja ganz interessant und wichtig, mit neuen Techniken zu experimentieren. Aber der Ton macht die Musik. Denkt bitte daran, dass nicht jeder einen Webkit-Nightly nutzt und dass wir auch noch auf Jahre hinaus Seiten ausliefern müssen, die im IE8 bedienbar sind und nicht ganz miserabel aussehen. Ich verstehe die Frontendentwickler nicht, die großzügig über die Existenz anderer Browser als ihres Lieblingsbrowsers hinweggehen.

Würde Mozilla den “-webkit”-Prefix einführen, hätten wir überhaupt keine Unterscheidungsmöglichkeiten mehr und wären wieder auf Browsersniffing angewiesen. Denn wer garantiert mir, dass Mozilla, Opera und Microsoft die Techniken mit dem fremden Prefix genauso einbinden und realisieren, wie die Webkit-Entwickler? Niemand kann das, niemand wird das.

Nein, die Browserhersteller sollten sich beeilen, einen Strich unter die meisten Techniken zu ziehen und sie ohne Prefix zu implementieren. Sie sind in der W3C-WG und können ein wenig Geschwindigkeit in diese lahme Veranstaltung bringen. Parallel müssen wir dafür sorgen, dass Entwickler kein Lob mehr für Demos bekommen, die nur noch auf einen Browser ausgerichtet sind, obwohl es auch in anderen funktionieren würde. Und wir sollten alle unseren Fokus ein wenig verändern.

Natürlich ist es toll, eine völlig neue Technik zu demonstrieren. Wir sollten aber immer mit kommunizieren, wie die Einsatzfähigkeit in der Realität ist. Welche Tricks, Kniffe und Verrenkungen sind notwendig, um alle Browser bis zum IE8 (und 7!) mitzunehmen? Ich meine nicht, dass sie alle die gleiche Technik präsentieren sollen. Aber graceful degredation darf ich doch zumindest erwarten. Was bringen meinem Kunden Teaser in 3D, wenn sie bei 98% seiner Besucher ein unlesbarers und unbedienbares Ergebnis hervorrufen?

Zu diesem Themenkomplex gibt es eine Reihe sehr interessanter Wortmeldungen. Leider fast ausschließlich im englischsprachigen Raum. Wir sollten uns von dieser wichtigen Debatte nicht ausklinken. Es geht um wichtige Grundlagen unserer Industrie. Denn aktuell scheint es so, als würden wir die alten Fehler wiederholen. Früher war es “best viewed with Internet Explorer”, jetzt steht da einfach “Webkit”. Es war ein Fehler und es bleibt einer. Wir sollten doch aus der Geschichte lernen können.

Und hier eine bunt gemischte Auswahl an weiterführenden Links mit sehr unterschiedlichen Ansichten und Ansätzen: