Auch wenn HTML5 ein Thema ist, um das man dieser Tage kaum herum kommt, so sind HTML4 und XHTML noch immer sehr weit verbreitet und werden es auch bleiben.
Alle (X)HTML Dialekte haben eine Gemeinsamkeit. Der Aufbau von Dokumenten, die in (X)HTML notiert sind, unterliegt gewissen Regeln. Damit ein Browser weiß, nach welchen Regeln ein Dokument aufgebaut ist, muss ein syntaktisch korrektes Dokument eine DOCTYPE Deklaration enthalten.
Leider sind die verfügbaren DOCTYPEs für HTML4 und XHTML ein wenig aufwendiger in der Notation als das beim HTML5 DOCTYPE der Fall ist.
Bei der Verwendung von HTML5 steht man immer wieder vor der Frage, welcher Browser welches HTML5 oder CSS3-Feature denn nun unterstützt.
Vor allem bei der Beurteilung ob und wie ein HTML5 Elemente oder eine CSS3 Eigenschaft verwendet wird, ist es durchaus von Vorteil, zu wissen, ab welcher Browserversion eine Element oder eine Regel unterstützt wird. Aus diesem Grund möchte ich diesen kurzen Artikel heute dazu nutzen, caniuse.com vorzustellen.
Der Umstieg von HTML4 oder XHMTL auf HTML5 bringt die eine oder andere Veränderung mit sich. Vor allem diejenigen, die vorher auf XHTML gesetzt haben, werden schnell vor der Frage stehen, wie es mit der korrekten Notation der Elemente, also der Syntax, aussieht. Wie werden (leere) Elemente geschlossen? Sind die Elemente Case-Sensitive? Welche Elemente und Attribute sind (nicht mehr) erlaubt? Wie werden leere Attribute notiert?
Gerade wenn man Wert auf syntaktisch korrekten Code legt, um das ist man sicher gewohnt, wenn man zuvor XHTML verwendet hat, sind einige Dinge zu beachten. Ganz so streng wie in XHTML sind die Regeln nicht mehr. Es ist durchaus Spielraum vorhanden, um den Code nach seinen Vorlieben zu gestalten. Dennoch sollte man um die Unterschiede wissen.
Zunächst einmal ist das <canvas>-Element nichts anderes als eines unter vielen Elementen, die in HTML5 definiert und somit Teil der Spezifikation (oder besser dem aktuellen Arbeitsentwurf) sind. Dennoch hält mit diesem Element etwas in die tägliche Arbeit Einzug, das bisher oft schmerzlich vermisst wurde: die Möglichkeit clientseitig dynamische Bildinhalte zu erzeugen und darzustellen.
Oftmals wird HTML5 auf die vielen (tollen) Effekte reduziert, die man auf so mancher Website findet. Dabei wird jedoch oft vergessen, dass HTML – und somit auch HTML5 – eine Auszeichnungssprache ist, die für die Auszeichnung von Inhalten und nicht für die visuelle Repräsentation von Inhalten verantwortlich ist. Um verschiedene Layout-Elemente umzusetzen, war es bisher weit verbreitet, Grafiken – also Images – zu verwenden. Dynamische Inhalte in Grafiken ließen sich bisher nur durch serverseitiges erzeugen oder verändern von Grafikresourcen erreichen. Das <canvas>-Element ermöglicht dies nun auch auf der Clientseite.
Wie es der Name schon erahnen lässt, stellt dieses Element eine Zeichenfläche (engl. canvas: Leinwand) zur Verfügung die mit Hilfe von JavaScript gefüllt werden kann.
Minimales Markup muss ein Designziel bei der Entwicklung von Websites sein. Dies hat gleich mehrere Vorteile. Neben der Erhaltung der Wartbarkeit hat dies vor allem den Vorteil, dass der eigentliche Inhalt ein höheres Gewicht erhält als bei Seiten, die viel unnötiges Markup enthalten. Ein weit verbreitetes Stück unnötigen Markups ist der sogenannte clearfix. Ein clearfix wird verwendet, um das floating von Elemente aufzuheben. Meist wird hierzu zusätzliches Markup in Form eines divs verwendet. das funktioniert zwar, ist aber wenig optimal. Dabei lässt sich dieses Problem einfacher und eleganter lösen.
Die Eigenschaft float wird oft dazu verwendet, Blocklevel-Elemente nebeneinander anzuordnen. Diese Site beispielsweise realisiert das dreispaltige Layout dadurch, dass die Spalten für das Menü, den Artikelinhalt und die Sidebar jeweils über die Eigenschaft float verfügen und somit nebeneinander angeordnet sind. Diese Vorgehensweise hat jedoch einen unangenehmen Nebeneffekt.
Immer dann, wenn man mit der Entwicklung von Layouts basierend auf HTML & CSS beschäftigt ist, steht man vor demselben Problem: »Wie gestalte ich die Anbindung von der Layoutinformationen dan die Elemente des HTML-Dokuments optimal?« Auf der einen Seite darf und sol die Kopplung zwischen Darstellung und Inahlt nicht zu eng werden, auf der anderen Seite muss der Code wart- und handhabbar aber auch performant bleiben. Wie kann eine möglichst gute Lösung also aussehen?
Auf dem Weg zu einer optimalen Lösung in Bezug auf die Verwendung von CSS-Selektoren und den durchdachten Aufbau von HTML-Dokumenten kommt man zwangsläufig irgendwann an den Punkt, an dem man sich fragt, was denn nun besser sei. Nutzt man besser verschachtelte Selektoren um den HTML-Code möglichst frei von Abhängigkeiten in Richtung Design zu halten, oder verwendet man besser ID- und Klassenselektoren für die Anbindung von Styles.
Alle Welt spricht darüber, und jeder will es – HTML5. Aber macht es Sinn, eine ganze Website auf HTML5 umzustellen, zu einem Zeitpunkt wo die Rahmenbedingungen dafür noch immer nicht zu 100% feststehen? Neben einer ganzen Menge an Arbeit kommt es bei einer Umstellung unweigerlich zu einer ganzen Reihe von Problemen. Lohnt sich also der Aufwand?
In den letzten Wochen habe ich daran gearbeitet, dieses Blog unter Verwendung von HTML5 und nicht wie zuvor XHTML weiter zu betreiben – eine lohneswerte Investition wie ich finde. Sicher war dieses vorhaben auch dadurch getrieben, endlich auch selbst Erfahrungen mit HTML5 zu sammeln. Nachdem bereits einige (wenn auch nicht genug) Artikel zum Thema HTML5 hier im Blog erschienen sind, möchte ich dieses Mal meine Erfahrungen mit der Umstellung auf HTML5 schildern und zeigen, was man bedenken sollte, wenn man mit dem Gedanken spielt, eine Migration anzugehen.
Weniger ist manchmal mehr. Je weniger Code für einen bestimmten Zweck benötigt wird, desto geringer ist die Wahrscheinlichkeit von Fehlern, desto höher ist evtl. die Wartbarkeit und desto effizienter kann dieser Code sein. Der Name LESS (Leaner CSS) mag aber trügen. Verwendet man LESS, ein Tool, das CSS um dynamische Komponenten wie Variablen, Funktionen uvm. erweitert, erhält man nicht zwangsweise weniger Code. Vielmehr biete LESS die Möglichkeit, CSS-Code schlanker, effizienter und komfortabler zu entwickeln.
LESS bezeichnet sich selbst als dynamische Stylesheet Sprache und erweitert CSS um dynamisches Verhalten. Es stellt Mechanismen wie Variablen, Operationen und Funktionen zur Verfügung, die es ermöglichen, Konstrukte ähnlich denen von Programmiersprachen in CSS zu realisieren. Die Auswirkung auf die Arbeit mit CSS ist enorm. Allein die Fähigkeit Variablen bzw. Konstanten zu verwenden, erleichtert einem die Arbeit und auch die Fehlersuche enorm. Werfen wir einen Blick auf die Möglichkeiten der Verwendung von LESS sowie deren Vor- und Nachteile.
Nun ist es soweit, der erste Clean Code Monday steht an. An dieser Stelle also allen Interessierten ein herzliches Willkommen.
In dieser Woche soll es darum gehen, eine Code-Bewertung vorzunehmen. Der Artikel CSS – id vs. class beschäftigt sich damit, herauszustellen, welche Variante der Anbindung von CSS-Definitionen an das Markup die bessere ist bzw. wann der ID-Selektor und wann der Klassenselektor verwendet werden sollte.
Zu diesem Thema gibt es eine große Anzahl von Artikeln im Netz, die sich mit dieser Thematik auseinandersetzen. Die meisten Beiträge setzen hierbei darauf, den ID-Selektor für die Anbindung von dokumentweit eindeutigen Elementen zu verwenden, den Klassenselektor hingegen für konkrete Elemente einer Klasse von Elementen. Meines Erachtens geht dieser Ansatz jedoch nicht weit genug.
Die Ergebnisse einer Untersuchung zu diesem Thema sind leider eindeutig. (Code-)Qualität hat nicht immer oberste Priorität. Dabei ist sie unabdingbarer Faktor, wenn man professionell mit der Entwicklung und Herstellung eines Produktes beschäftigt ist. Wer ärgert sich nicht darüber, ein Produkt gekauft zu haben, das sich im Nachhinein als mangelhaft erweist.
Leider sind Browser nicht sehr anspruchsvoll, was den Quellcode betrifft, der ihnen zur Interpretation vorgesetzt wird. Dieses Verhalten ist natürlich alles andere als förderlich, wenn es darum geht, guten und syntaktisch einwandfreien Code einzufordern. So ist zu erkennen, dass sich im auch professionellen Umfeld eine Haltung einschleicht (ich berichte aus eigener Erfahrung), die gegenüber Fehlern um einiges toleranter ist, als man annehmen dürfte.
Die »Clean Code – Initiative« hat sich zum Ziel gesetzt, die Verwendung von sauberem und effizientem Code im Netz zu fördern und zu fordern.
