CSS Vault Redesign

Die Redesign-Welle nimmt ihren “durchlauf”, da kann auch die Site die gute CSS-basierte Webdesigns 😉 listet nicht fehlen: in komplett neuem Gewande kommt CSS Vault v3 daher (ggf. reloaden). Leicht, schlicht, locker. Auf der Startseite sind nun einige Kategorien eingeführt, wie z.B. “Recently Redesigned”, was widerum den momentanen Trend zum relaunchen dokumentiert. Muss ich auch schon wieder? Ich könnte ja, aber ich glaube, ich bringe erstmal den Umzugsstress hinter mich. Danach sehen wir weiter.

Lummaland

lumma.de wurde justement redesignt.

Eine Insel mit zwei Bergen,
und im tiefen weiten Meer,
mit viel Tunnels und Geleisen
und dem Eisenbahnverkehr
nun wie mag die Insel heißen
ringsherum ist schöner Strand
jeder sollte einmal reisen
in das schöne Lummerland

🙂

80/20 Principle of Webdesign

Cameron Moll stellt die folgende Theorie auf:

Ananlog zum berühmten 80:20-Prinzip (20% von etwas ist verantworlich für 80% von etwas), sind in der Welt der Weblog für 80% aller webdesignerischen Errungeschaften 20 Leute (nicht 20%) verantwortlich. Und liefert eine Linkliste mit den 20 Innovatoren der Designblogosphäre.

Gut, das mag eine gewagte These sein, oft scheint sie jedoch zu stimmen. Muss man noch entscheiden, ob man das gut oder schlecht findet. Oder einfach davon profitieren und von den A-List-Designern kräftig lernen. Zu diesem Zwecke kann man die Liste mal für die eigenen Bookmarks kontrollieren.

Semantische Streitigkeiten

Matthew Thomas schreibt in When semantic markup goes bad über die falsch verstandene Nutzung semantischer HTML-Tags. Er hält es für schlicht falsch, <em> (em = emphasis = die Betonung) und <strong> (= strong emphasis = starke Betonung) für alle Gelegenheiten zu benutzen, bei denen etwas kursiv oder fett dargestellt werden soll. So stellt man beispielsweise Text aus anderen Sprachen eher kursiv dar, ohne es zu betonen oder muss bestimmte mathematische Formelzeichen fett darstellen, aber nicht betonen. Thomas besteht stattdessen auf die weitere Nutzung von <i> und <b>. Ich selbst bevorzuge ja auch ausdrücklich, soviel semantischen Code zu schreiben wie möglich, Thomas wirft jedoch interessante Fragen auf. Auch die Gegenartikel Understanding semantics, Matthew Thomas Sematic Markup (und mehr) helfen so recht nicht weiter.

Warum Semantik?

Am Anfang war HTML. Denkpause. Man bastelte sich seine Seiten zurecht, so dass sie gut aussahen. Dazu benötigte man Tags, die einem bestimmten Aussehen auf der Webseite entsprachen, also zum Beispiel bold/fett oder italic/kursiv, oder die font-Tags. Womit man das Aussehen seiner Webseiten erreichte war ziemlich egal, schließlich wurde alles in eine Datei gepackt, die nur einen Sinn hatte: mit Webbrowsern angesehen zu werden. Wichtig ist was hinten raus kommt. So entstanden mit der Zeit die tollsten Konstruktionen, so richtiger Scheiss-Egal-Code, den niemand lesen konnte, oft nicht mal der “Designer” selbst.
Aber: wir haben uns weiterentwickelt. Vor der Tür steht ein Web, das eben nicht mehr nur für die Anzeige im Browser geeignet sein soll, sondern von allen möglichen Programmen, Diensten und Geräten genutzt werden soll, vom vorlesenden Browser für Sehbehinderte bis zum Mobiltelefon. Und um dies zu erreichen gibt es eigentlich nur eine Lösung: die Trennung von Inhalt und Design bzw. richtiger: “Content and Presentation”. Aller Inhalt kommt in das HTML-File und alle das Aussehen der Seite betreffenden Dinge werden im CSS geregelt.
Da passen die Tags, die lediglich das Aussehen bestimmen natürlich nicht wirklich hinein. Denn dieser Text ist fett ist noch lange keine inhaltliche Aussage. Stattdessen benutzen viele (und meist auch richtig) <strong> beispielsweise. Das heisst, etwas wird stark betont, was einer inhaltlichen Aussage gleich kommt. Aber: wie die Webbrowser dies nun interpretieren ist dabei nicht vorgegeben (nennen wir es mal glücklichen Zufall, dass eigentlich alle Browser hier den Text fett drucken). Soll der Text anders aussehen, dann wäre das wieder Sache des CSS.

Aber geht das immer?

Das wäre dann ja auch alles gar kein Problem, wenn es denn für jede Gelegenheit den richtigen semantischen Tag gäbe. Matthew Thomas zählt Beispiele auf, wo das nicht so passt. Zum Beispiel eben, die Geschichte mit dem Text in Fremdsprache: je ne sait pas. Er will an diesen Stellen schreiben:

<i lang="fr">je ne sais pas</i>.

Von anderer Seite wird vorgeschlagen stattdessen ein span-Element zu benutzen, ungefähr so:

<span lang="fr">je ne sais pas</span>.

Was aber auch wieder nicht der Weisheit letzter Schluss ist, denn <span> ist jetzt auch nicht gerade das “Semantische HTML-Element des Jahrhunderts”. Aber zurück zu den alten Tags? In einem zweiten Artikel zum Thema stellt Thomas heraus, dass beispielsweise <i> und <b> keinesfalls in den aktuellen Standards des W3C als abgelehnt (“depreciated”) eingetragen sind, erst im Draft zu XHTML2.0 fehlen diese Elemente (genauso übrigens wie das lang-Attribut).

Und nun?

Bleiben nun welche Auswege?

  • Auf Semantik pfeifen und weiter alles so schreiben, wie einem die Nase gewachsen ist. Das macht das Netz nicht schöner, und wer auf Zukunftssicherheit setzt, wird mit XHTML2.0 seinen Spass haben, aber das ist ja mindestens noch 10 Jahre hin.
  • Nur semantische Tags verwenden, aber in wenigen Fällen, wenn das nicht passt nach Ersatzlösungen suchen bzw. Text zwangsweise falsch auszeichnen.

Beides nicht so toll, wie ich finde. Da haben wir noch einen langen Weg vor uns, bis wir Content und Presentation wirklich getrennt haben. Hoffentlich gibt es das Web dann noch. Und mein Blog. Und XHTML. Vielleicht können wir ja mit Evangilismus nicht alles lösen, schließlich wartet der Kunde, der Chef, der Leser auf seine Website.