Überarbeitete 2. Auflage: CSS – Cascading Style Sheets Level 3

Ihr erfolgreicher Einstieg in die Formatierungssprache CSS!

Frisch überarbeitet: die zweite Auflage meines CSS3-Buches.

Alle Texte sind auf den aktuellen Stand der Technik gebracht worden, den Möglichkeiten neuerer Browser-Versionen wird Rechnung getragen.

Wenn Sie sich CSS3 selber beibringen möchten oder ein Nachschlage-Werk für Schule, Studium oder Beruf suchen: mit diesem von Dozenten in Universitäten und Volkshochschulen verwendeten Lehrbuch, lernen Sie die Sprache, mit der Sie moderne Webseiten gestalten können.

Gedruckt (besonders bequem zum Lesen):
http://www.herdt.de/artikel/CSS3/CSS—Cascading-Style-Sheets-Level-3/#description

Digital (PDF – besonders bequem zum Nachschlagen):
http://www.herdt-digital.com/index.php?route=product/product&path=64&product_id=131

Link

Im Moment kann man sich kaum noch in einem Social Media Network bewegen, ohne über den Slider Slick zu stolpern. Scheint im Moment ziemlich angesagt zu sein und die Anleitung ist mit Code als “Copy & Paste”-Vorlagen gespickt.

Dem Einsatz in einer eigenen Website steht also nichts im Weg!

Slick beeindruckt mit einer langen Feature-Liste, umfangreichen Optionen und angeblicher Barrierefreiheit. Klar, dass ich hellhörig geworden bin. Bisher habe ich ihn noch nicht produktiv eingesetzt – ich steh generell nicht besonders auf Slider – aber Slick gefällt mir vom ersten Eindruck her.

Setzt Ihr Slick bereits ein? Welche Erfahrungen habt Ihr gemacht?

Umsetzung zugänglicher Webseiten

20131120-162814.jpgMan sollte nicht den Eindruck erwecken, es sei wahnsinnig
zeitaufwändig, zugängliche Webseiten zu erstellen. Nötig ist
eigentlich vor allem ein einmaliger Lernaufwand, damit man weiß,
wie es geht. Beispielsweise semantisch korrekte Auszeichnung: die
Tags zur Auszeichnung einer Überschrift schreiben sich nicht
langsamer als die für das Element strong. Man muss nur wissen, dass
strong eben nicht für die Auszeichnung von Überschriften geeignet
ist und wie es besser geht. Dasselbe gilt für die Verwendung von
header, main, blockquote, usw statt div. Auch zusätzliche Angaben
sind in aller Regel schnell gemacht. So soll die Hervorhebung von
angetabbten Links mindestens so deutlich sein, wie die
Hervorhebungen für Mausnutzer (:hover). In der Praxis bedeutet es,
dass ich einen langen Selektor wie main #content article a:hover
markiere, kopiere und ein zweites mal einfüge, hover durch focus
ersetze und ein Komma einfüge. Ergebnis: main #content article
a:focus, main #content article a:hover Dauer etwa 5-10 Sekunden.
Das ist selbst bei aufwändig durchgestylten Webseiten, an denen man
mehrere Tage entwickelt, selten mehr als zehn Mal nötig.
Gesamtaufwand maximal also eineinhalb Minuten. Nutzt man Vorlagen
wie HTML5-Boilerplate, hat man gleich jene ganze Reihe von Klassen
inklusive, die auch die Entwicklung zugänglicherSeiten erleichtern,
wie zum Beispiel visuallyhidden, um Texte nur für
Screenreadernutzer bereit zu stellen (oder falls mal CSS nicht
funktioniert). Mit einem durchdachten Workflow, klug gewählten
Vorlagen und Werkzeugen und dem nötigen Wissen entsteht dafür kaum
ein nennenswerter Mehraufwand. So ist es mit vielen Dingen.
Berücksichtigt man gleich beim Design ausreichende Kontraste und
gibt man für das Layout nicht pixelgenaue Breiten statt fluider
Spalten vor (was in Zeiten des responsiven Designs ohnedies
schwachsinnig ist), wie viel länger dauert das dann, wenn
überhaupt? Zugegeben, der Testaufwand steigt. Aber in Zeiten
responsiver Layouts ist auch das anteilmäßig nicht mehr so der
große Brocken. Es ist deutlich aufwändiger in allen Browser- und
(mobilen) OS-Kombinationen zu testen, als einen Test auf
Zugänglichkeit zu machen (der sich größtenteils in die anderen
Tests integrieren lässt). Viele Dinge, die für zugängliche
Webseiten vorgeschrieben sind, sind ohnehin nach W3-Standard nötig,
wie valides HTML, Verzicht auch veraltete Elemente und Attribute,
alt-Texte, semantische Elemente statt div und so weiter. Aufwändig
und teuer (und relativ nutzlos) sind dagegen Zusammenfassungen in
Leichter Sprache und Deutscher Gebärdensprache. Entweder man
“übersetzt” alle Inhalte (de facto wohl nicht zu leisten) oder man
steht auch dazu und lässt es gleich ganz. Für mich sind diese
Forderungen der BITV (die ohnehin nur für die wenigsten Sites,
nämlich Portale verlangt werden) reine Alibi-Forderungen, um sagen
zu können, dass man Gehörlose und Menschen mit kognitiven
Einschränkungen auch ernst nimmt. Von daher kann ich auch ein Stück
weit verstehen, dass die Vertreter der diversen Behindertenverbände
behaupten, die BITV berücksichtige vor allem die Interessen von
Fehlsichtigen und Blinden. Nichtsdestotrotz: viele wesentliche
Verbesserungen sind schnell gemacht. Der zusätzliche Aufwand sollte
(für die einmaligen technischen und gestalterischen Aspekte) 10%
kaum überschreiten, selbst wenn es schon richtig gut gemacht wird.
Wenn man dazu noch bedenkt, dass bei zwei bis fünf Jahren der
Laufzeit einer Website der Dauerbetrieb deutlich mehr Ressourcen
verbraucht, sieht man, wie gering der Zusatzaufwand während der
gesamten Lebensdauer solch eines Projektes ist. Was ich aber nicht
verschweigen möchte, Sind inhaltliche (nicht technische)
Gesichtspunkte. Redakteure müssen einige Angaben machen, die für
zugängliche Webseiten vorgeschrieben sind, die aber die Nutzbarkeit
für jeden Leser erhöhen verbessern. Das sind beispielsweise
saubere, tippfehlerfreie Texte, die nach den Regeln der
entsprechenden Textgattung verfasst und sprachlich an die
Zielgruppe angepasst sind: Zitate sollen als Zitate ausgezeichnet,
Abkürzungen aufgelöst, fremdsprachige Texte übersetzt sein – alles
für jeden Webseitenbesucher und -Betreiber ein Gewinn. Denn auf
solche Webseiten kommt man gerne wieder. Das gilt auch für Tante
Google, die man mit den Auflösungen von Abkürzungen oder
Übersetzungen natürlich ebenfalls füttert und die Texte so
bewertet, als wären sie gut geschrieben (wichtiges zuerst, später
die Details und am Ende ein Fazit). Google ist sicher der häufigste
wiederkehrende “blinde” Besucher der meisten Websites. Darum hat
auch der Betreiber einer Seite etwas davon, wenn diese Kriterien
der Zugänglichkeit berücksichtigt. Ganz zu schweigen davon, dass
man potentiell mehr Besucher erreicht, wenn man Menschen mit
Behinderungen nicht durch unüberwindbare Hürden vom Besuch der
eigenen Site abhält. Und letztendlich macht es einen Auftraggeber
oder Webseitenbetreiber sympathisch, wenn er Seiten für alle
erstellt. So kann man soziale Kompetenz demonstrieren.

Texte aufklappen und verbergen mittels <details> und <summary>

Gerade auf Smartphones ist Platz kostbar. Aber auch auf dem Desktop ist es mitunter sinnvoll, Inhalte nur bei Bedarf ainzublenden. HTML5 bringt mit den Elementen details und summary alles nötige mit.

Beispiele mit etwas Text

Mittels details und summary kann man es dem Besucher einer Webseite die Entscheidung überlassen, Texte anzuzeigen oder zu verbergen.

Leider unterstützen derzeit weder Firefox noch InternetExplorer diese Elemente (details auf caniuse). Glücklicherweise hat ein freundlicher Belgier namens Matthias Bynens hingesetzt und ein Polyfill geschrieben, dass bei fehlender Unterstützung die korrekte Verhaltensweise emuliert. Dies stellt er als jQuery-Plugin zur Verfügung:
http://mathiasbynens.be/demo/html5-details-jquery

RWD und Retina Displays: Bilder mit hoher Qualität auf Kilobyte-Diät

Ich mag PNG. Aber seit ich mich mit responsivem Webdesign auseinandersetze, greife ich doch immer häufiger auf JPEG zurück. Natürlich kann man für alles JavaScript einsetzen. Auch um auf kleinen Bildschirmen kleine Bilder auzuliefern und große Bilder auf großen Bildschirmen. Weil ich möchte, dass möglichst viel ohne JavaScript läuft, habe ich aber immer öfter mit den Kompressionsraten an großen Bildern heumgespielt und festgestellt, dass häufig erstaunlich kleine (leichte) Dateien dabei herauskommen, JPEG sei dank.

Das war erst mal nur eine Praxiserfahrung, die ich so hingenommen habe. Ich dachte, das sei mehr oder weniger zufällig so, weil die Bilder, mit denen ich gearbeitet hatte, das so hergaben. Allerdings trat dieser Zufall so häufig auf, dass ich in letzter Zeit bei Vorträgen und Schulungen immer häufiger empfahl, mit der Kompressionsrate zu “spielen” statt Bilder generell per JavaScript auszutauschen (was die Bereitstellung und Abarbeitung eines weiteren JavaScriptes erfordert, vorausgesetzt JavaScript ist überhaupt aktiv).

Irgendwann wollte ich dieses Phänomen mal genauer untersuchen, aber die Arbeit wurde mirvon Dann Jobsis abgenommen. Wie sich herausstellt, handelt es sich nicht um an eine Anhäufung von “Einzelfällen” sondern um eine belegbare Gesetzmäßigkeit.

Auch wenn es trotzdem immer noch Fälle geben mag, wo der Einsatz eines JavaScriptes Sinn macht, werden diese Fälle seltener:

Retina Revolution

Linktipps Responsives Webdesign (RWD)

In aller Kürze ein paar nützliche Links zum Thema responsives Webdesign:

Online Tool zum  Testen:
https://quirktools.com/screenfly/

RWD muss schnell sein und ein (von mir nicht präferierter) Lösungsansatz:
http://tympanus.net/Tutorials/ResponsiveRetinaReadyMenu/

Die Bücher aus dem Galileo-Verlag haben mich immer wieder begeistert. Das unten verlinkte werde ich mir auf jeden Fall besorgen. Ihr solltet Euch mal die Videos ansehen. Vor allem im Video Lektion: 3.4 Mobile First, Content First [12:02] wird eine prima Lösung gezeigt, um (ältere) InternetExplorer zu unterstützen, die ja keine media queries verstehen (Stichwort response.js).

Da diese Lösung JS benötigt könnt Ihr natürlich alternativ (falls die Seite auch ohne JS laufen muss) meine an anderer Stelle vorgeschlagene Lösung verwenden (d.h. alle Angaben in media queries für den IE wiederholen. Entweder per HTML5-Boilerplate-Klasse oder in einer CSS-Datei extra für den IE (was ich aus Performanz-Gründen empfehlen würde)).

Hier der Link zum Buch, (Auszüge und einige Videos können Online betrachtet werden):
http://www.galileocomputing.de/katalog/buecher/titel/gp/titelID-3347

Alle hier genannten links habe ich auch der Seite über Responsoves Webdesign zugefügt.

Speed is a feature – Tuning für Ihre Homepage

Wer eine Webseite besucht, möchte normalerweise nicht auf ein weißes “Blatt Papier” starren.

Um die eigene Webseite richtig schnell zu machen, muss Men eigentlich nichts tun. Wenn man ein statisches HTML-Dokument erstellt und dieses weder gestaltet noch per JavaScript aufpeppt, ist die Seite schneller beim Betrachter, als der gucken kann.

Aber wer will schon eine ungestaltete Webseite? Also kommen CSS, JavaScript, Bilder und all die anderen Zutaten hinzu, mit denen man den Besuch zu einem Erlebnis für den Betrachter macht.

Damit die Seite trotzdem blitzschnell beim Betrachter ankommt, kann man an verschiedenen Schrauben drehen. Dabei muss die Seite nicht immer schneller laden: es kommt auch darauf an, wann die großen Brocken übertragen werden. So kann man beispielsweise die meisten JavaScripte nach den eigentlichen Inhalten laden. Der Besucher bekommt auf diese Weise schnell etwas zu sehen und im Hintergrund wird noch unbemerkt weitergeladen.

Wie das geht und noch viel mehr erklärt die Seite browserdiet.com (die eigentlich Websitediet heißen müsste)

Auch Erfahrene Entwickler finden hier noch die eine oder andere Perle – und weil die Texte kurz und übersichtlich geordnet sind, lassen sich diese Perlen auch schnell finden.

20130331-110203.jpg

Empfohlene WP-Grundausstattung

Auf seinem Blog blogtrainer.de empfiehlt Karl-Heinz Wenzlaff einige PlugIns, die auf keiner Webseite fehlen sollten, deren Grundlage WordPress ist. Da ich seine Meinung teile, spare ich mir einen eigenen Artikel dazu. Zwar könnte man für den einen oder anderen Zweck auch ein anderes PlugIn wählen (z. B. für das Backup), dann sollte man aber wissen, was man tut…
Anfänger machen mit der vorgestellten Auswahl jedenfalls nichts verkehrt!