Weblog

Das neue Dokumentationskonzept

Die Dokumentation von YAML wurde vollständig neu gestaltet. Sowohl 2005 (YAML 1) als auch 2007 (YAML 3) erschien es gerechtfertigt, neben dem “wie” der Anwendung auch das “warum” der technischen Realisierung) ausführlich zu erläutern. Es gab in diesen Jahren kaum vollständige Dokumentationen zum Umgang mit Browserbugs und die Grundkonzepte von CSS2 waren für viele Entwickler noch vergleichsweise frisch. Diese Zeiten sind vorbei. Grobe CSS-Bugs, die massiv das Rendering einer Webseite beeinflussen, sind in den aktuellen Browsern mehr oder weniger ausgestorben, die Macken der alten Browsergeneration sind in zahlreichen Büchern und online umfassend dokumentiert. Zudem war die YAML-Doku in ihrer PDF-Fassung auf satte 150 Seiten angewachsen, die Pflege und Fortschreibung in zwei Sprachen war nicht mehr zu leisten.

Das neue Dokumentationskonzept behandelt zukünftig nur noch die Anwendung der einzelnen Features – also das “wie”. Lohn dieses neuen Konzepts: die Doku liegt nun als offline-taugliche HTML-Datei dem Zip-Paket des Frameworks bei und dient gleichzeitig als Kurzreferenz. Code-Schnipsel können direkt per copy & paste in das eigenen Projekt übernommen werden. Dafür steht die Dokumentation zukünftig nur noch in englischer Sprache zur Verfügung. Mir ist es sehr wichtig, eine möglichst gut verständliche und vollständige Dokumentation liefern zu können, weshalb mich in der Vergangenheit immer wieder kleine Unterschiede in den Sprachversionen gestört haben. Die CSS Dateien des Frameworks sind hingegen auch weiterhin überwiegend zweisprachig dokumentiert.

Nun zu den wichtigsten Neuerungen bei YAML selbst. Im März 2011 hatte ich ja bereits über einige der geplanten Änderungen bei YAML 4 gesprochen. Wer die Ankündigungen verfolgt hat, wird über die folgenden Dinge nicht mehr ganz so überrascht sein.

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.

Das Projekt »Thinkin’ Tags«

»Thinkin’ Tags« ist eine völlig neuartige, browserbasierte Entwicklungsumgebung für das schnelle Erstellen von Layout-/Webseiten-Prototypen mit bisher einzigartigen Features. »Thinkin’ Tags« ist als webbasierter Dienst konzipiert, der nach erfolgreicher Betaphase neben einem kostenfreien Zugang auch kostenpflichtige Premiumfeatures anbieten wird (allerdings wird bis dahin noch etwas Zeit vergehen). Die Layout-Prototypen können entweder von Grund auf mit einfachem HTML & CSS erstellt werden oder optional auf Basis verschiedener CSS-Frameworks. Dabei steht selbstverständlich YAML (aktuell in der Version 4 alpha3) zur Verfügung aber auch Grid-Frameworks wie Blueprint CSS (bereits experimentell implementiert) sowie zukünftig auch 960.gs sind angedacht.

Der große Vorteil des browserbasierten Prototypings in Verbindung mit einem CSS-Framework ist, dass der auf diese Weise entstehende Code in großen Teilen weiter- bzw. wiederverwendbar ist für die finale Umsetzung des Layouts für den Produktivbetrieb. Einerseits erlaubt der visuelle Ansatz, CSS-Layouts im Browser zu »entwerfen«, denn dank der mittlerweile hervorragenden Performance aktueller Browser und den visuellen Gestaltungsmöglichkeiten mit CSS2 und CSS3 ist das Vorzeichnen in Grafikprogrammen wie Photoshop in vielen Fällen unnötig. Andererseits sichert die professionelle Codebasis und die Ausrichtung von »Thinkin’ Tags« als Werkzeug für erfahrene Frontendentwickler eine Codequalität, die ein eine annähernd vollständige Übernahme des Prototypen in die nachfolgenden Enwicklungsschritte ermöglicht. Und auch wenn in der Vergangenheit zahlreiche desktopbasierte WYSIWYG-Editoren (Dreamweaver, GoLive, ExpressionWeb) nicht das erreicht haben, was ihre Werbung verspricht, ist dieser Ansatz innerhalb eines Browsers ausgesprochen reizvoll.

Das folgende Video basiert auf einem etwas älteren Entwicklungsstand (Januar 2011), es gibt jedoch einen recht guten Überblick darüber, wie die Applikation bedient wird und was in technischer Hinsicht momentan möglich ist.

Einige Features ...

• Vollständig browserbasierte Erstellung von Layout-Prototypen (in Firefox, Chrome, Safari und Opera)
• Unterstützung für CSS-Frameworks YAML und Blueprint CSS (960.gs in Vorbereitung)
• Der Anwender hat nahezu vollständige Kontrolle über Markup und CSS
• CSS-Parser zeigt CSS-Eigenschaften einschließlich Vererbung an
• Jegliche CSS-Änderungen werden unmittelbar sichtbar
• Verschiedene Darstellungsmodi zur Erstellung des Markups, sowie des Screen- und Print-Layouts
• Projektexport und Download als ZIP-File

Webkrauts Adventdskalender 2010

Der Adventskalender der Webkrauts erscheint bereits seit 2005 und widmet sich in jedem Jahr einem übergeordneten Thema. In diesem Jahr sind dies die “Kunden”

24ways 2010

Was der Webkrauts-Kalender im deutschsprachigen Raum ist, ist 24ways auf der großen internationalen Bühne. Das who-is-who der Szene trifft sich zu 24 abwechslungsreichen Beiträgen rund um das Thema modernes Webdesign

WPEngeneers - Advent Calendar

Meines Wissen zum zweiten Mal starten die Programmierprofis ihren Adventskalender rund um das Thema “Wordpress”

Maddesigns CSS3-Adventskalender

Sven Wolfersmann ist ein ganz harter Bursche und zieht dieses Jahr einen Adventskalender zum Thema CSS3 fast alleine durch. Ich bin gespannt ...

HTML5-Demos-Adventskalender

Wie es der Name schon sagt ... it’s all about HTML5

Na denn, für Lesestoff ist gesorgt ...

Wohin geht die Reise?

Wie sich unter aufmerksamen Lesern und Barcamp-Besuchern bereits herumgesprochen haben sollte, arbeite ich seit längerer Zeit an einem Nachfolger des YAML-Builders. Mit der Veröffentlichung dieses neuen Projektes wird gleichzeitig (bzw. kurz davor) YAML 4.0 das Licht der Welt erblicken. Diese Version 4.0 ist die Basis für die Arbeit an meinem JavaScript-Projekt und daher ebenfalls schon seit längerem in der Entwicklung und reift langsam heran, allergings wird bis zur geplanten öffentlichen Betaphase noch einige Zeit ins Land gehen.

Damit einher gehen aber einige größere Veränderungen des Frameworks, die eine Abwärtskompatibilität zu dem 3er-Releasestrang unmöglich machen. Aus meiner Erfahrung dürfte das den wenigsten Nutzern weh tun, da die Mehrzahl der Entwickler einen Versionswechsel nur in Verbindung mit neuen Projekten vornimmt. Dennoch habe ich mich entschlossen, einige der für YAML 4.0 geplanten Verbesserungen in der Version 3.3 vorzuziehen, um auch den 3er-Strang zukunftsfähig und für die nächsten 2 Jahre praxistauglich zu halten.