Was nicht passt wird responsive gemacht – Konferenz Premiere

Mir wurde die große Ehre zu teil meinen Responsive Web Design Vortrag “Was nicht passt wird responsive gemacht” auf einer der größeren Entwicklerkonferenzen mit weit über 1000 Besucher halten zu dürfen.

Es war ein großartiges Erlebnis. Einen ausführlichen Artikel darüber werde ich die Tage nachreichen.

Hier könnt ihr euch die Slides des Vortrags anschauen:

 

 

right-to-left CSS mit Hilfe von Sass

Mit der Aufgabe betreut eine right-to-left Plattform zu erstellen stand ich vor der Herausforderung dass ich für dieses Projekt das Layout einmal komplett spiegeln musste. In Ländern bzw. Sprachen in denen die Schreibrichtung von rechts nach links erfolgt, erfolgt auch die Darstellung von Webseiten von rechts nach links. Im einfachsten Fall bezieht sich das auf den Textfluss, betrifft aber auch Layouteigentschaften wie Spaltensysteme oder Overlays, Tooltips und Co.

Das HTML-Attribut DIR (http://www.w3schools.com/tags/att_global_dir.asp) gibt die Textauszeichnung in einem HTML-Dokument an und hilft einem damit schon bei der grundlegenden Textausrichtung. Durch eine globale Konfigurationseinstellung  und einer erweiterten Nutzung der Templatevererbung in Twig lies sich schnell mit einigen Zeilen PHP und Template-Code eine angepasste HTML-Struktur für die neue right-to-left Plattform einrichten. 

{# TheBundle::base.rtl.html.twig #}
{% set bRTL = true %}
{% extends "TheBundle::base.html.twig" %}

{% block dirattr %}dir="rtl"{% endblock %}

{% block leftcolContent %}
    {% render "TheBundle:Navigation:index" %}
{% endblock %}

{% block rightcolContent %}
{% endblock %}

Leider lassen sich floats und margin-lefts etc. davon nicht beeindrucken, alle diese positionsbezogenen CSS-Eigenschaften müssen im Zuge der Umstellung auf die right-to-left Darstellung angepasst werden. Dazu zählen CSS Eigenschaften wie u.a.:

border-left: 1px solid rgba(0,0,0,0.8);
left: 20px;
float: right;
margin: 10px 4px 6px 8px;
padding-left: 20px;

Alle diese Eigenschaften müssen gespiegelt werden. 

Es ist häufig vorzutreffen, dass in solchen Situationen die Betreiber einiger Plattformen nun einfach für die right-to-left Darstellung ein zusätzliches Stylesheet hinterher laden, dass alle Eigenschaften des Haupt-CSS überschreibt die positionsbezogene Layout-Angaben beinhalten.

// base.css 
.sidebar {
    float: left;
}

// base.rtl.css
.sidebar {
    float: right;
}

Im Sinne von Wartbarkeit und des DRY-Prinzips kommt dieser Ansatz natürlich nicht in Frage.

Eine weitere Möglichkeit ein rtl-css zu generieren besteht in der Hilfe von Tools wie z.B. flipCSS die das generierte ltr-css parsen und ein rtl-css erstellen indem sie automatisiert alle Positionsangaben tauschen. 

Bei diesem Ansatz würde sich ein weiteres Tools in den Entwicklungsprozess einschleichen und es stellt sich die Frage was mache ich wenn ich bestimmte Bereiche / Eigenschaften des CSS vielleicht nicht umwandeln möchte und die volle Kontrolle darüber behalten möchte welche Eigenschaften angepasst werden und welche nicht?

Wenn man sowieso schon Sass als CSS-Präprocessor verwendet und u.a. eine Menge von Mixins / Funktionen verwendet die einem bei der alltäglichen Pflege und Wartung des CSS helfen und zudem eine schnellen Skalierung der CSS Architektur ermöglichen, warum verwendet man nicht dann einfach dieses mächtige Tool als Hilfe zu Erstellung der rtl und ltr CSS Dateien?

Ein Mixin der Form

@mixin float($side)  {
    @if $side == left {
        float: $left;
    } @else if $side == right {
        float: $right;
    }
}

hilft bei der Generierung dieses CSS. Ein Aufruf dieses mixins je nach gesetzter Einstellung der Variablen $left und $right würde somit die entsprechende Eigenschaft für die entsprechende Auszeichnung der Webseite erzeugen.

Beispiel: _header.scss

.logo {
    @include float($left);
}

Im Zuge der Entwicklung wurden viele weitere Mixins erstellt die z.B. auch die Möglichkeit geben mit einem Aufruf von

.selector {
    @include margin(2px,3px,4px,5px);
}

entsprechende margins je nach Ausrichtung der Seite zu generieren.

Alles was man dann noch tun muss, ist eine globale Konfiguration von ltr und rtl anzugeben in Form zusätzlicher Variablen anzugeben und diese in die Base-files der Sprachrichtungen zu inkludieren.

_ltr.scss
// defines variables for left-to-right
$left: left;
$right: right;
$dir: ltr;

_rtl.scss
// defines variables for right-to-left
$left: right;
$right: left;
$dir: rtl;

Damit kann man nun die folgenden Base-files für left-to-right und right-to-left Webseiten erstellen:

// base.ltr.scss
@import "_ltr.scss"; // ltr declarations
@import "_declarations.scss"; // global declarations
@import "includes/_reset.scss"; // reset.css
@import "includes/_header.scss"; // page header
…

//base.rtl.scss
@import "_rtl.scss"; // rtl declarations
@import "_declarations.scss"; // global declarations
@import "includes/_reset.scss"; // reset.css
@import "includes/_header.scss"; // page header
…

Es werden dann die Dateien base.rtl.css und base.ltr.css im Build Prozess erstellt und nur das jeweils gültige CSS von der Seite abhängig der Konfigurationseinstellungen geladen.

Im Endresult lädt somit keine unnötigen und überflüssigen Dateien, hat die volle Kontrolle über das generierte CSS, verzichtet auf den Einsatz weiterer Tools sondern generiert stattdessen aus einer Quelle die unterschiedlichen CSS Dateien für left-to-right und right-to-left Plattformen.

 Beitragsbild:
www.flickr.com/photos/bitterlysweet/26131863

Demo-Files meiner RWD-Präsi

Vor fast 2 Wochen habe ich einen Vortrag bei der PHP Usergroup Düsseldorf über Responsive Web Design gehalten. Es war ein tolles Erlebnis nicht nur aufgrund des fantastischen Publikums. In einer Live-Demo habe ich anhand eines kleinen Beispiels gezeigt welche Bedeutung der Wert “em” hat und wie man aus einer statischen Seite mit ein paar Regeln des responsive Webdesigns eine responsive Version erstellt. Die Files dazu liegen in meinem Repository auf Github: https://github.com/creinartz/wnpwrg

Reset CSS vs Normalized CSS

Wenn man ohne Angaben von CSS ein HTML Dokument erstellt und im Browser aufruft sieht man dennoch ein gestyltes Dokument. Nehmen wir folgendes Markup als Beispiel:

<body>
<ul>
    <li>ein li tag</li>
</ul>
<em>hier ein em-tag</em>
<h2>ein h3-tag</h2>
<strong>das ist strong</strong>
</body>

Wir sehen dann vemutlich folgendes:

user agent stylesheet
user agent stylesheet

Jeder Browser verfügt ein eigenes Stylesheet, das User Agent Stylesheet, das Formatierungen für z.B. eine Überschrift enthält damit diese auch wie eine dargestellt wird. Da man sich nicht auf das User Agent Stylesheet verlassen kann,  da zwischen den Browsern zum Teil erhebliche Abweichungen in den Defintionen des User Agent Stylesheets bestehen versucht man mit Hilfe eines Reset CSS diese Angaben zu reseten oder mit einem Normalized CSS zu normalisieren.

Bekanntestes Reset CSS ist sicher das von Eric Meyer (http://meyerweb.com/eric/tools/css/reset/). Mit einem Reset CSS sieht dann das Markup Beispiel von oben wie folgt in (jedem) Browser aus.

reset css
reset css

Wie man sieht wurden alle Default Angaben der einzelnen Elemente resetet.

Einen etwas anderen Weg geht das Normalized CSS (http://necolas.github.io/normalize.css/) das wie der Name schon andeutet die Darstellung der Elemente browserübergreifend versucht zu normalisieren. So nimmt setzt es z.B. die margin-Property des body-Elementes auf 0 und sorgt für einen einheitlichen Einzug eines li-Elementes das von Browsern gerne unterschiedlich im User Agent Stylesheet behandelt wird. U.a. setzt es noch die Standard-Schrift auf Sans-Serif.

normalisiert
normalisiert

Was man nun davon benutzt ist sicher auf dem eigenen Geschmack und den projektspezifischen Umständen geschuldet.

Beitragsbild:
www.flickr.com/photos/alex-web56/5360015934