Webdesign
Freitag13. April 2012

Die Fragen danach, ob man HTML5 bereits produktiv einsetzen kann, werden zunehmend weniger. Es hat sich die allgemeine Sichtweise durchgesetzt, das dem so ist. Um dabei auch die alten Browser(-versionen) nicht außen vor zu lassen und die zahlreichen neuen HTML5-Elemente und JavaScript APIs browserübergreifend nutzen zu können, stehen zahlreiche Polyfills zur Verfügung. Die Aufgabe eines Polyfills ist es, die Funktionalität eines HTML5 Features mit Hilfe von JavaScript nachzubilden.

Vor wenigen Tagen ist die erste Ausgabe eines brandneuen, deutschsprachigen Online-Magazins namens mag.js erschienen und darin ein lesenswerter Beitrag von Matthias Reuter zum Thema “Mit jQuery alten Browsern HTML5 beibringen”. Darin beschreibt er, wie mittels jQuery das Placeholder-Attribut in alten Browsern nachgerüstet werden kann.

Das Placeholder-Attribut liefert einen zusätzlichen Hilfetext für Formularelemente (<input>, <textarea>), der immer dann erscheint, wenn das betreffende Formularfeld leer und nicht focussiert ist. Man kennt derartige Hilfetexte schon seit langer Zeit (seinerzeit vielfach über Inline-Event-Handler zusammengebaut), weshalb das Placeholder-Attribut auch eines der HTML5-Features war, die bereits frühzeitig in allen modernen Browsern implementiert wurden.

Den gesamten Beitrag lesen


Donnerstag05. April 2012

Ein wenig überrascht war ich ja schon, ob der zahlreichen Reaktionen auf meinen Blogbeitrag “Von fliegenden Kühen und anderen Merkwürdigkeiten” und deshalb möchte ich mit diesem Folgebeitrag ein paar Dinge ergänzen, die mir aktuell in der aktuellen Weiterentwicklung von CSS fehlen, also die “missing parts” von CSS.

Nochmal zu Floats

Das Konzept, ein Layout zu beschreiben, indem man einzelnen Elementen eine Breite x zuweist und lediglich deren Ausrichtung links- oder rechtsbündig innerhalb des Elternelements bestimmt, ist keine Erfindung von CSS. Sowas gibt es schon sehr viel länger. Ich kenne ein solches System beispielsweise von der Erstellung von Benutzeroberflächen für den Amiga. Bei Software für dessen dessen Desktop-Oberfläche (Workbench) war schon in den 80er Jahren schlau, sich auf sehr unterschiedliche Bildschirmauflösungen und skalierbare Fonts einzustellen. Aus diesem Grund waren Floats für mich auch nie ein Mittel, welches allein zur Contentgestaltung herangezogen werden sollte. Wenn dem so wäre, hätte man im CSS Standard die Eigenschaft float auch einfach nur für das Image-Element definieren können. Dem ist aber nicht so.

Ich setze Floats seither sehr gern ein, weil ich sie mittlerweile in allen Browsern sehr robust geworden sind auch für die älteren Browsergenerationen gut dokumentierte, stabile Workarounds für die wichtigsten Bugs existieren. Nicht umsonst arbeiten die Layoutmodule von YAML mit Floats.

Dennoch wünsche ich mir eine Verbesserung der aktuellen Situation, denn auch wenn ich bisher fast jedes an mich herangetragene CSS-Problem lösen konnte, ist dies in – aus meiner Sicht zuvielen praxisrelevanten Standardaufgaben – nur mühsam zu erreichen. Als Beispiele wären da ...

Containing Floats

Wir benötigen eine Eigenschaft, die es ermöglicht, floatende Elemente durch den Elterncontainer sauber umschließen zu lassen. Aktuell nutzen wir dazu CSS-Eigenschaften wie overflow:hidden oder display:table, die diesen Effekt quasi als Nebenprodukt mitliefern. Da es uns in diesen Fällen aber gar nicht um das Verstecken übergroßer Elemente (overflow:hidden) oder das Rendern von Tabellen (display:table) geht, schleppen wir die Auswirkungen dieser Eigenschaften als störende Nebeneffekte zwangsläufig mit.

Was wir benötigen, damit Floats leichter handhabbar werden, ist CSS-Eigenschaft, die das Einschließen floatender Kind-Elemente zur Hauptaufgabe macht, wie z.B float:contain;. Die vom CSS-Standard dem am nächsten kommende Eigenschaft ist clear. Allerdings ist sie für Inhaltskonzepte konzipiert, weswegen ihre Wirkungsweise uns für Layoutzwecke solche Probleme bereitet und uns an diesem Punkt nicht weiterhilft.

Flexible Breiten & Source Order

Bei der Umsetzung flexibler (responsive) Layouts stößt man unweigerlich auf Probleme, wenn fixe und flexible Seitenbereiche nebeneinander zu platzieren sind. Wir platzieren sekundäre Inhalte typischerweise am Rand (Stichwort: Sidebar), neben den zentral gelegenen Hauptinhalten. Die Reihenfolge der Inhalte im Quelltext sollte die Relevanz natürlich widerspiegeln, womit auch hier erst der Hauptinhalt und dann die sekundären Infos folgen sollten. Diese Markupkonstellation stellt uns aber hinsichtlich des Layouts mit Floats vor ein konzeptionelles Problem, da laut CSS-Standard das Element, welches umflossen werden soll (hier bricht die inhaltsbezogene Ansatz von Floats im CSS-Standard durch), im Quelltext zwingend vor den Elementen, stehen muss, die es umfließen (man achte auf die aktive/passive Formulierung).

Das Problem sind hier nicht die Floats ansich, sondern dass wir kein Layout-Modul in CSS kennen, welches dieser Aufgabe gewachsen ist. Die Aufgabe besteht darin, die zur Verfügung stehende Gesamtbreite in einen Bereich mit definierter Breite (Maßeinheit em,% oder px) und einen flexiblen Rest zu unterteilen. Genau dieser flexible Rest ist in CSS nur für statische Elemente spezifiziert über width:auto. Auf positionierte (position:absolute|fixed) oder floatenden (float:left|right) Element lässt sich diese Breitenangabe aber nicht anwenden.

Deshalb ist es uns ohne Tricksereien nicht möglich, eine horizontale Zweiteilung durch zwei “gleichwertige” Layoutbausteine vorzunehmen. Wir greifen mangels Alternativen auf Floats zurück, wobei hierbei immer der Zwang besteht, dass das floatende Element im Quelltext vor den statischen Element stehen muss.

Natürlich ist es dennoch möglich, dieses Problem mit den aktuellen Bordmitteln zu lösen. Entsprechend Codebeispiele dafür habe ich in die Dokumentation des Spaltenmoduls von YAML aufgenommen (achtet auf die verschiedenen Layoutansätze für 2-Spalter). Das ganze geht zurück auf die cleveren Ansätze aus dem Beitrag “In Search of the Holy Grail” von A-List-Apart vom Januar 2006. Seither sind 6 Jahre vergangen, in denen sich CSS enorm weiterentwickelt hat. Dieses Grundproblem flexibler Layouts wurde jedoch bisher nicht zufriedenstellend gelöst.

User Interfaces für Webapplikationen

Als drittes möchte ich nochmal darauf hinweisen, dass gemäß der Logik der CSS-Spezifikation Webseiten eine definierbare Breite haben, in ihrer Länge aber grundsätzlich als unendlich definiert werden, weswegen es im Grunde keine Möglichkeiten gibt, den vertikalen Layoutaufbau sinnvoll zu gestalten, außer durch den linearen Aufbau des Markups und einer abschnittsweisen Gestaltung der aufeinander folgenden Elemente (Header, Content, Footer). Der CSS-Standard ist für HTML-Seiten konzipiert, das vertikale Scrollen gehört quasi zum Konzept dazu, um die theoretisch unendliche Informationsmenge einer HTML-Seite durch das Schlüsselloch Browserfenster (mit begrenzten Dimensionen) betrachten zu können. Schon für einen sticky Footer nutzen wir CSS-Kniffe, die ein Großteil von CSS-Einsteigern nicht mehr voll durchdringt und deshalb nur schwer auf die eigenen Randbedingungen anpassen kann.

Nun hat sich aber der HTML5 Standard auf die Fahnen geschrieben, HTML fit für Webapps zu machen. Befeuert wird diese Entwicklung durch potente Smartphones und Tablets. Man will eine echte Alternative zu nativen Applikationen schaffen, die naturgemäß für jedes OS separat entwickelt.

Der Gedanke ist ausgesprochen reizvoll, jedoch ist einer der grundlegenden Unterschiede, dass User Interfaces in nativen Applikationen anders funktionieren als eine Website. Niemand will auf der Suche nach einem wichtigen Funktion erst mühsam nach unten scrollen müssen, um dann für den Klick auf einen Menüpunkt wieder nach oben zu scrollen usw. Ihr versteht, was ich meine?

Es geht also um User Interfaces, die mit dem verfügbaren Platz in horizontaler und vertikaler Ausdehnung auskommen müssen/sollen – ohne Scrollen. Im CSS-Standard haben wir nichts, womit diese Aufgaben zu bewältigen wären. Der aktuelle Umweg geht hier über JavaScript. ExtJS bietet in seinen UI Komponenten so genannte Layout Manager, für jQuery gibt es das von mir hoch geschätzte Layout Plugin. Speziell auf den Mobilbereich ausgelegt, gesellen sich Projekte wie jQuery Mobile und Sencha Touch hinzu.

Diese JavaScript-basierenden Tools liefern uns die Layoutwerkzeuge, ohne die es kaum denkbar wäre, webbasierte Applikationen zu schreiben, die sich wie eine native App anfühlen. Dennoch stelle ich mir die Frage, ob wir es uns dauerhaft leisten wollen, Layoutaufgaben, die eigentlich der Browser für uns viel schneller und effizienter lösen könnte, an JavaScript auszulagern. An anderer Stelle diskutieren wir bis aufs Messer um jedes Byte, was wir aus Performancegründen weglassen können. Beim Layout jedoch sind wir jedoch JavaScript praktisch ausgeliefert, was nie so schnell werden kann wie die hardwarebeschleunigte Rendering-Engine eines Browsers (oder eben die des Betriebssystems, die jeder nativen App zur Verfügung steht). Und das hat auch die Konsequenz, dass eine native App sich – zumindest aus dieser Sicht – immer flüssiger anfühlen und reagieren wird als eine clientseitige JS-Implementation.

Damit will ich den gedanklichen Steifzug durch meine CSS-Phantasien beenden. Wichtig war mir, aufzuzeigen, dass wir Layouts aktuell noch mit vergleichsweise unausgereiften Techniken bauen, obgleich die technischen und qualitativen Anforderungen an CSS-basierte Layouts durch die heutige Vielzahl der Endgeräte enorm gestiegen ist und ich neben den tollen CSS3 Entwicklungen der letzten Jahre (Schatten, Gradienten, Webfonts, Animationen, etc), die niemand mehr missen will, hier eigentlich dringender Nachholebedarf und erhebliches Potential performantere Lösungen besteht. Auch habe ich mich bei dieser Liste ausschließlich auf die Belange des Seitenlayouts beschränkt. Schaut man sich andere Bereiche, könnte man hier sicherlich endlos weitere Wünsche ergänzen.


Dienstag03. April 2012

Vor 10 Jahren was CSS gerade mal dazu gut, Schrift- und Hintergrundfarbe von Texten festzulegen. Heute können wir dank CSS3 Transitions, Transforms und Animationen in allen modernen Browsern problemlos eine Horde gescheckter Kühe geschmeidig animiert (weil hardware-beschleunigt) über die Pixelweide treiben.

Was wir aber nicht können, sind vermeintlich simple Layoutaufgaben ohne abstruse CSS-Tricksereien realisieren. Schon vor einer kleinen Weile schlug Louis Lazaris mit seinem Blogbeitrag “CSS: The Bad Parts” in eine ähnliche Kerbe, wobei ich nur zum Teil die von ihm angesprochenen “Probleme” als solche wahrnehme.

Die Sache mit den Floats

Über den Sinn und Zweck von Floats lässt sich trefflich streiten. Vor 5..6 Jahren waren sie der Heilsbringer, der die CSS-Layouts dahin geführt hat, sich über den Layouttabellenschmarn des letzten Jahrhunderts zu erheben. Und in einem Umfeld, in dem überwiegend pixelexakte Layouts propagiert wurden, funktioniert dieser Ansatz auch leidlich. Nun hört man in den letzten Jahren – anfangs nur von Standards-Fetischisten – heute auch aus der breiten Frontendler-Masse, Floats wären ja laut Standard nie für Gestaltungsaufgaben vorgesehen gewesen und würden demzufolge für Layoutzwecke genauso missbraucht, wie seinerzeit die HTML-Tabellen.

Nun, diese Argumentation mag für Verschwörungstheoretiker brauchbar sein, für mehr aber auch nicht. Viel schwerwiegender ist doch die Erkenntnis, dass sich Floats trotz aller Widrigkeiten im Detail der Spezifikation durchgesetzt haben und wir monentan gar keine Alternativen dazu haben. Und damit bin ich wieder beim Aufhänger für diesen Blogpost. CSS 3 hat in den letzten 2 Jahren eine rasante Entwicklung hinter sich und vom Gefühl her beschleunigt diese Entwicklung noch immer. Nur passiert der technische Fortschritt auf ganz anderen Bereichen: Runde Ecken, Gradients, Schatten, Animationen, 3D, Schriften usw. usw.

All die neu hinzugekommenden CSS3 Features will man aber nun auch einsetzen und damit werden viele der Probleme, die es mit Floats gibt, erst jetzt mit Nachdruck sichbar. Umso unbefriedigender ist die Tatsache, dass mit CSS3 bisher kaum brauchbare Layoutkonzepte in die Standardisierung – geschweigedenn in die Praxis – Einzug gehalten haben.

Kein Float-Clearing ohne Nebenwirkungen

Wer bis heute der Meinung ist, die Clearing-Problematik wäre mit der Erfindung des Clearfix-Hacks gelöst, der führt zum einen ein offenbar gut behütetes Entwicklerleben und irrt zum anderen gewaltig. Schauen wir auf die aktuellen Webdesign-Trends: Responsive Webdesigns, flexible Grids und CSS3 Box-Shadows.

  • Der Clearfix-Hack hat das Ärgernis beseitigt, für das Clearing der Floats zusätzliche Elemente ins Markup stopfen zu müssen. Er hat aber schon immer das Problem, Auswirkungen auf die Positionierung anderer floatender Elemente im gleichen Kontext zu haben, was seinen Einsatzzweck zum Einschließen von Floats stark einschränkt.
  • Die Eigenschaft overflow:hidden schien zur Hochzeit von CSS2 nahezu nebenwirkungsfrei zum Einschließen von Floats. Mit der Praxistauglichkeit von CSS3 ist dieser Status dahin, denn CSS-Schatten von Child-Elementen werden an den Elementrändern gnadenlos abgeschnitten.
  • Die Eigenschaft display:table scheint auf den ersten Blick die Nachteile von overflow:hidden mit CSS3 ausgleichen zu können, denn es wird nichts abgeschnitten. Dafür ist die Implementation in den Browsern uneinheitlich, was schon damit beginnt, wie sich ein Element mit dieser Eigenschaft hinsichtlich seiner Breite verhält. Dazu kommt ein noch tiefer liegendes Problem, welches nicht immer sofort sichtbar wird. Die Eigenschaft display:table hebelt eines der grundlegenden Rendering-Prinzipien von CSS aus, dass ein Elterncontainer nicht mit der Breite seines Kind-Elementes mitwächst. Sichtbar wird dieses Verhalten, wenn man beispielsweise flexible Grids damit baut und linearisiert, ohne den einzelnen “Zellen” eine Breite zuzuweisen (wozu auch, Blockelemente dehnen sich von allein auf die Größe des Elternelementes aus). Fügt man in ein solches CSS-Konstrukt allerdings ein flexibles Bild ein, wird dieses plötzlich nicht mehr skaliert dargestellt, sondern in voller Größe und die Elterncontainer werden entsprechend ausgedehnt – genauso wie bei Tabellen. Dieses Problem ist bisher kaum bekannt. Aber ihr könnt mir glauben, es ist extrem mühsam, die eigentliche Ursache beim Debugging überhaupt zu erkennen.

Mit dem Durchbruch flexibler Layouts unter dem Deckmantel des Buzzwords “Responsive Design” werden weitere Probleme sichtbar. Wir sind bei CSS weit davon entfernt, Elemente unabhängig vom Markup im Screendesign anordnen zu können. Zahlreiche Entwickler bemerken erst jetzt bei der Umstellung von fixen Grid-Systemen auf Grids in Prozentwerten, was es heisst, mit Rundungsfehlern der Browser offensiv umzugehen. Und und und ...

Fehlende Alternativen

Tja, was gibt’s hier? Der eine oder andere weiß sicher, dass einige CSS-Frameworks (z.B.: die Grid-Komponente von YUI3) auf display:inline-block aufbauen. Auch diese Eigenschaft ist keine Lösung, denn sie wurde noch viel weniger für Layoutzwecke entworfen als Floats. Das äußert sich insbesondere darin, dass ein Grid mit diesem CSS-Konzept plötzlich höchst sensibel auf Leerzeichen und Zeilenumbrüche im Quelltext zwischen den einzelnen Grid-Zellen reagiert. Es braucht nicht viel Phantasie, um sich die Probleme vorzustellen, wenn man als Entwickler keine vollständige Kontrolle über den Quellcode hat. Und wer hat die schon? Denkt nur an verschachtelte Templates in einem CMS und die dadurch entstehenden Zeilenumbrüche im Quelltext.

CSS3 verspricht uns gleich vier neue Layout-Module: Multicolumn, Grid-Layout, Flex-Box und das Template-Modul. Das Multicolumn-Modul ist als einziges bereits beim Status “Testing” angekommen allerdings lässt es sich im Grunde nur auf Fließtext sinnvoll anwenden. Für den Bau eines Seitenlayouts im herkömmlichen Sinne ist es ungeeignet. Die anderen drei pendeln zwischen “Revising” und “Exploring”, d.h. ihre Anwendbarkeit liegt in weiter Ferne. Erschwerend kommt hinzu, dass der visuelle Seitenaufbau ein so grundlegender Baustein ist, dass sich hier kaum sinnvolle Progressive-Enhancement-Strategien realisieren lassen. Entweder die gesamte relevante Browserlandschaft unterstützt die Technik fehlerfrei oder sie ist für den Alltag noch nicht reif. Sprich: Wir lesen uns 2016 wieder.

Während wir mittlerweile selbst auf Smartphones gut und gerne 50 animierte Kühe per CSS fliegen lassen können, mühen wir uns bei den grundlegenden Gestaltungswerkzeugen im Web auch in den nächsten Jahren noch mit unzureichenden Techniken ab. Und es verblüfft mich schon ein wenig, dass wir uns so bereitwillig von all dem HTML5- und CSS3-Bling Bling blenden lassen.

Nachtrag: Für die Zweifler unter Euch: Zwar keine fliegenden Kühe, dafür nicht minder knuffige, fliegende Schweine. (gefunden und mir zugetragen von Christian Heilmann).


Dienstag06. März 2012

Liebes T3N Magazin,

Die Überschrift Eures heutigen Beitrags “Contao: Open-Source-CMS mit HTML5” ist ein schlechter Witz. Der einzige Bezug des gesamten Beitrags zu Eurem Lieblings-Buzzword “HTML5” findet sich im ersten Satz:

Contao ist ein Open-Source-CMS, das auf PHP basiert und HTML5 unterstützt.

Das war’s. Bis zum Ende des Beitrags kommt der Autor kein zweites Mal auf HTML5 zu sprechen.

Bitte, was soll das? Gibt es bei Euch noch eine Redaktion, die sich der inhaltlichen Abstimmung der Beiträge verpflichtet fühlt, oder redigiert und veröffentlicht jetzt nur noch Euer Marketing die Beiträge?

Ich habe in der Vergangenheit zu verschiedenen Themen und auf verschiedenen Kanälen (Skype, Twitter, Kommentare, Blogposts) Feedback an Eure Redaktion weitergegeben. Doch die konstruktive Kritik scheint Euch nicht zu interessieren.

Das ist schade, denn scheinbar bemerkt ihr auch nicht, dass Ihr damit auch dem vorgestellten Projekt Contao keinen Gefallen tut. In Bezug auf HTML5 ist der Beitrag noch nicht einmal enttäuschend. Er geht völlig am Thema der Überschrift vorbei. Dabei gäbe es wirklich interessante Fragen. Jedes halbwegs gute CMS überlässt heute dem Anwender die Kontrolle über das Markup des Seitenlayouts. Aber spätestens bei den Inhalten wird es spannend, denn z.B. bei Formularen muss man sich bei fast jedem CMS mit irgendwelchen Generatoren oder Plugins auseinandersetzen. Diese haben nämlich meist eigene Vorstellungen hinsichtlich des verwendeten Markups und lassen dem Anwender selten Wahlmöglichkeiten, solange man nicht selbst willens und fachlich dazu in der Lage ist, teils tief in den Code einzugreifen. Ein Paradebeispiel dafür ist nach Hörensagen das Formularmodul von Drupal. Wie es hier bei Contao und dem Einsatz von HTML5 Formularelementen (und deren Validierung) momentan bestellt ist, wäre durchaus hochinteressant zu erfahren gewesen. Oder was hinsichtlich der dynamischen Verwendung von HTML5 Elementen hinsichtlich IE6/7/8 Support zu beachten ist? Bei jQuery ist dafür seit v1.7 innerShiv integriert. Contao arbeitet jedoch standardmäßig mit Mootools. Wie läuft das da?

Stattdessen folgt auf das Buzzword-Bingo (2x HTML5 innerhalb der ersten zwei Zeilen) nur eine, sagen wir durchschnittliche, Vorstellung des Content-Management-Systems. Da fragt man sich natürlich: Warum gerade jetzt? Denn auf das vor 2 Wochen erschienene Release 2.11 und dessen Neuerungen geht der Beitrag genauso wenig ein.

Ihr seid das Fachmagazin. Wie kann es sein, dass Ihr auf solche Fragen nicht kommt und Euch dieses Informationsniveau für Eure Leser ausreichend erscheint?

Kommen wir zu dem Punkt, warum ich mich überhaupt darüber aufrege: Weil ... ich mir mehr deutschsprachige Fachblogs und Online-Magazine zum Thema Frontendentwicklung wünsche, sich aber leider keine Alternativen aufdrängen. Gleichzeitig verstehe ich nicht, warum es den vielen anderen Frontendentwicklern da draußen so egal ist, wohin sich das T3N Magazin seit einiger Zeit entwickelt. Das Smashing Magazine ist vor 2..3 Jahren ähnlich in die Kritik geraten mit ihren endlosen “10 best anything” Toplisten-Artikeln und es hat viel Kritik von außen und sicher sehr viel mehr Kraft von innen bedurft, um das Ruder wieder herumzureißen.

Aber vielleicht erwarte ich ja auch einfach nur zuviel vom Online-Bereich des “führenden deutschsprachigen Printmediums zu den Themen Web 2.0, Social Media, E-Business und Open Source”.

Ich hoffe, in Eurer Redaktion ist noch jemand wach.


Mittwoch18. Januar 2012

Es ist getan. Seit wenigen Minuten steht auf YAML.de nicht nur eine neue Version meines CSS Frameworks zum Download bereit, es gibt auch zahlreiche Veränderungen: angefangen bei einem vollständig überarbeiteten Dokumentationskonzept über einen neuen, zeitgemäßen Webauftritt bis zu einem neuen Lizenzmodell. Aber der Reihe nach ...

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.

Den gesamten Beitrag lesen


Seite 2 von 13 Seiten

 <  1 2 3 4 >  Letzte »