Eine neue CSS Grid Layout Spezifikation gibt Webworkern nun die Möglichkeit eigene Grids nach den jeweiligen Anforderungen selbst zu definieren. Das ist nicht nur für Seitenlayouts, sondern auch für Modul-Layouts sehr nützlich. Aber zugegeben sind auch sehr viele neue Eigenschaften zu lernen, 17 neue Eigenschaften in Summe.

Nun wird sich der ein oder andere Entwickler fragen: „ok, aber was ist jetzt der Unterschied zu Flexbox“? Einige Entwickler nutzen bereits Flexbox anstatt „Floats“ als CSS-Technik für Grid-Layouts.

Wenn man Layouts wie gewohnt in 12 Spalten aufbaut und diesen Aufbau nicht verändert, sondern nur die unterliegende CSS-Technik, dann klingt das auch erstmal logisch und einfach Flexbox zu verwenden. Deshalb nutzt Bootstrap ab Version 4 auch Flexbox-Grids.

Was ist nun der Unterschied zwischen Flexbox und CSS Grids?

CSS Grids sind zweidimensional, Flexbox ist eindimensional. Flexbox-Grids sind bildlich gesprochen nur 1-zeilig (flex-wrap: wrap mal ignoriert), also Zelle für Zelle auf einer Zeile ohne Umbruch. Ein CSS Grid-Layout kann man über mehrere „Zeilen“ aufbauen. Man stelle sich vor, dass man ein einfaches Seitenlayout hat. Dort ist eine Spaltigkeit für header und footer festgelegt – dies kann man natürlich auch mit Flexbox abbilden, aber die Zellen haben untereinander keine Verbindung. Mit einem CSS Grid-Layout ist das anders, dort gibt es ein sogenanntes Grid-Template, das für den Bereich gilt.

Aber vielleicht mal ein einfaches Beispiel als Einstieg: ein 3-spaltiges „Komponenten-Layout“. Hier das visuelle Ergebnis, was wir mit CSS Grids aufbauen möchten:

Ein Komponentencontainer (.wrapper) und 4 Inhaltscontainer (.box)

<div class="wrapper">
  <div class="box a">.a</div>
  <div class="box b">.b</div>
  <div class="box c">.c</div>
  <div class="box d">.d</div>
</div>

Für diese Komponente fügen wir nun ein Grid-Layout hinzu.

Ein neuer Wert für die CSS-Display-Eigenschaft: `grid`:

/* grid layout, 3 columns */
.wrapper {
  display: grid; /* display: inline-grid;*/
  grid-template-columns: 1fr 1fr 1fr; /* 3 x 1 fraction */    
}

display: grid ist wie display: flex ein neuer Wert für die Display-Eigenschaft des Container-Elements. Alle direkten Kinder werden dann zu Grid-Elementen. Zu den neuen Layout-Eigenschaften bringt CSS Grids auch eine neue Maßeinheit mit. Gridgrößen können natürlich auch weiterhin mit allen vorhanden Maßeinheiten erstellt werden. Sowohl Prozent-, als auch Pixelwerte, als auch weitere Breiteneinheiten sind möglich. Grid-Zellengrößen können nun in ‚fr‘ (fraction) angegeben werden. Als Beispiel können drei gleich breite Spalten mit grid-template-columns: 1fr 1fr 1fr; erstellt werden. Ein 2-spaltiges Grid mit einer großen Haupt- und einer Marginalspalte im Verhältnis 2:1 erstellt man wie folgt: grid-template-columns: 2fr 1fr; – 1fr bedeutet 1 Teil, 2fr bedeutet 2 Teile der Gesamtbreite. Je Spalte wird je ein Wert getrennt mit Leerzeichen geschrieben. Für das letzte Beispiel könnte man auch grid-template-columns: 66.667% 33.334%; schreiben.

12 gleich breite Spalten, das klassische 12-spaltiges Layout?

Der Aufbau geht natürlich auch mit 12 gleichen Werten, aber der Einfachheit halber gibt es die repeat()-Funktion: grid-template-columns: repeat(12, 1fr); – 12 gleiche Spalten, quasi je 1/12 Spaltenbreite. Für zeilenweise Grids gibt es das Pendant grid-template-rows. Möchte man z.B., dass der Seitenheader und der -footer eine bestimmte Höhe haben, der Inhalt dazwischen aber flexibel ist, kann man auto als Höhe für den Hauptinhalt angeben, Beispiel: grid-template-rows: 10em auto 10em;, Seitenheader und -footer sind hier genau 10em hoch. Für unser Beispiel von oben machen wir für die Grid-Zeilen keine Größenvorgaben, dann sind die Gridzellen, wie bei Flexbox, alle gleich hoch und zwar so groß wie die größte Zelle der gesamten Zeile.

Positionierung im CSS-Grid

Historisch bedingt gibt es ähnlich wie bei Flexbox unterschiedliche Schreibweisen um Position und Größe einer Grid-Zelle festzulegen. Die unterschiedlichen Schreibweisen können aber in allen Browsern verwendet werden. Folgende Schreibweisen ergeben alle die gleiche Positionierung:

.a {
  /* starts at col pos 1, spans 2 cols */
  grid-column: 1 / span 2;
  /* starts at row pos 1, spans 1 row */
  grid-row: 1 / span 1;
}

.a {
  grid-column-start: 1;
  grid-column-end: 3;
  grid-row-start: 1;
  grid-row-end: 2;
}

.a {
  /* grid-column-start: 1 / grid-column-end: 3 */
  grid-column: 1 / 3;
  /* grid-row-start: 1 / grid-row-end: 2 */
  grid-row:    1 / 2;
}

Die Eigenschaften grid-column/-row sind für die Positionierung der Zellen im Grid zuständig, wobei grid-column/-row die Kurzschreibweise für grid-column-start/-end (grid-row-start/-end) ist. Bei dieser Schreibweise gibt man die Startposition und die Endposition der Zelle an. Die alternative Schreibweise ist, dass man die Startposition angibt und nicht die Endposition, sondern über wie viele Spalten sich die Grid-Zelle aufspannen soll. Die Angabe lautet dabei span anzahl, also hier im Beispiel span 2, zwei Spalten vom Grid-Layout nimmt die Gridzelle ein.

.a {
  grid-column: 1 / span 2;
  grid-row: 1 / span 1;
}
.b {
  grid-column: 3 / span 1;
  grid-row: 1 / span 2;
}

Dies ist ebenso für das Überspannen von Zeilen möglich – grid-row: 1 / span 2; – überspannt zwei Zeilen beginnend ab Zeile 1. Der Default-Fall ist, dass eine Zelle automatisch platziert wird und 1 Spalte breit ist, also in CSS-Code gesprochen: grid-column: auto / span 1;.

Die Postionen im Grid sind in den aktuellen Firefox Dev-Tools schön visualisiert. Die Endposition ist manchmal nicht so klar, manchmal hilft es, wenn man die Hand zur Hilfe nimmt, die Grid-Spalten sind immer die Zwischenräume zwischen den Finger. So beginnt das Grid dann immer mit dem ersten Finger (Pos. 1) und endet mit der letzten Position, bei einem 3-spaltigen Grid ist das die Position 4.

Für unser Layout brauchen wir im Grunde nur 5 Zeilen CSS:

.wrapper {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  grid-gap: 12px;
}

.a {
  grid-column: auto / span 2;
}

.b {
  grid-row: auto / span 2;
}

Codepen-Beispiel (für Browser die Grids unterstützen ohne Fallback):

See the Pen CSS Grid by example, simple 3 column grid component layout by Sven Wolfermann (@maddesigns) on CodePen.

Definierte Gridlinien-Benennung

Zudem gibt es die Möglichkeit Gridlinien-Benennung in der Gridvorlage zu vergeben. Dies passiert im grid-template-*, Liniennamen werden umschlossen mit einer eckigen Klammer deklariert. Unser Beispiel mit benannten Gridlinien:

.wrapper {
  display: grid;
  grid-template-columns: [grid-line1] 1fr [grid-line2] 1fr [grid-line3] 1fr [grid-line4];
}
.a {
  grid-column: grid-line1 / grid-line3;
}

Bei der Benennung kann man natürlich kreativer sein. Mit den Liniennamen können dann auch Positionen im Grid vergeben werden.

Der Vollständigkeit halber hier der Code für die Zellen .c und .d, wenn man die Positionen fixieren möchte. Da sich Gridzellen grundsätzlich im autoflow verteilen, wäre der Code aber für das erwartete Ergebnis unnötig.

.a {
  grid-column: 1 / span 2;
}
.b {
  grid-column: 3;
  grid-row: 1 / span 2;
}
.c {
  grid-column: 1;
  grid-row: 2;
}
.d {
  grid-column: 2;
  grid-row: 2;
}

An dieser Stelle auch der Hinweis, dass sich durch Grid super einfach die visuelle Reihenfolge der Elemente mit CSS manipulieren lässt. Bei Flexbox ist dies mit order möglich. Bei Grids greift hier die Positionierungslogik, so kann man ganz simpel eine Navigation vom „Header“ in den „Footer“ verschieben, wenn man das möchte. Die Source-Order im HTML bleibt davon unberührt. Hier muss man prüfen, ob das nicht die Barrierefreiheit beeinträchtigt, wenn man es anwendet.

Browser Support

Der Browser-Support bei neuen CSS-Eigenschaften ist immer etwas spezielles, teilweise muss man Jahre warten bis alle Browser die Eigenschaften unterstützen, damit man den Code produktiv einsetzen kann. Bei CSS Grids gibt es eine Besonderheit, alle modernen Browser unterstützen nahezu zeitgleich die Eigenschaft und wer den Internet Explorer oder MS Edge unterstützt, hat Glück, da bereits der IE10 CSS Grids der ersten Spezifikation unterstützt. Microsoft hat die Eigenschaften entwickelt und in den IE10 integriert. Seither haben die anderen Browserhersteller zusammen mit Microsoft an einem W3C-Standard gearbeitet und die überarbeitete Fassung in die Browser implementiert. So ist es mit Autoprefixer möglich einige Eigenschaften automatisch für die alten Internet Explorer zu generieren, allerdings nur für die Eigenschaften, die der IE unterstützt. Eine gute Übersicht hat Rachel Andrew zusammengestellt. Zu Bedenken ist aber, dass alte Android-Versionen CSS Grids nicht unterstützen. Zudem ist zu empfehlen, dass der Browser-Support mit @support im CSS zu überprüfen ist und die Grid-Eigenschaften in die At-Rule gekapselt werden. Polyfills gibt es in der Form nicht, da es eine vollkommen neue Layout-Technik ist, die zudem die ganze Seite betreffen kann, was, wenn man mit Javascript das Layout beeinflusst, sehr performance-intensiv sein kann.

Aktuell unterstützen Firefox 52, Chrome 57 und Safari 10.1 sowie iOS 10.3, Android Chrome sowie Android Firefox die aktuelle Spec. Internet Explorer ab Version 10 (auch mobile) und Microsoft Edge unterstützen grundlegenden Grid-Eigenschaften mit Vendor-Präfix. Damit Microsoft auf die aktuelle Spec updated, müssen noch mehr Entwickler das Backlog-Ticket hoch voten.

http://caniuse.com/#feat=css-grid

Fazit:

Die neuen Möglichkeiten von CSS Grid Layout sind fantastisch. Endlich ist es möglich sehr viel einfacher eigene Grid-Layouts ohne spezielle Frameworks umzusetzen. Entwickler und Designer werden in Zukunft viel Freude mit den neuen Eigenschaften haben und endlich komplexe Layout-Anforderungen umsetzen können, die bislang nicht, bzw. sehr schwer möglich waren. Ich empfehle jedem Webentwickler mit Grids zu spielen und die Möglichkeiten auszuloten. Auch wenn man Grids aktuell noch nicht in vielen Projekten produktiv einsetzen kann, so ist zumindest der Internet Explorer diesmal nicht der Spielverderber. Dennoch denke ich, das spätestens in einem Jahr mehr und mehr Projekte mit CSS Grid Layouts umgesetzt werden.

Ich möchte zudem nochmals deutlich machen, dass CSS Grids kein Ersatz für irgendeine bisherige Layout-Technik ist, sondern eine tolle neue Ergänzung zu Flexbox, Float & Co darstellt. Ich bin gespannt welche schönen Ideen Designer haben, jetzt wo sie wissen, dass in modernen Browsern nun technisch viel mehr möglich ist.

Wer noch mehr Beispiele sehen möchte, wie man vom Bootstrap-Grid zum eigenen Grid gelangt, findet in meiner Präsentation „Grids & Glory“ weitere Beispiele. Zudem hab ich auf Codepen eine CSS Grid Collection meiner Tests zusammen gestellt.

Der Beitrag Native CSS Grid Layouts ohne Framework – ein einfaches Beispiel erschien zuerst auf maddesigns.

Kurz notiert – was macht der „Parent Selector“?
Der „Parent Selector“ referenziert in einer verschachtelten Regel den Eltern-Selektor und verbindet beim Kompilieren die Knoten zum endgültigen Selektor. Das ‚&‘ Ampersand dient als Platzhalter. Hier ein einfaches Beispiel:

a {
    color: blue;
    
    &:focus,
    &:hover { color: red; }
}

a {
  color: blue;
}

a:focus, a:hover {
  color: red;
}

Weitere Infos in der Sass Dokumentation.

Da seit der Sass-Version 3.3 das ‚&‘ (Ampersand) auch am Anfang von Selektoren verwendet werden kann und ich dahingehend meine Schulungsunterlagen anpassen wollte, habe ich ein paar Tests gemacht. Hier mal eine Zusammenstellung von ein paar Möglichkeiten:

$componentname: 'block';

.#{$componentname} {
  $parent: &;

  // .block.block
  &#{&} { color: red; }
  
  // .block + .block
  & + & { color: purple; }

  // .block__element
  &__element { color: green; }

  // .block .block__element
  #{&}__element { color: maroon; }
  
  // .block--modifier
  &--modifier {
    color: yellow;
    
    // .block--modifier__element
    &__element { 
      color: lime;
    }
    
    // .block--modifier .block__element
    #{$parent}__element { 
      color: blue; 
      
      // .block--modifier .block__element > .block__more
      > #{$parent}__more { color: white; }   
    }
  }
  
  // .block.block--no-img
  &#{&}--no-img { color: teal; }
  
  // div .block 
  div & { color: aqua; }
  
  // div.block .block
  div#{&} & { color: fuchsia; }
  
  // div.block 
  @at-root {
    div#{&} { color: gray; }
  }
}

Sassmeister „Codepen“:

Play with this gist on SassMeister.

Die Möglichkeiten für BEM-Klassen-Strukturen sind interessant. Ich möchte auch hier dazu keine Diskussion entfachen, darum geht es hierbei nicht. Ich weiß, dass einige Entwickler es nicht mögen, wenn BEM-Klassen mit ‚&‘, (z.B. &__element) zusammengesetzt in Sass verwendet werden, da es schwieriger ist bei der Suche im Projekt. Dennoch sehe ich dabei schon einige Vorteile und Sass wurde genau für das „DRY-Prinzip“ entwickelt.

Der Clou ist dabei ist, den Parent-Selektor in eine Sass-Variable innerhalb des Block zu referenzieren, also den Scope mitzuschleifen.

.block {
  $parent: &;
  
  &--modifier {
    color: yellow;
    
    #{$parent}__element {
      color: green;
    }
  }
}

Das ergibt folgenden Selektor:

.block--modifier .block__element {}


Kennt ihr noch mehr Tricks?

Der Beitrag Sass Parent Selector - '&' (ampersand) erschien zuerst auf maddesigns.

Aber mal kurz ein Schritt zurück – was macht eigentlich dieses PostCSS? PostCSS-Module verändern das geschriebene CSS, dabei kann das CSS auch vorher durch einen Präprozessor erstellt worden sein, muss es aber auch nicht. PostCSS kann auch SCSS-Dateien verarbeiten bevor es mit Sass kompiliert wird. Wenn man Sass verwendet, ist man ein großes Featureset gewohnt, das bereits enthalten ist. PostCSS ist erstmal nur das Gerüst und kann mit individuellen Plugins bestückt werden. Quasi ein LEGO für CSS-Entwicklung, man kann es nach den eigenen Wünschen zusammenstecken. <meinung>Es gibt Puristen, die Präprozessoren den Rücken gekehrt haben, jetzt aber zig PostCSS-Module einsetzen, die das CSS verwursteln – das soll jetzt besser sein? Na ich weiß nicht. </meinung>

Nichtsdestotrotz gibt es Module, die mir persönlich die Arbeit erleichtern. Und was mir die Arbeit leichter macht, ohne dass ich meinen kompletten Workflow umstellen muss (reicht, wenn man das alle 2–3 Jahre macht), finde ich gut. Ich verwende PostCSS zusätzlich zu Sass, für die Aufgaben, die Sass nicht oder nicht so komfortabel beherrscht. Letztlich soll PostCSS bei der Erstellung von CSS unterstützen. Jeder sollte sich sein eigenes Bild davon machen, ob es für ihn/das Team nützlich ist.

Hinweis:

Ich habe in den Code-Beispielen die Verwendung mit Grunt-PostCSS genutzt (quasi aus dem Gruntfile.js kopiert). Wer andere Build-Tools nutzt muss u.U. andere Konfigurationen angeben. Wie die PostCSS-Plugins eingebunden werden, findet ihr immer in der Plugin-Readme.

Autoprefixer

Das bekannteste PostCSS-Plugin und in den letzten Jahren auch das nützlichste ist Autoprefixer. Ihr kennt das – viele neue CSS3-Eigenschaften wurden mit Vendorpräfixe in die Browser gebracht und jeder Hersteller hat fleißig mitgemacht und seine eigenen Präfixe eingeführt. Beliebtes Beispiel war border-radius. So las man dann oft folgendes Beispiel im Netz:

.rounded-corner {
  -webkit-border-radius: 1em;
     -moz-border-radius: 1em;
          border-radius: 1em;
}

Wir wissen, dass border-radius schon ewig keine Vendorpräfixe braucht, aber andere Eigenschaften haben heute immer noch welche. Jede neue Eigenschaft doppelt und dreifach schreiben ist bescheuert, war aber nötig.</history> Für Sass gab es Compass, das eine Vielzahl an CSS3-Mixins lieferte, die einem diese Aufgabe abnahm. Man inkludierte 1x das Mixin und Compass schrieb die Vendorpräfixe. Deshalb war Compass sehr beliebt. Das Problem war, dass Compass die Vendorpräfixe immer eingesetzt hat, unabhängig davon, ob die Präfixe noch gebraucht wurden oder nicht.

Das macht Autoprefixer anders. Hier kann ich einen Browser-Support angeben. Autoprefixer prüft anhand caniuse.com-Daten, ob ein Präfix für die definierten Browser noch notwendig ist.

Grunt-PostCSS Config für Autoprefixer

require('autoprefixer')({
    browsers: ['last 2 version', 'ie >= 9', 'Android >= 2.3', 'Firefox ESR']
})

Als Webworker schreibe ich dann standardkonformes CSS und Autoprefixer wandelt das anschließend in CSS um, das alle meine Browser verstehen, die ich unterstützen möchte. Mittlerweile auch so intelligent, dass es die unterschiedlichen Flexbox-Syntaxen und die verschiedenen linear-gradient Schreibweisen einfügt. Also tatsächlich richtig mächtig.

Kleiner Zusatzhinweis:
Anstatt der Caniuse-Daten Browser-Daten kann ich mittlerweile auch eigene Analyse-Daten als Grundlage verwenden. Ich kann angeben, dass ich alle Browser unterstütze, die mehr als 5% Zugriffe auf meine Webseite ausmachen.

Beispiel:

require('autoprefixer')({
    browsers: ['> 5% in my stats', { stats: 'path/to/the/stats.json' }]
})

doiuse

Doiuse checkt, ob ich CSS-Eigenschaften einsetze, die Browser in meinem angegebenen Browser-Support nicht verstehen.

require('doiuse')({
  browsers: ['last 2 version', 'ie >=9', 'Android >= 4'],
  ignore: ['rem', 'css-boxshadow', 'css-transitions']
})

Zum Beispiel supporte ich in der oberen Config alle IEs ab Version 9. Verwende ich Flexbox-Styles in meinem CSS, würde das Plugin Alarm schlagen, da der IE9 Flexbox nicht versteht.

Aktuell prüft es das meiner Meinung nach zu gut. ;) Es prüft dabei, ob die Angabe bei Caniuse dunkelgrün ist, also voll unterstützt wird. Ein teilweiser/buggy Support wird als fehlerhaft angezeigt, überprüft aber nicht, ob ich den „buggy“ Fall im CSS überhaupt nutze. Das kann leicht verwirren. Dieses Verhalten soll sich aber in Zukunft ändern, so der Plugin-Autor. Das Plugin soll dann besser kennzeichnen welche Eigenschaft buggy/partial Support hat und welcher Browser die Eigenschaft überhaupt nicht versteht.

Rundum finde ich das aber ein nützliches Plugin, das zur Codequalität beiträgt.

CSS Next

CSS Next ist ein Sammelsurium an Plugins, welche mehrere Sachen machen. Man kann mit CSS Next bereits jetzt schon CSS der Zukunft schreiben. Es ermöglicht unter anderem die Benutzung von nativen Variablen (Custom Properties), Custom Media Queries oder wandelt Pixel-Angaben und rem-Werte um. Zudem hat CSS Next Autoprefixer und „Sass-Features“ wie Nesting schon an Board. Es ist quasi das Babel des CSS.

Ein Beispiel für Custom Properties

/* custom properties */
:root {
  --heading-color: #ff0000;
}

/* custom selectors */
@custom-selector :--headings h1, h2, h3, h4;

/* usage */
:--headings {
  color: var(--heading-color);
}

CSSNext kompiliert das zu:

h1, h2, h3, h4 {
  color: #ff0000;
}

Ich denke, dass es nicht viele Entwickler geben wird, die die allerneuesten Features für CSS schon heute verwenden werden. Viele Webworker schrecken ja schon davor zurück Flexbox einzusetzen, weil sie es noch nicht allumfänglich verstehen bzw. Browser-Bugs fürchten oder noch uralte Browser unterstützen müssen. Dennoch spannend zu beobachten, ob es dazu führt, dass mehr Entwickler zukunftsweisendes CSS schreiben.

postcss-assets

Ich muss sagen, dass ich es praktisch fand, dass Compass Funktionen bereit stellt, die mir die Breite und Höhe einer Datei auslesen können. In einigen Projekten brauchte ich das. Die Funktionalität bietet „postcss-assets“ genau so.

Beispiel: Breite eines Logo auslesen:

.logo {
  width: width("logo.svg");
  height: height("logo.svg");
}

Das kompilierte CSS:

.logo {
  width: 100px;
  height: 40px;
}

Zudem kann man auch Grafiken enkodiert (als background-image), also inline ins CSS ausgeben lassen. Aber dazu im nächsten Kapitel noch ein Plugin, dass das noch umfänglicher macht.

Beispiel inline SVG als background-iamge:

.logo {
  background-image: inline("logo.svg");
}

Das kompilierte CSS:

background-image: url("data:image/svg+xml,%3Csvg…")

Des Weiteren kann ein Cache-Buster aktiviert werden, praktisch besonders bei statischen Seiten.

postcss-svg

PostCSS-SVG stellt kleine Helferlein für die Arbeit mit SVG bereit. Icon-System hin oder her, Iconfont vs. SVG, ihr kennt das. Das Thema ignorieren wir hier mal. Es gibt Anforderungen, die außerhalb von Icons liegen. Ich hatte ein Projekt, da ist es erforderlich gewesen, dass eine Box einen unförmigen Hintergrund hat (Sprechblase) – ein Paradebeispiel für SVG als background-image. Nun ist es allerdings so, dass dieser Hintergrund mehrere Farbvarianten hatte, was auf den ersten Blick mehrere Assets mit den jeweiligen Farben bedeuten würde.

Oder man fügt den SVG-Code als enkodierten String ins CSS ein und tauscht dabei die Füllfarbe aus. Das PostCSS-Plugin postcss-svg macht das für uns.

Beispiel Sass

.svg-bg1 {
  background-image: svg('path/to/bg-svg', 
  '[fill]: #{$color-text}');
}

.svg-bg2 {
  background-image: svg('path/to/bg-svg', 
  '[fill]: #{$color-main}');
}

Wenn man Assets enkodiert ins CSS einbindet, muss man unbedingt vorher die Datei so klein schrumpfen wie es nur geht.

Dateien enkodiert ins CSS aufzunehmen ist immer ein Drahtseilakt… einerseits möchte man das CSS so schlank wie möglich halten, andererseits Requests sparen. Lohnt es sich für 2–3 Dateien ein Sprite zu erstellen oder ist der Request für das Sprite „teurer“? Muss/kann das einzelne Sprite-Element visuell verändert werden? Ist es wartbar? Wenn beim Build-Prozess generiert, sollte das kein Problem sein. Diese Fragen sollten sich Entwickler stellen, wenn sie grafische Elemente einbinden.

In dem besagten Projekt fand ich es die beste Lösung die SVG-Formen als background-image zu verwenden. Über die PostCSS-Funktion verknüpft und die Füllfarbe zugewiesen, fertig.

Ideal wäre für mich, wenn man diese Teile in ein separates Stylesheet auslagern und async nachladen könnte. Aber soweit hab ich den Bauprozess nicht gebracht.

CSSnano

CSSnano ist ebenfalls eine Ansammlung kleiner Scripte, die das CSS möglichst klein schrumpfen wollen. Dabei versuchen sie weiter zu gehen, als Minifizierer von Sass & Co. Neben den üblichen „ich entferne alle Whitespaces“, werden auch CSS-Regeln zusammen gezogen, die den gleichen Selektor haben. Da muss man vorsichtig sein, da dabei die Kaskade verändert werden könnte und das Ergebnis nicht mehr das Selbe ist. Auch versucht es z-Indizes zu simplifizieren. Auch das führt manchmal dazu, dass das gewünschte Aussehen im Anschluss nicht mehr passt. Ich empfehle, dass man das ausführlich gegenüber den bisherigen CSS-Minifier testet und vergleicht, ob es einen Vorteil bringt. Dennoch leistet es grundsätzlich eine gute Arbeit beim Minifizieren von CSS-Dateien.

Natürlich ist die Liste an Plugins lang und es gibt sicherlich für jeden nützliche und unnütze Plugins. Wer einen Präprozessor ersetzen möchte, kann CSSNext oder PreCSS verwenden. Wer nicht in die Probleme mit Flexbugs rennen möchte, kann mit postcss-flexbugs-fixes viele Bugs im Buildtasks elimieren – durchaus praktisch. Auf der Seite postcss.parts sind viele PostCSS-Plugins in unterschiedlichen Kategorien aufgeführt.

Welche nützlichen PostCSS-Plugins habt ihr noch im Einsatz?

Der Beitrag Nützliche PostCSS-Module erschien zuerst auf maddesigns.

Klar ist – mit CSS Flexbox sind uns Entwicklern neue Möglichkeiten gegeben worden, die bisher nur mit Hacks in CSS zu realisieren waren. Nun können wir verlässlich Inhalte vertikal zentrieren, zueinander ins Verhältnis setzen, visuelle Reihenfolge der Elemente verändern und endlich Boxen mit gleicher Höhe darstellen. Selbst der Browser-Support ist mittlerweile hervorragend (auch Opera-Mini unterstützt nun Flexbox), also kein Grund mehr auf die Vorteile zu verzichten.

Ein klassisches Beispiel für Flexbox ist eine horizontale Navigation. Die Anforderung: egal wie viele Menüpunkte, sie sollen sich optimal den verfügbaren Platz aufteilen.

Beispiel HTML

<nav role="navigation">
    <ul class="the-flextable">
        <li><a href="">Item 1</a></li>
        <li><a href="">Item 2</a></li>
        <li><a href="">Item 3</a></li>
        <li><a href="">Item 4</a></li>
        <li><a href="">Item 5</a></li>
    </ul>
</nav>

Beispiel CSS

.the-flextable {
    display: table; /* Fallback IE<9 */
    display: flex;
    width: 100%;
}

.the-flextable > li {
    display: table-cell; /* Fallback IE<9 */
    flex: 1 1 auto;
    min-width: 1%; /* Fix for Firefox */
}

Codepen-Link: http://codepen.io/maddesigns/pen/NGZJxG

Mit display: table/table-cell; hat man für diese simple Aufgabe einen guten Fallback für Browser die Flexbox nicht verstehen. Selbst vertikal zentrieren des Textes ist mit table-cell möglich.

Vorteile: ‚display: table‘

• vertikales zentrieren und gleiche Höhen

Nachteil: ‚display: table‘

• Zwischenräume (margins) können auf table-cell nicht angewendet werden, border-collapse: separate und border-spacing als Ersatz ist nicht optimal

Selbst für Fälle wo flex-wrap zum Einsatz kommt, kann man mit display: inline-block oder float gute Fallbacks erreichen. Nachteil bei inline-block/float ist leider, dass die Höhe der „Flex-Items“ nicht automatisch gleich hoch ist, hier müsste man sich über min-height an das gewünschte Aussehen annähern. Für den Fallback mit display: inline-block ist es zudem notwendig Whitespace, den inline-block mitbringt, zu eliminieren. Der Blogbeitrag von CSS-Tricks zeigt die unterschiedlichen Möglichkeiten. Ich finde die font-size: 0 Methode oft am praktischsten.

Hier mal ein einfaches responsive „floating“ flex-wrap Fallback-Beispiel mit inline-block (hab ich alle buzzwords eingebunden?):

Codepen-Link: http://codepen.io/maddesigns/pen/EBlHd

Vorteile: ‚display: inline-block‘

• vertikales Zentrieren
• kein Clearing notwendig

Nachteile: ‚display: inline-block‘

• keine gleichen Höhen
• Whitespace-Foo
• kein Clearing möglich

Vorteile: ‚float‘

• Verhalten und Anwendung von float ist den meisten Entwickler vertraut

Nachteile: ‚float‘

• Clearing
• kein vertikales Zentrieren
• keine gleiche Höhe

Selbst für einen einfachen Source-Order-Switch kann man auf display: table als Fallback zurückgreifen. Im Blog-Post: Content-Source Ordering habe ich eine Möglichkeit für IE8 & Co. skizziert.

Grundsätzlich bin ich immer ein Freund von mobile first/semantic first, also erst die richtige Source-Order von der Logik her erstellen und dann das gewünschte Ergebnis visuell abbilden.

Ein typisches Beispiel hatte ich letztens im Projekt auch: Ein Kochrezept! Die visuelle Vorgabe für große Viewports (aka Desktop) sah in etwa so aus:

Für Schmalscreens und als Struktur entschied ich mich dazu folgenden Wireframe umzusetzen.

Der Fallback für IE9 (der eigentlich nicht unterstützt wird) ist in dem Fall display: inline-block, allerdings bleibt die logische Reihenfolge der Elemente unverändert. Ich finde das nicht tragisch, optisch sieht es vollkommen in Ordnung aus.

Braucht man aktuell noch alle Flexbox-Varianten?

Flexbox hat einige Spezifikationsvarianten durchlebt und Browserhersteller haben unterschiedliche Schreibweisen implementiert, so dass wir teilweise nicht nur Vendor-Präfixe, sondern auch verschiedene Schreibweisen (Eigenschaftsnamen) für den Cross-Browser-Support einbinden müss(t)en. Autoprefixer nimmt uns das glücklicherweise alles ab. Wenn man alte Android-Versionen unterstützt (4.x ist auch alt ;)), dann benötigt man auf jeden Fall die alte Schreibweise. IE10 braucht die Zwischenlösung von 2012.

Mir ist aufgefallen, dass es weniger Probleme gibt, wenn man z.B. mit Modernizr den Support testet und dann dementsprechend die Zuweisung der Eigenschaften macht, heißt also Fallback mit .no-flexbox.

Einen einfacher Test, ob Flexbox (mit Flex-Wrap) verfügbar ist, hat Ethan Marcotte in einem 24ways Artikel gezeigt:

var doc = document.body || document.documentElement;
var style = doc.style;
​
if ( style.webkitFlexWrap == '' ||
    style.msFlexWrap == '' ||
    style.flexWrap == '' ) {
  doc.className += " supports-flex";

Alle Styles werden dann also mit .supports-flex gepräfixt.

CSS-Beispiel:

.supports-flex .flex-container {
    display: flex;
}

.supports-flex .flex-item {
    flex: 1 1 0%;
}

Wie so oft, ist es auch leider so, dass bei der Implementation der Spezifikation Fehler unterlaufen und so gibt es auch für Flexbox Bugs in Browsern. Auch das führt oft zur Ablehnung der Technik. Philip Walton hat die Flexbugs mal zusammengeschrieben.

Die entscheidendsten Bugs sind:

1. In der vertikalen Flexbox-Ausrichtung mit „column“ wird im IE10–11 die gesetzte Mindesthöhe nicht an die Flex-Items vererbt. Besser wäre es eine definierte Höhe zu setzen.
2. Chrome, Opera und Safari missachten die per Default vergebene Inhaltsbreite der Flex-Items. Hier empfiehlt es sich den flex-shrink Wert auf 0 statt dem Defaultwert 1 zu setzen um umgewollte Darstellungen zu vermeiden.
3. Flex-Basis sollte man nicht ohne Einheit in der Flex-Shorthand-Notation benutzen, das führt zu Fehlern im IE10 und 11. Besser ist es 0% anstatt 0px zu verwenden, da einige CSS-Minifizierer 0px zu 0 wandeln (0 ohne Einheit ist ja genau das Problem).

Ein PostCSS-Script hilft uns beim Flexbugs fixen – https://github.com/luisrudge/postcss-flexbugs-fixes. Es scannt das CSS und ersetzt mögliche Problemstellen mit dem empfohlenen Code.

Flexbox-Polyfill für IE8/9

Jonathan Neal, der schon den Polyfill „SVG4everybody“ entwickelt hat, hat mit Flexibility einen Flexbox-Polyfill für IE8 und 9 veröffentlicht. Der Polyfill scannt die Seite und das CSS und stellt das Flexbox-Verhalten mit JavaScript nach. Also kein manueller Aufwand für Entwickler. Als Trigger für JavaScript wird in CSS -js-display: flex; gesetzt.

.foo {
    -js-display: flex;
    display: flex;
}

Um das noch weiter zu Vereinfachen gibt es auch dafür ein PostCSS-Plugin, dass das Einfügen des Triggers -js-display: flex automatisch macht.

Natürlich sollte man genau überprüfen, ob das gewünschte Ergebnis damit auch erzielt wird bzw. ob es notwendig ist dafür extra JavaScript zu verwenden – oft reicht ja auch ein wenig CSS als Fallback aus. Auch wenn das Ergebnis nicht immer 100%ig das Gleiche ist, so gibt es eine Reihe guter Fallbacks für Flexbox – denn müssen Webseiten in jedem Browser gleich aussehen? Nein!

Update 06.04.2016:

Eine sehr schöne Übersicht dazu hat Kenan Yusuf erstellt: Almost complete guide to flexbox (without flexbox)

Der Beitrag Flexbox Fallbacks erschien zuerst auf maddesigns.

Eines der komplizierteren Themen im Responsive Webdesign ist unbestritten die Navigation, gerade wenn ein Relaunch bestehender Inhalte geplant ist. Wird auf der vorhandenen Webseite eine umfangreiche Navigation (z. B. „Mega Dropdown“) verwendet, ist eine Anpassung auf kleinere Bildschirme eine herausfordernde Aufgabe. Hier gibt es keine Einheitslösung, es muss eine gut durchdachte Lösung gefunden werden. Beim Responsive Re-Design sollte es immer eine Anpassung von Inhalt (Content Strategy) und Navigationsstruktur geben, auch wenn dies sicherlich schwerfällt.

Verfolgt man den „Mobile First“ Ansatz, bei dem man zuerst für mobile Geräte konzipiert und designt, ist es oft leichter sich auf die wesentlichen Kernpunkte der Navigation zu konzentrieren. Demzufolge ist eine simple Navigation zu erstellen mit den wichtigsten Navigationspunkten. Eine Navigation mit sehr vielen Unterebenen ist für Benutzer – gerade auf kleinen Bildschirmen – schwer zu erfassen. Hier muss in der Konzeption darauf geachtet werden, dass die Navigationsstränge für den Besucher schlüssig sind.

Das direkte Erfassen der Navigationsstruktur bzw. der Kategorien eines Shops hat sich als enorm wichtig herausgestellt. Auch wenn Lösungen wie das „Off-Canvas-Menü“ praktisch sind um bei größeren Menüs Platz im Sichtbereich zu sparen, sind diese doch für unerfahrene Nutzer oft eine Hürde. Studien haben gezeigt, dass Benutzer, die zum ersten Mal auf einer neuen Shop-Homepage landen, sich zuerst durch hoch- und runterscrollen orientieren. Dies geschieht, um für sich zu Erfassen, ob das Gesuchte (die gewünschte Kategorie) auf der Webseite zu finden ist, also ob die Seite thematisch den Erwartungen entspricht. Platzieren Sie zumindest ein paar Hauptmenüpunkte direkt auf der Startseite im Header.

Ein großer Aufhänger für Meinungsverschiedenheiten ist das sogenannte „Hamburger-Icon“. Das in der Designer- und Entwicklergemeinde bekannte Icon wird mittlerweile häufig verwendet, um ein (Off-Canvas)-Menü zu öffnen. Inzwischen wurde es oft wieder von Webseiten entfernt, da Studien zeigten, dass viele Nutzer das Icon (noch) nicht verstehen. Es ist für den Einsatz des Hamburger-Icons daher abzuwägen, welche Zielgruppe man auf der Webseite hat. Bei einer Seite mit technik-affiner Zielgruppe ist der Einsatz durchaus denkbar, bei einer internetunerfahrenen oder breiten Nutzergruppe ist eher darauf zu verzichten.

Der Online-Auftritt der britischen Zeitung „The Guardian“ verwendet auf ihrer Seite ein ausgeklügeltes Navigationskonzept. Das sogenannte „Priority“-Konzept zeigt in einer horizontal swipebaren Navigation schon so möglichst viele Navigationspunkte im verfügbaren Sichtbereich. Alle weiteren Punkte sind über einen Menü-Button erreichbar. Je größer das Gerät, umso mehr Menüpunkte können direkt vom User erfasst werden.

Unbestritten ist es gerade bei Shops mit vielen Kategorien schwierig — wie etwa m.zalando.de oder otto.de — eine einfache Navigationsform zu finden. Aber auch hier wurde versucht, in flachen Hierarchien zu bleiben. Nichts ist schlimmer, als sich immer tiefer in einen Navigationsstrang zu graben, nicht das zu finden, was man sucht und zum Schluss gar nicht mehr zu wissen, wo man sich befindet. Für viele Nutzer ist es um so wichtiger, eine gute Suche und umfangreiche Filtermöglichkeiten zur Verfügung zu stellen.

Natürlich muss man dann nicht auf eine erweiterte Navigation auf Desktopgröße verzichten. Optimalerweise lädt man die „fehlenden“ Untermenüs dort nach. Technisch gesehen ist dies die bessere Lösung, als zwei verschiedene Menüs in die Seite einzubauen und diese jeweils auf Smartphone- und Desktopscreens ein- bzw. auszublenden.

Unterschätzt wird gerade bei Shops der Einsatz von Breadcrumb-Pfad-Navigationen. Auch wenn diese in großen verzweigten Kategoriebäumen eher visuell störend empfunden werden, hilft es dem Besucher enorm, wenn er auf einer Produktdetailseite nicht genau das gefunden hat, was er suchte. Viele User gehen dann über die Breadcrumb-Navigation in die übergeordnete Kategorie zurück, um von dort weiterzusuchen.

Allerdings wird das Thema Navigation im Online-Shop-Bereich manchmal überschätzt. Einige Nutzergruppen (speziell Frauen) gehen eher so vor, dass sie von Übersicht zu Übersicht springen (aka. „bummeln“), bis sie etwas Interessantes entdecken. Sie navigieren also nicht übers Menü. Andere suchen eher ein bestimmtes Produkt und nutzen die Suche oder navigieren durch Empfehlungen.

Festzuhalten bleibt: Die Navigation sollte simpel gehalten sein und den User unterstützen und ihn nicht verwirren. Denn wie sagte schon der Usability-Guru Steve Krug: „Don’t Make Me Think.“

Dieser Artikel zum Thema „Responsive Navigation aus UX-Sicht“ erschien zuerst im Newsletter des E-Commerce Dienstleisters dynamic commerce GmbH.

Der Beitrag Responsive Navigation aus UX-Sicht erschien zuerst auf maddesigns.

tl;dr; „Warum ist mir egal, ich will Code sehen” => hier klicken

Mir persönlich nutzt ein Static Site Generator oft bei meinem täglichen Workflow, beim Erstellen von Klickdummys und Templates. Der Vorteil eines „Static Site Generator“ liegt auf der Hand: man nutzt die Dynamik einer Script-Sprache um wiederholende Elemente nicht jedes Mal neu schreiben zu müssen oder Markup mit dynamischen Daten zu vermischen. Man stelle sich vor, man muss bei einer statischen Seite einen Navigationspunkt ändern und das bei vielen Seiten, das ist aufwändig und fehleranfällig.

OK, jetzt könnte man meinen, dass man doch gleich PHP oder ähnliches nehmen könnte. Ja kann man auch. ;) Aber auch hier wäre es von Vorteil, wenn man das Markup von der Logik entkoppelt, also sowas wie ein MVC-Prinzip. Möchte/Soll man die Template-Schnipsel wieder verwenden können, also sollen die Schnippets möglichst modular wiederverwendbar sein, ist man schnell bei einer Template-Engine, die das unterstützt.

Ähnlich mit Javascript-Bausteinen. Immer mehr Teile der Website werden mit dynamischen Daten und Markup-Schnipseln in die Seite integriert, bzw. werden ja bereits viele JS-Anwendungen komplett im Browser zusammengebaut… buh! lang lebe semantisches Markup!

Auch hier gibt es Template-Engines, z.B. Handlebars, die eine klare Trennung von Markup und Logik handle’n ;). Und schwuppdiwupp ist man schon bei einem System, aus dem man auch statische Seiten exportieren könnte. Mit Grunt ein paar Prozesse definiert, fertig. Bonus: die Handlebars-Templates können auch im Javascript verwendet werden.

Assemble macht das alles und bringt noch ein paar Features mehr mit.

• Handlebars (nutzt Mustache Syntax)
• YAML Frontmatter
• Datenverarbeitung aus JSON oder YAML

Installation von Assemble

npm install assemble --save-dev

Grunt Beispiel Config

assemble: {
    options: {
        flatten: true,
        assets: 'assets',
        helpers: ['templates/helpers/*.js', 'handlebars-helpers'],
        partials: ['templates/partials/**/*.hbs'],
        layout: ['templates/layouts/default.hbs'],
        data: ['templates/data/*.{json,yml}']
    },
    pages: {
        src: ['templates/pages/**/*.hbs'],
        dest: 'dist'
    },
    docs: {
        src: ['templates/docs/**/*.hbs'],
        dest: 'dist/docs'
    }
}

Ein einfaches Default-Layout mit Partials

Ein einfaches HTML5-Dokument als Beispiel für die Haupt-Layout-Datei. Über {{> Name}} können so genannte Partials integriert werden. In dem Beispiel, Teile des Dokuments, die immer auf der Seite sind (Header, Footer,…).

layout: default.hbs

<!DOCTYPE html>
<html lang="en" class="no-js">
  <head>
    <title>{{page-title}}</title>
    {{> head }}
  </head>
  <body {{#if site-class}} class="{{site-class}}"{{/if}}>
    {{> header}}
    {{> nav}}
    {{> body}}
    {{> footer}}
    {{> foot }}
  </body>
</html>

Das {{> body }} Partial ist hier etwas spezieller und wird als Platzhalter für die jeweiligen Seiten verwendet. Es kann im oberen Bereich der Seite eine YAML-Frontmatter-Konfiguration enthalten. Diese YAML-Daten können z.B. auch an das Haupt-Layout-Template (Default.hbs) übergeben werden.

pages: index.hbs (body partial)

---
page-title: Index Template
site-class: "index"

intro: 
  name: 
  - the name 1
  - the name 2
  - the name 3
---
<h1>here comes the hotstepper</h1>

<ul class="intro">
  {{#each intro }}
  <li class="intro_item
    {{#unless @index}}
    is-active
    {{/unless}}">
    <h3>{{ this.name }}</h3>
    <img src="{{ assets }}/img/{{hyphenate this.name }}.jpg" alt="{{ this.name }}">
    <p>{{ lorem ipsum.sentence }}</p>
  </li>
  {{/each}}
</ul>

Diese Intro-Section (vielleicht News-Teaser) kann man als Partial auslagern, wenn man dieses HTML-Konstrukt mehrfach nutzen möchte.

partials: _intro-section.hbs

<ul class="intro">
  {{#each intro }}
  <li class="intro_item
    {{#unless @index}}
    is-active
    {{/unless}}">
    <h3>{{ this.name }}</h3>
    <img src="{{ assets }}/img/{{hyphenate this.name }}.jpg" alt="{{ this.name }}">
    <p>{{ lorem ipsum.sentence }} </p>
  </li>
  {{/each}}
</ul>

Anderes Page-Layouts innerhalb „pages“ verwenden

Wenn man für bestimmte Seite ein anderes „Page-Layout“ verwenden möchte, kann man das einfach in Kopfbereich (YAML-Frontmatter-Bereich) der Seite angeben.

pages: test.hbs

---
page-title: pages
layout: pages.hbs
---

Die Datei ‘pages.hbs’ legt man in das Layout-Verzeichnis, das man in der Grunt-Config angegeben hat. Hier kann man auch das Layout-Verzeichnis mit layoutdir angeben:

assemble: {
    options: {
        layout: 'default.hbs',
        layoutdir: 'templates/layout/'
    }
}

Dann wird unter ‘layout’ nur noch der Name der Default-Datei angegeben.

Anders Dateiformat in der Ausgabe generieren

Standardmäßig wird aus den .hbs Dateien eine HTML-Datei generiert. Möchte man ein anderes Dateiformat generieren, kann man dafür eine gesonderte Konfiguration in Grunt angeben. In den ‘options’ kann die ’ext’ention festgelegt werden.

gruntconfig.js

assemble: {
  // Build sitemap from JSON and templates 
  sitemap: {
    options: { ext: '.xml' },
    files: {
      '.': ['path/to/sitemap.tmpl' ]
    }
  },
  // Build README from YAML and templates 
  readme: {
    options: { ext: '.md'  },
    files: {
      '.': ['path/to/readme.tmpl' ]
    }
  }
}

Dynamische Daten verwenden

Ein großer Vorteil von Assemble ist es, dass mit Assemble Daten im JSON- oder YAML-Format verarbeitet werden können. Das ist praktisch, wenn man z.B. wiederkehrende Daten hat. Diese Daten legt man das in den Grunt-Options festgelegte Verzeichnis, z.B. in ‘templates/data/’.

assemble: {
    options: {
        data: ['templates/data/*.{json,yml}']
    }
}

Wiederkehrende Daten kann man in ein JSON-Objekt oder in eine YAML-Notation auslagern.

Beispiel: site.json

{
    "sociallinks": [
        "facebook",
        "youtube",
        "xing"
    ]
}

sociallinks.hbs partial template

<div class="social-links">
    {{#each site.sociallinks}}
    <a href="#linkurl" title="Link to {{capitalizeEach this }}">
        {{.}}
    </a>
    {{/each}}
</div>

simple Daten übergeben

Mit dem Helper parseJSON kann man einfache Daten bei der Einbindung an ein Partial übergeben.

Einbindung des Partials in page-Template

{{#parseJSON '{"teasertext": false, "limit": 5}'}}
    {{> _newslist }}
{{/parseJSON}}

### partial code
<ul class="teaserlist">
{{#each limit==limit}}
    <li>
        <h3>Teaser Headline</h3>
        {{#is teasertext true}}
        <p>lorem ipsum</p>
        {{/is}}
    </li>
{{/each}}
</ul>

So kann man ein Partial an anderen Stellen in leicht veränderter Ausgabe verwenden, schön modular. In dem Beispiel wird eine Teaserliste mit 5 Teasern und ohne Teaser-Text ausgegeben.

Eine Übersicht der generierten Seiten erstellen (Sitemap)

Um eine Link-Liste mit den generierten Seiten als Übersicht zu erstellen, kann man den View-Helper ’{{#pages}}’ verwenden.

---
title: Overview
---
<ul>
{{#pages}}
    <li><a href="{{lowercase basename}}{{ext}}">{{data.title}}</a></li>
{{/pages}}
</ul>

Für die Linkbezeichner wird hier der Wert aus dem YML-Kopfbereich ‘title’ verwendet. Zugriff auf die Daten bekommt man mit ‘data’, also ‘data.title’.

Weitere nützliche Handlebars-Helpers

Mittlerweile gibt es eine Vielzahl an zusätzlichen Plugins bzw. Handlebars-Helpers.

Nach dem Installieren, die Helper in den Grunt-Options Grunt-Options hinzufügen.

assemble: {
    options: {
        helpers: ['templates/helpers/*.js', 'handlebars-helpers', 'handlebars-partials'],
    }
}

Soweit ein kleiner Einblick in Assemble. Letztlich hab ich festgestellt, dass der Artikel mehr zu einer Tipps & Tricks Liste geworden ist… und wieder mal länger als anfangs gedacht.

Habt ihr weitere Tipps zur Verwendung?

Der Beitrag Assemble – erste Schritte mit dem Static Site Generator für Grunt erschien zuerst auf maddesigns.

Ein Blogpost der nunmehr 3 Jahre auf Vollendung wartet, ist jetzt endlich fertig :)

Responsive iFrame? Das klingt schon falsch und ist auch ein schwieriges Pflaster. Grundsätzlich können iFrames responsive sein, Voraussetzung ist natürlich, dass sich deren Inhalt ebenfalls responsive verhält. Es ist ja quasi ein Browserfenster im Browserfenster. Doch die Anpassung der Breite ist nicht das Problem, die Anpassung der Höhe macht es kompliziert.

Prominentes Beispiel: YouTube Video responsive einbinden

Der YouTube-iFrame soll folgendermaßen eingebunden werden:

<iframe width="560" height="315" src="https://www.youtube.com/embed/9T7eSyo7DRU" frameborder="0" allowfullscreen></iframe>

Die Breite des iFrame überschreibt man durch CSS wie auch bei Responsive Images:

img,
iframe {
  max-width: 100%;
}

Die Breite passt sich immer dem Container an. Die Höhe wird leider nicht automatisch angepasst, im Beispiel bleibt die Höhe also bei 315px. Die Regel height: auto; hat hier leider keinen Einfluss auf unseren iFrame. Das Problem bleib die relationale Höhenanpassung des iFrames, wenn sich die Breite verändert. Für das reponsive iFrame Video behelfen wir uns mit einem bekannten Trick. Den iFrame umschließen wir mit einem Container-DIV und erweitern den Container mit ‚padding-bottom‘ durch die prozentuale Höhe des Seitenverhältnis vom iFrames, genauso wie bei Lazy Loading Responsive Images Blogpost.

Beispiel:

<div class="embed-container">
    <iframe width="560" height="315" src="https://www.youtube.com/embed/9T7eSyo7DRU" frameborder="0" allowfullscreen></iframe>
</div>

.embed-container {
  position: relative; 
  padding-bottom: 56.25%; /* ratio 16x9 */
  height: 0; 
  overflow: hidden; 
  width: 100%;
  height: auto;
}
.embed-container iframe {

  position: absolute; 
  top: 0; 
  left: 0; 
  width: 100%; 
  height: 100%; 
}
/* ratio 4x3 */
.embed-container.ratio4x3 {
  padding-bottom: 75%;
}

Jetzt wird die Video-Containerhöhe immer relational an die Breite angepasst. Je nach Seitenverhältnis kann man auch weitere Klassen im .embed-container verwenden, z.B. .ratio4x3 für ein Seitenverhälnis 4:3.

Bei einem externen Video mit festem Seitenverhältnis ist das recht einfach, schwieriger wird es mit interaktiven Inhalten, die eine dynamische Höhe haben.

iFrame Interaktion

Wenn man im iFrame weitere Aktionen durchführen kann (Bestellformular, etc.) und die iFrame-Inhaltsseiten unterschiedlich lang sind, wird unter Umständen ein Scrollbalken angezeigt oder man hat viel Weißraum. Dieses Verhalten ist verständlicherweise nicht gewollt. In einem Projekt sollte die Anwendung (Berechnung einer Versicherung) in Partnerwebseiten eingebunden werden, ohne dass auffällt, dass es eine externe Anwendung (ein externes Produkt) ist.

Das ist unlängst komplizierter, da iFrames insbesondere von verschiedenen Domains aus Sicherheitsgründen nicht so einfach miteinander kommunizieren dürfen (Same-Origin-Policy).

Same Origin iFrame

Wenn der iFrame von der gleichen Domain aus z.B. mit der ID „responsive-iframe“ eingebunden ist, kann man folgende jQuery-Funktion verwenden.

$(function(){
  $(window).on('load resize', adjustIframe);
});

function adjustIframe() {
  $(parent.document.getElementById("responsive-iframe")).css("height", $("html").css("height"));
}

Erfolgt die Einbindung unter einer anderen Domain, muss man eine andere Technik verwenden damit die Kommunikation zwischen den Frames gewährleistet ist.

Cross Origin iFrame

In HTML5 ist postMessage eingeführt worden, das eine Kommunikation zwischen Browserfenstern erlaubt. Hiermit ist es möglich die aktuelle Höhe des iFrame-Inhalt an die einbindende Seite zu übermitteln.

postMessage Definition:

otherWindow.postMessage(message, targetOrigin, [transfer]);

JavaScript Funktion für Cross-Origin responsive iFrames

iframe.html – Sender:

var rIframe = {};
rIframe.requestAnimFrame = (function(){
        
    return  window.requestAnimationFrame       ||
            window.webkitRequestAnimationFrame ||
            window.mozRequestAnimationFrame    ||
            window.oRequestAnimationFrame      ||
            window.msRequestAnimationFrame     ||
            function( callback ){
                window.setTimeout(callback, 1000 / 60);
            };
})();    
rIframe.windowHeight = 0;
rIframe.htmlElement = document.getElementsByTagName('html')[0];
rIframe.targetDomain = 'domain.tld';
rIframe.resizeFrame = function (){
    var windowHeight = document.body ? Math.max(document.body.offsetHeight, rIframe.htmlElement.offsetHeight) : rIframe.htmlElement.offsetHeight ;
    if ( rIframe.windowHeight === windowHeight ) {
        rIframe.requestAnimFrame.call(window, rIframe.resizeFrame);
        return false;
    }
    rIframe.windowHeight = windowHeight;
    try {
        // Same Origin iFrame
        window.frameElement.style.height = windowHeight + 'px';
    }
    catch ( e ) {
        // Cross Origin iFrame
        window.parent.postMessage('resize:' + windowHeight , rIframe.targetDomain);
    }
    rIframe.requestAnimFrame.call(window, rIframe.resizeFrame);
};
rIframe.requestAnimFrame.call(window, rIframe.resizeFrame);

index.html – Empfänger:

function receiveMessage(event) {
    var message = event.data.split(':');
    var eventName = message[0];
    var iframes, len, i = 0;

    // only receive messages from this domain
    var senderDomains = ['domain.tld'];

    if ( senderDomains.indexOf(event.origin) !== -1 && eventName === 'resize' ) {
        iframes = document.getElementsByTagName('iframe');
        len = iframes.length;
        
        for (; i < len; i++) {
            if ( ( iframes[i].contentWindow || iframes[i].documentWindow ) == event.source) {
                iframes[i].style.height = message[1] + "px";
                return;
            }
        }
    }
}

if ( window.addEventListener ) {
    window.addEventListener('message', receiveMessage, false);
} 
else if (window.attachEvent)  {
    window.attachEvent('onmessage', receiveMessage);
}

Den kompletten Code findet man hier

JavaScript-Plugins

easyXMD

easyXDM ist eine Javascript Library, die es Entwicklern ermöglich mit den Limitierung der Same Origin Policy umzugehen und Anwendungen Cross-Domain kommunizieren zu lassen. Im Blogpost auf http://easyxdm.net/wp/2010/03/17/resize-iframe-based-on-content/ wird gut beschrieben, welche Schritte man unternehmen muss.

http://easyxdm.net/wp/

Wer im Projekt jQuery verwendet, kann das „responsiveiframe” Plugin von NPR verwenden.

http://npr.github.io/responsiveiframe

Eine umfangreiche API für iFrame Embeds bietet iframely. Die Basisvariante ist auch auf Github verfügbar. Der Online-Service bietet noch weitere Features, wenn man ein Bezahlmodell wählt.

https://iframely.com/

Performance Tweak

Ein letzter Hinweis, wenn der iFrame onload nicht im Viewport ist, sollte man überlegen, ob man den iFrame mit einer Lazy Loading Technik verzögert lädt. Am Beispiel der lazySizes Bibliothek von Alex Farkas, ist das sehr einfach zu integrieren.

<iframe data-src="//www.youtube.com/embed/ZfV-aYdU4uE" class="lazyload" frameborder="0" allowfullscreen></iframe>

Die eigentliche Soure (src) wird durch „data-src“ ersetzt, zusätzlich mit der Klasse „lazyload“ versehen. Das Script lädt dann den iFrame beim Scrollen nach, wenn der iFrame sich den Viewport nähert.

Das ist aber mehr oder weniger nur ein Zusatzfeature der Bibliothek - das Hauptaugenmerk liegt auf das Lazy Loading von Responsive Images (srcset/picture). Also durchaus eine Script, das man in vielerlei Hinsicht verwenden kann.

Der Beitrag Responsive iFrames erschien zuerst auf maddesigns.

Diese kleine Serie gibt ein paar Beispiele, wie man ein paar knifflige Aufgaben beim „responsive-fähig-machen” einer Desktop-Seite lösen kann.

Wie schon in Teil 1 zum Thema „Responsive Tabellen“, nochmals vorab der Hinweis, dass man bei einer umfangreicheren Seite mit neuer Code-Basis im Mobile-First-Modus starten sollte.

Ein häufiges Problem beim sogenannten „Responsive Retro Fitting”, also bestehende Desktop Webseiten „responsivefähig” zu machen, ist die visuelle Neuordnung von Inhalt, wenn man am bestehenden Markup nichts ändern kann/darf.

Ein kleines Beispiel dafür:

Auf einer Desktopseite ist das User-Login-Formular in der „rechten” Spalte. Linearisiert man jetzt das Layout, so dass die Inhaltscontainer nicht mehr nebeneinander floaten, würde das Login-Formular erst unter dem Hauptinhalt kommen. Das kann ja durchaus so gewollt sein, meist möchte man aber das Login-Formular als ersten Inhaltsbereich auf der Seite sehen, um sich schnell einloggen zu können und nicht erst lange scrollen zu müssen.

Ein anderes Beispiel: „Aktuelle News” in der rechten Spalte, News-Listenansicht in der „linken Spalte” – die aktuellen Nachrichten erwartet man in der Smartphone-Ansicht eher oberhalb der alten News.

Ein typisches Markup

<div class="container">
    <div class="col-left">
        left content
    </div>
    <div class="col-right">
        right content
    </div>
</div>

Gesetzt den Fall, dass man die Elemente bereits fluide mit prozentualen Breiten ausgestattet hat, könnte man für kleine Bildschirme (wir nehmen hier kleiner als 600px an) folgendes CSS zuweisen um die Reihenfolge der Spalten zu verändern.

CSS

@media screen and (max-width: 600px) {
  .container {
    display: table;
  }
  .col-left {
    display: table-footer-group;
  }
  .col-right {
    display: table-head-group;
  }
}

Hierbei kommt ein kleiner Trick zum Einsatz, der eigentlich für das Styling von Tabellen gedacht ist, nämlich das Setzen einer Display-Eigenschaft für Table-Head bzw. Table-Foot. Das ist zwar ein wenig dirty, aber es funktioniert.

Dieser Trick wird von allen modernen Browsern verstanden, selbst der IE8 würde das machen – der bekommt aber normalerweise keine Smartphone-/Tablet-View, da nur auf Desktop-Geräten im Einsatz, wenn er überhaupt noch was bekommt…

Allerdings begegnet uns hier ein kleines Problem – table-footer-group nimmt kein padding an, da es eigentlich nur als Container ohne Eigenschaften agiert.

Eine alternative Variante:

@media screen and (max-width: 600px) {
    .container {
        display: table;
    }
    .col-left,.col-right {
        display: table-caption;
        padding: 1em;
    }
    .col-left {
        caption-side: bottom;
    }
    .col-right {
        caption-side: top;
    }
}

Wir nutzen hier wieder CSS-Eigenschaften, die für das Stylen von Datentabellen gedacht waren, caption-side: top/bottom ist eigentlich für die Anordnung der Tabellenbeschreibung (<caption>) gedacht. So ist es möglich den Spalten auch ein padding zuweisen.

Anordnung mit Flexbox

Besser geeignet und für solche Anwendungsfälle gedacht, ist die Eigenschaft flex-direction: column-reverse im Flexbox-Kontext.

Flexbox column-reverse Beispiel

@media screen and (max-width: 600px) {
    .container {
        display: flex;
        flex-direction: column-reverse;
    }
    .col-left,.col-right {
        padding: 1em;
    }
}

Hier werden die Elemente, die innerhalb des Container liegen als Spalte in umgekehrter Reihenfolge gestapelt. Die direkten Kindelemente vom Flexbox-Container (display: flex/inline-flex) werden in ihrer Reihenfolge umgekehrt angezeigt.

Angenommen man hat mehr als zwei Elemente, ist es ratsam mit der Flexbox-Eigenschaft order zu arbeiten, um genauer definieren zu können, welche Spalte an welcher Stelle kommt.

Flexbox Order Beispiel: HTML

<div class="container">
    <div class="col-left">
        left content
    </div>
    <div class="col-middle">
        middle content
    </div>
    <div class="col-right">
        right content
    </div>
</div>

CSS

@media screen and (max-width: 600px) {
    .container {
        display: flex;
        flex-direction: column;
    }
    .col-left {
        order: 3;
    }
    .col-middle {
        order: 2;
    }
    .col-right {
        order: 1;
    }
}

Mit order kann man ganz genau bestimmen welches Element wann kommt.

Browser-Support

Der Browser-Support für Flexbox ist mittlerweile sehr gut. Allerdings sollte man für ältere Browser, die eine ältere Spezifikation von Flexbox implementiert haben oder noch Vendor-Prefixe verwenden ( Android, iOS, IE10, … ) und die dementsprechenden Eigenschaften verwenden. Zudem sollte man auf die Flexbugs-Liste ein Auge werfen, ob nicht ein Browser doch noch ein Bug mitliefert.

Für die Generierung des alten Flexbox-Syntax mit Browser-Prefix empfehle ich Autoprefixer. Wer Sass verwendet, aber kein Autoprefixer, dem sei das Flexbox Mixin ans Herz gelegt. Besser wäre aber Autoprefixer in seinen Workflow zu integrieren.

Happy Retrofitting!

Der Beitrag Content Source Order in RWD erschien zuerst auf maddesigns.

Die alte Eigenschaft clip gibt es zwar schon länger in CSS, wurde jetzt aber überarbeitet spezifiziert. Der aktuelle Einsatz von clip ist sicherlich ein anderer als ursprünglich angedacht. Meist nutzen Webworker clip für barrierefreies Verstecken von Elementen wie <input type="radio" /> um ein Custom-Design zu integrieren und gleichzeitig die Browser-Funktionen zu erhalten. Die HTML-Boilerplate nutzt dies in der .visuallyhidden Definition. Ein Beispiel: http://codepen.io/maddesigns/pen/jbiDn

Die alte Clip-Eigenschaft:

.clip-me {
  /* old:  absolute or fixed positioning required */
  position: absolute;  
  /* deprecated version */
  clip: rect(110px, 160px, 170px, 60px);
  /* reset/default on deprecated version */
  clip: auto;
}

Diese neuen hilfreiche Funktionen sind nun hinzu gekommen:

.clip-me {
  /* reset/default on current version */
  clip-path: none;
  /* current version */
  clip-path: rect(110px, 160px, 170px, 60px);
  /* rounded rectangle */
  clip-path: inset(10% 10% 10% 10% round 20%, 20%);
  /* circle */
  clip-path: circle(30px at 35px 35px);
  /* ellipse */
  clip-path: ellipse(65px 30px at 125px 40px);
  /* polygon */
  clip-path: polygon(0% 0%, 100% 50%, 0% 100%, 0% 0%);
}

Beispiel:

See the Pen Simple CSS Shapes demo by Sven Wolfermann (@maddesigns) on CodePen.

Zudem können auch die bereits vorhandenen Formenausmaße als Clip-Path verwendet werden.

clip-path: fill-box | stroke-box | view-box

clip-path: url() – SVG-Vorlage mit <clipPath>

Neben den einfachen Clip-Formen kann man auch umfangreiche Clip-Pfade, die in SVG definiert sind, verwenden. So können auch Bézierkurven verwendet werden, ganze Formen-Gruppen (<rect>, <circle>, <path> etc.) oder auch Texte.

SVG clipPath MDN-Referenz

Diese definierten Formen können im Anschluss in CSS als URL referenziert werden.

.element {

  /* referencing path from (inline SVG) <clipPath> */
  clip-path: url(#clipPath);

  /* referencing path from external SVG */
  clip-path: url(img/path.svg#clipPath);

}

Beispiel:

See the Pen CSS Shapes & responsive clipPath SVG image by Sven Wolfermann (@maddesigns) on CodePen.

Wenn sich die beschnittenen HTML-Elemente responsive verhalten sollen, muss man auf das in SVG angewendete Koordinatensystem acht geben. Gewöhnlicher Weise wird hier mit absoluten Pixelwerten gearbeitet, so dass sich Schnittmaske nicht mit skaliert. Durch clipPathUnits="objectBoundingBox" wird das Koordinatensystem so umgestellt, dass es sich relative zur viewBox verhält. Es ist also ratsam das Bild über <image> in SVG zu definieren und das komplette SVG inline in HTML zu integrieren.

SVG mit Text

Wie schon kurz erwähnt kann auch Text in SVG als Pfad- bzw. Beschnittform dienen. Über CSS @font-face ist es dann natürlich auch möglich den gewünschte Webfont nutzen. Die Positionierung kann manchmal etwas hakelig sein.

Beispiel:

See the Pen SVG clipPath text by Sven Wolfermann (@maddesigns) on CodePen.

Animated clip-path

Die Beschnittpfade können auch animiert sein, bzw. auf Mouse-Aktionen Transitions durchführen. Wichtig ist dabei, dass die Knotenanzahl des Pfades gleich bleibt, sonst funktioniert die Animation nicht. Es ist also nicht möglich von einem Stern-Polygon zu einem Viereck zu animieren, die Knoten müssen alle erhalten bleiben und dementsprechend positioniert werden, dann geht’s.

img {
    clip-path: polygon(0% 0%, 100% 50%, 0% 100%, 0% 0%);
    transition: clip-path 0.3s 0.1s;

    &:hover {
        clip-path: polygon(0% 0%, 100% 0%, 0% 100%, 0% 0%);
    }
}

Eine Animation kann auch direkt in SVG definiert sein. Es gibt aber teilweise große Performance-Unterschiede in den verschiedenen Browsern, also vorsichtig damit experimentieren.

• http://www.pencilscoop.com/demos/animating-svg-clipping-masks/
• http://codepen.io/maddesigns/pen/xvipD

Tools

Um clip-path zu experimentieren, hat Bennett Feely ein tolles Online-Tool entwickelt. Dort sind mehrere Formen bereits vordefiniert. Die Veränderung der Formen und die Auswirkung auf den CSS-Code ist schön umgesetzt. Ein weiteres Tool stammt von Alex Bylim – der Clip-Path-Generator.

• http://bennettfeely.com/clippy/
• http://cssplant.com/clip-path-generator

Wie für CSS-Shapes, kann man auch für clip-path die Chrome-Browser-Erweiterung nutzen, um in den Dev-Tools Formen hinzuzufügen oder zu verändern.

Browser-Support

Der Browser-Support sieht grundsätzlich, mit Abstrichen, ganz gut aus. Aber der aktuelle Standard ist noch nicht in allen Browsern verfügbar. Chrome/Opera und Safari unterstützen die erwähnten Form-Funktionen in clip-path, allerdings mit -webkit-Präfix. Firefox unterstützt die Form-Funktionen leider noch nicht, aber die Variante mit url(#clipPath). Der Internet-Explorer unterstützt leider gar nichts davon. Hier müsste man das zu beschneidende Element (z.B. Bild) direkt in SVG einbinden, darauf anwenden und diesen SVG-Code inline ins HTML einfügen (Beipiel: http://codepen.io/maddesigns/pen/kbqzu). Dann funktioniert es auch dort.

Der komplette Browser-Support:

Empfohlene Blog Posts:

• http://sarasoueidan.com/blog/css-svg-clipping/
• http://blogs.adobe.com/webplatform/2014/01/16/making-the-web-sweeter/

Das Schöne ist, das clip-path auf alle möglichen Elemente angewandt werden kann, z.B. auch Videos oder Textblöcke, nicht nur Bilder. Zudem sind die Beschnittpfade animierbar und können dynamisch über JavaScript generiert werden. Mit den zusätzlichen Möglichkeiten von SVG, bleibt kaum ein Wunsch an Gestaltungsmöglichkeiten offen. Wenn jetzt nur noch der Browser-Support insgesamt besser würde…

Bonus: Mask

Eine ähnliche Eigenschaft wie clip-path ist mask, was ebenfalls aus der SVG-Spezifikation her rührt. Neu ist die CSS-Eigenschaft ja eigentlich nicht, Safari (WebKit) hat mask bereits 2008 in einem Blog-Post beschrieben und Christian @derSchepp Schaefer beschrieb in seinem Blog-Post wie man die mask-Eigenschaft auch in alten IEs umsetzen kann. mask kann man (halb-)transparente URLs zuweisen, wie bei shape-outside. Im Unterschied zu clip-path kann <mask> auch halbtransparente Flächen beinhalten und somit das zu maskierende Element auch nur halbtransparent „beschneiden“.

• http://www.html5rocks.com/en/tutorials/masking/adobe/
• http://collidercreative.com/how-to-create-css-image-masks-for-the-web-with-svgs/

Einen Maske kann direkt in SVG definiert werden und dort natürlich alle Möglichkeiten nutzen. Unter Anderem könnte man auch Text als Maske benutzen, hier ein Beispiel:

Beispiel:

See the Pen SVG text mask by Sven Wolfermann (@maddesigns) on CodePen.

Allerdings ist hier der Browser-Support nicht ganz so einfach zu lesen http://caniuse.com/#feat=css-mask da hier verschiedene Stufen der Spezifikation integriert sind.

Der Beitrag CSS clip-path erschien zuerst auf maddesigns.

Nachdem wir mit CSS3 schon die Möglichkeit bekommen haben, die Ecken einer Box optisch abzurunden, bleibt natürlich eines offen – der Text bricht nach wie vor an der „geraden” Box-/Bildkante um, dass heißt er orientiert sich z.B. nicht an der Kante von border-radius, erst recht nicht am Inhalt des Bilds. Die eigentliche Box bleibt viereckig. Das ändert CSS-Shapes.

Mit der neuen Eigenschaft shape-outside, die auf Initiative von Adobe als W3C-Standard etabliert wurde, können nun geometrische Formen zu einer Box hinzugefügt werden, so dass sich der Textfluß an den Formen orientiert. Diese Formen (Shapes) können mit folgenden Funktionen generiert werden:

• circle() – Kreis
• ellipse() – Ellipse (ovale Kreisform)
• inset() – orientiert sich an der Box
• polygon() – eigene Form mit mehreren Knotenpunkten

einfaches Beispiel Kaffeetasse – circle()

img.coffeecup {
    float: right;
    width: 33%;
    shape-outside: circle(50%);
}

Beispiel-Grafik:

Noch einfacher – der Textfluss kann sich auch am Border-Box-Model orientieren, also z.B. falls dem Element border-radius zugewiesen ist.

shape-outside: margin-box | border-box | padding-box | content-box;

Shape: polygon()

Mit polygon() kann man ein Form mit mehreren Knotenpunkten erstellen – allerdings keine Beziér-Kurven-Formen, sondern nur gerade Linien zwischen den Knotenpunkten. Aber klar… umso mehr Punkte, umso mehr könnte man eine Kreisform abbilden.

einfaches Beispiel: Dreckeckform

.triangle {
    shape-outside: polygon(0 0, 100% 50%, 0% 100%);
}

(Hier im Beispiel sind nur 3 Werte angegeben, polygon() braucht normal min. 4 Werte um die Form zu schließen, allerdings wird die Form immer zum Ausgangspunkt hin automatisch geschlossen. Deshalb funktioniert das Beispiel mit dem Pfeil trotzdem wie erwartet.)

Shape aus Bildvorlage – url()

Zudem kann aber auch ein URL-Asset, als Shape-Vorlage verwendet werden.

Das wird dann wie folgt eingebunden:

img {
    float: right;
    shape-outside: url(path/to/image-with-shape.png);
}

Klassisches Anwendungsbeispiel ist eine Vorlage wie diese:

Ein Bild mit „transparenten” Flächen (bzw. der gleichen Hintergrundfarbe wie der Background). Hier wäre es doch praktisch, wenn der Text sich optimaler Weise an der „transparenten” Kante orientieren könnte.

HTML

<section class="intro">
    <h2>headline</h2>
    <img src="img/iphone6.jpg" height="450" width="600" alt="new iPhone 6">
    <p>Lorem</p>
    <p>Lorem</p>
    <ul>
        <li>Lorem ipsum dolor sit amet.</li>
        <li>Eius enim unde esse alias aut.</li>
        <li>Aliquam mollitia itaque officiis ab blanditiis.</li>
    </ul>
</section>  

CSS

.intro img {
    float: right;
    shape-outside: url(img/iphone6.png);
}

Weitere Eigenschaften um den Fluss des Textes um das Shape-Bild zu verändern:

shape-image-threshold: 0.5;
shape-margin: 1em;

• shape-margin dürfte klar sein – Abstand vom transparenten Bildkante nach außen.
• shape-image-threshold – Schwellenwert ab wann ein halbtransparenter Pixel als Shapes-Kante gilt. Ein Wert von 0.5 bedeutet, dass der Shape-Kantenverlauf an Pixeln mit mehr als 50% Deckung verläuft.

CSS-Shapes Demo

Codepen Live-Demo

See the Pen CSS Shapes url() by Sven Wolfermann (@maddesigns) on CodePen.

Shape-Masken Bild aus Photoshop-Vorlage erstellen

Recht einfach ist es, wenn man bereits eine freigestellte Grafik hat – z.B. in Photoshop auf einer transparenten Ebene. Beim Exportieren die Grafik reduziert man das Bild auf zwei (2) Farben und lässt Transparenz aktiviert. Fertig.

Unterstützte Bildformate für shape-outside: url()

• grundsätzlich wird jedes Format unterstützt
• bei animierten Bilder wird laut Spezifikation der erste Frame verwendet, funktioniert aber aktuell mit alles Frames
• Data URIs geht ebenfalls
• die Bilder müssen den gleichen Ursprung haben (same origin) oder die Nutzung muss durch CORS zugelassen werden hatte ich Probleme bei Codepen-Beispielen
• generierte Verläufe funktionieren ebenfalls, sowohl linear-gradient als auch radial-gradient
• in Zukunft noch mehr, wenn die CSS image Werte erweitert werden

Shape-Form mit Chrome-Devtools-Erweiterung erstellen

Die Chrome-Erweiterung CSS-Shapes-Editor ermöglicht es in den Chrome-Developer-Tools einem Element eine Shape-Form hinzuzufügen.

Probleme:

• CSS-Shapes ist eine Technik, die sich schwerlich in ein CMS integrieren lässt, wie ich finde. Nicht dass es nicht möglich ist, aber es verlangt den Redakteuren ein erhöhtes Mehrwissen ab. Ich sehe den Einsatz eher auf speziellen (statischen) Seiten. Sicherlich ist es möglich ein Tool zu bauen um Polygone zu editieren bzw. zu erstellen, lieber würde ich aber ein schönes Admin-Tool für Responsive Art-Direction Images sehen. Zudem muss dynamisches CSS generiert werden, bzw. Inline-Styles, was natürlich nicht das optimalste ist.
• Aktuell können CSS-Shapes nur auf Elemente, die floaten angewandt werden, nicht aber auf Hintergrundbilder. Bedeutet also, die müssen, auch wenn es nur dekorierende Bilder sein sollten, ins Markup eingebunden werden. Wenn zudem ein Shape-Bild verwendet wird, dann werden zwei Bilder geladen. Hier sollte man auf die Performance acht geben, dass nicht zu viele Daten geladen werden. Das zusätzliche Shape-Bild ist sicherlich recht klein, aber der zusätzliche Request ist natürlich unschön. Es könnte auch ein und dasselbe transparente PNG24 für die Darstellung und die Form verwendet werden, aber hierbei wird das Bild leider trotzdem 2x geladen (quasi 1x von HTML & 1x von CSS).

Linktipp: wer bei transparenten PNG-Bilder die Datenmenge reduzieren will – und das sollte jeder tun – dem sei pngmini.com oder tinypng.com ans Herz gelegt.

Shapes circle() & url() Beispiel

Browser-Support:

Aktuell unterstützen diese Technik

• Chrome 37 (Opera 24)
• Safari 8 mit -webkit-prefix

Der Fallback ist das was man bereits kennt, also im Moment ist das Feature ein Enhancement. Es gibt zwar ein Polyfill, den würde ich aber nicht einsetzen, wenn es sich nicht vermeiden lässt, denn der Polyfill generiert in nicht unterstützten Browsers massig zusätzlichen Code, dass geht natürlich zu Lasten der Scroll-Performance.

Adobe Blogartikel über den CSS Shapes Polyfill

Man kann dieses Feature natürlich auch mit der nativen CSS-Methode @supports einbinden.

@supports feature query

@supports (shape-outside: circle(50%)){
  /* styles only for browsers which support CSS Shapes */
  .element {
    shape-outside: circle(50%);
  }
}

Beispiel:

See the Pen Responsive CSS Shapes Google Map by Sven Wolfermann (@maddesigns) on CodePen.

Ärgerlich ist, dass Safari @supports nicht unterstützt, so dass hier shape-outside nicht angezeigt würde obwohl Safari die Eigenschaft ja unterstützt. Also doch wieder Modernizr Feature-Detection.

shape-inside()

Die Eigenschaft shape-inside(), die in manchen Tutorials genannt wurde, wird es zunächst erstmal nicht geben. Mit shape-inside soll es möglich sein, die eigene Form einer (Text-)Box zu manipulieren. Das ist dann praktisch, wenn man background-image auf einer Box verwendet. Das ist allerdings nicht ganz trivial in Browser zu integrieren, da auch Eigenschaften wie position: absolute, flexbox & Co. berücksichtigt werden müssten, was nicht so trivial ist.

Codepen-Collection

Auf codepen.io habe ich unterschiedlichste Beispiele zusammengestellt. Einige ganz simple, andere mit Fallback für nicht unterstützte Browser.

Weitere Informationen / Blog-Posts

• CSS Shapes 101
• Creating Non-Rectangular Layouts With CSS Shapes
• CSS Shapes: Breaking the Rectangular Design Shackles
• CSS3-Shapes: Diese Möglichkeiten eröffnen sich mit dem neuen CSS-Moduls

Habt ihr schöne Anwendungsbeispiele für CSS-Shapes? Lass es mich wissen.

Der Beitrag CSS Shapes - neue Formen braucht das Web erschien zuerst auf maddesigns.

Wenn wir mit bestehenden Inhalten planen müssen, kommt es oft vor, dass wir Daten-Tabellen responsive darstellen sollen. Diese Tabellen sind naturgemäß meist sehr schwierig auf kleinen Bildschirmen abzubilden, viele Tabellen sind sehr groß und enthalten viele Daten. Das rührt daher, dass Redakteure (bzw. diejenigen, die für den Inhalt verantwortlich sind) versuchen über Excel-Tabellen komplexe Daten abzubilden und die Daten so ins Web übernommen werden (sollen). In der Vergangenheit war der Platz auf großen Bildschirmen vorhanden, im Multi-Screen-Zeitalter und in einer responsiven Website heutzutage, meist nicht mehr.

Meine erste Regel wenn Tabellen „responsive“ abgebildet werden sollen, prüfen ob man den Inhalt nicht auch anders ausgezeichnet werden kann, bzw. flexiblere HTML-Elemente für die Abbildung verwendet werden können. So haben wir in einem Projekt eine Suchergebniss-Ausgabe von einer Tabellenansicht in eine Listenansicht (UL) umgewandelt.

Ein schlechtes Beispiel, wie ich finde, ist die Verwendung von DIV-Containern wie im Artikel „Responsive and SEO friendly data tables“ beschrieben. Tabellendaten haben (wenn richtig verwendet) auch eine semantische Zuordnung untereinander. Über Tabellenkopf (thead, th) und Tabellenzellen (tbody, td), optimalerweise auch über scope-Attribute können die Zusammenhänge im Markup ausgezeichnet werden. Das kann man nicht mit unsematischen DIV-Container nachbilden (es sein denn man nutzt zusätzlich WAI-Aria Attribute, aber lassen wir mal die Kirche im Dorf).

Besser geeignet für diesen Zweck sind semantische Elemente wie eine Description List (DL). Ein <dl>-Element ist dann im übertragenem Sinne ein <tr>, ein <dt> ist ein <th> und ein <dd> das Äquivalent zu <td>. Somit haben die Inhalte auch eine semantische Bedeutung zueinander. Das ist zwar auch von hinten durch die Brust ins Auge, aber besser als DIVs.

Ein Beispiel:

<div class="tabled-view">
  <dl>
    <dt>Beschreibung:</dt>
    <dd>Lorem ipsum is evil!</dd>
  </dl>
</div>

Altlasten

Für den Fall, dass man das Markup nicht verändern kann, muss man sich anderer Tricks behelfen. Eine Möglichkeit wäre das „Responsive Tables“ jQuery-Plugin von Zurb (die Macher von Foundation). Das Plugin klont die Tabelle, überlagert beide Tabellen und blendet einerseits die Tabellenzellen, andererseits die Tabellenköpfe aus. Zudem macht das Script den Zellenbereich horizontal scrollbar. Der ein oder andere kennt das vielleicht von Excel, dort kann man ebenfalls einen Bereich festsetzen und den Rest der Zeilen scrollen.

CSS und JavaScript in den HEAD einfügen:

<link rel="stylesheet" href="responsive-tables.css" />
<script src="responsive-tables.js"></script>

Die Klasse „responsive” zur Tabelle hinzufügen, fertig.

<table class="responsive">
  <tr> … </tr>
</table>

Nachteil: es ist nur ein fester Breakpoint im JavaScript gesetzt. Das könnte im Fall der Tabelle auch ausreichen, aber man weiß ja nie… Ich habe zudem noch -webkit-overflow-scrolling: touch hinzugefügt für ein flüssigeres Momentum-Scrollen in WebKit-Browsern.

div.table-wrapper div.scrollable { 
  overflow: scroll; 
  overflow-y: hidden;  
  -webkit-overflow-scrolling: touch; 
}

Weitere Plugins:

• FooTable
• Filament Table Saw

CSS-only Lösung

Eine weitere Möglichkeit, die ich bereits in Projekten verwendet habe, beschreibt Chris Coyier im Artikel „Responsive Data Tables“. Hierbei werden alle Tabellen-Zellen in Blockelemente umgewandelt und mit Pseudo-Elementen versehen, die wiederum die Zeilenbeschreibungen als content Wert mitbringen. Das funktioniert sehr gut, ist aber nicht so flexibel, da fest in CSS geschrieben.

/* Label the data */
  th:nth-of-type(1):before { content: "Name:"; }
  th:nth-of-type(2):before { content: "Vorname:"; }
  th:nth-of-type(3):before { content: "Straße:"; }
  th:nth-of-type(4):before { content: "PLZ:"; }
  th:nth-of-type(5):before { content: "Ort:"; }

Chris beschreibt weiter in seinem Blogpost, wie man die Variante mit HTML5 data-Attributen flexibel bekommt (Idee von @chriseppstein).

<th data-label="Name">Name</th>

th:before { content: attr(data-label); }

Beispiel: http://codepen.io/maddesigns/full/pHqnt

Browser-Support für diese Lösung

Der IE9, sowie alle älteren IEs mögen es nicht, wenn man Tabellen auf ‚display: block‘ setzt, es kann – muss nicht – zu Darstellungsfehlern kommen. Das sollte man bedenken.

Wichtig ist, dass man sich den Inhalt vorher genau anschaut und dann entscheidet, welche Responsive Tabellen Lösung die Beste ist, es kommt auf den Inhalt an.

There I said it: Content First!

Der Beitrag Responsive Tabellen erschien zuerst auf maddesigns.

Ich hatte mich auch gefreut, als ich ein SVG als Quelldatei sah, was dann geschah, glaubt ihr nicht… böses heftig.co – geh weg!

Das SVG-Logo ist als Background-SVG-Sprite eingebunden, welches mehrere Zustände hatte und wurde, wie man es von CSS-Sprites kennt, über background-position je Breakpoint verschoben.

Das ist nicht unbedingt das, was ich unter einem Responsive Logo verstehe, da man in SVG viel mehr Möglichkeiten hat. SVG ist eine Textdatei und besteht ebenfalls aus einzelnen Elementen oder Gruppen, vergleichbar mit einem HTML-Dokument, die ebenfalls mit CSS und JavaScript angesprochen werden können. Man könnte also die „Responsiveness” auch im SVG behandeln, was bei einem Logo Sinn ergeben würde. Media Queries sind auch hier möglich, so dass man Breakpoints festlegen und dementsprechend Logo-Teile sinnvoll ausblenden kann. Zu beachten ist, dass sich die angegebenen Werte (z.B. min-width/max-width) der Breakpoints auf die SVG-Ausmaße selbst beziehen, also nicht auf den Viewport der einbindenden Seite. Quasi so etwas wie Element Querys – ha!

Bei der Clown-Car-Technik für Responsive Images kommt die Media Query Technik zum Einsatz (Pssst: aber nicht verwenden, gibt jetzt einen offiziellen Standard – war ne wilde Zeit damals).

Ein fantastisches „Responsive Logo” Beispiel hat Andreas Bovens bereits 2009 veröffentlicht. So verstehe ich ein Responsive Logo.

Ein einfaches Beispiel wäre, eine Logo Textzeile auf kleinen Displays auszublenden.

Was auch denkbar ist, dass man für den Druckmodus – @media print – das Logo einfarbig (schwarz) gestaltet. Das funktioniert allerdings nur, wenn man das SVG-Logo direkt ins HTML einbindet und nicht über eine <img src=“*.svg“>.

Diese Technik, innerhalb von SVG je Breakpoint Veränderungen vorzunehmen, nutzen mittlerweile auch einige Icon-Libraries. Iconic wirbt damit und auf Smashing Magazine gab es Anfang des Jahres ein Tutorial dazu.

Es ist also einiges möglich in dem Bereich. Für Icons bevorzuge ich mittlerweile SVG-Sprites, da dies im Gegensatz zu Icon-Fonts viele Vorteile hat.

Der Beitrag Responsive SVG-Logos erschien zuerst auf maddesigns.

Iconfonts, also Schriften á la Dingbats, die anstatt Buchstaben und Ziffern Symbole haben, wurden bisher als ein adäquates Mittel für skalierbare Icons eingesetzt. Dass das auch immer mit Problemen behaftet ist, werden viele Webentwickler schon festgestellt haben.

Probleme Icon-Fonts:

• Fallback (-schrift)
• Zugänglichkeit
• Positionierung (line-height)
• Rendering
• Einfarbigkeit
• Ladezeit (werden später geladen)

Für einige der Probleme gibt es mittlerweile gute Anleitungen, um dies zu verhindern – oft denkt man sich aber, „das sind doch alles nur Hacks und nichts solides, das muss doch irgendwie einfacher gehen.”

SVG-Sprites

Wir wissen, SVG ist ein Vektor-Grafikformat, das dafür genau das Richtige ist. Eine Option ist natürlich das Icon-Sprite aus SVG-Grafiken zu erstellen und wie gewohnt über background-position anzuzeigen. Allerdings haben wir auch dann kaum Einfluss auf die Größendarstellung der Icons.

SVG-Inhalte können in modernen Browsern auch direkt in HTML integriert werden. Das hat dann den Vorteil, dass wir auf die SVG-Elemente mit CSS und JS zugreifen können und so Veränderung vornehmen könnten.

SVG bietet zudem die Möglichkeit auf ein einzelnes Element zu referenzieren, also einen Inhalt woanders darzustellen. Über <use xlink:href="" /> können die Inhalte an anderer Stelle ausgegeben werden. Das kann ein SVG-Block innerhalb der Seite sein, das kann aber auch eine externe SVG-Datei sein. Extern eingebundene Ressourcen haben natürlich den Vorteil des Browser-Caching.

internes SVG-Element referenzieren

<use xlink:href="#menu"></use>

externe SVG-Datei referenzieren

<use xlink:href="img/all.svg#menu"></use>

Chris Coyier hat dazu in letzter Zeit einiges auf css-tricks.com geschrieben:

• Inline SVG vs Icon Fonts
• SVG `use` with External Source
• SVG `symbol` a Good Choice for Icons

Vorteile SVG-Icons:

• Semantik
• barrierefrei(er)
• Mehrfarbig + Effekte
• bessere Positionierung
• mit CSS + SVG-CSS stylebar (win-win ;))

SVG Store – ein Grunt-Task für SVG-Sprites

Mit dem Grunt-Task „SVG-Store” hat man die Möglichkeit aus den einzelnen SVG-Dateien ein „SVG-Sprite” zu erstellen. In Wirklichkeit ist es ja kein richtiges Sprite wie wir es kennen, sondern eher ein Dokument, in dem hintereinander alle einzelnen SVG-Blöcke gepackt werden, die dann über eine ID referenziert werden können.

Installation grunt-svgstore:

npm install grunt-svgstore --save-dev

Grunt-Task:

svgstore: { 
  options: {}, 
  dist: { 
    files: { 
      'dist/img/all.svg': ['source/img/icons/*.svg'] 
    } 
  } 
}

Im Anschluss kann man noch zusätzlich SVGmin zur Komprimierung drüber laufen lassen.

Alternativ sollte man sich auch ’Iconizr’ bzw. ’grunt-iconizr’ anschauen!

Einbindung in HTML und Styling mit CSS

Einbindung in HTML:

<svg class="icon-menu" role="img" title="Menu Icon" 
     viewbox="0 0 75 75" width="25" height="25"> 
  <use xlink:href="img/all.svg#menu"></use> 
</svg>

Hier wird auf ein eine SVG-Datei mit allen Icons referenziert und das Element mit der ID „menu” angezeigt. Das SVG-Snippet kann man nun über (SVG-)CSS-Eigenschaft fill einfärben.

.icon-menu { 
  fill: green; 
}
/* other context */
header .icon-menu {
    fill: pink;
}

In der Original SVG-Icon Datei kann man ebenfalls Klassen zum Styling vergeben.

… 
  <path class="original-svg-pin" … /> 
…

Auch das kann man dann über die fill Eigenschaft anders einfärben.

.original-svg-pin { 
  fill: blue; 
}

Andere SVG-Style-Eigenschaften wie stroke oder stroke-width sind natürlich auch möglich.

Chris Coyier beschreibt in seinem Blogpost „Cascading SVG fill color” die Möglichkeit mit currentColor, dazu hab ich aber folgendes Problem auf Stackoverflow gefunden: Geht nicht im iOS Safari, das Beispiel geht aber bei mir, hm…

Probleme & Tipps

• wird nicht von allen Browsern unterstützt (kein IE9-IE11 Support) – das ist aktuell das größte Problem
• Es ist nur eine fill-Farbe für alle Pfade (path, polygon, …) in dem verknüpften SVG-Snippet zuweisbar – über Selektoren möglich (werden allerdings nicht in den Developer-Tools angezeigt), sonst nur direkt über Klassen in der SVG-Datei
• der Attribut-Selektor [viewBox] {} geht nicht in WebKit-based Browsern (hat nix mit den SVG-Icons zu tun, ist aber trotzdem doof)
• SVGs werden onLoad auf die volle Bildschirmbreite gezogen, deshalb width="" + height="" wie bei Pixelgrafiken setzen, kann anschließend mit CSS überschrieben werden
• aufpassen bei backface-visibility & z-index –> SVG-Icons auf der gleichen Ebene werden nicht neu hochauflösend gerendert (und wirken also pixelig)

SVG4everybody

Die JS-Library SVG4everybody löst die fehlende Browser-Kompatibilität, so funktioniert die Technik nun auch im IE9-11. Mit ’SVG4everybody’ werden die SVG-Fragmente über Ajax direkt in die Seite geladen, das hat zudem den Vorteil, dass man die SVG-Inhalte besser stylen kann.

CSS styling with ’fill’

/* inherit the fill color from parent */ 
svg { 
  polygon, 
  path, 
  rect { 
    fill: inherit; 
  } 
}

Alle Icon-Pfade sollen die ’fill’-Farbe vom Elternelement erben.

/* fill all elements contains the class „icon” with ’red’ */ 
[class*="icon"] { 
  fill: red; 
}

Alle Icons werden mit ’icon’ benannt und bekommen alle die gleiche Einfärbung.

/* set individual color – cascade after [class*="icon"] */ 
.icon-menu { 
  fill: green; 
}

Individuelle Icons kann man noch individuell färben.

• Vergibt man wie im obigen Beispiel mehrere CSS-Klassen für die einzelnen Elemente der Originaldatei, dann ist es möglich SVG-Einzelteile einzeln zu stylen/zu färben.
• Problem, das mir aufgefallen ist: mehrere Requests – für jedes Bild wird je ein Request benötigt bzw. im Network-Panel angezeigt

Blurry Rendering in Firefox (Win)

Fabian Beiner hatte ein Problem mit dem Rendering von SVG im Firefox (Windows) festgestellt. Unter bestimmten Bedingungen wirken harte Kanten unscharf. Dieser Hinweis behebt das Problem:

Try styling your rects with shape-rendering: crisp-edges to remove antialiasing and force the lines to really be 1px. Also try offsetting the rects 1px (<rect x=“1″). The border can be cropped by the border of the svg.

SVG shape-rendering

SVG-Fallback für IE8 & Android 2.3

IE8 sowie Android-Browser der Version 2.x unterstützen kein SVG, hier müsste man, wenn man die Browser unterstützt, einen Fallback mit PNG-Grafiken einsetzen.

• SVG2PNG – Grunt-Task zum einfachen Umwandeln von SVG zu PNG
• SVG4everybody stellt einen Fallback für IE8 bereit.
• Problem: die PNG-Datei hat die originale SVG-fill-Farbe – wenn mit CSS die ’fill’-Color verändert wurde, wird das natürlich nicht erkannt und das icon wird nicht eingefärbt
• auch hier mehrere Requests (PNG-Sprite wäre besser, Aufwand/Nutzen ist aber vertretbar)

Icomoon

Der Online-Service Icomoon bietet seit einiger Zeit ebenfalls die Möglichkeit die gewählten Icons als SVG(-Sprite) herunterzuladen. Hier hat man nun alle Möglichkeiten, entweder Icon-Font generieren oder SVG-Icons herunterladen – oder beides. Toller Service!

Vorteil Icon-Fonts

„Aber irgendwas gutes müssen Iconfonts doch haben, oder?!” Ja:

• Browser-Support
• Hinting
• Subpixel Rendering

Wer noch nicht überzeugt ist, dass SVG-Icons die bessere Wahl ist, sollte sich den Blogpost Ten reasons we switched from an icon font to SVG von Ian Feather durchlesen.

Das Video von der Beyond Tellerrand Konferenz zum Thema „SVG Is For Everybody” von Chris Coyier ist jetzt online – solltet ihr euch unbedingt (nochmal) anschauen.

Codepen Beispiel:

See the Pen SVG use example by Sven Wolfermann (@maddesigns) on CodePen.

Wer jetzt noch tiefer in die Thematik einsteigen will, dem sei der Artikel Structuring, Grouping, and Referencing in SVG – The <g>, <use>, <defs> and <symbol> Elements von Sara Soueidan ans Herz gelegt.

Habt ihr noch weitere Tipps oder Probleme festgestellt?

Der Beitrag SVG Sprites vs. Icon-Fonts erschien zuerst auf maddesigns.

Ein kurzer Reminder:

Bisher können Webworker folgende Positionen für Container/Elemente einer Seite zuweisen.

• position: static (default)
• position: relative (relative position in document order)
• position: absolute (absolute position in relative context)
• position: fixed (fixed in viewport)

Die Idee ein Container/Element ab einer bestimmten Position „sticky“ zu setzen, also zuerst mitscrollen zu lassen und dann ab einer bestimmten Position zu fixieren, gibt es im Webdesign schon länger. Ich erinnere mich noch als @rem auf jqueryfordesigners.com die Umsetzung mit jQuery erklärt hat.

Seit einiger Zeit gibt es aber eine neue CSS3-Eigenschaft, die das Verhalten nativ im Browser integriert. Diese ist bereits im Safari 6.1 und neuer (mit -webkit-Prefix) aktiviert, funktioniert also auch im Safari Mobile. Chrome und Firefox (auch auf Android) haben die Eigenschaft aktuell hinter einem Flag integriert, Microsoft denkt drüber nach.

position: sticky in Chrome/Firefox aktivieren

im Chrome in der Adresszeile chrome://flags/#enable-experimental-web-platform-features eingeben und „Experimentelle Webplattformfunktionen” aktivieren

im Firefox in der Adresszeile about:config eingeben, layout.css.sticky.enabled suchen und auf true setzen.

Verwendung in CSS

.sticky {
  position: -webkit-sticky;
  position: sticky;
}

Modernizr Feature Detection

Mit Modernizr kann ich mit einem zusätzlich eingebundenem Test prüfen ob der Browser ‚position: sticky‘ unterstützt. Auf der http://modernizr.com/download/ ist die Option unter „Non-core detects”, hier den Haken setzen und ein Custom-Build erstellen.

Wer grunt-modernizr verwendet, gibt als Option den zusätzlichen Test mit tests: ['css-positionsticky'] in der Grunt-Config (gruntfile.js) an:

// Build modernizr
modernizr: {
  dist: {
    devFile: 'path/to/source/modernizr.js',
    outputFile: 'path/to/build/modernizr.min.js',
    files: {
      src: [
        'js/{,*/}*.js',
        'css/{,*/}*.scss',
        '!js/vendor/*'
      ]
    },
    uglify: true,
    parseFiles: true,
    tests: ['css-positionsticky']
  }
}

Dann kann anschließend die Eigenschaft mit Javascript abgefragt werden:

Modernizr.csspositionsticky; // true or false

Fallbacks und Polyfills

Ich tendiere ja immer dazu ein visuelles Verhalten nur für Browser zu aktivieren, die das bereits vollständig nativ unterstützen. Besonders bei Responsive Webdesign lässt sich ein Fallback zu position: fixed schwieriger integrieren, da die dynamischen Positionen von Javascript immer neu berechnet werden müssten, das kann sich natürlich negativ auf die Performance auswirken.

Der mögliche Fallback sollte also immer getestet werden.

Aktuell empfehle ich die sticky Eigenschaften nur mit zusätzlicher (Detection-) Klasse zu nutzen. Die Position (top/bottom) also nur zusammen mit sticky setzen.

Beispiel

.sticky {
  position: static;
}
.csspositionsticky .sticky {
  position: sticky;
  top: 20em;
}

Polyfill:

Die Filamentgroup hat einen Polyfill für position: sticky veröffentlicht, der das Verhalten auch für Browser implementiert, die die Eigenschaft nicht unterstützen.

Den Polyfill bei Bedarf nachladen kann man über Modernizr.load

Modernizr.load({
  test: Modernizr.csspositionsticky,
  nope: 'fixedsticky.js'
});

Hinweis: in Modernizr 3.0 soll Modernizr.load (das unter der Haube ja yepnope ist) wieder herausgelöst werden, dann also yepnope verwenden

Demo: Sticky Header

See the Pen position: sticky header by Sven Wolfermann (@maddesigns) on CodePen.

Ich hoffe, dass Chrome und Firefox die Eigenschaft bald frei schalten – fehlt nur noch der IE…

Der Beitrag CSS3 – position: sticky erschien zuerst auf maddesigns.

Das Problem: faux-bold

Das Problem ist nicht neu, 2012 schrieb Alan Stearns bei A List Apart den Artikel „Say No to Faux Bold“ und erst kürzlich Gerrit van Aaken im Artikel „Webfonts: Fette Fehlerquelle“.

Abhilfe soll die Eigenschaft ‚font-synthesis‚ schaffen:

.say-no-to-faux-bold {
  font-synthesis: none;
}

leider wird die Eigenschaft von keinem Browser unterstützt :(

@font-face Einbindung für moderne Browser

Um die Fehldarstellungen zu vermeiden, bindet man den Font wie folgt ein:

@font-face {
  font-family: Fontname; /* regular font */
  src: url("Fontname-Regular.woff") format("woff");
  font-weight: normal; font-style: normal; }

@font-face {
  font-family: Fontname; /* bold font */
  src: url("Fontname-Bold.woff") format("woff");
  font-weight: bold; font-style: normal; }

@font-face {
  font-family: Fontname; /* light font */
  src: url("Fontname-Light.woff") format("woff");
  font-weight: 300; font-style: normal; }

@font-face {
  font-family: Fontname; /* italic font */
  src: url("Fontname-Italic.woff") format("woff");
  font-weight: normal; font-style: italic; }

@font-face {
  font-family: Fontname; /* bolditalic font */
  src: url("Fontname-BoldItalic.woff") format("woff");
  font-weight: bold; font-style: italic; }

für Android zusätzlich TTF/OTF einbinden

@font-face {
  font-family: Fontname; /* regular font */
  src: url("path/Fontname-Regular.ttf") format("truetype"),
       url("path/Fontname-Regular.woff") format("woff");
  font-weight: normal;
  font-style:  normal; }

Zuweisung in Überschrift:

h1 {
  font-family: Fontname, sans-serif;
}

@font-face für Old-IE (IE8)

Für die älteren Internet Explorer, die das WOFF-Format nicht unterstützen, kann man die Schrift im EOT-Format einbinden. Hier denke ich auch immer an die Performance und an das Rendering der Schriften und empfehle meist, für die Browser keine Webfonts zu verwenden. Zudem sollte man die Zugriffsstatistik für die Versionen prüfen, bevor man sich die Mühe macht. Zugegeben bisher wollten noch nicht sehr viele Kunden der Empfehlung, die Schriften für IE8 weg zu lassen, folgen. ;)

Für IE8 muss die Schriften wie folgt eingebunden werden:

/* ie-specific.css */
@font-face {
  font-family: Fontname-regular; /* regular IE font */
  src: url("Fontname-Regular.eot"); }

@font-face { /* bold IE font */
  font-family: Fontname-bold;
  src: url("Fontname-Bold.eot"); }

@font-face { /* italic IE font */
  font-family: Fontname-italic;
  src: url("Fontname-Italic.eot"); }

@font-face { /* bold italic IE font */
  font-family: Fontname-bolditalic;
  src: url("Fontname-BoldItalic.eot"); }

über Conditional Comments in die Seite einbinden

<!--[if lt IE 9]>
  <link rel="stylesheet" href="ie-specific.css" media="screen" />
<![endif]-->

Font-Loading Performance

Text der mit Webfonts ausgezeichnet ist, wird in einigen Browsern solange nicht angezeigt, bis die Schrift heruntergeladen ist, um den „FOUT“ (flash of unstyled text) zu vermeiden. Besonders nachteilig ist dieses Verhalten in mobilen Browsern, z.B. Mobile Safari (iOS), da das Laden im Mobilnetz häufig langsamer ist (Stichwort Latenz). Hier wartet man oftmals lange bis man endlich den Text lesen kann. Besonders ärgerlich ist das meiner Meinung nach bei Schriften, die nicht großartig anders aussehen als vorhandene Systemschriften. (Typonazis werden mich jetzt steinigen)

Randnotiz: Moderne Browser laden Schriften erst, wenn sie im CSS zugewiesen sind. Bedeutet also man könnte mehrere Schriften über @font-face verknüpfen, das Laden der Schrift erfolgt erst, wenn im CSS die Zuweisung über font-family geschieht.

In Firefox für Android kann man Webfonts über about:config deaktivieren (geht auch beim Desktop Firefox)

gfx.downloadable_fonts.enabled = false

Auch die Zeit, wann ein Fallback-Font geladen wird, kann eingestellt werden, der Defaultwert ist aktuell 3000ms für die Anzeige des Fallback-Font.

gfx.downloadable_fonts.fallback_delay = 1000

Paul Irish hat für Chrome (Blink) letztens eine Umfrage unter den Entwicklern gestartet, wie das Browserverhalten beim Laden von Schriften sein sollte. Ilya Grigorik beschreibt auf Google+ wie die Ladeperformance in Chrome verbessert wurde und sich Chrome in Zukunft wie Firefox verhält.

Fonts base64 decodieren

Fonts sollten nicht mit base64 codiert in CSS eingebunden werden, da das das Stylesheet unnötig aufbläst und somit das Rendering der Seite verzögert.

Webfontloader – Webfonts asynchron laden

Webfontloader ist ein Open-Source-Script von Typekit, mit dem man die Schriften von Typekit, Google, Fontdeck, Fonts.com und weiteren Foundries asynchron laden kann. Zu dem kann man auch selbst gehostete Fonts über den Webfontloader laden.

Einbindung des Webfontloader

<script>
WebFontConfig = {
  typekit: { id: 'xxxxxx' }
};
(function() {
  var wf = document.createElement('script');
  wf.src = ('//ajax.googleapis.com/ajax/libs/webfont/1.4.7/webfont.js';
  wf.type = 'text/javascript';
  wf.async = 'true';
  var s = document.getElementsByTagName('script')[0];
  s.parentNode.insertBefore(wf, s);
})();
</script>

Font-Events

Bindet man das Script ein, stellt Webfontloader beim Aufruf Klassen für die erfolgten Font-Events bereit. Das Script meldet also, was der aktuelle Zustand des Ladevorgangs ist. Die Klassen werden wie bei Modernizr zum
<html> Class-Attribut hinzugefügt.

Klassen, die Webfontloader hinzufügt:

.wf-loading
.wf-active
.wf-inactive
.wf-<familyname>-<fvd>-loading
.wf-<familyname>-<fvd>-active
.wf-<familyname>-<fvd>-inactive

Verwendung im CSS:

h1, h2, h3 {
  font-family: sans-serif;
}

.wf-active h1, .wf-active h2, .wf-active h3 {
  font-family: "webfont", sans-serif;
}

Beispiel: Einbindung der „Source Sans Pro“ mit Webfontloader über GoogleFonts.com:

//= require webfonts.js

WebFont.load({
    google: { families: [ 'Source+Sans+Pro:400,300,600:latin' ] }
    // load Source Sans Pro: light, normal, bold, light italic, normal italic, bold italic : latin subset
    // google: { families: [ 'Source+Sans+Pro:400,300,700,700italic,400italic,300italic:latin' ] }
});

Wie sich vielleicht erahnen lässt, kann man in der Konfiguration mehrere Schriftschnitte, die man laden möchte, definieren.

• 400 == normal
• 700 == bold
• 300 == light
• 400italic == normal kursiv
• 500 == medium

Mit dem Zusatz :latin kann man den Zeichenumfang steuern, hier wären es alle lateinischen Schriftzeichen. Welche Schriftzeichen wirklich vorhanden sind, sollte man genau prüfen manchmal fehlen Schriftzeichen (skandinavische).

native HTML5 Font-Events

… gibt es noch nicht, sind aber bereits in einer ersten Version spezifiziert. Dafür gibt es aber bereits einen Polyfill: Polyfill für native Font-Events

lokale System-Fonts bevorzugen

Nicht immer muss ein Webfont geladen werden, in Mac OSX ist z.B. seit Mavericks ‚PT Sans‘ im System verfügbar, den Font extra zu laden wäre unnötig. Mit dem Keyword ‚local‘ werden Systemfonts bevorzugt.

@font-face {
  font-family: 'PT Sans';
  src: local('PT Sans'), local('PTSans-Regular'), url('fonts/ptsans-regular.woff') format('woff'),
       local('PT Sans'), local('PTSans-Regular'), url('fonts/ptsans-regular.ttf') format('truetype');
  font-weight: normal;
  font-style: normal;
}

Auch die in iOS7 hinzugekommene ‚Helvetica Neue Condensed Bold‘ kann über den Post-Script Namen verwendet werden.

@font-face { 
  font-family: Helvetica; 
  font-weight: bold; 
  src: local(HelveticaNeue-CondensedBold); 
}

Fallback-Font auf mobilen Geräten

Wenn man responsive Webseiten erstellt, sollte man sich bewusst sein, dass nicht alle Schriften, die verwendet werden sollen, auch auf dem Endgerät vorhanden ist. Android hat nur wenige Schriften vorinstalliert. Jordan Moore hat eine Übersichttabelle der Systemfonts auf mobilen Systemen bereit gestellt. Allerdings fehlt dort noch ein iOS7 Update. ;)

Auf Android sind weder Arial, noch Helvetica oder Times installiert, die Standard-Schrift ist Droid (Sans/Serif). Man sollte meinen, wenn man font-family: 'Times New Roman', Times, serif; angibt, dass Android dann auf den Serif Font zurück fällt. Anscheinend kann das Android ganz schön verwirren und führt zu Fehldarstellungen.

Als Fix, damit alle getesteten Androids den Fallback-Font anzeigen, musste ‚Droid Serif‘ explizit angegeben werden. (HT @closingtag)

font-family: 'Serif Webfont', 'Droid serif', 'Times New Roman', Times, serif;

Wer noch Ergänzungen hat, bitte einfach kommentieren.

Der Beitrag Webfonts *richtig* verwenden erschien zuerst auf maddesigns.

Das Bild responsive zu machen, ist nicht schwer:

img {
  max-width: 100%;
  height: auto;
}

Die Imagemap-Area mit der Klickfläche passt sich allerdings nicht an, also auch wenn das Bild verkleinert auf ein Smartphone-Bildschirm passt, ist die Klickfläche noch immer in der Ausgangsgröße.

Abhilfe schafft hier ein jQuery-Plugin von Matt Stow namens RWD-ImageMap , das die Klickflächen automatisch je Screen-Größe umrechnet. Die Einbindung ist einfach:

//= require "vendor/jquery.min.js"
//= require "vendor/jquery.rwdImageMaps.min.js"
$('img[usemap]').rwdImageMaps();

Soweit so gut. Problem ist allerdings, dass man die Klickflächen nur mit einer Maus (oder Stylus) erfahren (im Sinne von mouseover) kann. Auf einem Touchdisplay hat man keinerlei visuelle Hilfen (Mauszeiger wechselt). Man müsste auf gut Glück überall tappen um zu erfahren, ob ein Bild eine Imagemap ist, in der bestimmte Bereiche verlinkt sind. Das ist natürlich problematisch und sollte bei der Konzeption bereits bedacht werden. Ich würde grundsätzlich davon abraten eine Imagemap im klassischen Sinne zu verwenden.

Eine Idee von Dudley Storey beschreibt eine Umsetzung mithilfe von SVG. Hier sollte man beachten, dass SVG direkt im HTML eingebunden unter Android 2.3 oder im Opera Mini nicht funktioniert. Weiterhin bin ich der Meinung, dass man die Klickflächen in SVG einen Rand geben sollte (zumindest für touchfähige Geräte), damit man sie eher als solche wahrnimmt.

Responsive Imagemap mit Akkordion-Liste

In einem Projekt war eine responsive Imagemap allerdings Anforderung. Glücklicherweise waren die Klickflächen direkt im Bild farblich hinterlegt, so dass das den Eindruck einer Schaltfläche ergab. Der Tap auf eine visuelle Schaltfläche sollte den Beschreibungstext unterhalb der Imagemap einblenden.

Ein paar Zeilen jQuery blendet die Texte ein und wieder aus:

$('area').on('click', function(e) {
  e.preventDefault();
  var target = $(this).attr('href');
  var imagemapItems = $('.imagemap__item');
  imagemapItems.hide();
  $(target).show();
  $(target +' > h3').addClass('is-open');
});

Das CSS dazu (Desktopansicht):

@media screen and (min-width: 48em) {
  .imagemap__item {
    display: none;
  }
  .imagemap__item:target {
    display: block;
  }
  .imagemap__item:target > .imagemap__text {
    display: block;
  }
}

In der Smartphone-Ansicht bis maximal 600px (37.5em) sollte das Imagemap-Bild und die Überschriften der beschreibenden Texte angezeigt werden und als Akkordion dargestellt werden. Die Imagemap-Funktionalität sollte verhindert werden. Einerseits weil die Schaltflächen zu klein werden, andererseits weil der User nicht unbedingt eine Imagemap auf einem Touch-Device erwartet.

Außerdem ist es problematisch, dass man die ImageMap-Klickflächen nicht mit CSS stylen kann. Man kann sie weder Off-Canvas positionieren, noch mit display: none; ausblenden. Einzige Möglichkeit, das ImageMap-Markup mit JavaScript löschen.

// remove ImageMaps Markup
var imageMaps = document.querySelectorAll(".m-imagemap map");
[].forEach.call( imageMaps, function(el) {
    el.parentNode.removeChild(el);
});

Wie man in dem Beispiel sehen kann, werden hier Standard HTML5 Javascript Funktionen und nicht jQuery verwendet. In dem Projekt wurde sehr auf Performance geachtet. So wurde erst ab dem Bereich "Tablet" jQuery hinzu geladen. Smartphones mit HTML5-Unterstützung können anhand von CSS-Selektoren sowohl eine Auswahl generieren document.querySelectorAll, als auch Klassen im DOM toggle’n classList.toggle().

Eine einfache HTML5 class-toggle-Funktion mit Vanilla-JS:

// select all H3 headers in .imagemap__item
var imageMapList =  document.querySelectorAll('.imagemap__item h3');

// on click handler to toggle .imagemap__text visibility
[].forEach.call(imageMapList, function(el) {
   el.addEventListener('click', function() {
     this.classList.toggle('is-open');
  }, false);
});

CSS:

.js .imagemap__text {
  display: none;
}
.imagemap__item .is-open + .imagemap__text {
  display: block;
}

Für Android 2.3 muss man allerdings einen classList-Polyfill einbinden um die toggle Funktion zu nutzen (classList.toggle wird erst ab Android 4 unterstützt). Mit Modernizr testet man ob der Viewport maximal 600px breit ist und ob classList nicht unterstützt wird. Wenn der Test true ergibt, wird die Polyfill-Datei (classList.min.js) geladen.

Modernizr.load([{
  test: Modernizr.mq("only screen and (max-width: 600px)") && !Modernizr.classlist,
  yep: "./js/classList.min.js";
}]);

Ich hab mal versucht ein reduziertes Beispiel aus dem Projekt heraus zu eisen und separat zusammen zu bauen: Demo Responsive Image Map

Wie gesagt, technisch alles machbar, aber manchmal ist es besser die Inhalte konzeptionell zu ändern. Das bedingt aber einen anderen Prozess. Aber das ist ein anderes Thema…

Der Beitrag Responsive Imagemap erschien zuerst auf maddesigns.

Mit CSS kann man die im HTML festgelegten Breiten überschreiben und die Bilder so flexibel machen.

Responsive Images basics:

img {
  max-width: 100%;
  height: auto;
}

Das Bild passt sich somit immer dem Container an, wird aber nie größer als seine eigentliche Originalgröße in Pixel. Das dürfe sicherlich bekannt sein. Wenn das nicht funktioniert, liegt ein anderer „Fehler“ vor, wie ein anderer BFC durch ‚float‘ oder ähnliches.

Aber gehen wir mal zurück, auf das Problem der fehlenden ‚width‘ und ‚height‘ Attribute. Angenommen, dass Bild soll links im Text floaten. Wenn die Breiten- und Höhenattribute fehlen wird der Platz für das Bild im Layout nicht vorgehalten und der Text läuft über die gesamte Breite. Ist das Bild dann vollständig geladen, springt der Text und fließt um das Bild. Das kann je nachdem wie viele Bilder man lädt und was für ein Layout man hat, sehr hin-und-her springen. Der Browser führt jeweils einen Reflow durch.

Zugegeben, wenn wir von Responsive Images reden, ist das mit der Angabe von ‚width‘- und ‚height‘-Attributen im HTML-Quellcode schon fast wieder hinfällig. Durch die Angabe max-width: 100%; height: auto; muss der Browser die anzuzeigende Größe so oder so berechnen und das erzwingt dann den Reflow.

Hochauflösende Bilder / Retina

Bei der klassischen Einbindung von Bildern für hochauflösende Displays, aka Retina, geht man davon aus, dass man ein Bild in doppelter Größe einbindet. Bei der heutigen Varianz der Displaygrößen und Pixel-Ratios ist das um einiges komplizierter geworden, aber das ist noch mal ein anderes Thema…

Gehen wir mal von der doppelten Bildgröße und folgendem Beispiel aus:

<p>
  <img src="images2x.jpg" alt="">
  lorem ipsum
</p>

Angenommen das Bild hat in einfacher Auflösung eine Größe von 400x300px, das Retina-Bild ist dementsprechend 800px breit. Ohne weitere Angaben würde das Bild im obigen Beispiel auf größeren Bildschirmen 800px breit angezeigt werden, bzw. so breit wie der Container ist. Initial wollten wir aber dass das Bild maximal 400px breit ist.

Mit einer Breiten-Angabe width="400" im HTML wäre unser Retina-Bild auch nur max 400px breit und nicht größer.

<p>
  <img src="images2x.jpg" width="400" height="300" alt="">
  lorem ipsum
</p>

Demo: http://codepen.io/maddesigns/full/bFwnK

An dieser Stelle möchte ich nicht auf Responsive Images (Adaptive Images) eingehen, also für die richtige Bildgröße für die passende Displaybreite an zu geben.

Slides zum Thema „Responsive Images“

Lazy-Loading

Um nicht sofort alle Bilder zu laden, die nicht im Sichtbereich der Seite sind, gibt es schon seit Jahren eine Methode die man „Lazy Loading“ nennt. Alter Hut… Mit statischem Layout hatte man da kaum Probleme, mit flexiblem Layout schon. Einen faden Beigeschmack hat das allerdings, wenn Browser die Bilder ondemand laden. Man umgeht damit den Preparser des Browsers, der schon Vorarbeit beim Aufruf der Seite leistet. Das Hinzufügen von DOM-Elementen durch das Lazy Loading ist „teuer“. Das merkt man besonders bei schwächeren mobilen Endgeräten. Das Bilder sofort laden ist in dem Sinne auch problematisch, da das die gesamte Ladezeit der Seite erhöht, Stichwörter: Requests und Latenzen. Ein Abwägen und Testen der Möglichkeiten ist immer notwendig, wobei ich grundsätzlich zu Lazy Loading tendiere, wenn der Scope hauptsächlich moderne Smartphones/Tablets ist.

Eine schmale Lazy-Loading-Lösungen mit JS

Unveil.js ist ein kleines jQuery-/Zepto-Plugin, dass wahlweise auch Retina-Bilder laden kann.

<img src="img/loader.gif" data-src="img2.jpg" data-src-retina="img2-retina.jpg" />

Lazy Loading wird W3C Standard

Solch ein Verhalten soll in Zukunft eigenständig und optimiert vom Browser selbst durchgeführt werden. Durch ein Attribut soll das Laden einer Resource verzögert werden. Microsoft hat dies bereits im IE11 umgesetzt. Ein Beispiel:

<img src="example.jpg" lazyload="1" />

Ich wiederhole das nochmal – Microsoft hat ein natives „Lazy Loading“ im Internet Explorer 11 bereits integriert. Fantastisch, oder?

Allerdings ist das nicht ganz 1:1 von der Idee der JavaScript-Bibliotheken übernommen. „Lazyload“ bedeutet in dem Fall, der Browser lädt die Resource, das können z.B. auch <script> oder <video> Elemente sein, verzögert, also erst nachdem andere Resource geladen sind, auch wenn sie vorher im Dokument sind.

Das Verhalten „Bild wird erst geladen, wenn es im Sichtbereich ist“ soll nach der Resource-Priorities-Spezifikation mit dem Attribut postpone möglich sein. Einen Polyfill für postpone gibt es bereits.

Mit der aktuellen Lazy-Loading-Methode im Responsive Webdesign hat man weiterhin das Problem, dass beim Einsetzen der Bilder ein Reflow der Seite durchgeführt wird und der Text springt. Reminder: „teuer“.

padding-bottom Trick

Wenn man mit Bildern arbeitet, die ein gleichbleibendes Seitenverhältnis haben, z.B. 16:9 oder 4:3, dann kann man den benötigten Platz bereits vorhalten, so dass Text, der um das Bild fließen würde, bereits richtig positioniert ist und nicht springt wenn das Bild lädt.

Der Container, der die Bilder beinhaltet, benötigt folgende CSS-Regeln:

.parent {
  display: block; /* if inline element */
  position: relative;
  height: 0;
}

Die richtige Container-Höhe wird anhand des festen Seitenverhältnis berechnet.

Einfacher Dreisatz: 9 × 100% ∕ 16

Dieser errechnete Wert, ist der Wert, der die Box nun durch padding-bottom visuell vergrößert. Das Bild innerhalb des Containers wird absolut positioniert und mit width: 100% sowie height: 100% auf die komplette Größe der Containerbox aufgespannt. Stimmt das Seitenverhältnis nicht, erkennt man das am verzerrten Bild.

.parent {
  display: block;
  position: relative;
  height: 0;
  padding-bottom: 56.25%;
  width: 100%;
}

.parent > .child {
  display: block;
  position: absolute;
  width: 100%; 
  height: 100%;
  top: 0;
  margin: 0;
  padding: 0;
}

So kann man Bilder (in der passenden Bildschirmgröße) ondemand laden ohne dass der Text erneut ausgerichtet wird (reflow).

Wenn Bilder aber nicht mit einer Container-Breite von 100% eingebunden sind, ist die Dreisatzrechnung eine andere. Angenommen das Bild soll links im Text mit einer Breite von 33% angezeigt werden, dann ist die Berechnung des padding-bottom Abstand folgendermaßen: 9 × 33% ∕ 16

Den padding-bottom Trick beschreiben Anders Andersen & Tobias Järlund in Ihrem Smashing-Magazine Artikel Addressing The Responsive Images Performance Problem: A Case Study ausführlich.

fixed ratio Sass mixin

Da man das ja nicht immer selbst ausrechnen möchte, kann man sich hier mit einem kleinen Sass-Mixin aus dem Sass-Toolkit behelfen:

// @mixin fixed-ratiobox();
//
// stealed from https://github.com/Team-Sass/toolkit/blob/master/compass/stylesheets/toolkit/_intrinsic-ratio.scss
//
// usage: @include fixed-ratiobox(4/3, 50%, 'img, figure');
//
$intrinsic-ratio: 16/9 !default;
$intrinsic-ratio-width: 100% !default;
$intrinsic-ratio-elements: '> *' !default;
$intrinsic-ratio-extend: true !default;
$intrinsic-ratio-direction: bottom !default;

@mixin intrinsic-ratio-parent($extend: $intrinsic-ratio-extend) {
    @if $extend {
      @extend %intrinsic-ratio-parent;
    }
    @else {
      display: block;
      position: relative;
      height: 0;
    }
}

@mixin intrinsic-ratio-child($extend: $intrinsic-ratio-extend) {
  @if $extend {
    @extend %intrinsic-ratio-child;
  }
  @else {
    display: block;
    position: absolute;
    width: 100%; // !important Nuke the external styles
    height: 100%; // !important Nuke the external styles
    top: 0;
    margin: 0;
    padding: 0;
  }
}

@mixin intrinsic-ratio-ratio($ratio: $intrinsic-ratio, $width: $intrinsic-ratio-width, $direction: $intrinsic-ratio-direction) {
  padding-#{$direction}: (1 / $ratio) * $width;
  width: $width;
}

@mixin intrinsic-ratio($ratio: $intrinsic-ratio, $width: $intrinsic-ratio-width, $elements: $intrinsic-ratio-elements, $extend: $intrinsic-ratio-extend, $direction: $intrinsic-ratio-direction) {
  @include intrinsic-ratio-parent($extend);
  @include intrinsic-ratio-ratio($ratio, $width, $direction);

  @each $element in $elements {
    #{$element} {
       @include intrinsic-ratio-child($extend);
    }
  }
}

@mixin fixed-ratiobox($ratio: $intrinsic-ratio, $width: $intrinsic-ratio-width, $elements: $intrinsic-ratio-elements, $extend: $intrinsic-ratio-extend, $direction: $intrinsic-ratio-direction) {
  @include intrinsic-ratio($ratio, $width, $elements, $extend, $direction);
}

%intrinsic-ratio-parent {
  @include intrinsic-ratio-parent(false);
}

%intrinsic-ratio-child {
  @include intrinsic-ratio-child(false);
}

Anwendung des fixed ratio Mixins

.parent {
  @include fixed-ratiobox(2/1);
}

Der generierte CSS-Code:

.parent {
  position: relative;
  height: 0;
  padding-bottom: 50%;
  width: 100%;
}
.parent > * {
  display: block;
  position: absolute;
  width: 100% !important;
  height: 100% !important;
  top: 0;
  margin: 0;
  padding: 0;
}

Die Einbindung einer Box mit festem 4:3 Seitenverhältnis, welche aber nur 50% der Container-Breite einnimmt und für ‚IMG‘ oder ‚FIGURE‘ Kindelemente gilt, geht so:

.wrapperclass {
  @include fixed-ratiobox(4/3, 50%, 'img, figure');
}

.wrapperclass {
  position: relative;
  height: 0;
  padding-bottom: 37.5%;
  width: 50%;
}
.wrapperclass img, .wrapperclass figure {
  display: block;
  position: absolute;
  width: 100% !important;
  height: 100% !important;
  top: 0;
  margin: 0;
  padding: 0;
}

Wer damit herum spielen möchte, kann das mit Sassmeister machen.

Wie man vielleicht auch schon erahnen kann, ist das nicht nur hilfreich für Bilder im festen Seitenverhältnis, sondern auch allgemein für Inhaltselemente mit festem Seitenverhältnis. Diese Technik nutzt man unter anderem auch für die Einbindung von responsive Youtube-Videos. Marc Hinse beschreibt die Technik für gleiche Seitenverhältnisse in seinem Artikel Height equals width with pure CSS.

Der Beitrag Responsive Images – width/height-Attribute entfernen, lazy loading & padding-bottom Trick erschien zuerst auf maddesigns.

Hammer for Mac

Als erstes habe ich mir „Hammer for Mac“ angeschaut. Hammer ist meiner Meinung nach ein einfaches Tool, um ein paar statische HTML-Seiten zusammen zu schrauben. Beim ersten Testlauf stellte ich aber schnell fest, dass Hammer nicht das machen konnte, was ich damit machen wollte.

Problem: Hammer konnte (damals?) keine HTML-Dateien in Unterverzeichnisse kompilieren — das ist doof. Zudem unterstützt Hammer Compass nicht. Das war auch suboptimal, autoprefixer & Co. gab es noch nicht.

Für Hammer gibt es ein kleines (eigenständiges) Zusatztool, das die statischen Seiten über einen kleinen (Ruby-) Server ausliefert – Anvil Server. Man kann so ganz easy virtualle Hosts wie http://project.dev anlegen. Das fand ich ganz gut.

Wie aber schon erwähnt, reichte Hammer für meine Anforderungen nicht aus.

Codekit

Codekit ist eine beliebte Software, die viele Sachen vereint, sämtliche CSS-Präprozessoren sind integriert, zudem JS-Hint/-Lint, Bildkompremierung u.v.m. Ich hatte mir sofort die Beta-Version angesehen und fand es soweit ganz gut. Mit Verlassen der Beta-Phase wurde Codekit kostenpflichtig, kurz danach wurde eine neue Template-Engine in Codekit integriert. Zu dem Zeitpunkt hatte ich mich schon mit Middleman beschäftigt, aber dazu später mehr. Die Template-Language „Kit“ ist meiner Meinung nach nicht ausreichend für etwas komplexere Templates, man kann lediglich einfache „Includes“, sowas wie SSI & Variablen verwenden. Es fehlen aber Schleifen oder If-Else-Bedingungen. Beim Anlegen einer mehr-oder-weniger dynamischen Navigation (beispielsweise mit class="active" für die aktuelle Seite) scheitert man bereits.

Sonst ist Codekit aber ein feines Tool, mit Browser-Reload und allem was man normal braucht.

Prepos

Prepos ist ein Tool, welches ich mal ausprobiert hatte, als ich gezwungen war, vier Wochen in einer Agentur auf einem Windows-Rechner zu coden. Ein Vorteil von Prepos: es ist Windows fokussiert (gibt es aber auch für Mac) und funktioniert wohl ganz gut, soweit ich gehört habe. Mein Problem war, dass ich die Compass-Struktur, die wir in dem Projekt hatten nicht abbilden konnte. So war das Experiement schnell erledigt.

Mixture.io

Mixture hatte ich mir ebenfalls in einer frühen Alpha-Version angesehen und ich war vom Featureset sofort begeistert. Mit Mixture ist es möglich komplexere Templates (mit Partials, etc.) umzusetzen. Die benutzte Template-Language ist Liquid. Zudem kann man mit Mixture neue Projekte mit Vorlagen wie Foundation oder Bootstrap starten.

Mixture unterstützt eine Daten-Anbindung über JSON, so dass man auf Grund von echten Daten statische Templates erstellen könnte. Das ist toll!

Mixture habe ich mittlerweile schon mehreren Kollegen empfohlen und würde es sofort wieder empfehlen, wenn man sich nicht gern auf der Konsole bewegt. Aber dazu sind ja die Tools da, sie nehmen einen die Arbeit mit der Konsole ab, kosten dafür aber Geld. ;)

Middleman

Im Kontext „Static Site Generators” taucht auch schnell Middleman auf. Wie der Name schon sagt, ist das die Software „dazwischen“. Middleman ist Ruby-basiert und unterstützt demzufolge die Ruby Template-Sprachen ERB, HAML, Slim, etc., aber auch Markdown (Kramdown) oder Jade.

Mit Middleman würde auch gleichzeitig Sass und Compass installiert werden, falls man es nicht bereits installiert hat. Middleman hat einen Server-Task, in dem ein kleiner Ruby-Server für Dateiänderungen gestartet wird. Zudem gibt es natürlich einen Build-Task. Auch für Middleman gibt es Vorlagen, mit denen man neue Projekte starten kann. Da das aber Open-Source und Community-getrieben ist, werden hier nicht so oft Updates oder neue Versionen veröffentlicht. Anders bei Mixture.io, dort sorgt die Firma dafür, dass Updates oder neue Template-Vorlagen-Versionen schnell zur Verfügung gestellt werden. Ein USP von mixture.io.

Aber zurück zu Middleman: Weiterhin gibt es für Middleman auch viele Plugins wie middleman-autoprefixer oder middleman-livereload. In der Middleman-Dokumentation werden ERB-Template-Beispiele verwendet. ERB ist für den Einstieg in die Ruby-Template-Engines auch ganz gut, da diese nicht so abstrakt ist wie z.B. HAML. Es sind einige Template-Helper in Middleman integriert. Es können z.B. Platzhaltertexte eingebunden werden, die je Aufruf variieren. Das ist besonders hilfreich beim Erstellen von Responsive Websites, abseits von Lorem Ipsum. In der Konfiguration kann man für den Build-Prozess einstellen, ob JavaScript oder CSS komprimiert und zusammengefasst werden. Middleman unterstützt auch die Rails-Asset-Pipeline sowie Asset-Caching. Eigentlich alles was man für ein statisches Template/eine statische Seite benötigt. Gute Tutorials zu Middleman:

• Understanding Middleman – the static site generator for faster prototyping
• Building static websites with Middleman

Jekyll

Jekyll wird aktuell häufig als statischer „Blogersatz“ verwendet. Das ist in Wirklichkeit auch schon das, was man am besten damit machen kann: Jekyll bietet neben der Möglichkeit Inhalte in Markdown-Dialekten oder HTML in verschiedenen Layouts zu publizieren, hauptsächlich Möglichkeiten, die aus der Blogging-Welt kommen: Kategorien, Tags, Posts und dazu passende Paginatoren. Für Entwickler eignet sich das ganze als Ersatz für WordPress ganz besonders: Jekyll publiziert absolut problemlos auf GitHub Pages (ein Wunder, entstammt doch Jekyll auch aus der Feder des GitHub CEOs Tom Preston-Werner) und hat mit Pygments einen Syntax-Highlighting Präprozessor, der diverse JavaScript-Bibliotheken obsolet macht. Mit Poole ist sogar ein recht brauchbares Starterkit für Jekyll verfügbar.

Will man über die übliche Dokumentation- oder Blogfunktionalität hinaus, stößt man allerdings schnell an die Grenzen des von Jekyll. Zwar kann man sich zahlreicher Plugins bedienen, an die Möglichkeiten die z.B. Assemble (mit Handlebars Helpers) oder Jade bieten, kommt Jekyll nicht heran.

Assemble

Ich habe lang gezögert mich näher mit Grunt zu beschäftigen, da ich letztes Jahr nicht so viel Schnittpunkte mit meiner Arbeit gesehen habe. Ich war und bin mit Middleman äußerst zufrieden und würde wahrscheinlich ausschließlich Middleman nutzen.

Im aktuellen Projekt wird allerdings Grunt für die JavaScript-Entwicklung eingesetzt, was Sinn ergibt. Die Überlegung war nun, ob man nicht die Templates, die für die Module, die clientseitig (mit Javascript) verarbeitet werden, die gleiche Template-Engine nutzen könnte. Bei der Suche nach einer Template-Engine, die das unterstützt, bin ich auf Assemble gestoßen. Assemble nutzt Handlebars als Template-Engine und unterstützt zusätzlich eine Vielzahl an Template-Helpern. Zudem ist die Community recht groß (obwohl das Projekt noch recht neu ist) und es werden für Assemble bereits viele Plugins angeboten. Ich muss das aber erstmal produktiv ausprobieren, Assemble sieht aber sehr vielversprechend aus.

Fazit:

Es fällt mir schwer eine Empfehlung auszusprechen. Ich habe im letzten Jahr mehrere Projekte mit Middleman umgesetzt und werde es sicherlich weiterhin benutzen. Hätte ich mich nicht so sehr mit Middleman angefreundet, gleichzeitig auch mit der Konsole, würde ich aktuell zu Mixture tendieren. Wer viel mit Grunt arbeitet, sollte sich vielleicht Assemble anschauen, das macht für mich aktuell den besten Eindruck als Static Site Generator mit Grunt. Unter http://staticsitegenerators.net/ findet man eine laaaaaange Liste von aktuell 220 Tools.

Eine lustigen Tweet zum Thema hab ich heute auch entdeckt. ;)

the net award for best static site generator goes to Dreamweaver

— jennmoneydollars (@jennschiffer) 29. Januar 2014

Der Beitrag Static Site Generators erschien zuerst auf maddesigns.

Früher als man das Design ausschließlich in Photoshop machte, wurde natürlich auch der Styleguide in Photoshop erstellt — mit Bemaßung LOL! Diese Vorlage sollten Webentwickler dann nutzen, um ein Design möglichst pixelgenau umzusetzen. Ich kann mich an keinen „Styleguide“ erinnern, der zu 100% stimmte. Häufig waren Fehler in der „Bemaßung“ oder in Farbwerten… ihr kennt das.

Die „gedruckten“ Styleguides sind natürlich nicht mehr zeitgemäß. Im Responsive Webdesign können Webseiten-Elemente in unterschiedlichen Ausgabegrößen unterschiedlich dargestellt werden. Zudem werden im agilen Responsive Workflow Designelemente auch geändert und sehen u.U. nicht mehr so aus, wie es der Designer geplant hatte.

(Anekdote am Rande: Im aktuellen Projekt wurde das Aussehen bei ca. ¾ der Elemente/Module während des agilen Entwicklungsprozess nach Rücksprache mit dem Designer geändert)

Ein „Living Styleguide“, der das Projekt widerspiegelt (also vielleicht responsive ist) und bei Veränderungen ohne großen Aufwand neu generiert wird, brauchte man. Gibt es! Grunt zu Hülf! :)

Grunt – The JavaScript Task Runner

Grunt ist ein Kommandozeilen „Task Runner“, mit dem man automatisiert Aufgaben erledigen lassen kann. Zum Beispiel kann man JavaScript auf Validität oder sauberer Schreibweise mit „jslint/jshint“ überprüfen oder Sass kompilieren und eine Vielzahl weiterer Tasks erledigen lassen. Tiefer will ich nicht auf Grunt(d)lagen eingehen, gute Einsteigerartikel findet ihr unter:

• Webkrauts-Artikel von Frederic Hemberger (@fhemberger) und
• Grunt-Einführung (en) von Chris Coyier

Grunt-Styleguide

Automatisierung von Webentwicklungsaufgaben ist super. Da liegt es natürlich nahe, auch Styleguides automatisiert erstellen zu lassen. Mit Grunt-Styleguide gibt es ein Grunt-Modul, das das für uns erledigen kann.

Installation von Grunt-Styleguide:

npm install grunt-styleguide --save-dev

Die Grunt-Modul-Konfiguration lässt zwei „Styleguide-Frameworks“ zu. Per Default ist Styledocco aktiv. Styledocco lässt allerdings keine eigenen Styleguide-Vorlagen zu. Das andere Framework, das mit Grunt-Styleguide verwendet werden kann, ist KSS-node und ist ebenfalls bereits im Modul enthalten. Der Node.js-Port von KSS, das für die Styleguide-Generierung des Github.com Styleguide verwendet wird, eignet sich meiner Meinung nach besser um individuelle Styleguides zu generieren.

Styleguide-Konfiguration in gruntfile.js:

// only the styleguide part of the gruntfile.js
styleguide: {
    options: {
        template: {
            src: 'styleguide/template/'
        },
        framework: {
            name: 'kss'
        }
    },
    all: {
        files: [{
            'dist/styleguide': 'css/sass/**/*.scss'
        }]
    }
}

grunt.registerTask('build', [], function () {
    grunt.loadNpmTasks('grunt-styleguide');
    grunt.task.run('styleguide');
});

Styleguide-Vorlage
Mit KSS-node ist es möglich, ein eigenes Styleguide-Template zu verwenden und somit den Styleguide an das Look and Feel des Projektes anzupassen.

Im Grunt-Modul ist unter templates/kss/index.html eine Beispiel-Datei hinterlegt. Diese Vorlage kann man in ein anderes Verzeichnis kopieren und nach belieben anpassen. Das Template ist mit Handlebars Helpern ausgestattet, um eine flexible Ausgabe der Daten zu ermöglichen.

Styleguide-Navigation in der Styleguide-Vorlage:

<ul class="styleguide-navigation">
  {{#eachRoot}}
    <li>
      <a href="section-{{reference}}.html">
        {{reference}}.0: {{header}}
      </a>
    </li>
  {{/eachRoot}}
</ul>

Soweit, so gut. Das Styleguide-Template liegt vor und der Grunt-Task ist konfiguriert, jetzt nur noch den Sass-Code kommentieren und der Styleguide kann erstellt werden.

Sass Kommentare in Styleguide umwandeln

Die einzelnen Styleguide-Abschnitte werden anhand von Kommentaren im CSS bzw. direkt aus den Sass-Kommentaren generiert. Das hat gleichzeitig den Vorteil, dass Entwickler ihren Code kommentieren. :)

Ein Beispiel:

// Links
//
// usual links and style for external links
//
// Markup: <a href="" class="{$modifiers}">Link</a>
//
// :visited  - visited styles
// :hover    - Highlight the button when hovered.
// :focus    - focus styles
// :active   - "Press" the button down when clicked.
// .external - external link styles
//
// Styleguide 1.1

a {
  color: $link-color;
  text-decoration: underline;

  &:visited {
    color: $link-colorV;
  }
  &:hover {
    color: $link-colorH;
  }
  &:focus {
    color: $link-colorF;
    outline: thin dotted;
  }
  &:active {
    color: $link-colorA;
    outline: none;
  }
  &:hover, &:active {
    outline: none;
  }
  &.external {
    color: $link-external;
  }
}

In den Kommentaren kann man mehrere Teile der Styleguide-Section Beschreibung unterbringen.

// Titel
//
// Beschreibung
//
// Markup: 
// <div>
//   <span>HTML-Code</span>
//   <span>mehrzeilig</span>
// </div>  
//
// Modifiers ({$modifiers}) 
// z.B. Pseudo-Klassen oder Modifier-Klassen 
// plus Beschreibung 
//
// Styleguide Abschnitt (1.1)

Als großer Unterschied zum original KSS Styleguide, der auf Ruby basiert, ist es mit KSS-node möglich über den „Markup-Teil“ in den Kommentaren auch Markup-Beispiele im Styleguide anzuzeigen. Zudem wird pro Modifier das Markup mit der Modifier-Klasse in den Styleguide eingefügt. Bei Pseudo-Klassen wie :hover wird das Styling dann per JavaScript (kss.js) on-the-fly eingesetzt.

Die freie Gestaltung des Markups lässt natürlich auch zu, dass man ganze Seitenmodule im Styleguide abbilden kann.

Beispiel Suchfeld:

// Search
//
// Below are global search field and search result list styles
//
// Styleguide 4

// global search field
//
// Markup:
// <form action="" class="global-search">
//   <fieldset>
//     <label for="search_field">Search</label>
//     <input type="search" id="search_field" 
//            name="search_field" 
//            placeholder="enter search term">
//     <button type="submit" class="btn-submit">Search</button>
//   </fieldset>
// </form>
//
// Styleguide 4.1

Ich habe in den Styleguide noch den Prism-Syntax-Highlighter von Lea Verou integriert, et voilà, der Living-Styleguide nimmt Formen an.

Screenshots

(leider aktuell nur Screenshots vom Styleguide bis der veröffentlicht wird)

Der Beitrag Styleguide generieren mit Sass & Grunt erschien zuerst auf maddesigns.

Breakpoint Compass plugin

Breakpoint ist ein Compass Plugin, das IMO die universellste Lösung für das Schreiben von Media Querys in Sass ist. Breakpoint funktioniert grundsätzlich wie Sass-IE, wenn man ein Media Query schreiben möchte, ruft man ein Mixin auf. Ein einfaches Beispiel:

$basic-value: 543px;
$pair-value: 456px 794px;

.foo {
  content: 'No Media Queries';

  @include breakpoint($basic-value) {
    content: 'Basic Media Query';
  }

  @include breakpoint($pair-value) {
    content: 'Paired Media Query';
  }
}

Der Default-Wert für Media Querys ist min-width. Werden zwei Variablen übergeben wird eine UND-Verknüpfung von min- und max-width generiert.

.foo {
  content: 'No Media Queries';
}

@media (min-width: 543px) {
  .foo {
    content: 'Basic Media Query';
  }
}

@media (min-width: 456px) and (max-width: 794px) {
  .foo {
    content: 'Paired Media Query';
  }
}

Breakpoint kann auch automatisch EM-Media-Querys generieren. Dazu einfach die globale Variable $breakpoint-to-ems auf true setzen.

$breakpoint-to-ems: true;
$media: 'screen' 700px;

#foo {
  @include breakpoint($media) {
    content: 'Media';
  }
}

@media screen and (min-width: 43.75em) {
  #foo {
    content: 'Media';
  }
}

Das Beispiel oben zeigt, dass man in Breakpoint das Medium (screen) für den der Media Query zutrifft optional angeben kann. Denkbar wäre auch eine Variable wie $forprint: 'print'; für ein Druckstylsheet.

IE8 Fallback in separate Dateien generieren

Wie beim Mixin von Jake kann man in Breakpoint auch ein Stylesheet für IE8 in eine gesonderte generieren Datei lassen.

// _layout.scss
// global breakpoints
$small: 24em;
$middle: 34em;
$large: 65em, 'no-query' true;

.component {
  color: red;
  @include breakpoint($middle) {color: blue}
  @include breakpoint($large) {color: green;}
}

In der Sass-Hauptdatei wird die _layout.scss importiert und die globalen Variablen aus Breakpoint $breakpoint-no-queries und $breakpoint-no-query-fallbacks auf false gesetzt.

// styles.scss
$breakpoint-no-queries: false;
$breakpoint-no-query-fallbacks: false;
@import 'layout';

Für den IE8-Fallback wird eine eigene Datei angelegt, die ebenfalls

// fallback-ie8.scss
$breakpoint-no-queries: true;
@import 'layout';

styles.css

.component {
  color: red;
}
@media (min-width: 34em) {
  .component {
    color: blue;
  }
}
@media (min-width: 65em) {
  .component {
    color: green;
  }
}

fallback-ie8.css

.component {
  color: red;
  color: green;
}

Fallback mit „.lt-ie9“ in der Hauptdatei

Zusätzlich kann man Selektoren auch mit speziellen Root-Klassen erweitern lassen. Die Vorgehensweise kennt man sicherlich durch HTML5 Boilerplate. Durch Conditional Comments im <head> wird für den IE8 die Klasse lt-ie9 im HTML hinzugefügt. Diesen Selektoren kann man nun verwenden um Styles für den IE8 zu generieren.

Mit Breakpoint kann man das wie folgt erreichen:

// style.scss
// use px values, convert them to EM
$breakpoint-to-ems: true; 
$breakpoint-no-query-fallbacks: true;
$large: 960px, 'no-query' '.lt-ie9';

.component {
  color: red;
  @include breakpoint($large) {
    color: green;
  }
}

style.css

.component {
  color: red;
}
@media (min-width: 60em) {
  .component {
    color: green;
  }
}
.lt-ie9 .component {
  color: green;
}

Letztlich kann man auch bei Mixin-Aufruf noch die nötigen Variablen mitgeben, z.b. könnte man

.component {
  color: red;
  @include breakpoint($large) {
    color: green;
  }
  @include breakpoint(1200px,'.no-mq') {
    color: yellow;
  }
}

Das würde folgendes CSS als Fallback generieren:

.component {
  color: red;
}
.lt-ie9 .component {
  color: green;
}
.no-mq .component {
  color: yellow;
}

Man kann separate Dateien generieren oder den Fallback direkt in die Datei einfügen, und und und. Das macht es für mich so flexibel und ich bin noch nicht an die Grenzen gestoßen. Habt ihr weitere Tipps zum Thema „Mobile First und IE8-Fallback“?

Der Beitrag Mobile First & IE8 Fallback mit Sass (Teil2) erschien zuerst auf maddesigns.

In dem Artikel geht es um die technischen Möglichkeiten für den Internet Explorer 8 automatisiert eine optimierte ähnlich gute Ansicht der Responsive Website zu generieren.

Problem: der IE8 unterstützt keine Media Querys.

Wenn man technisch gesehen „Mobile First” entwickelt, bedeutet das, dass der erste Media Query kein Media Query ist und alle Geräte zuerst die „mobile Ansicht“ bekommen. Die Layout-Anpassungen mit Media Querys würden von klein zu groß gemacht, nicht umgekehrt. Da der IE8 keine Media Querys unterstützt, ignoriert er die Styles, die innerhalb diesen definiert sind, und macht die Anpassungen nicht mit. Demzufolge zeigt er die „Smartphone-Ansicht“. Oftmals wäre das nicht mal so schlimm, das Ergebnis ist oft übersichtlicher und performanter. ;)

Andererseits ist es natürlich auch nachvollziehbar, dass das Kunden nicht ausreicht und man den Usern mit IE8 eine „Desktop-Ansicht“ präsentieren möchte.

IE8 Verbreitung in Deutschland

Was ich grundsätzlich nie empfehle, dem IE8 über Scripte wie respond.js oder CSS3-mediaqueries.js ein responsives Verhalten zu implementieren. Den IE8 gibt es nicht auf mobilen Endgeräten, er ist fast ausschließlich auf Windows XP Rechnern, vereinzelt noch auf Vista Rechnern, installiert. Hier surfen die User sehr häufig mit dem IE über die volle Bildschirmbreite. Seiten, die bisher nicht ins Fenster gepasst haben, bekamen einen horizontalen Scrollbalken. Das ist der Ansatz, den ich immer empfehle: Der IE8 bekommt eine Desktop-Ansicht. Diese kann auch ein Stück weit flexibel (mit min- und max-width) sein, aber passt sich nicht „responsive“ an. Die zusätzlichen Scripte machen den IE8 nur noch langsamer, als er schon ist.

responsive Hinweis
Die responsiven Frameworks Foundation sowie Bootstrap sind technisch auch auf den „Mobile First” Ansatz umgestiegen und unterstützen somit den IE8 nicht mehr. Das sollte man beachten, wenn man diese Frameworks produktiv einsetzt.

IE8-Fallback-Stylesheet mit Sass

Oft werde ich gefragt, wie ich das mache und sage dann meist „ganz einfach – mit Sass“. ;)

Sass-IE von Jake Archibald ist ein kleines Mixin-Plugin, mit dem man „Mobile First“ Media-Querys schreiben kann und gleichzeitig ein Stylesheet für IE < 9 ohne @media Angaben generiert wird. Grundsätzlich benötigt man zwei sog. Sass-Manifest-Dateien, im Beispiel von Sass-IE ist das all.scss und all-old-oldie.scss. In der all.scss werden all (haha) unsere Sass-Dateien importiert und eine Variable $fix-mqs auf false gesetzt.

// all.scss
$fix-mqs: false !default;
@import styles.scss;

In der Datei all-old-oldie.scss wird die Variable $fix-mqs auf den Wert gesetzt, der für den IE als „Desktop-Min-Width“ gelten soll. Hier im Beispiel 65em. Zudem muss die Variable $old-ie: true; gesetzt sein und die all.scss importiert werden.

// all-old-oldie.scss
$old-ie: true;
$fix-mqs: 65em;
@import 'all';

Media Querys werden in Sass nun wie folgt benutzt:

.component {
  color: red;
  @include respond-min(32em) { color: green; }
  @include respond-min(65em) { color: blue; }
}

Sass generiert daraus folgendes CSS.

/* all.scss */
.component {
  color: red;
}
@media screen and (min-width: 32em) {
  .component {
    color: green;
  }
}
@media screen and (min-width: 65em) {
  .component {
    color: blue;
  }
}

/* all-old-ie.scss */
.component {
  color: red;
  color: blue;
}

Das Mixin „respond-min“ im Detail:

$fix-mqs: false !default;
@mixin respond-min($width) {
  // wenn die Ausgabe an ein fixed Media Query erfolgen soll
  @if $fix-mqs {
    // wenn $fix-mqs einen Wert hat
    @if $fix-mqs >= $width {
      // und der Wert größer/gleich 
      // der übergebenen Breite ist
      // dann den übergebenen Inhalt parsen
      @content;
    }
  }
  @else {
    // andererseits ein Media Query Bereich generieren 
    // und Inhalt parsen
    @media screen and (min-width: $width) {
      @content;
    }
  }
}
// es gibt natürlich auch ein respond-max mixin, 
// das das macht, was man erwartet

$old-ie: false !default;

CSS in die HTML-Datei integrieren

Die beiden CSS-Dateien werden über Conditional Comments in die Seite eingebunden. Zuerst die oldIE-Datei, dann unsere CSS-Datei mit den Media Querys. Der IE8 erkennt das oldIE Stylesheet und ignoriert den zweiten Conditional Comment, da er anscheinend für den Internet Explorer größer IE8 gilt. Der IE9 merkt, dass der erste Conditional Comment nicht für ihn bestimmt ist und lädt das zweite Stylesheet. Der IE10/IE11 und alle anderen modernen Browser ignorieren Conditional Comments und laden das zweite Stylesheet. Das Besondere an dieser Stelle ist, dass der HTML-Kommentar hinter dem öffnenden Conditional Comment gleich wieder geschlossen wird: <!-->. Moderne Browser erkennen, dass der zweite Conditional Comment sofort wieder geschlossen wird und laden die verlinkte CSS-Datei.

<!--[if lte IE 8]>
  <link rel="stylesheet" href="css/all-old-ie.css">
<![endif]-->

<!--[if gt IE 8]><!-->
   <link rel="stylesheet" href="css/all.css">
<!--<![endif]-->

Einzelne Eigenschaften (Hacks) nur für oldIE
Die kleine Mixin-Library von Jack bringt noch ein kleines old-ie Mixin speziell für einzelne IE-Hacks mit.

@mixin old-ie {
    // Only use this content if we're dealing with old IE
    @if $old-ie {
        @content;
    }
}

Man könnte hier z.B. eine Fallback-Lösung für RGBA-Farbwerte mitgeben.

So schön wie die Lösung funktioniert, hat sie doch ein paar Nachteile. Media Querys werden nur für einen Wert (min-width bzw. max-width) und ein Medium (@media screen …) ausgegeben. Es ist also nicht möglich ein Media Query für zwei Werte zu schreiben. @media screen and (min-width: 450px and max-width: 650px) geht damit leider nicht. Dennoch ist es ein großer Gewinn ein Stylesheet, dass schon zum größten Teil für die Desktop-Darstellung im IE8 optimiert ist, automatisch bei der „Mobile First“ Entwicklung zu generieren.

Der Beitrag Mobile First & IE8 Fallback mit Sass erschien zuerst auf maddesigns.

Internet Explorer via VirtualBox oder VMware Fusion

Um sicher zu testen, sollte man auf virtuelle Maschinen zurück greifen. Prominente Tools sind VMware Fusion, Parallels Desktop oder VirtualBox. In VirtualBox kann man aber nicht nur Windows und IE installieren, sondern auch andere Systeme abbilden. VirtualBox wird aktuell sehr häufig mit Vagrant genutzt um z.B. eine Live-Server-Umgebung abzubilden.

Seit einiger Zeit gibt es eine Initiative von Microsoft um das Testen von Webseiten auf verschieden Internet Explorer zu erleichtern – modern.ie. Mit dem Online-Tool kann man eine bestehende Seite im Netz überprüfen, ob z.B. die Möglichkeiten für Windows 8 ausgeschöpft werden ob proprietäre CSS-Eigenschaften verwendet werden. Zudem bietet Microsoft dedizierte virtuelle Maschinen für das lokale Testen zum Herunterladen an. Über modern.ie bekommt man zudem eine 3-monatige Testphase für Browserstack.

Testen mit Browserstack
Browserstack ist ein Service, mit dem man nicht nur die IEs, sondern auch eine Vielzahl mobiler Devices testen kann. Browserstack stellt virtuelle Maschinen oder Emulatoren zur Verfügung auf denen man dann via Tunnel eine Webseite debuggen kann und besitzt zudem eine REST API zum automatisierten Testen. Codepen-Snippets können ebenfalls „on-the-fly“ via Browserstack getestet werden.

Internet Explorer als virtuelle Maschine mit VirtualBox installieren

Ich benutze schon seit einiger Zeit VirtualBox und spezielle virtuelle Maschinen für das lokale Testen von IE8 & Co. Bei der Installation der Boxen half mir ein Shell-Script von ievms. Beim Installieren kann man zudem angeben welche Versionen vom IE man installieren möchte, oder einfach alle verfügbaren Versionen installieren (IE6-IE11).

1. Aktuelle Version von VirtualBox herunterladen:
   https://www.virtualbox.org/wiki/Downloads

2. ievms über die Konsole via Shell-Script installieren

   curl -s https://raw.githubusercontent.com/xdissent/ievms/master/ievms.sh bash
   

3. oder: spezielle IE-Versionen installieren (IE8 – IE10)

   
   curl -s https://raw.githubusercontent.com/xdissent/ievms/master/ievms.sh | env IEVMS_VERSIONS="8 9 10" bash
   

4. Warten
   Das dauert je nach Verbindungsgeschwindigkeit und Rechnerleistung einige Zeit (bis zu mehreren Stunden) – am besten vielleicht nachts laufen lassen und sicher stellen, dass die Internetverbindung stabil ist und der Rechner nicht in den Ruhemodus geht. ;)

IE VMs auf externem Speichermedium (SD-Card) installieren

Bei der Installation von IE VMs werden sehr große Dateien im System hinterlegt (ist ja immer ein komplettes Windows-Betriebssystem mit Browser). Das kann natürlich den verfügbaren Speicherplatz einer Festplatte sehr stark dezimieren, besonders wenn man nur eine kleine SSD hat.

Da ich die VMs zwar sehr gern verwende, aber nicht mehr allzu häufig brauche und sie mir die Festplatte ein wenig zumüllen, habe ich mir die VMs auf einer externen Quelle installiert. Ich habe mir eine 64Gb Micro-SD-Karte und einen kleinen SD-Karten-Adapter zugelegt, da ich den SD-Karten-Slot am MacBook Air selten brauche.

Bei der Installation über ievms muss dann ein anderer Pfad angegeben werden um die virtuelle Maschine auf der SD-Karte zu speichern. Das Script anwerfen und Kaffee trinken gehen oder so. Das Installieren dauert eine Weile, da extern speichern bekanntermaßen noch langsamer als intern speichern ist.

curl -s https://raw.githubusercontent.com/xdissent/ievms/master/ievms.sh | env IEVMS_VERSIONS="7" INSTALL_PATH="/Volumes/SanDisk64/.ievms" bash

Installationspfad anpassen: „/Volumes/[YOUR_SDCARD_NAME]“

Das ievms Shell-Script erstellt automatisch einen Sicherungspunkt, zu dem man nach Ablauf der 90-Tage-Windows-Testphase zurückkehren kann und die VMs nicht erneut herunterladen und installieren muss. Bis dahin kann man Windows völlig kostenlos nutzen.

Wenn alles installiert ist, kann man die Maschinen starten (eine nach der anderen) und weitere Einstellungen machen. Die Maschinen werden per default mit englischer Tastatur installiert. Ich stelle diese immer auf deutsch um und erstelle dann nochmal einen Snapshot (Sicherungspunkt).

Der Beitrag IE-Debugging via VirtualBox mit modern.ie erschien zuerst auf maddesigns.

Als Einstieg in die Thematik eignet sich der Artikel „Fluid Grids“ (2009) von Ethan Marcotte himself. Dort beschreibt Ethan wie man ein fixes Layout in ein flexibles Layout umrechnet. Eine einfache Formel ist das Geheimnis der fluiden Grids:
Ziel/Kontext = Ergebnis in Prozent

Ein klassisches Beispiel:
300px / 960px = 0.3125 * 100% = 31.25%

Wer sich bereits mit Responsive Webdesign beschäftigt hat, kennt sicherlich diese Grundlagen.

Das responsive Frontend-Framework Foundation bietet die Möglichkeit mit den Klassen-Präfixen ’small-‚ und ‚large-‚ individuelle Breakpoints für die jeweilige Module zu vergeben. Dadurch kann man die prozentuale Spaltenbreite je Viewport anpassen. Im HTML fügt man dazu folgende Klassen hinzu:

<div class="small-2 large-4 columns">...</div>
<div class="small-4 large-4 columns">...</div>
<div class="small-6 large-4 columns">...</div>

Bootstrap (formerly known as Twitter Bootstrap) hat einen ähnlichen Gridaufbau.

<div class="col-xs-12 col-md-8"> .col-xs-12 .col-md-8 </div>
<div class="col-xs-6 col-md-4"> .col-xs-6 .col-md-4 </div>

Welche Vorteile bringt ein „individuelles Gridsystem“ gegenüber den Gridsystemen von Bootstrap oder Foundation?

Erst einmal sollte man sich bewusst sein, dass ein (Frontend-) Framework eine Reihe an Modulen und Features mitbringen, die beim Prototyping und bei der Entwicklung durchaus hilfreich sein können. Setzt man aber nur ein Modul davon ein (z.B. Grids) und achtet nicht darauf nur die verwendeten Dateien (die nötigen CSS-Stile) im HTML zu referenzieren, handelt man sich unter Umständen einen unnötigen Overhead ein.

Wer nur ein einfaches flexibles Gridsystem sucht, könnte auch das 1000px Gridsystem von Elliot Jay Stocks oder das Online-Tool Gridpak nutzen.

Bei herkömmlichen Gridsystemen ist man an die vorgegebene Klassen-Logik des Gridsystem gebunden, um eine Änderung an der Spaltigkeit zu machen. Dazu müssten Änderungen am Markup gemacht werden. Zudem bieten die allermeisten responsiven Gridsysteme nur einen vorkonfigurierten Breakpoint (Foundation 5 hat jetzt auch zusätzlich ein „Medium-Grid“) um Layoutänderungen zu machen.

Sass Gridsysteme

Mit Sass hat man die Möglichkeit Grids unabhängig vom Markup, bzw. auf das Markup angepasst, zu erstellen. Nicht vergessen ein anderes Border-Box-Modell für alle Elemente deklarieren.

*, *:before, *:after {
  @include box-sizing('border-box');
}

Drei Gridsysteme möchte ich nachvolgend kurz vorstellen:

Semantic GS

Ein einfaches individuelles Gridsystem ist Semantic GS. Letztlich ist die Berechnung der Spalten in 2-3 Funktionen hinterlegt, einfach die Grid-Variablen setzen und loslegen. Selbst die Unterscheidung ob das Grid feste Breiten hat oder fluide agiert, kann konfiguriert werden.

@import 'grid.scss';

$column-width: 60;
$gutter-width: 20;
$columns: 12;
$total-width: 100%;  // fluid grid

// 9 columns main article and 3 columns aside content
article {
   @include column(9);
}
aside {
   @include column(3);
}

Subgrid-Logik:

article {
    @include column(9);

    ul {
      // include grid row 
      @include row(9);
      li {
        // include 3 columns of a 9 columns context (33.334%)
        @include column(3,9);
      }
   }
}

Das Semantic.gs Gridsystem gibt es als LESS-, Stylus- und SCSS-Präprozessor-Variante.

Susy – Responsive grids for Compass

Susy ist ein responsive Grid-Framework für Compass. Wer 960.gs kennt, kommt auch mit Susy schnell zurecht. Susy verwendet z.B. ebenfalls das Keyword ‚omega‘ um bei der letzte Spalte den Abstand (Gutter) nach rechts auf 0 zu setzen.

Gem Installation über die Kommandozeile

gem install compass-susy-plugin

Susy zu einem bestehenden Projekt hinzufügen – Anpassung der Compass-Konfiguration (config.rb):

#config.rb
require "susy"

Susy in die Sass-Dateien importieren

@import "susy";

Grid Konfiguratuion:

// global variables
$total-columns: 12;            // a 12 column grid
$column-width:  4em;           // each column is 4em wide
$gutter-width:  1em;           // 1em gutters between columns
$grid-padding:  $gutter-width; // grid-padding equal to gutters

// usage 
.page {
  @include container;
  @include susy-grid-background; // visualize the grid as bg-img
}

article {
  // content spans 9 columns of 12
  @include span-columns(9,12);    
}
aside { 
  // aside content spans the final 3 (omega) of 12 columns
  @include span-columns(3 omega,12); 
}

Susy bietet eine Vielzahl an Möglichkeiten wie Push oder Pull, sowie IE <9 Support (.lt-ie9 Klasse) um ein eigenes Responsive Gridsystem aufzubauen, zudem eine umfangreiche Doku: http://susy.oddbird.net/guides/reference/

An der nächsten Version von Susy wird schon fleißig gearbeitet, die Version 2.0 hat Sass 3.3 Support und brauch Compass nicht mehr unbedingt, siehe Github Changelog.

Singularity – Grids without limits

Singularity ist etwas mehr als ein Gridsystem wie man es häufig verwendet. Singularity kann neben den üblichen symmetrischen Grids (alle Spalten gleich breit) auch asymetrische Grids erstellen, d.h. nicht alle Spalten müssen immer gleich breit sein. Es lassen sich auch Spalten unterschiedlicher Breite anlegen. Zudem hat Singularity die sogenannte „Isolation-Methode“; als standardmäßige Spalten-Positionierungslogik und umgeht damit Browserbugs durch fehlerhafte Prozentrechnung.

Installation des Singularity Gridsystem

Die Installation von Singularity erfolgt genau wie bei Susy.

gem install singularitygs

Singularity in die Compass-Konfiguration hinzufügen:

# config.rb
require "singularitygs"

Singularity in die Sass-Dateien importieren:

@import "singularitygs";

Globale Grid-Variablen festlegen:

// 12 columns á la 960gs:
$grids: 12;
$gutters: 1/3;

Das SCSS Grid-Mixin:

@include grid-span($span, $position);

$span = Spaltenlänge
$position = Startposition

// usage 
article {
  // content spans 9 columns of 12 columns.
  @include grid-span(9,1);  
}
aside { 
  // aside content spans 3 of 12 columns.
  @include grid-span(3,10); 
}

Play with this gist on SassMeister.

Visuelle Positionierung (push und pull) – Der ‚$location‘ Parameter
Mit dem zweiten Parameter im @include Aufruf kann die Start-Position ($location) der Spalte festgelegt werden.

article {
  // content spans 9 columns begins at position 4.
  @include grid-span(9,4);  
}
aside { 
  // aside content spans 3 at position 1.
  @include grid-span(3,1); 
}

Play with this gist on SassMeister.

Asymetrische Grids mit Singularity

Singularity kann in der $grids Variable nicht nur einfache Zahlen verarbeiten, sondern auch mehrere Zahlen, die dann zu einem Gesamtgrid zusammen gezählt werden.

$grids: 1 4 1; // grid of 6 columns
$gutters: 1/6;            // 1/6 gutter of 1 column
$gutter-style: split;     // split gutter - half gutter on each side

Oder unser Ausgangsbeispiel:

$grids: 2 8 2; // grid of 12 colums
$gutters: 1/3;

article {
  // article content spans 1 column (is in fact 2 columns wide)
  // begins at position 1
  @include grid-span(1,1);
}
aside { 
  // aside content spans 1 column (is in fact 8 columns wide)
  // begins at position 2
  @include grid-span(1,2); 
}
.ads {
  // article content spans 1 column (is in fact 2 columns wide)
  // begins at position 3
  @include grid-span(1,3);
}

Bei asymmetrischen Grids ist darauf zu achten, dass der ‘$grids’-Variable in Teile aufgeteilt wird, aus denen sich die Positionen (Start der Spalte) ergeben. Drei Teile ergeben dann die Positionen 1, 2 und 3. Die „Spaltenbreiten“ können demzufolge jeweils eine Spalte breit sein (im Beispiel eigentlich 2 Spalten von 12) oder zwei bzw. drei Spalten (100%) breit.

Singularity kann auch automatisiert responsive Grids erstellen, also dass sich die Spaltenanzahl je Breakpoint geändernt wird. Ein Beispiel:

$break-small:   450px;
$break-medium:  700px;
$break-large:   900px;
$break-xlarge: 1200px;

$grids: 3; // mobile first view - 3 columns
$grids: add-grid(6 at $break-small); // 6 equal columns from 450px 
$grids: add-grid(12 at $break-medium); // 12 equal columns
$grids: add-grid(2 8 2 at $break-large); // 3 columns (2|8|2)
$grids: add-grid(1 3 5 7 9 at $break-xlarge); // 5 columns (1|3|5|7|9) 

$gutters: 1/3;
$gutters: add-gutter(.25 at 900px);

In dem Beispiel sind im „Mobile First“ Viewport drei Spalten mit einem Gutter von ⅓ der Spalte deklariert. Ab dem Breakpoint „$break-small“ (450px) wird das Grid in ein 6 Spalten-Grid umgewandelt, ab „$break-medium“ (700px) in ein 12 Spalten-Grid. Diese Spalten sind alle gleich breit. Ab dem Breakpoint „$break-large“ (900px) wird das Grid in 3 Spalten (die insgesamt aus 12 Spalten bestehen) asymmetrisch aufgeteilt. Letztlich gibt es nochmal ein asymmetrisches Grid ab dem Breakpoint „$break-xlarge“ (1200px). Ich möchte darauf hinweisen, dass das nur ein Beispiel ist, was möglich ist, nicht ob das ein sinnvolles Grid ist.

Hier eine Live-Demo und von allen Views mal Screenshot:

Relationale Grids – Singularity-Extras

Mit der Erweiterung „Singularity-Extras“ können mit Singularity Grids auf Basis bestimmter Relationen erstellt werden. So z.B. ein Gridsystem nach „Goldenen Schnitt“ oder „Compound-Grid“, das die Spaltenbreiten überlagert, kombiniert und zu einer Einzelspalte nach dem Vorbild von Karl Gerstner zusammenfügt. Dadurch sind natürlich sehr individuelle Grids möglich. Das Zuweisen der Spalten wird dann teilweise etwas komplizierter und ist manchmal ganz schöner Brain-Fuck, aber funktioniert.

@import "singularitygs";
@import "singularity-extras";

$break-small:   450px;
$break-medium:  700px;
$break-large:   900px;
$break-xlarge: 1200px;

$grids: 3;
$grids: add-grid(1 2 3 at $break-small);
$grids: add-grid(ratio(golden(), 6) at $break-medium);
$grids: add-grid(compound(2, 3, 4) at $break-large);

$gutters: .25;

Ein Beipiel mit Singularity-Extras: Mobile First Grid

Aktuell wird auch an der Sass 3.3 Kompatibilität von Singularity gearbeitet, das viele Verbesserungen intern mit sich bringt.

Ich würde mich freuen, wenn ich mal ein asymmetrisches Design-Raster umsetzen könnte, die meisten Designs sind ja mit symmetrischen Spalten aufgeteilt, aber immerhin besser als gar kein Raster. Hatte ich erwähnt, dass man mit Singularity auch sowas machen kann:

$grids: 55px 55px 55px 55px 55px 55px 55px 55px 55px 55px 55px 55px 55px 55px 55px;

Nicht? Jetzt aber. ;)

Nutzt ihr andere Grid-Systeme und welche Erfahrungen habt ihr damit?

Der Beitrag Individuelle responsive Gridsysteme mit Sass erschien zuerst auf maddesigns.

Mittlerweile beherrscht er unser Tun und stellt uns immer wieder Fallen. Wir versuchen ihn zu beherrschen. Wir versuchen ihn einzugrenzen. Oft schlägt dies fehl. An dieser Stelle möchte ich meine Feldforschungsergebnisse der letzten Monate mit Euch teilen.

Warum ist das so?

Ich möchte nicht zu technisch werden. PPK erklärt den ganzen Zusammenhang zwischen CSS-Pixel und Device-Pixel hier und hier exzellent. Auch bei Apple oder Opera findet man auch gute Zusammenfassungen.

Zuersteinmal erinnern wir uns, dass der Meta-Viewport-Tag gesetzt werden muss, damit die Seite „responsive“ dargestellt wird. Ansonsten wird von den mobilen Browser die Seite auf eine Breite von 980px gezoomt dargestellt. In der HTML5 Boilerplate findet man diese Angabe:

<meta name="viewport" content="width=device-width">

Das wisst Ihr ja sicherlich. Aber hier beginnen schon die Probleme. Nehmen wir an, der Entwickler hat im CSS einen Media-Query (für das iPad) wie folgt definiert:

@media only screen and (min-width: 768px) {
  body {
    color: red;
  }
}

@media only screen and (min-width: 1024px) {
  body {
    color: blue;
  }
}

Beispiel: http://codepen.io/maddesigns/full/ykJzC

In der Desktop-Simulation werden wir ab 1024px blaue Schrift sehen, auf einem Android-Device auch, nicht aber auf dem iPad. Das iPad suggeriert es sei ein Hochkant-Device und meldet hier dem Browser eine Breite von 768px. Auch wenn man das Gerät quer in den Landscape-Modus dreht, bleibt die Gerätebreite auf 768px und der Inhalt wird gezoomt dargestellt. Gleiches passiert auch auf dem iPhone bei 320px. Auf den iOS-Geräten wird man also nie die Landscape-Ansicht erhalten, wenn man nicht zusätzlich für die Viewport-Angabe im Media-Query „and (orientation: landscape)“ angibt. Jetzt könnte man schmollen und twittern wie doof doch Apple ist, aber es ist wie es ist.

Abhilfe für das Verhalten auf iOS ist die zusätzliche „initial-scale=1.0“ im Meta-Viewport. Dann wird auch bei 1024px der Media-Query aktiv. Ich nutzte also immer:

<meta name="viewport" content="width=device-width,initial-scale=1.0">

Kleiner Nachteil: ab und zu kommt es dann zum sogenannte „iOS Zoom Bug“ Verhalten, das aber in iOS6 gefixt ist. Ein Javascript-Bugfix für die älteren Betriebssysteme gibt es von Scott Jehl. Im aktuellen Master der HTML5-Boilerplate wurde das nun auch wieder so eingeführt. https://github.com/h5bp/html5-boilerplate/commit/ff37dba6bf025a00f58b2bb12f7c6a827e6643c5

Apropos „orientation: landscape“ – einigen erzähle ich nichts Neues – aber orientation: landscape/portrait ist nur die Auswertung vom Seitenverhälnis des Browserfensters, und wird nicht anderweitig durch das Device geliefert. DAS kann man also auch auf dem Desktop simulieren.
Beispiel: http://codepen.io/maddesigns/full/Blygt

device-width Media-Querys

Meiner Meinung nach ist es nicht optimal mit device-width Media-Querys zu arbeiten. Aus mehreren Gründen:

– man orientiert sich an bestimmten Devices
– man kann es schlecht am Desktop nachvollziehen
– bräuchte man noch einen dritten Punkt auf der Liste?

Man orientiert sich an bestimmten Devices

Unter Umständen greifen die Anpassungen nur für ein Gerät, könnten aber für viele andere Geräte auch zutreffen, die nur geringfügig andere Werte haben. Viele Media-Query Anpassungen bedeutet also mehr Arbeit, unter Umständen mehr Pflegeaufwand. Zudem ist es bei dem rasanten Anstieg an neu veröffentlichten Geräten kaum noch möglich Schritt zu halten.

Man kann es schlecht am Desktop nachvollziehen

Noch einmal gefährliches Halbwissen vorausgesetzt dürfte bekannt sein, dass viele Geräte bereits ein hochauflösenden Display haben. Die Pixel sind kleiner und enger als bei herkömmlichen Displays. So werden – wie beim Klassiker unter den hochauflösenden Geräten dem iPhone 4 – auf der gleichen Fläche wie zuvor die 4-fache Menge an Pixel untergebracht. In der Breite nicht mehr nur 320 Pixel, sondern 640 Pixelchen. Würde die Website nun auf die Device-Pixel gematcht werden, wäre die Schrift mit Sicherheit zu klein. Deshalb bleibt der Viewport gleich und die Angaben für Schrift und Co. werden umgerechnet. Bildlich gesprochen: Eine Überschrift mit der Größenangabe 24px, wird beim iPhone 4 auf 48px hochgerechnet und erscheint uns dann auf dem hochauflösendem Display wie 24px und nebenbei noch sehr scharf. Für die Angabe der Schriftgröße nehmt ihr aber „rem“ oder „em“, klar oder? ;)

Um auf unseren „Viewport-Switcher“ zurückzukommen, tritt dann natürlich folgendes Problem auf. Ich habe einen Media-Query folgendermaßen angegeben:

/* iPad Retina */
@media only screen and (min-device-width: 1536px) {
  body {
    color: red;
  }
}

Diese Anpassung werde ich auf dem Desktop erst ab einer Bildschirmauflösung von min. 1536px sehen können. Selbst dann könnte man das noch nicht richtig überprüfen, weil u.U. noch ein Media-Query für „Große Desktop-Ansicht“ greift.
Beispiel: http://codepen.io/maddesigns/full/njFcp

Um es einfach und nachvollziehbar am Desktop zu haben, habe ich mir angewöhnt im Sinne von „Mobile first“ alle Media-Querys mit der Angabe „min-width“ zu machen. Falls Anpassungen für hochauflösende Displays zu machen sind, wird dann die Pixel-Ratio bzw. Resolution abgefragt.

@media (-webkit-min-device-pixel-ratio: 1.5),
       (min-resolution: 144dpi),
       (min-resolution: 1.5dppx) {
	/* hiDPI stuff */
}

Diese Anpassungen greifen dann automatisch bei sehr vielen Geräten. Viele ältere Android-Geräte haben ein (laut Android) HiDPI-Display also eine Pixel-Dichte von 1.5.

Zum Beispiel:
– Galaxy S
– Galaxy S2
– Motorola Milestone (Droid)
– HTC Desire,
– Samsung Nexus S

Diese Geräte haben alle einen Display mit 480x800px und einen Viewport im Browser von 320×533px. Ergo könnte man die Geräte mit

@media only screen and (min-device-width: 480px) {
  …
}

ansprechen, bräuchte man aber nicht, sie bekommen automatisch die Anpassungen für „iPhone“ (falls man welche hat).

Zur Pixel-Density noch eine Geschichte: Ein paar Android-Geräte haben ein sehr kleines und schlechtes Display, z.B. das sehr verbreitete Galaxy Y, das Samsung Galaxy Mini oder das HTC Wildfire. Das Display ist 240×320px groß. In einigen „Responsive View“ Online-Tools kann man die Webseite mit einer Breite von 240px darstellen lassen. Das ist schön, aber diese Ansicht wird man auf diesen Geräten nicht bekommen. Zumindest, wenn man die Defaulteinstellungen so lässt. Klingt komisch, ist aber so. Diese genannten Geräte haben eine Pixel-Dichte von 0.75. Hier wird also der Viewport nicht verkleinert, sondern vergrößert und liegt bei unseren Beispielen demnach bei 320×427px, also etwa wie das iPhone 4. Es gibt auch zahlreiche Billig-Tablets, die das genauso so machen.

Achso Tablets…

Mein Lieblingsbeipiel das Nexus 7 macht total verrückte Sachen. Bei der Veröffentlichung des Nexus 7 (1. Generation) hatte es mit dem Chrome gemessen eine Viewport-Breite von 603px bei einem Display von 800×1280px. Einige Monate später wurde das durch irgendein Update (entweder OS oder Browser) korrigiert und der Chrome meldete 600px. Aber alle anderen Browser meldeten etwas anderes, Opera mobile (noch ohne Blink) meldete 800px, Firefox 533px und derUC-Browser 602px. Hier zu sagen „so sieht Ihre Website auf dem Nexus 7 aus“, ist schon fast fahrlässig.

Dann wäre da noch das iPad Mini, das so gar nicht nach den Regeln spielt. Das iPad Mini hat ein 7,9″ Display mit einer Auflösung von 768×1024px, quasi genauso wie das iPad 2, nur eben 20% kleiner (aber leicht höhere Pixeldichte). Das Gerät meldet auch den Viewport und Pixel-Dichte genau wie das iPad 2, also zeigt exakt die gleiche Menge an Inhalten an wie das iPad 2, nur eben 20% kleiner. Es zeigt auch die gleiche Ansicht wie das iPad 3/4 nur nicht so scharf und 20% kleiner. Eine Ansicht „wie im iPad mini“ kann ich am Desktop also schlecht simulieren.

Na doch ich könnte folgendes machen:

iframe.ipadmini {
  transform: scale(0.8);
}

Zu Guter Letzt

Was die meisten* Viewport Resizer Tools (bzw. in dem Fall die Browser) falsch machen, sie beziehen die Scrollbar mit in die Anzeige der Größe ein. WebKit basierende Browsers sind die einzigen Browser, die die Scrollbar in der Berechnung des passenden Media-Query nicht mit einbeziehen. Das kann also je nach System und Browser ein falsche Ansicht ergeben. Mobile Browser haben ja keine richtige Scrollbar.

Nur was tun?

Nicht auf die Ansicht im Desktop-Browser verlassen! Auf echten Geräten testen, z.B. mit Adobe Edge Inspect, Ghostlab oder MIH-Tool. Open Device Labs nutzen oder eröffnen. Ich habe mir mittlerweile einen (klitzekleinen) Park an Devices angeschafft odl.maddesigns.de.

Ein gutes Online-Tool ist Ish von (na klar) Brad Frost (auf http://bradfrostweb.com/demo/ish/ – mal http://roxik.com/cat/ links oben bei URL eingeben und dann rechts oben bei „size“ „Disco“ anschalten => Party! Hier kann man das Layout überprüfen, indem man auf die unterschiedlichen Größen (S, M, L, XL,…) klickt, klickt man mehrfach auf die Button wird der Viewport in dem gewählten Viewport-Bereich leicht angepasst. Eine Verbindung zu irgendwelchen Devicegrößen ist hier bewusst nicht gemacht worden. Persönlich finde ich auch die neue Responsive View im Firefox sehr gut gelungen (seit FF 15, also seit mehr als 6 Wochen drin ;)).

Was man auf dem Desktop auch nicht simulieren kann: Systemschriftarten, deren Fallbacks, und und und … aber das ist wieder eine ganz andere Geschichte.

*es gibt kein Sternchen

Der Beitrag Der Viewport — das unbekannte Wesen erschien zuerst auf maddesigns.

Anfang der Woche hab ich dann ein WordPress-Update gemacht und dabei das neue responsive Default-Theme gesehen. Na klar, ich hätte das Theme lieber selbst erstellt, aber wie eingangs bereits erwähnt, fehlt mir aktuell absolut die Zeit. Deshalb hab ich das jetzt übergangsweise aktiviert (und werde es nach und nach noch ein wenig pimpen). Morgen wird es einen neuen Artikel geben, der mir schon länger unter den Nägeln brennt.

Heute hatte ich auch die neue T3N im Briefkasten, da gibt es einen Artikel von mir über den „Responsive Workflow“ zu lesen. Im Wesentlichen ist das inhaltlich der Vortrag „Responsive Webdesign Process„.

Also, danke fürs dran bleiben und stay tuned!

Der Beitrag Lange nix gehört von dir erschien zuerst auf maddesigns.

Der Beitrag The Responsive Webdesign Process erschien zuerst auf maddesigns.

Der drei Stunden Workshop, den ich bei den TYPO3 Developer Days in München gegeben habe, habe ich am letzten Samstag auch nochmal beim TYPO3camp Stuttgart wiederholt. Im Workshop ging es um die ersten Schritte mit Sass & Compass, sowie die hilfreichsten Features vorzustellen und einen Ausblick auf die neue Sass Version 3.2 zu geben.

Bei Fragen, pingt mich gern auf Twitter dazu an, kommentiert hier im Blog oder schreibt mir eine E-Mail

Der Beitrag Sass & Compass Introduction erschien zuerst auf maddesigns.

Hat man im Layout, runde Ecken (border-radius) nur an einer Seite, z.B. rechts abgerundet, dann sind im IE9 die Ecken allerdings links abgerundet. Der IE9 dreht von sich aus die runden Ecken im RTL-Modus um. Das ist zwar nett vom IE9, aber nicht richtig und auch nicht immer gewollt. Bei gleichmäßig abgerundeten Ecken kann man den Bug natürlich nicht nachvollziehen, deshalb fällt er selten auf.

Hier mal ein jsFiddle-Beispiel:

Im IE9 sieht das allerdings so aus (Screenshot):




Der simplifizierte HTML-Aufbau:

<body dir="rtl">
    <div class="box"> right to left </div>
</body>

CSS:

.box {
    background-color: red;
    padding: 48px;
    height: 100px;
    width: 200px;
    margin: 40px;
    border-radius: 0 48px 48px 0;
}

Den Bug muss man nun per Conditional-Comments für den IE9 entgegnen und die angerundeten Ecken „umdrehen“:

<!--[if IE 9]>
  <style>
    body[dir="rtl"] .box  {
      border-radius: 48px 0 0 48px; /* switched from left to right */
    }
  </style>
<![endif]-->

Im IE10 ist der Bug bis zum Build 8250 auch noch nachzuvollziehen.
Den Bug hat Andrea Herzog-Kienast entdeckt und ich kann das Verhalten leider nur bestätigen.

Der Beitrag IE9 border-radius right-to-left (direction: rtl) Bug erschien zuerst auf maddesigns.

Livereload erkennt Änderungen im Projektordner beim Speichern einer Datei. Ein Browser-Plugin für Chrome (oder Firefox, Safari, Mobile Safari) führt dann umgehend im Hintergrund den Refresh/Reload durch. Das erspart natürlich einige Tastenanschläge/Mausklicks. Auf größeren Bildschirmen ist es praktisch, wenn man die beiden Fenster parallel positioniert und dann die Änderung am HTML oder CSS direkt im Blick hat.

Das wäre schon schön genug, aber Livereload bietet noch mehr. Es kann auch Sass-, LESS- oder Stylus- sowie CoffeeScript-Dateien kompilieren und dann den Browser-Reload durchführen. Zudem können auch „Refresh-Pausen“ eingestellt werden. Das ist hilfreich, wenn man z.B. die geänderten Dateien beim Speichern direkt auf den Webserver hochlädt und die Änderung dort betrachtet. Diesen Zeitinterval kann man als Wartezeit zum Live-Reload konfigurieren.

Das Mac-Tool ist nach der Beta-Phase nun im App-Store erhältlich und kostet $9.99. Ich kann das Tool nur jedem empfehlen und habe von @livereload 2 Promo-Codes für meine Leser erhalten. Um zu gewinnen einfach einen Kommentar abgeben!

Der Beitrag Livereload - ein Browser Refresh Tool erschien zuerst auf maddesigns.

Was man muss tun, um gewinnen zu können?!

…wird im Webstandard-Blog erklärt: Das große Weihnachtsgewinnspiel

Allen Teilnehmern viel Spaß, Glück & natürlich auch Erfolg!

Der Beitrag Das große Weihnachtsgewinnspiel - Tag 24 im CSS3 Adventskalender 2011 erschien zuerst auf maddesigns.