Es setzt unter einigen vielleicht eine Ernüchterung ein. Euphorisch losgerannt, wird/wurde der ein oder andere jäh gebremst.

Es gibt zwar schon das ein oder andere interessante Beispiel, ja sogar reale, in die Praxis umgesetzte Ansätze. So z.B. bei Youtube. Das war’s dann aber auch schon. So lange noch in großem Stil Fallbacks eingebaut werden müssen, rechnet sich der Aufwand eben nicht. Außerdem gibts es bereits die ersten Nebenkriegsschauplätze. So könnte Flash beispielsweise zur Spaßbremse werden: Die Angst vor dem Flash-Ersatz.

D.h. wir werden noch eine ganze Zeit mit dem schnöden alten Internet zu tun haben. Man kann aber dankbar sein, dass manch Einer die Zeit für Experimente mitbringt oder (finanzkräftige) Unternehmen, mit entsprechenden Forschungsressourcen Pionierarbeit leisten. So kann zumindest der Druck auf Browserhersteller und Standards-Stricker hoch gehalten werden. Nach dem Motto: „Da ist eigentlich schon was, das auch noch ganz gut funktioniert und Verbesserungen verspricht“.

So einfach kann es eigentlich nicht sein. Zumindest, wenn man sich die Problem- und Fragestellungen in zahlreichen Foren etc. ansieht. Oft offenbare diese eben ein mangelndes Verständnis der Grundlagen. Gerade im Bezug auf CSS.

In zwei Artikeln wurde u.a. auch darauf eingegangen.

Weak constructs are most often due to the fact that people do not know what block formatting contexts are and what they do.Everything you Know about Clearfix is Wrong

Often when designers try to explain a particular feature of CSS to each other, they get a few things wrong.8 Common CSS Mistakes and How to Fix Them

In einem Bewerbergespräch hatte ich mal das Vergnügen mit einem Erwachsenen. Zwei Fragen haben ausgereicht aufzuzeigen, wie einfach HTML & CSS sind – nicht ;-)

Da muss man durch: Grundregeln und Spezifikationen

Grundlagenartikel, die mir selbst geholfen haben, habe ich vor ein paar Jahren mal übersetzt: Block vs. Inline und Vererbung und Kaskaden. Es werden zentrale Grundkonzepte von CSS beschrieben. Mit diesem Grundlagenwissen lässt sich so manchem CSS-Problem vorbeugen.

Als Dauerbrenner immer zu empfehlen, ist die Einführung von Michael Jendryschik: Einführung in XHTML, CSS und Webdesign.

Es kann auch nicht schaden, sich mal durch die kompletten Spezifikationen zu wühlen. Zumindest bei Verständnisproblemen mal darauf zurückzugreifen. Also ran an die Specs: (X)HTML & CSS (W3C).

Zugegeben machen Spezifikationen und Grundregeln nicht alle Kinder froh. Wer aber fleißig ist, wird als Erwachsener mehr Spaß haben.

HTML is an unbroken line stretching back almost two decades, and version numbers are a vestige of an older development model for standards that never really matched reality very well anyway. HTML5 is so last week. Let’s talk about what’s next.What’s Next in HTML, episode 1

Zu begrüßen wäre es auf jeden Fall, wenn man die Versionierung los wird. Am besten auch die für’s Web. Kein Web 2.0 mehr. Einfach Web. Dauerwurst.

Dazu andere

HTML-Zukunft: Nach 5 kommt 6 und What Comes After HTML5? Just HTML.

Es begann mit der Abhandlung Why CSS should not be used for layout. Weiter mit vielen Kommentaren im Blog unter dem gleich lautenden Titel Why CSS should not be used for layout. Immer daran denken: Nicht zu Hause nachmachen. Mit Tabellen spielen ist gefährlich.

Gefolgt von zwei weiteren Beiträgen. CSS and the meaning of life und On the semantics of HTML.

Die Hitze der Diskussion reicht aus, um die paar Tage bis zum Frühling zu heizen.

Via CSS for Layout. Another Rant

Aber keine Panik. Man muss es nicht heute schon auf Biegen und Brechen einsetzen.

Mit Biegen und Brechen meine ich v.a. die Handstände, die man machen muss, um auch den IE zu einem möglichst sinnvollen Umgang mit HTML5 zu bewegen. Davon abgesehen, ist die Browserunterstützung insgesamt noch nicht soweit, als das man bereits von einer unbedingten Praxisrelevanz sprechen müsste.

Die Devise lautet dranbleiben und informieren. Wenn man darüber hinaus noch Zeit hat, kann man auch schon mit HTML5 experimentieren oder es, soweit bereits möglich, einsetzen. Eric Meyer hat es jüngst in einem konkreten Projekt eingesetzt und berichtet darüber.

Eins vorweg: Sauberer Quellcode ist sehr wichtig und sollte immer das Ziel sein. Nicht nur der Standardkonformität wegen.

Würde sich alles so schnell entwickeln, wie vielleicht erträumt, dann hätte man bei Fehlern im (X)HTML-Quellcode sogar mit größeren negativen Auswirkungen zu rechnen. Diskutieren müsste man dann eher nicht mehr. Wie in Programmiersprachen auch, wäre es dann so, dass bei Fehlern in den meisten Fällen das Programm schlicht und ergreifend nicht läuft.

(X)HTML ist eine Auszeichnungssprache und lässt eben mehr Spielräume. Die Mühlen bei 3 mal W mahlen bekanntlich etwas langsamer. Und so ist es derzeit so, dass auch Websites, deren Quellcode mit 100 oder mehr Fehlern gespickt ist, im Prinzip meist einwandfrei funktionieren. Die Verstöße gegen die allgemein gültigen Regeln sind meist (noch) rein formaler Natur …

Diese Erkenntnis soll aber bitte kein Freifahrtschein dafür sein, sich nicht mehr um die Qualität seines Quell- und CSS-Codes zu kümmern.

So schwingt das nämlich derzeit bei der ein oder anderen Diskussion durch. Z.B. hier: Valid (X)HTML – Is it important?. Zumindest etwas kontrovers diskutiert. An sich ein guter Artikel mit guten Denk- und Diskussionsansätzen.

Angetrieben sind die neuerlichen Diskussionen wahrscheinlich auch durch die Ergebnisse der MAMA-Studie (Operas Studie zum Thema Standardkonformität von Websites). Der Artikel Operas MAMA-Studie: Die durchschnittliche Webseite validiert nicht beschreibt und kommentiert das Ganze ausführlich. Auch die anschließende Dikussion dazu ist einen Besuch wert.

Schlechter Code hat Konsequenzen

Die Auswirkungen sind bisher dann eher größer, wenn der Code nicht sauber und effizient im Sinne von Organisation ist. Dann nämlich wird man das früher oder später bei Wartungskosten merken. Dann, wenn man im Team möglichst schnell und effizient entwickeln muss. Dann, wenn es darum geht, dass Code schnell nachvollziehbar und wartbar sein soll. Dabei hilft es ungemein, sauberen und fehlerfreien Code zu schreiben. Es diszipliniert auf gewisse Weise. Etwas Disziplin und Konzentration haben noch nie geschadet.

Jens Meiert schreibt zu diesem und verwandten Themen immer wieder gelungene Artikel. Allgemein ist das ein Thema, dem er sich verschrieben hat und zu dem er vieles richtige zu sagen hat. Wer seine Artikel bisher noch nicht kennt, sollte sich das bei ihm mal ansehen: meiert.com

Bleib sauber – soweit’s geht (?)

Ganz deutlich bleibt festzustellen: Sauberen, d.h. validen und effizienten Quellcode zu schreiben, bedeutet in der Regel keinen Mehraufwand. Nur wenn man an die Grenzen der Machbarkeit stößt, sollte überhaupt über einen aktiven “Verstoß” nachgedacht werden.

Diese Grenzen sind wiederum dehnbar. Muss man bei einer Warnung des Validators immer auf fehlerhaften oder gar korrupten Code schließen? Ein Beispiel:

line 90 column 616 – Warning: trimming empty <span>Warnmeldung nach HTML-Tidy

Bei welcher Gelegenheit hat man damit zu kämpfen? Genau, bei “runden Ecken” z.B. Das wiederum ist ein anderes Thema. In diesem Sinne, schönen Feierabend.