Blog-Posts about Project Ironman

As announced in my last post i finally wrote my article about Project Ironman for my companies tech-blog. You can find the post here or on Medium.

I received a lot of (nice) feedback mostly via twitter.

 

about:consistency – lessons learned: the hard way

i had the big pleasure to give a lightning talk at the leanUX meetup organized by the guys from sipgate at Düsseldorf.

the most exciting point for me was that one of my favorite speakers, a man called brad frost, also talked at this meetup.

so to let him understand what i am talking about i did this talk in english, which was quite challenging and needed some more practice than doing a talk in my native language.

i was very glad that i received a lot of cool feedback after the talk.

Responsive Design – Anti Patterns

  1. Denselben Content für alle Devices laden
    Viele responsive Seiten laden den gleichen Content über alle Devices hinweg. Zum Beispiel 1 CSS File das alle Media Queries behandelt oder Images für alle Auflösungen, Bilder werden in diesem Fall einfach runterskaliert.
    Beweis hierfür ist der HTTP traffic. Bei Seiten die den gleichen Traffic deviceübergreifend haben ist dies i.d.R. der Fall.
  2. Zusätzliche Assets laden
    Während das Laden der gleichen Assets für alle Devices die Unterschiede derselbigen ignoriert ist das Laden zusätzlicher Assets für mobile Geräte alles das was wir für “mobile experience” wissen. I.d.R. handelt es sich hierbei um zusätzliche CSS Anweisungen oder Image Sprites
  3. Images in der doppelten Größe laden
    Auch beliebt ist der Laden von Bildern in doppelter Größe die dann herunterskaliert werden um auch auf Retina Geräten scharf auszusehen.

Alle Punkte haben etwas gemeinsam:

  • Sie sehen die  Desktop Seite als die Basis, anstatt sich auf mobile first zu konzentrieren
  • Sie nutzen nicht die Vorteile oder gehen gewissenhaft mit den Limitierungen der einzelnen Plattformen um.
  • Sie versuchen das Problem exklusiv von der client Seite zu lösen.

Effiziente CSS Selektoren

Immer wieder gerne stellt man die Frage nach effizienten und schnellem CSS.  Daher hier ein grober Überblick über die Performance von CSS Selektoren.

Sobald der Browser HTML und CSS geladen hat beginnt der Abgleich des CSS mit dem Dokumentenbaum. Dabei wird sich nach dem Schlüsselelement gerichtet das normalerweise das letzte Element des Selektors ist.

Das CSS wird vom Browser von rechts nach links verarbeitet, d.h. es werden vom Schlüsselelement ausgehend alle Vorfahren die im Selektor notiert sind mit dem Dokumentenbaum abgeglichen bis die Definition zutrifft oder eben nicht.

Ein kleines Beispiel

header div.branding img.logo
{
    margin: 10x 5px;
}

Das Schlüsselelement ist img.logo. Der Browser sucht nun die Klasse .logo. Um sicherzustellen dass auch das richtige Element gefunden wurde wird dann auf das Element img geprüft, dann das Elternelement mit Klasse .branding gesucht. Anschließend wird geprüft ob das Element vom Type div ist und letzlich ob das Elternelement ein header-Element ist.

Zwei Schlüsse lassen sich daraus schließen:

  1. Jede weniger Elemente (bzw. Klassen, IDs) im Selektor notiert sind, desto schneller kann der Browser prüfen ob das Element matcht.
  2. Je eindeutiger das Schlüsselelement im Selektor definiert ist, desto weniger aufwändig ist die Abgleichung mit dem Dokumentenbaum.

Dazu ein Beispiel. Jeder kennt sie die berühmten .active oder .selected Klassen

.filter .active
{
   @include opacity(1);
   border: 1px solid black;
}
.searchresult .active
{
   background-color: #666;
}

Nun mal rein hypothetisch angenommen es gäbe jetzt 15 aktivierte Filter (z.B. in einem Online-Shop) und ein mit der Klasse .active versehenes Suchergebnis. Die Prüfung und Anwendung des Selektors .searchresult .active würde damit 15 aktivierte Filterelemente und deren Elternelemente abgleichen sowie das eigentlich benötigte Suchergebnis und seines Vorfahren.

Daraus ergibt sich folgende effizientere Notation für das aktive Suchergebniss:

.sresult_active
{
   background-color: #666;
}

In diesem Fall wird nur ein Abgleich stattfinden.

Kurz zusammengefasst kann man die Effizienz von CSS Selektoren wie folgt definieren: Es die Zeit die der Browser benötigt um die Selektoren mit dem DOM abzugleichen.

 

 

 

 

Should read 01 / 2014

Ich stöbere so gerne und daher anbei ein paar Links über die ich im Laufe des Monats gestolpert bin und für sehr lesenswert halte.

Ein interessanter Artikel über responsive Images

So, You’re Writing A Responsive Images Script
http://filamentgroup.com/lab/respimg_scripts/

Eine Case-Study zum Thema Frontend Performance

We spent a week making Trello boards load extremely fast. Here’s how we did it.
http://blog.fogcreek.com/we-spent-a-week-making-trello-boards-load-extremely-fast-heres-how-we-did-it/

Sind CSS Regions wirklich so cool?

CSS Regions Considered Harmful
http://alistapart.com/blog/post/css-regions-considered-harmful

Wie ist das noch mal mit nativem JavaScript

A Dive Into Plain JavaScript
http://blog.adtile.me/2014/01/16/a-dive-into-plain-javascript/

Vertikel Zentrierung ist ein Problem ohne Tables? Nein!

Vertical align anything with just 3 lines of CSS
http://zerosixthree.se/vertical-align-anything-with-just-3-lines-of-css/

So klappts auch mit den Icon Fonts

Bulletproof Accessible Icon Fonts
http://filamentgroup.com/lab/bulletproof_icon_fonts/

Neue Features von Sass 3.3 verheiratet mit der BEM Syntax

Sass 3.3 @at-root & BEM!
http://blog.unakravets.com/post/64113156740/sass-3-3-at-root-bem