Mittwoch16. November 2011

Der Beitrag “6 Things I Learned About Print Stylesheets From HTML5 Boilerplate” hat mich daran erinnert, dass ich schon lange mal ein paar Worte über das HTML5 Boilerplate verlieren wollte. Ich halte dieses Projekt abseits des HTML5 Hypes für eine geniale Sache, insbesondere wegen seines umfangreichen und ausgeklügelten Build-Skripts und der mitgelieferten Apache-Konfiguration per .htaccess. Bei den CSS-Definitionen finde ich die Einbindung des Normalize.css Projekts sehr viel sinnvoller (wenn auch recht umfangreich) als die vielseits beliebten Reset-Stylesheets von Eric Meyer oder YUI.

Die Vorgaben des Print-CSS kann ich allerdings weniger empfehlen (ist aber auch weniger dramatisch). Speziell geht es mir um die “Print Friendly Links”, wie es der oben zitierte Beitrag nennt. Hier der betreffende Auszug aus dem HTML5 Boilerplate.

a[href]:after { content: " (" attr(href) ")"; }
abbr[title]:after { content: " (" attr(title) ")"; }
.ir a:after, a[href^="javascript:"]:after,
a[href^="#"]:after { content: ""; } /* Don't show links for images, or javascript/internal links */

Ich habe Vergleichbares (Automatische Auszeichnung von URLs, Akronymen und Abkürzungen) seit vielen Jahren in den YAML Druckstylesheets integriert, allerdings bin ich recht schnell wieder einen Schritt zurück gegangen, indem ich diese Regeln nur noch auskommentiert mitliefere und das aus gutem Grund.

Es ist auf den ersten Blick sicher nachvollziehbar, dass verlinkte URLs beim Druck verloren gehen und man als zuvorkommender Webentwickler diese deshalb hinter dem Linktext mit ausdrucken will, damit für den Anwender der Quellenverweis erhalten bleibt. Doch mal ehrlich: Wie oft hat jeder von Euch im letzten Jahr eine auf Papier abgedruckte URL in den Browser eingetippt? Und wie oft war diese dann länger als 10 Zeichen? Ist die pauschale Ausgabe von URLs also wirklich sinnvoll?

Aus dem anvisierten Komfort für den User wird in der Praxis schnell ein Nerv-Feature – und meist auch der Regelfall. Im Gegensatz zum Print arbeiten wir im Netz nicht mit Quellenverzeichnissen am Ende des Textes, sondern verlinken Schlagworte oder ganze Sätze direkt und im Idealfall auch recht umfangreich. Allerdings steht im Netz die Querverlinkung dem Lesefluss und -genuss auch nicht im Wege. Ausgedruckt ist ein solches Dokument allerdings nur noch bedingt gut lesbar, wenn der Fließtext regelmäßig durch lange, kryptische, nicht umbrechbare URLs unterbrochen wird. Ganz zu schweigen davon, dass sich die Mehrzahl der Anwender eben nicht diebisch darüber freut, eine neue URL zum Abtippen gefunden zu haben.

Gleiches gilt für die Anzeige der title-Attribute von Abkürzungen. Gute Schreibe gebietet, dass Abkürzungen bei ihrem ersten Auftauchen im Text eingeführt/erläutert werden. Aber eben nur beim ersten Mal (vielleicht noch beim zweiten, dann ist aber gut). Das Einpflegen von Akronymen und Abkürzungen erledigt im HTML aber fast niemand von Hand - weil es recht lästig und umständlich ist. Dafür gibt es bei vielen Content Management Systeme entsprechende Plugins, die diese Aufgabe automatisch anhand von Wortlisten übernehmen. Auch daran gibt auf den ersten Blick nichts auszusetzen, denn schließlich wird das title-Attribut nur angezeigt, wenn der Anwender das Element mit der Maus ansteuert und darüber verweilt. Aber schon Nutzer von Screenreadern dürften derartige Automatismen stören, wenn z.B. in einem Webdesign-Fachtext hinter jedem jedem HTML (Hypertext Markup Language) steht/vorgelesen wird. Und Lesern eines ausgedruckten Dokuments geht es da nicht anders.

Die sichtbare Auszeichnung von URLs und Abkürzungen ist per Definition weder unnütz noch schädlich. Allerdings ist sie eben nur dann sinnvoll, wenn die Inhalte entsprechend sorgfältig dahingehend aufbereitet sind, in dem beispielsweise nur die URL von besonders gekennzeichneten Links ausgegeben wird. Genauso wie der Ausdruck der title-Attribute von Abkürzungen nur dann für den User sinnvoll ist, wenn die Texte auch entsprechend sorgfältig aufbereitet werden. Andernfalls kann beides schnell zum billigen Werbefeature des Entwicklers werden, welches u.U. deutlich an den Interessen des Lesers (Internetausdruckers) vorbei geht.

Und so versteckt sich auch im HTML5 Boilerplate die eine oder andere Regel, deren Nutzen mehr Schein als Sein ist, wenn man sie gedankenlos übernimmt.


Seite 1 von 1 Seiten