Meinung: Ausnahmen von Best Practices<p>Geht nicht! Gibt’s nicht! Darf man nicht! Bei bestimmten Themen weiß jeder Webworker reflexartig, was sich gehört und wie man es richtig macht. Alles andere ist böse! Darf das HTML oder CSS vielleicht auch mal nicht validieren? Darf ein Webworker target="_blank" nicht doch benutzen? Darf er nicht? Doch, darf er. Wenn er einen guten Grund dafür vorweisen kann.</p>
HTML und CSS müssen validieren
<p>Nö, aktuell müssen HTML und CSS nicht unbedingt in jedem Fall validieren. Oder genauer: Es kommt darauf an. HTML und CSS entwickeln sich laufend weiter. Unter Umständen ist der Validator bei bestimmten Elementen nicht auf der Höhe der Zeit. Bzw. ändern sich einige Schemata so schnell, dass der Validator nicht nachkommt. Etwa beim Thema RDFa. Auf Wikipedia ist aktuell ein Beispiel für <a href="http://en.wikipedia.org/wiki/RDFa#HTML_5_.2B_RDFa_1.1_example">HTML 5 + RDFa 1.1</a> zu finden. Ergänzt um den HTML5-Doctype lautet es:</p>
<!DOCTYPE html><html prefix="dc: http://purl.org/dc/elements/1.1/" lang="en"> <head> <title>John's Home Page</title> <base href="http://example.org/john-d/" /> <meta property="dc:creator" content="Jonathan Doe" /> <link rel="foaf:primaryTopic" href="http://example.org/john-d/#me" /> </head> <body about="http://example.org/john-d/#me"> <h1>John's Home Page</h1> <p>My name is <span property="foaf:nick">John D</span> and I like <a href="http://www.neubauten.org/" rel="foaf:interest" lang="de">Einstürzende Neubauten</a>. </p> <p> My <span rel="foaf:interest" resource="urn:ISBN:0752820907">favorite book is the inspiring <span about="urn:ISBN:0752820907"><cite property="dc:title">Weaving the Web</cite> by <span property="dc:creator">Tim Berners-Lee</span></span> </span> </p> </body></html>
<p>Der <a href="http://validator.w3.org">HTML-Validator</a> aber meldet drei Fehler und sechs Warnungen. Auch Beispiele des W3C zum <a href="http://www.w3.org/TR/rdfa-syntax/">RDFa Core 1.1</a> validieren nicht. Wer Zeit und Muse hat, kann sich näher einarbeiten und findet vielleicht eine Variante, die der Validator kennt und akzeptiert. Aber auf größeren Webseiten werden die Autoren ja nicht alle Elemente selbst per Hand eintragen. Das wird ein entsprechendes RDFa-Modul übernehmen. Statt daran rumzuschrauben, kann es viel einfacher sein, auf ein Update des Moduls und/oder des Validators zu warten. In der Zwischenzeit validiert die Seite eben nicht.</p>
Das Ergebnis des RDFa-Beispiels im Validator des W3C
<p>Hinweis: Es existiert auch ein eigener <a href="http://www.w3.org/2012/pyRdfa/Validator.html">RDFa Validator</a>. Der meldet bei dem Wikipedia-Beispiel zwar keinen Fehler, prüft aber auch nur das RDFa und nicht den Rest einer HTML- oder XML-Datei.</p>
<p>Ähnliches gilt für CSS. Wir nutzen für viele Eigenschaften noch Browser-Prefixes. Beispielsweise für Transitions, damit diese in möglichst vielen Browsern korrekt funktionieren. Da die Prefixes Erweiterungen der Browserhersteller sind, die nicht zum Standard gehören, können diese zwangsläufig nicht validieren. Immerhin werden sie nur als Warnung angezeigt. Der CSS-Validator produziert also trotzdem ein ersehntes: Dieses Dokument wurde als CSS level 3 validiert!</p>
<p>Anders verhält es sich bei <a href="http://coding.smashingmagazine.com/2011/05/11/the-future-of-css-experimental-css-properties/">experimentellen Features</a>: neuen CSS-Eigenschaften in einem frühen Draft oder auch Ideen einzelner Browser-Hersteller. Wer sich zum Beispiel näher mit Typografie beschäftigt, wird eventuell auf die Eigenschaft <a href="http://aestheticallyloyal.com/public/optimize-legibility/">text-rendering</a> aufmerksam. Vielleicht sorgt diese Eigenschaft bereits jetzt schon in modernen Browsern für eine bessere Lesbarkeit. Grund genug sie auch einzusetzen. Allerdings wird der CSS-Validator melden: Die Eigenschaft text-rendering existiert nicht. Und damit validiert das CSS nicht mehr.</p>
Anzeige via text-rendering mit den Werten optimizeLegibility, optimizeSpeed und geometricPrecision in Chrome
<p>Das heißt: In weiten Teilen und auf »normalen«, »einfachen«, »üblichen« Webseiten sollten HTML und CSS tatsächlich validieren, ja. Aber bei einigen Projekten mag es interessant sein, mit neuen Möglichkeiten zu spielen, die vielleicht nur in manchen Browsern funktionieren – und auch nicht validieren.</p>
<p>Der Validator ist nur ein Werkzeug. Es ist unser Job, richtig damit umzugehen; und die angezeigten Fehler und Warnungen zu verstehen und entsprechend einzuordnen.</p>
target="_blank" gehört verboten
<p>Unter Webworkern hat es sich durchgesetzt, dass allein der Besucher entscheiden soll, ob sich ein Link in demselben oder einem neuen Fenster (Tab) öffnen soll. Insofern gilt erst einmal: das Relikt <a href="http://www.peterkroener.de/warum-target_blank-nervt-und-verboten-gehoert/">target="_blank" nervt und gehört verboten</a>.</p>
<p>Eine Ausnahme geben Kunden vor. Wenn die eine Liste mit Partnern auf ihrer Webseite pflegen, kommen sie irgendwann auf die Idee, dass sich solche Links doch bitte in einem neuen Tab öffnen sollen. Da können wir dann argumentieren. Manchmal gewinnen wir, manchmal gewinnt der Kunde. Als Dienstleister fügen wir wenn nötig eben das target="_blank" ein; auch wenn wir es selbst anders handhaben würden.</p>
<p>In einem Fall aber finde ich target="_blank" sogar sinnvoll. Und zwar immer dann, wenn Links in der Nähe eines Formulars vorkommen. Wir haben unten in den Kommentaren unsere Hausregeln und die Gravatare verlinkt. Auf anderen Webseiten können das Hinweise zum Datenschutz oder Hilfen für HTML-Formate sein. Für erfahrene Webworker ist das kein Problem. Die nutzen automatisch STRG + Mausklick (oder ⌘ + Mausklick). Aber ich habe schon mehrere Projekte betreut, bei denen sich die Kunden beschwert haben, dass der Text »plötzlich« verschwindet, nur weil sie auf einen der Links geklickt haben. Es kann nämlich passieren, dass die das Formular schon ausfüllen, und später erst auf die Idee kommen, auf den Link zu klicken. Hier sorgt target="_blank" zumindest dafür, dass der Text in den Formularen erhalten bleibt. In diesem Fall ziehe ich die Usability für unerfahrene Nutzer vor.</p>
<p>Alternativ könnten wir solche Links natürlich auch per JavaScript in einer Lightbox öffnen. Dann bleibt der Text im Formular ebenso erhalten. Aber dann bräuchten wir trotzdem eine Lösung, falls JavaScript ausgeschaltet wäre.</p>
<p>Insofern: target="_blank" ist zwar eigentlich böse, wird aber in bestimmten Fällen explizit gewünscht und kann sogar nützlich sein.</p>
JavaScript richtig einbinden
<p>An welcher Stelle packen wir unser JavaScript auf die Seite? Am besten in den Fuß, kombiniert mit all den anderen JS-Dateien und ordentlich minifiziert. Natürlich, das ist <a href="/artikel/2008/sehr-sehr-schnelle-seiten-website-performance-best-practice-teil-2">besser für die Performance</a>.</p>
<p>Auch hier bestätigen Ausnahmen die Regel. Die Bibliothek Modernizr zum Beispiel empfiehlt, das <a href="http://modernizr.com/docs/#installing">JavaScript im <head> einzubinden</a> (weil 1. das HTML5 Shiv vor dem <body> ausgeführt werden muss und 2. ein <a href="http://en.wikipedia.org/wiki/Flash_of_unstyled_content">Flash Of Unstyled Content</a> vermieden werden soll).</p>
<p>In Content-Management-Systeme kann es – abhängig von den installierten Modulen – vorkommen, dass die JavaScripte nicht mehr funktionieren, wenn sie erst im Fuß eingebunden werden. Das spricht manchmal für ein schlecht programmiertes Modul. Aber in der Regel will ich ja keine Module überarbeiten, sondern Webseiten bauen. Dann stehen die JavaScripte eben im <head> – auch wenn es der Best Practice widerspricht.</p>
<p>Es gibt auch (seltene) Fälle, in denen JavaScripte nicht mehr richtig arbeiten, wenn sie minifiziert und kombiniert werden. Das deutet erst recht auf ein schlecht geschriebenes Modul hin. Hier gilt es also abzuwägen: Brauche ich das Modul? Bin ich in der Lage, es selbst zu verbessern? Wird mir die Zeit dafür bezahlt? Oder verzichte ich aufs Minifizieren/Kombinieren und hoffe, dass sich niemand den Quellcode anschaut?</p>
Pixel-Größen für Schriften sind böse
<p>Eigentlich seltsam, dass das (in dieser Form) immer noch kursiert. Früher sind wir brav auf em-Werte für Fonts umgestiegen, weil die Internet Explorer keinen reinen Text-Zoom bei Pixel-Werten hinbekommen. Das hat uns beim schon IE6 genervt, aber auch die <a href="http://www.456bereastreet.com/archive/201010/ie_9_does_not_resize_text_sized_in_pixels/">IE 7 bis 9 scheitern daran kläglich</a>.</p>
<p>Allerdings hat sich die Zoom-Situation in den letzten Jahren grundlegend geändert. Während wir zunächst überall einen reinen Text-Zoom hatten, haben alle Browser mittlerweile standardmäßig auf einen Seiten-Zoom umgestellt. Und wenn wir die komplette Seite vergrößern, wächst eben auch die Schrift mit. Im Sinne der Barrierefreiheit und WCAG 2.0 sind Pixel-Angaben im Zusammenspiel mit dem Seiten-Zoom durchaus ok.</p>
<p>Genauer: Der Seiten-Zoom reicht für die Stufe AA der WCAG 2.0. Bei AAA hingegen ist kein waagerechter Scrollbalken mehr erlaubt. Wenn also AAA angepeilt wird, dann sind Zoom-Layouts meist nicht mehr ausreichend. AA ist jedoch weitgehend Standard, beispielsweise auch in den kommenden EU-Vorgaben für Ausschreibungen im ICT-Bereich, die im Rahmen von Mandat 376 entstehen.<br />
Es kommt also auf das konkrete Projekt an und nach welchem Maßstab die Barrierefreiheit geprüft wird. Beim BITV-Test etwa muss auch die reine Textvergrößerung bei 150% – bzw. »Schriftgrad am größten« im IE – erfüllt sein (entgegen WCAG 2.0, die von 200% spricht).</p>
<p>Insofern sind Pixel-Größen nicht mehr grundsätzlich böse. Durch den Seitenzoom ist die Barrierefreiheit sogar erst einmal erfüllt. Allerdings können wir es besser machen, wenn wir auch den reinen Text-Zoom berücksichtigen wollen (oder müssen).</p>
Die Website muss perfekt werden
<p>Bei vielen Projekten können wir uns schnell davon verabschieden, auch nur im Ansatz an einem »Perfekt« zu kratzen. Aus Zeit- oder Budgetgründen holen wir ohnehin »nur« das Beste heraus, was zu machen ist. Und haben im Kopf eine lange Liste von möglichen Verbesserungen im Detail. Bei unseren eigenen Projekten sieht es schon ganz anders aus. Wir wissen ja, worauf es ankommt. Was wir alles bedenken wollen und sollten. Und vor allem: Was, wenn die Kollegen da mal genauer hinschauen? Da können wir ja nicht etwas nur Fast-Fertiges ins Web stellen. Das muss schon Hand und Fuß haben!</p>
<p>Ja, bis zu einem gewissen Grad muss es das. In erster Linie aber gilt: Hauptsache online. Alles andere können wir auch im laufenden Betrieb verbessern. Sonst würde dieser Adventskalender zum Beispiel auch noch im alten Design erscheinen. Die perfekte Webseite gibt es ohnehin nicht.</p>
<a href="/autor/nicolai-schwarz">Nicolai Schwarz</a>
HTML und CSS müssen validieren
<p>Nö, aktuell müssen HTML und CSS nicht unbedingt in jedem Fall validieren. Oder genauer: Es kommt darauf an. HTML und CSS entwickeln sich laufend weiter. Unter Umständen ist der Validator bei bestimmten Elementen nicht auf der Höhe der Zeit. Bzw. ändern sich einige Schemata so schnell, dass der Validator nicht nachkommt. Etwa beim Thema RDFa. Auf Wikipedia ist aktuell ein Beispiel für <a href="http://en.wikipedia.org/wiki/RDFa#HTML_5_.2B_RDFa_1.1_example">HTML 5 + RDFa 1.1</a> zu finden. Ergänzt um den HTML5-Doctype lautet es:</p>
<!DOCTYPE html><html prefix="dc: http://purl.org/dc/elements/1.1/" lang="en"> <head> <title>John's Home Page</title> <base href="http://example.org/john-d/" /> <meta property="dc:creator" content="Jonathan Doe" /> <link rel="foaf:primaryTopic" href="http://example.org/john-d/#me" /> </head> <body about="http://example.org/john-d/#me"> <h1>John's Home Page</h1> <p>My name is <span property="foaf:nick">John D</span> and I like <a href="http://www.neubauten.org/" rel="foaf:interest" lang="de">Einstürzende Neubauten</a>. </p> <p> My <span rel="foaf:interest" resource="urn:ISBN:0752820907">favorite book is the inspiring <span about="urn:ISBN:0752820907"><cite property="dc:title">Weaving the Web</cite> by <span property="dc:creator">Tim Berners-Lee</span></span> </span> </p> </body></html>
<p>Der <a href="http://validator.w3.org">HTML-Validator</a> aber meldet drei Fehler und sechs Warnungen. Auch Beispiele des W3C zum <a href="http://www.w3.org/TR/rdfa-syntax/">RDFa Core 1.1</a> validieren nicht. Wer Zeit und Muse hat, kann sich näher einarbeiten und findet vielleicht eine Variante, die der Validator kennt und akzeptiert. Aber auf größeren Webseiten werden die Autoren ja nicht alle Elemente selbst per Hand eintragen. Das wird ein entsprechendes RDFa-Modul übernehmen. Statt daran rumzuschrauben, kann es viel einfacher sein, auf ein Update des Moduls und/oder des Validators zu warten. In der Zwischenzeit validiert die Seite eben nicht.</p>
Das Ergebnis des RDFa-Beispiels im Validator des W3C
<p>Hinweis: Es existiert auch ein eigener <a href="http://www.w3.org/2012/pyRdfa/Validator.html">RDFa Validator</a>. Der meldet bei dem Wikipedia-Beispiel zwar keinen Fehler, prüft aber auch nur das RDFa und nicht den Rest einer HTML- oder XML-Datei.</p>
<p>Ähnliches gilt für CSS. Wir nutzen für viele Eigenschaften noch Browser-Prefixes. Beispielsweise für Transitions, damit diese in möglichst vielen Browsern korrekt funktionieren. Da die Prefixes Erweiterungen der Browserhersteller sind, die nicht zum Standard gehören, können diese zwangsläufig nicht validieren. Immerhin werden sie nur als Warnung angezeigt. Der CSS-Validator produziert also trotzdem ein ersehntes: Dieses Dokument wurde als CSS level 3 validiert!</p>
<p>Anders verhält es sich bei <a href="http://coding.smashingmagazine.com/2011/05/11/the-future-of-css-experimental-css-properties/">experimentellen Features</a>: neuen CSS-Eigenschaften in einem frühen Draft oder auch Ideen einzelner Browser-Hersteller. Wer sich zum Beispiel näher mit Typografie beschäftigt, wird eventuell auf die Eigenschaft <a href="http://aestheticallyloyal.com/public/optimize-legibility/">text-rendering</a> aufmerksam. Vielleicht sorgt diese Eigenschaft bereits jetzt schon in modernen Browsern für eine bessere Lesbarkeit. Grund genug sie auch einzusetzen. Allerdings wird der CSS-Validator melden: Die Eigenschaft text-rendering existiert nicht. Und damit validiert das CSS nicht mehr.</p>
Anzeige via text-rendering mit den Werten optimizeLegibility, optimizeSpeed und geometricPrecision in Chrome
<p>Das heißt: In weiten Teilen und auf »normalen«, »einfachen«, »üblichen« Webseiten sollten HTML und CSS tatsächlich validieren, ja. Aber bei einigen Projekten mag es interessant sein, mit neuen Möglichkeiten zu spielen, die vielleicht nur in manchen Browsern funktionieren – und auch nicht validieren.</p>
<p>Der Validator ist nur ein Werkzeug. Es ist unser Job, richtig damit umzugehen; und die angezeigten Fehler und Warnungen zu verstehen und entsprechend einzuordnen.</p>
target="_blank" gehört verboten
<p>Unter Webworkern hat es sich durchgesetzt, dass allein der Besucher entscheiden soll, ob sich ein Link in demselben oder einem neuen Fenster (Tab) öffnen soll. Insofern gilt erst einmal: das Relikt <a href="http://www.peterkroener.de/warum-target_blank-nervt-und-verboten-gehoert/">target="_blank" nervt und gehört verboten</a>.</p>
<p>Eine Ausnahme geben Kunden vor. Wenn die eine Liste mit Partnern auf ihrer Webseite pflegen, kommen sie irgendwann auf die Idee, dass sich solche Links doch bitte in einem neuen Tab öffnen sollen. Da können wir dann argumentieren. Manchmal gewinnen wir, manchmal gewinnt der Kunde. Als Dienstleister fügen wir wenn nötig eben das target="_blank" ein; auch wenn wir es selbst anders handhaben würden.</p>
<p>In einem Fall aber finde ich target="_blank" sogar sinnvoll. Und zwar immer dann, wenn Links in der Nähe eines Formulars vorkommen. Wir haben unten in den Kommentaren unsere Hausregeln und die Gravatare verlinkt. Auf anderen Webseiten können das Hinweise zum Datenschutz oder Hilfen für HTML-Formate sein. Für erfahrene Webworker ist das kein Problem. Die nutzen automatisch STRG + Mausklick (oder ⌘ + Mausklick). Aber ich habe schon mehrere Projekte betreut, bei denen sich die Kunden beschwert haben, dass der Text »plötzlich« verschwindet, nur weil sie auf einen der Links geklickt haben. Es kann nämlich passieren, dass die das Formular schon ausfüllen, und später erst auf die Idee kommen, auf den Link zu klicken. Hier sorgt target="_blank" zumindest dafür, dass der Text in den Formularen erhalten bleibt. In diesem Fall ziehe ich die Usability für unerfahrene Nutzer vor.</p>
<p>Alternativ könnten wir solche Links natürlich auch per JavaScript in einer Lightbox öffnen. Dann bleibt der Text im Formular ebenso erhalten. Aber dann bräuchten wir trotzdem eine Lösung, falls JavaScript ausgeschaltet wäre.</p>
<p>Insofern: target="_blank" ist zwar eigentlich böse, wird aber in bestimmten Fällen explizit gewünscht und kann sogar nützlich sein.</p>
JavaScript richtig einbinden
<p>An welcher Stelle packen wir unser JavaScript auf die Seite? Am besten in den Fuß, kombiniert mit all den anderen JS-Dateien und ordentlich minifiziert. Natürlich, das ist <a href="/artikel/2008/sehr-sehr-schnelle-seiten-website-performance-best-practice-teil-2">besser für die Performance</a>.</p>
<p>Auch hier bestätigen Ausnahmen die Regel. Die Bibliothek Modernizr zum Beispiel empfiehlt, das <a href="http://modernizr.com/docs/#installing">JavaScript im <head> einzubinden</a> (weil 1. das HTML5 Shiv vor dem <body> ausgeführt werden muss und 2. ein <a href="http://en.wikipedia.org/wiki/Flash_of_unstyled_content">Flash Of Unstyled Content</a> vermieden werden soll).</p>
<p>In Content-Management-Systeme kann es – abhängig von den installierten Modulen – vorkommen, dass die JavaScripte nicht mehr funktionieren, wenn sie erst im Fuß eingebunden werden. Das spricht manchmal für ein schlecht programmiertes Modul. Aber in der Regel will ich ja keine Module überarbeiten, sondern Webseiten bauen. Dann stehen die JavaScripte eben im <head> – auch wenn es der Best Practice widerspricht.</p>
<p>Es gibt auch (seltene) Fälle, in denen JavaScripte nicht mehr richtig arbeiten, wenn sie minifiziert und kombiniert werden. Das deutet erst recht auf ein schlecht geschriebenes Modul hin. Hier gilt es also abzuwägen: Brauche ich das Modul? Bin ich in der Lage, es selbst zu verbessern? Wird mir die Zeit dafür bezahlt? Oder verzichte ich aufs Minifizieren/Kombinieren und hoffe, dass sich niemand den Quellcode anschaut?</p>
Pixel-Größen für Schriften sind böse
<p>Eigentlich seltsam, dass das (in dieser Form) immer noch kursiert. Früher sind wir brav auf em-Werte für Fonts umgestiegen, weil die Internet Explorer keinen reinen Text-Zoom bei Pixel-Werten hinbekommen. Das hat uns beim schon IE6 genervt, aber auch die <a href="http://www.456bereastreet.com/archive/201010/ie_9_does_not_resize_text_sized_in_pixels/">IE 7 bis 9 scheitern daran kläglich</a>.</p>
<p>Allerdings hat sich die Zoom-Situation in den letzten Jahren grundlegend geändert. Während wir zunächst überall einen reinen Text-Zoom hatten, haben alle Browser mittlerweile standardmäßig auf einen Seiten-Zoom umgestellt. Und wenn wir die komplette Seite vergrößern, wächst eben auch die Schrift mit. Im Sinne der Barrierefreiheit und WCAG 2.0 sind Pixel-Angaben im Zusammenspiel mit dem Seiten-Zoom durchaus ok.</p>
<p>Genauer: Der Seiten-Zoom reicht für die Stufe AA der WCAG 2.0. Bei AAA hingegen ist kein waagerechter Scrollbalken mehr erlaubt. Wenn also AAA angepeilt wird, dann sind Zoom-Layouts meist nicht mehr ausreichend. AA ist jedoch weitgehend Standard, beispielsweise auch in den kommenden EU-Vorgaben für Ausschreibungen im ICT-Bereich, die im Rahmen von Mandat 376 entstehen.<br />
Es kommt also auf das konkrete Projekt an und nach welchem Maßstab die Barrierefreiheit geprüft wird. Beim BITV-Test etwa muss auch die reine Textvergrößerung bei 150% – bzw. »Schriftgrad am größten« im IE – erfüllt sein (entgegen WCAG 2.0, die von 200% spricht).</p>
<p>Insofern sind Pixel-Größen nicht mehr grundsätzlich böse. Durch den Seitenzoom ist die Barrierefreiheit sogar erst einmal erfüllt. Allerdings können wir es besser machen, wenn wir auch den reinen Text-Zoom berücksichtigen wollen (oder müssen).</p>
Die Website muss perfekt werden
<p>Bei vielen Projekten können wir uns schnell davon verabschieden, auch nur im Ansatz an einem »Perfekt« zu kratzen. Aus Zeit- oder Budgetgründen holen wir ohnehin »nur« das Beste heraus, was zu machen ist. Und haben im Kopf eine lange Liste von möglichen Verbesserungen im Detail. Bei unseren eigenen Projekten sieht es schon ganz anders aus. Wir wissen ja, worauf es ankommt. Was wir alles bedenken wollen und sollten. Und vor allem: Was, wenn die Kollegen da mal genauer hinschauen? Da können wir ja nicht etwas nur Fast-Fertiges ins Web stellen. Das muss schon Hand und Fuß haben!</p>
<p>Ja, bis zu einem gewissen Grad muss es das. In erster Linie aber gilt: Hauptsache online. Alles andere können wir auch im laufenden Betrieb verbessern. Sonst würde dieser Adventskalender zum Beispiel auch noch im alten Design erscheinen. Die perfekte Webseite gibt es ohnehin nicht.</p>
<a href="/autor/nicolai-schwarz">Nicolai Schwarz</a>