http://dconstruct.org/, http://webjamsession.com, http://barcamp.at, http://BlogTalk.net

Willkommen beim Casted-Podcast Nummer 5.

Zuersteinmal möchte ich mich für das lange Fernbleiben entschuldigen, aber mein PC machte Anfang Juni Probleme und es sieht so aus als ob sie noch nicht ausgestanden wären.

Heute gibt es jedoch mal wieder eine Ladung Nachrichten aus der Welt der Webentwicklung.

Amazon Redux

Andy Rutledge, ein Webentwickler aus der Nähe von Dallas, hat auf seiner Webseite ein Redux der Amazon.com-Seite veröffentlicht.

Er zeigt, das auch eine komplexe Seite wie Amazon durch eine Neuausrichtung wieder zu einem Erlebnis werden kann.

Das ganze stellt er zusätzlich noch sehr ausführlich in einem Artikel dar: andyrutledge.com/amazon_redux.php

Wer sich das Ergebnis anschauen möchte sollte unter andyrutledge.com/amazon_redux_example.html vorbeischauen.

Neues vom W3C

Das World Wide Web Consortium, kurz W3C, musste in letzter Zeit etwas Kritik einstecken:

Björn Hörmann hat seine Arbeit bei der Qualitätssicherung des W3C aufgegeben, weil er sich Sorgen macht in welche Richtung die Entwicklung geht.

Dabei kritisiert er vor allem die mangelnde Weiterentwicklung des Validators, die fehlende Hardware und die ausbleibende Wartung von Spezifikationen.

Er spricht dabei auch die Verkürzungen an, die in HTML grundsätzlich erlaubt seien, aber von keinem Browser interpretiert würden.

Jeffrey Zeldman, dessen Buch “Designing with Webstandards” in einer Überarbeitung erscheinen wird, klinkt sich in die Diskussion mit ein:

Er fragt sich, ob sich das W3C nicht von seinen Designern und Entwicklern abgekoppelt habe.

Er kritisiert den fehlenden Meinungsaustausch mit Nicht-Mitgliedern und verweist auf das WASP-Projekt, das – außerhalb des W3C – viel Arbeit investierte um Webstandards zu promoten.

Er bezeichnet das W3C als Fernsehwerbung vor der Einführung des Kabelfernsehens, als geschlossenes Ein-Weg-System.

Am Ende seines Artikels verweist er auf Mikroformate als Alternativen zu den aufgeblähten Spezifikationen des W3Cs.

Die Entwicklung scheint aber beim W3C nicht stehen geblieben zu sein. Gerade in dieser Woche hat das Konsortium wieder ein Projekt vorangebracht.

XHTML2

XHTML2 ist der Nachfolger von XHTML1. Dabei wird XHTML2 nicht völlig Rückwärtskompatibel sein. Per XML-Parser und angewandtem Stylesheet könne aber schon vieles von XHTML2 umgesetzt werden. Das W3C spricht im neuesten Draft sogar von 95% aller Browser.

Einiges XHTML2-spezifisches wird natürlich noch nicht unterstützt.

Folgende Neuerungen soll es gegenüber XHTML1 geben:

• Es gibt nun section und h Elemente, die die Struktur des Dokumentes besser widergeben sollen.
• Das hr Element soll ein generisches Trenn-Element sein. Zur Unterstützung dieser Absicht wird es in separator umbenannt.
• Zeilenumbrüche werden zukünftig nicht per br Element eingeleitet. Die einzelnen Zeilen sollen in l Elemente eingefasst werden. Das mache es auch möglich Zeilen zu nummerieren oder sie abwechselnd zu färben.
• Absätze können jetzt auch Listen und Tabellen enthalten. Dies ist beispielsweise bei Aufzählungen innerhalb eines Satzes sinnvoll.
• Es wird ein neues Element nl geben, das eine Navigationsliste darstellen soll. So sollen beispielsweise Drop-Down-Menüs von den Browsern direkt unterstützt werden.
• In Zukunft wird jedes Element zum potenziellen Bild: Der Inhalt des Elements wird als Alternative zu einem per src Attribut referenzierten Bildes verstanden und nur dann angezeigt wenn es nicht existiert.
  Vorteile sind neben der besseren Durchsuchbarkeit der Seite die einfachere Handhabung im Vergleich zum selten genutzten longdesc Attribut. Zudem hat diese Methode mehr Möglichkeiten der Gestaltung als ein alt Text.
  Nachteil könnte sein, das der Text auf dem Bild nicht mit dem Alternativtext übereinstimmt. Das würde natürlich Suchmaschinen-Spammern in die Hände spielen.
• Statt del und ins Anweisungen kann das neue edit Element benutzt werden um Änderungen an einem Dokument sichtbar zu machen.
• Jedes Element kann nun ein Link sein, wenn es ein href Attribut besitzt. Dadurch werden bspw. in Listen Verschachtelungen gespart.
• Es gibt nun das role Attribut, welches die Rolle im Dokument veranschaulicht und Semantik zum Dokument hinzufügt. So ist beispielsweise ein Absatz mit der Rolle “note” möglich um eine Notiz auszuzeichnen.
• Statt HTML-Event-Handler werden XML-Events eingesetzt. Sie erlauben eine größere Freiheit.
• Auch bei den Formularen wird die HTML-Version vom XML-Pendant abgelöst: XML-Forms.

Draft beim W3C

Mit diesem Ausblick auf die Zukunft entlasse ich euch in die Woche. Musik gibt es keine, weil ich hier am Modem sitze und die MP3-Dateien nur bitweise hier eintreffen.

Auch hier wieder der Text im Wortlaut:

Willkommen beim vierten Podcast.

Heute geht es um das hochauflösende Internet.

Hochauflösendes Internet? Weshalb braucht man das denn? Nun diese Frage ist relativ leicht zu beantworten: Auf dem Bildschirmmarkt gibt es einen Trend zur Miniaturisierung.

Dies bedeutet, dass die Pixelzahl steigt, die Größe der Bildschirme jedoch abnimmt.

Mein Notebook, welches jetzt fast zwei Jahre alt ist, hat beispielsweise eine Auflösung von 1280×800 Pixeln, bei einer Bildschirmdiagonale von 15,4 Zoll.

Das neue MacBook hat die selbe Auflösung, der Bildschirm ist aber nur 13,3 Zoll groß.

Das bedeutet, das die Pixel schrumpfen.

Aber keine Panik, das ist kein neuer Prozess. Erinnert sich noch jemand an die Anfänge von Windows 95? Da war man froh, wenn man eine Auflösung von 800×600 auf einem 15 Zoll-Monitor hatte.

Kein Wunder also, dass 12 Pixel große Schrift bald zum alten Eisen gehört. Mehr noch.

Kleine Displays operieren teilweise bereits mit 220 DPI. Was DPI ist? DPI ist eine Abkürzung aus der Druckersprache und bedeutet Dots per Inch. Das ist also die Anzahl der Farbkleckse pro Zoll.

Nun passen Farbkleckse nicht zu LCD-Displays, weshalb man sich eigentlich darauf geeignet hatte PPI zu sagen, also Pixel pro Zoll.

Dies bedeutet also auch, dass Webprojekte immer kleiner werden.

Eine Webseite, die den Viewport eines 800×600er-Monitors gerade so ausfüllt ist bei einer Auflösung von 1920×1200 nur noch ein Schatten ihrer selbst.

Was tun?

Man kann die Webseite so vergrößern, dass sie wieder lesbar ist. Dies bedeutet aber, dass Grafiken ebenfalls vergrößert werden, was natürlich zu einer hässlichen – wenn auch feineren – verpixlung führt.

Als Lösung bietet sich dann natürlich ein mitskalierendes Vektorformat wie SVG (also Scalable Vector Graphics) an.

Ein neuer Vorschlag kommt von den Entwicklern des Webbrowsers Safari.

Sie schlagen eine Erweiterung der Media Queries von CSS3 vor. Media Queries dienen dazu Informationen vom Endnutzergerät abzufragen.

Man kann also die Breite eines Fensters abfragen und ein entsprechendes Stylesheet verwenden.

Das Surfin’ Safari Blog hat sich mit eben dieser Erweiterung der Safari-Entwickler befasst. Sie lässt Abfrage zum Pixelverhältnis zu.

Man wird also Safari ein Medium angeben können, welches screen and min-device-pixel-ratio: 2 hat.

Wenn also (durch Zoom) ein CSS-Pixel 2×2 Gerätepixel sind wird ein spezielles Stylesheet angezeigt.

Ob und wie dieser Vorschlag vom Safari-Team vom W3C auf- und angenommen wird ist noch nicht vorherzusehen.

Es ist aber sicher, dass wir eine entsprechende Spezifikation für hochauflösende Bilder benötigen.

Kommentar der Woche

Zu jeder Ausgabe soll es jetzt einen Kommentar eines Webentwicklers geben. Heute ist es Håkon Wium Lies Antwort auf die Frage, weshalb das W3C so langsam sei:

Nein, ich denke nicht, dass das W3C zu langsam ist. Das W3C ist nicht der Flaschenhals, das sind die Browser. Der dominierende Browser auf dem Markt wurde jahrelang nicht auf den neuesten Stand gebracht und es ist nicht sinnvoll, wenn die Spezifikationen der Entwicklung zu weit vorraus sind.

Weitere Antworten und Einsichten von Håkon Wium Lie findet man unter interviews.slashdot.org

Das war die casted-Ausgabe dieser Woche. Nächste Woche bin ich wieder an mein Modem gefesselt, deshalb kann ich kein Erscheinungsdatum garantieren.

Wer mich einmal live erleben will kann auf einen der Webmontage in Karlsruhe am 03. Juli, in Trier am 10. Juli oder in Frankfurt am 14. August kommen.

Zum Abschluss noch ein wenig Reggae, wie immer aus dem Podsafe Music Network. Hier sind Satori mit Loosing Time.

Hier der Text im Wortlaut:

Willkommen bei der ersten Ausgabe von Casted während der Fußball-Weltmeisterschaft.

Heute eine Kurzausgabe mit den folgenden Themen:

1. Soll Inline-CSS per style-Attribut bei Strict-Doctypes erlaubt sein?
2. JavaScript als Ersatz für das target-Attribut.

Soll Inline-CSS per style-Attribut bei Strict-Doctypes erlaubt sein?

Nicht, wenn es nach Emil Stenström geht, einem Informatik-Studenten aus Stockholm.

Er hat auf friendlybit.com einen Artikel veröffentlicht, der den Titel ‘Inline CSS schould not be allowed in strict doctypes’ trägt.

Als Begründung führt er an, dass in einem als Strict ausgezeichnetem Dokument keinerlei Styleangaben enthalten sein sollten.

Dies gelte ja auch für alle Präsentationsangaben, beispielsweise das Attribut bgcolor im body-Element oder das center-Element.

Seltsam findet er, dass stattdessen style-Attribute für direkte Formatierungen im HTML-Quelltext erlaubt sind.

Sie widersprechen allem wofür der restriktivste Doctype steht – vor allem wiederspricht es der Trennung von Inhalt und Gestaltung.

Grundsätzlich hat Stenström natürlich recht, deshalb wird von der Verwendung des Attributs auch generell abgeraten.

Manchmal kann jedoch die Flexibilität des style-Attributs Gold wert sein, beispielsweise bei kurzfristigen Änderungen oder, bei Elementen, die lediglich einmal auf der kompletten Webseite vorkommen.

Eine Auslagerung in eine externe CSS-Datei könnte in diesem Fall die CSS-Datei unnötigerweise aufblähen und so einige der Vorteile von CSS aufheben.

Das gleiche gilt bei einem Redesign, bei dem diese einzelnen Elemente ihre Gestalt behalten.

Es gilt also: Die Trennung vn Inhalt und Gestaltung sollte nicht angetastet werden. Ausnahmen dürfen lediglich Inhalte bieten, die einmal vorkommen und sich deshalb einer Auslagerung in eine externe CSS-Datei nicht lohnt.

Eine bessere Lösung könnte dann aber eine Klasse oder ID für das Element und entsprechtende Anweisungen in einem style-Element im head-Bereich sein.

JavaScript als Ersatz für das target-Attribut.

Roger Johansson von 456 Berea Street hat eine Javastcript-Lösung für das Öffnen neuer Fenster (Version 1.1) entworfen.

Wenn sich heute beim Klick auf Links Fenster öffnen steckt meist eine Javascript-Anweisung oder das target-Attribut mit dem Wert _blank dahinter.

Beide Lösungen sind meist nicht optimal umgesetzt. JavaScript-Links sind meist ohne Javascript nicht benutzbar und aus einer Anweisung wie javasccript:openwin(‘334455’); kann niemand herausfinden wohin die Reise gehen soll.

Das target-Attribut ist in dieser Beziehung zwar zugänglicher beraubt jedoch den Benutzer der Möglichkeit selbst festzulegen, wo er Links gerne geöffnet haben möchte.

Schließlich sollte er zwischen dem gleichen Fenster, einem neuen Tab oder einem neuen Browserfenster wählen können.

Das target-Attribut ist zudem bei strictem Doctype nicht erlaubt.

Die Javascript-Datei, die Roger auf seiner Internetseite bereitstellt ist relativ einfach und enthält alles, was unaufdringiches Javascript ausmacht.

• Jeder Link mit der Klasse non-html wird in einem neuen Fenster geöffnet.
• Zudem wird ein Hinweis eingefügt, der die Besucher vorwarnt, falls JavaScript an-, CSS jedoch ausgeschaltet ist.
• Es können die browsereigenen Tasten benutzt werden um Links in neuen Tabs zu öffnen.

So können beispielsweise externe Links oder PDF-Dokumente oder Videos in einem neuen Fenster geöffnet werden, sofern JavaScript verfügbar ist.

Die neuen Links (die ja eh durch die Klasse non-html gekennzeichnet sind) müssen natürlich per CSS so ausgezeichnet werden, dass der Benutzer erkennen kann, wohin der Link führt.

Ob das Öffnen von neuen Fenstern überhaupt sinnvoll ist, oder ob das den Benutzer nicht eher verwirrt kann man nicht sagen.

Oft kommt es vor, dass Benutzer versuchen auch im neuen Fenster den Zurückbutton zu benutzen.

Andere haben Probleme, wenn sich im selben Fenster eine ganz andere Webseite öffnet.

Wieder andere meinen, dass die Gestaltung einer Webseite und wo sie sich öffnet nur zweitrangig ist, sofern der Inhaltsbereich klar erkennbar ist.

Abspann

Das war die dritte Ausgabe des casted-Podcast, ich freue mich auf das nächste Mal.

Für Anregungen und Kritik bin ich immer dankbar. Einfach eine E-Mail an casted@yatil.de schicken oder natürlich als Kommentar zu diesem Podcast.

Zum Ausklang nun ein Lied aus dem podsafe music network: Passend zum Wetter in Deutschland und Österreich: Monkey mit Summertime Sun.

Im Folgenden der Text aus der aktuellen Ausgabe des Technikwürze-Podcast. Die nächste Ausgabe des casted-Podcasts gibt es eventuell am Mittwoch.

Hallo. Mein Name ist Eric Eggert und ich bin der Verfasser des casted-Webstandardspodcasts.

In dieser Ausgabe geht es um die Unterschiede zwischen HTML und XHTML anhand eines praktischen Beispiels.

Neben den bekannten Unterschieden wie Kleinschreibung der Tags, Attributwerte in Anführungszeichen und Wohlgeformtheit gibt es auch Differenzen, die sich nicht so einfach ausmachen lassen.

Am Beispiel einer verschachtelten Tabelle lässt sich solch ein Fall ganz gut aufzeigen.

Die eine Tabelle hat zwei Zeilen und zwei Spalten, das heißt also, dass wir innerhalb des Tabellenelementes zwei tr-Elemente haben, die ihrerseits je zwei td-Elemente enthalten.

Eine dieser Zellen enthält eine weitere Tabelle, deren Gestalt für uns nicht erheblich ist.

Wenn wir nur die äußere Tabelle per CSS ansprechen wollen bietet sich eine Konstruktion per Childselektoren, also dem Größer-Symbol, an:

body > table > tr > td { background-color: #eee; }

Wenden wir diese CSS-Angabe nun auf ein HTML-Dokument an bemerkt man, dass nichts passiert. Die Angabe findet lediglich dann Anwendung, wenn man eine XHTML-Datei auch als XHTML parst.

Dazu muss das Dokument mit dem Content-Type application/xml application/xhtml+xml vom Webserver gesendet werden. Ein Vorgehen, welches der Internet Explorer allerdings nicht versteht.

Weshalb wird die Angabe aber in XHTML interpretiert und in HTML nicht.

Die Ursache ist eine Besonderheit in der HTML-Spezifikation nach der bei manchen Elementen sowohl Anfangs- als auch Endtags im Quelltext weggelassen werden können.

Eines dieser Elemente ist das tbody-Element: Die Spezifikation fordert mindestens ein tbody-Element im table-Element. Dessen Anfangs- und Endtags dürfen allerdings weggelassen werden.

Das bedeutet, dass nach der Verarbeitung durch den Parser ein tbody-Element existiert, das dann durch die CSS-Anweisung nicht angesprochen wird. Schließlich spricht der Child-Selektor nur direkte Kindelemente an.

Eine Anweisung wie body > table > tbody > tr > td greift also.

Und warum verhält sich (korrekt geparstes) XHTML denn anders, ist doch XHTML 1 eine einfache transformation von HTML 4 nach XML?

Bei der Transformation wurden die Sonderfälle zum Weglassen von Tags in Regelfälle umgewandelt. Meist bedeutet das, dass beide Tags vorgeschrieben werden.

Nicht so beim tbody-Element: Innerhalb der Tabelle wurden auch direkt tr-Elemente erlaubt um nicht ein zweites Schachtelelement bei einfachen Tabellen zu erzwingen.

Dies ist auch der Grund weshalb unsere Ausgangsanweisung in XHTML funktioniert, dort wird der “Quelltext” nämlich nicht angetastet.

Solchen “Quelltextmanipulationen” kann man mit dem Firefox-Plugin View formatted Content Source auf die Spur kommen.

Hörer, die tiefer in die Materie eintauchen möchten sind herzlich unter casted.yatil.de willkommen.