Weblog

Doch so gern und trefflich die Blogosphäre sich auch über den IE6 und dessen Schwächen auslässt so gründlich wird in der Diskussion meist außer acht gelassen, dass auch andere Browser einem Alterungsprozess unterliegen. Wer testet denn heute noch ernsthaft seine Projekte gegen den Firefox 1, Safari 2 oder Opera 8? Der Firefox 1.0 beispielsweise stammt aus dem Jahre 2004 und hat damit ebenfalls bereits 5+ Jahre auf dem Buckel. Schon mal drüber nachgedacht?

In den Focus rückt diese Fragestellung bei mir durch Googles aktuelle Ankündigung, den IE6 bei den eigenen Applikationen nicht mehr zu unterstützen - worüber auch sofort wieder reichlich berichtet wird. Nur steht in Googles Ankündigung weit mehr als das Ende des IE6-Supports. Auch die nächste Generation der “Guten” - Firefox 2.x, Opera 9, Chrome 2.x usw. nähert sich dem Ende ihrer Unterstützung. Zwar findet man diese Aussage in dieser Deutlichkeit nicht in diesem Google-Blogpost, dafür beispielsweise bei Yahoo’s Aufstellung für den abgestuften Browsersupport der YUI Library.

Interessant an der Yahoo-Tabelle ist beispielsweise, dass selbst der Firefox 3.0 unter Windows Vista/7 bereits den A-Grade Status verloren hat. Von Opera ist generell nur die aktuelle Version 10 in der Liste vertreten und auch der Safari unter Mac nur in der aktuellen Version 4 gelistet wird. Alle älteren Versionen werden aktuell als B-Grade eingestuft. Sie werden selbstverständlich weiterhin unterstützt werden - jedoch bereits heute mit geringerer Priorität. Nun dreht es sich sowohl bei Google als auch bei Yahoo in allererster Linie um die JavaScript-Unterstützung/-Performance. In Sachen CSS ist es vor allem der Internet Explorer 6, der mit zahlreichen Bugs gesegnet ist, die Webentwicklern bei den immer komplexer werdenden Applikationen mehr und mehr zu schaffen machen. Doch auch bei den modernen Browsern werden die Unterschiede momentan eher größer als kleiner. Konkretes Beispiel: Die JavaScript-Performance des aktuellen Firefox 3.6 ist nicht einmal halb so gut wie die des Chrome 4. 

Abgestufter Browsersupport bei HTML5 & CSS3?

Die Frage, die ich deshalb in den Raum stellen möchte lautet: Wie geht man mit den älteren Generationen der “guten” Browser um? Ich klammere hier bewusst den IE 6 und 7 aus, mir geht es um Firefox 1.x,2.x,3.0.x, den Opera 8.x,9.x, den Chrome 1,2 oder auch Safari 1,2. Was die immer weiter wachsende Unterstützung für beispielsweise CSS3 und HTML5 angeht, so gibt es mit den älteren Generationen sicherlich weniger Probleme. Doch was ist mit waschechten CSS-Bugs?

Der Firefox 3.6 ist beispielsweise der erste Firefox überhaupt, der CSS-Tabellen endlich fehlerfrei darstellt. Alle seine Vorgänger hatten da so ihrer Schwierigkeiten. Der Firefox 2.x ließ teilweise Labels hinter Formularelementen verschwinden. Im Gegensatz zum Internet Explorer 6, der neben seinen zahlreichen CSS-Bugs ebenso zahlreiche Parser-Bugs mitlieferte, über deren Ausnutzung viele Probleme gefixt werden konnten, steht man bei den “guten” Browsern meist im Regen. Bugfixes für deren CSS-Probleme sind Mangelware. Mit der wachsenden Verbreitung von Firefox und Co. und den immer neuen Versionen/Generationen wird auch die Streubreite bei den Anwendern zunehmen und damit wird es zwangsläufig dazu kommen, dass diese Bugs “sichtbar” werden, wenn aktuelle Webtechnologien vermehrt Anwendung finden.

Wir beginnen gerade erst, die ersten graphischen Spielereien von CSS3 in unsere Projekte einzubauen. Ein falscher Schatten oder eine runde Ecke stellen in der Regel kein Problem dar. Doch wie sieht es aus, wenn wir damit beginnen, die neuen Layout-Module zu verwenden (Mehrspaltigkeit, Alternative Box-Modells, ect)? Das sind layoutkritische Elemente, was wenn hier Bugs auftreten, weil die ersten Implementationen noch nicht ausgereift waren - aber noch nicht vom Browsermarkt verschwunden sind?

Thema HTML5: Auch hier hat die Entwicklung deutlich an Fahrt gewonnen. Im letzten Jahr gab es reichlich Tutorials, wie HTML5 schon heute angewandt werden kann. Doch auch hier werden wir bei der aktuellen Geschwindigkeit Mühe haben, dass ältere Browsergenerationen von FF und Co. bereits aus den Statistiken verschwunden sind, bevor wir damit richtig anfangen zu arbeiten - oder wir warten bis 2020 (das will niemand wirklich, oder?). Dem Firefox 2 kann man nur sehr mühevoll den Umgang mit den neuen Elementen beibringen, vernünftiges Styling ist fast unmöglich. Für den IE7 und 8 gilt das gleiche, doch beide werden uns vermutlich noch eine ganze Weile begleiten.

Es bleibt spannend und unberechenbar ...

In die Browserwelt ist sichtlich Bewegung gekommen. HTML5 und CSS3 nehmen Woche für Woche weiter Fahrt auf. Die Performance-Entwicklung der JavaSript-Engines von Google, Safari und Opera (v10.5) eröffnet Möglichkeiten, die vor 1..2 Jahren noch völlig undenkbar waren - ganz unabhängig von den zahlreichen neuen Features, die uns durch jedes Browserupdate beschert werden. Jetzt also, wo der IE6 so langsam von der Bildfläche verschwindet, haben wir nicht zwingend Eitel Sonnenschein. Stattdessen wird sich der Focus einfach etwas verschieben, weg von dem einen zentralen Problembrowser hin zu den zahlreichen alten Browsergenerationen, welche die neuen Webtechnologien unzureichend oder fehlerhaft implementiert haben.

Nach so vielen vagen Gedanken würde mich Eure Meinung interessieren:

• Wie geht mit der wachsenden Versionsvielfalt und den damit verbundenen Leistungsunterschieden um?
• Wie reagiert Ihr auf Browserbugs, die sich nicht mehr so leicht fixen lassen, wie im guten alten Internet Explorer 6?
• Wie handhabt Ihr die unterschiedliche Unterstützung von Standards (HTML5, CSS3)?

Entfernen wir uns wieder von “Graceful Degradation” und “Progessive Enhancement” weil die Leistungsunterschiede im Vergleich zu heute tendentiell geringer werden oder bleiben wir als Webentwickler so tolerant wie bisher und sorgen uns in Zukunft auch um die älteren Guten, auch wenn deren Aufkommen in der Statistik geringer sein wird als es der IE6 momentan noch ist?

Wie schon im letzten Jahr war auch dieses Mal YAML wieder zahlreich unter den Finalisten und Preisträgern vertreten. Insgesamt 5 der 24 Webseiten im Finale des Wettbewerbs setzen auf das bekannte CSS-Framework, drei davon wurden letztlich mit einer Biene in Bronze prämiert.

Hier noch einmal die Finalisten und Preisträger mit YAML unter der Haube:

• Gemeinde Issum:www.issum.de – BIENE in Bronze (Kategorie ›Komplexe Informations- und Kommu­nikations­angebote‹)
• Stadt Nettetal: www.nettetal.de – BIENE in Bronze (Kategorie ›Komplexe Informations- und Kommu­nikations­angebote‹)
• Naturheilpraxis Angela Käßner: http://www.naturheilpraxis-kaessner.de – BIENE in Bronze (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)
• Stadt Kevelaer: www.kevelaer.de (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)
• Stadt Emmerich am Rhein: www.emmerich.de (Kategorie ›Einfache Informations- und Kommu­nikations­angebote‹)

Dabei steuert das YAML Framework nur einen kleinen Teil zur Barrierefreiheit einer Webseite bei, die Hauptarbeit liegt nach wie vor bei den verantwortlichen Webdesignern und Redakteuren, denn so aufwändig die Erstellung einer Webseite auch ist, stellt deren Betrieb mit regelmäßigen Anpassungen/Überarbeitungen und ständigen redaktionellen Änderungen die wahre Herausforderung dar, soll der hohe Qualitätsstandard dauerhaft gehalten werden. Als Technische Basis der verschiedenen YAML-basierten Seiten kamen die Framework-Versionen 2.5.x und 3.0.x zum Einsatz. Schon daran kann man erkennen, dass der Aufbau komplexer Informationsangebote viel Zeit in Anspruch nimmt, denn die Version 3.1 (Januar 2009) sowie die aktuelle Version 3.2 waren noch nicht vertreten. Damit aber genug dazu.

Besonders beeindruckend finde ich die Tatsache, dass trotz der gestiegenen Anforderungen an die Bewerber, vermehrt komplexe Angebote ins Finale einziehen und Preisträger werden. So konnten in diesem Jahr, der Webauftritt der DHL, das Online-Banking-Portal der Credite Suisse oder auch der SWR und die Zeit Online silberne Bienen mit nach Hause nehmen. Für den Webshop Manufaktum gab’s gar eine Biene in Gold.

Ebenfalls immer mit dabei sind die zahlreichen Kritiker, die Finalisten und Preisträger im Nachhinein sezieren und dabei immer wieder vermeintliche Haare in der Suppe finden. Sei es die mangelnde Validität oder die vergleichsweise schlichte Optik mancher Seite oder oder oder. Doch die Biene bewertet keine Photoshop-Künste, sondern Zugänglichkeit. Und so stellt die Riege der Finalisten und Preisträger einen aus meiner Sicht im Bezug auf die Designqualität einen durchaus repräsentativen Querschnitt aktueller Webseiten dar. Darunter sehr schöne Seiten wie www.bund.de oder die Zeit Online und daneben eben auch weniger schicke Angebote wie die des Hamburger Verkehrsverbundes (Biene in Bronze) oder der Stadt Suttgart. Hier mag dem einen oder anderen das Bling Bling  fehlen, dafür überzeugen alle diese Seiten mit hervorragender Zugänglichkeit, was viel zu viele Hochglanz-Webseiten nicht für sich in Anspruch nehmen können. Und an dieser Stelle vertraue ich der Jury, denn ins Finale kommt man nicht allein durch das Abarbeiten von Barrierefreiheits-Checklisten sondern die Seiten müssen sich in zahlreichen Nutzertests beweisen - Design hin oder her.

Allen Kritikern sei daher angeraten: Kritik ist erlaubt, schnödes Meckern ist nur peinlich. Aber wenn Ihr es besser wisst dann geht bei Euren eigenen Projekten mit gutem Beispiel voran und zeigt, dass es besser geht. Entwickelt charmante Lösungen, erstellt attraktive Webseiten, reicht diese zur Biene 2010 ein. Dann könnte der Anteil attraktiver Angebote weiter steigen und vielleicht hört dann auch endlich mal die BF-Szene damit auf, sich selbst der der Lächerlichkeit preiszugeben, indem permanent gegenüber Berufskollegen gemeckert und Preisträger seziert werden. Tomas Caspers hat es auf der diesjährigen Webtech-Konferenz auf den Punkt gebracht.

“Auch bei Beachtung der WCAG 2.0 und dem Einsatz moderner Webtechniken wie WAI-ARIA kann man dennoch an einzelnen Details scheitern. Doch passiert dies immernoch auf einem weitaus höheren Niveau als bei jenen, die sich aus Angst vor dem möglichen Scheitern gar nicht erst auf den Weg machen.”

Und genau so sehe ich das auch: Der Weg ist das Ziel.

Abschließend sei noch die Stadtbibliothek Marzahn-Hellersdorf erwähnt, die ebenfalls mit einer Biene in Silber ausgezeichnet wurde. Dieses Projekt wurde innerhalb von 3 Jahren ausschließlich von engagierten Mitarbeitern der Bibliothek realisiert – ganz ohne eine professionelle Agentur. Eine solche Leistung verdient höchsten Respekt.

Insbesondere das breitgefächerte Themenangebot hat es mir dieses Mal angetan. So umfasste mein persönlicher Sessionplan eine CMS-Diskussion, Rechtfragen in Social Networks, Rapid Prototyping mit jQuery, User Interface Design aus Spiele-Sicht, Erfahrungsberichte von Freelancern sowie zahlreiche kurze und einige längere Gespräche bei Kaffee und leckerem Kuchen. Ich selbst habe die Gelegenheit genutzt, nach ca. 8 Monaten und ca. 6000 Zeilen JS-Code ein erstes Feedback zu meinem aktuellen Projekt einzuholen.

Und abseits der Sessions sind Barcamps eben auch immer wieder eine tolle Gelegenheit, bekannte und unbekannte Gesichter zu treffen, sich auszutauschen und über alle möglichen und unmöglichen Dinge zu schwatzen. Und genau für diese entspannte Atmosphäre danke ich dem Orga-Team. Allen voran Darren Cooper, dessen herzerwärmende, lebensfrohe englische Art ich an zwei Abenden im #csshaus als Gast von Jens erleben durfte. Und so war ich denn einerseits etwas traurig, dass Sonntag 15:00 das Barcamp für mich bereits zu Ende war - mein Flieger nach Dresden wartete auf mich - andererseits bin ich selten so motiviert aus einer Veranstaltung gegangen wie dieses Mal.

Jederzeit gerne wieder ... wir sehen uns Mainz.

Die Vorgeschichte

Es begab sich im Sommer zu 2009, als ein aufstrebener Webentwickler, ich nenne ihn Herrn X. seine eigene Webseite neu einrichten wollte. Da die eigene Kreativität wohl gerade gemeinsam mit seinem Verstand auf Badeurlaub in der Karibik waren, griff Herr X. von jeglichen Hemmungen befreit in eine der unteren Schubladen des guten Benehmens, setzte seine copy & paste Mütze auf und streifte durchs Internet: Warum sich etwas neu ausdenken, was andere schon so übersichtlich und ansprechend hinbekommen haben? Letztlich sind wir doch eh eine große Familie im Web … und so fand er meine Webseite. Und diese gefiel ihm vom Aufbau und Design so einmalig gut, dass er seine ganz genauso aufgebaut und aussehen sollte. Nur hier und da einige winzige Änderungen – der individuellen Note wegen – ein Tüpfelchen Farbe hier und eine runde Ecke da, ganz dezent natürlich, die Vorlage war für ihn schließlich schon so nahe der Perfektion. Schön auch, dass ich seinerzeit einen längeren Blogbeitrag zu meinen Designentscheidungen verfasst hatte. Das hatte auch Herr X. bemerkt und erwähnenswerte Passagen kurzerhand in den Relaunch-Beitrag seines neuen Layouts übernommen.

Einige Monate später trug es sich zu, dass ich beim Sichten einiger Kommentare zufällig auf der schönen neuen Webseite des Herrn X. landete und dort ein ein selten-klares Déjà-vu erlebte. Das alles hatte ich schon mal gesehen … ja richtig, bei mir selbst. Und weil ich wenig begeistert war, die Mühen meiner Freizeit weitgehend deckungsgleich als das Aushängeschild des "professionell" arbeitenden Herrn X. wiederzuerkennen (einzelne Grafiken flossen sogar in eines seiner Referenzprojekte ein), kontaktierte ich Herrn X. per Skype um ihm mein Unbehagen bezüglich seines Handelns zu verdeutlichen. Herr X. berief sich im weiteren Verlauf auf selektiven Gedächtnisausfall ("Ich weiß nicht, was ich mir dabei gedacht habe.") gab jedoch nach mühsamer Diskussion, wie anders ein eigenständiges Layout denn mindestens sein müsse, letztlich doch nach und beseitigte das Problem weitgehend. Damit war das Thema aus der Welt und die Welt drehte sich langsam weiter…

Schlankerer Framework-Core

Die wichtigste Änderung gleich zu Beginn: YAML besteht nunmehr nur noch aus zwei Kernbausteinen. Die base.css ist das Herzstück des Frameworks und stellt dem Nutzer ein schonendes Browser-Reset, oft benötige CSS-Klassen für die Layouterstellung (Float Clearing, Skiplinks, ect.), die “Subtemplates” als flexible Grid-Bausteine, ein universelles Fallback auf ein dreispaltiges Basislayout und wichtige Vorgaben für eine fehlerfreie Druckausgabe bereit. Über den zweiten Baustein, die iehacks.css werden die älteren Versionen des Internet Explorers 5.x bis 7.0 mit Bugfixes versorgt, die so formuliert sind, dass sie ohne Eingreifen des Anwenders den überwiegenden Teil der CSS-Bugs dieser Browser korrigieren. Der ehemaliige dritte Baustein, die print_base.css ist in der base.css aufgegangen.

Eine Umstrukturierung der medienspezifischen Definitionen innerhalb der base.css ermöglichte weiterhin einige Vereinfachungen der Codebasis, sodass trotz der Erweiterung der Grid-Komponente der gesamte Framework-Core insgesamt fast 600 Byte (ca. 10%) kleiner geworden ist. Mit den Wegfall der print_base.css kann zudem ein HTTP-Request eingespart werden (zumindest, wenn man die finalen Stylesheets nicht zusammenfasst) und in modernen Browsern wie dem Internet Explorer 8, Firefox, Opera, der Safari benötigt der YAML-Core nur noch 2,34 kB (slim_base.css). Ausschließlich die veralteten Versionen des Internet Explorers 5.x – IE 7.0 müssen den vollständige Core mit 5,04 kB laden.

Neue Features & Altlastenentsorgung

Wie mit fast jeder YAML-Version wird auch mit YAML 3.2 der Funktionsumfang des Frameworks leicht erweitert. Die Subtemplates (die Grid-Komponente von YAML) erhält vier weitere Unterteilungen (20%, 40%, 60% und 80%). Selbstverständlich besteht auch hier die Möglichkeit, gleiche Containerhöhen über die Klasse .equalize zu erzwingen. Daneben steht mit einem weiteren Add-on, dem SyncHeight-Plugin für jQuery, eine JavaScript-Alternative für das Erzwingen gleichhoher Container zur Verfügung.

Der Formularbaukasten ist ebenfalls flexibler geworden. So ist die Klasse .yform nicht mehr an das form-Element gebunden, was den Einsatz in Content Management Systemen wie z.B. ExpressionEngine vereinfacht, bei denen der form-Tag automatisch vom CMS generiert wird. Die zusätzliche Darstellungsklasse .full hilft bei Platzproblemen (schmale Formulare) und erzeugt Input-, Select-Felder und Textareas mit voller Breite des umgebenden Elternelementes. Ein neues Layoutbeispiel demonstriert, wie einfach und komfortabel sich mehrspaltige Formulare mit YAML erstellen lassen.

Neben diesen neuen Möglichkeiten, wurden mit diesem Release auch einige Altlasten beseitigt. So wurden die IE-Fixes für die ehemaligen ID’s #page_margins und #page aus der iehacks.css entfernt. Beide ID’s werden seit YAML 3.1 (Januar 2009) in mehrfach verwendbare Klassen umgewidmet. Einen echten Feature-Drop betrifft der Verzicht auf die Möglichkeit, Spaltenhintergründe mit Hilfe der Border-Definition von #col3 zu erzeugen. Zwar ist diese Technik denkbar einfach in der Umsetzung, sie beschwört aber in Verbindung mit den Windows-Kontrastmodi ein Zugänglichkeitsproblem herauf, da in diesen Modi Vordergrund- und Rahmenfarben auf den gleichen Farbwert gesetzt werden, infolgedessen Inhalte mit dahinterliegenden farbigen Rahmen (den simulierten Spaltenhintergründen) z.T. nicht mehr lesbar sind. Erschwerend kam hinzu, dass diese Technik im Internet Explorer ein Anpassung des z-index von #col3 bedurfte, was in seltenen Fällen das Selektieren von Inhalten mit der Maus im Browser blockierte.

Ein oft diskutierter Punkt unter vielen Framework-Anwendern war bisher der Workaround zur Vermeidung seitlich springender, zentierter Layouts im Firefox und Safari durch Erzwingen eines vertikalen Scrollbalkens. Mit der Veröffentlichung der neuen Browsergenerationen Internet Explorer 8, Firefox 3.5, Safari 4 und Opera 10 wurde die bisherige Lösung unbrauchbar und deshalb aus dem Core entfernt. An ihre Stelle tritt eine CSS3-basierte Lösung (overflow-y: scroll), welche nunmehr in den Nutzerstylesheets (basemod.css) verankert ist und somit von jedem Anwender bei Nicht-Gefallen einfach deaktiviert/entfernt werden kann.

Ebenfalls ersatzlos gestrichen wurde das Debug-Stylesheet (debug.css), welches mit der Version 3.0 Einzug in das Framework gehalten hatte. Zu sehr litt die Übersicht bei der Vielzahl der gleichzeitig eingeblendeten Informationen. Die fehlende Konfigurierbarkeit und die umständlichen Handhabung waren ebenfalls nicht vorteilhaft. Mit dem bereits im Febuar 2009 veröffentlichten Codeanalyse-Tool YAML Debug steht YAML-Entwicklern eine deutlich bessere und vielseitigere Alternative zur Verfügung, die mit einem einzigen Klick jedes Layout analysiert.

Handwerkszeug für die Barrierefreiheit

Kein Framework, auch nicht YAML, ist ein Garant für barrierefreie Webseiten. Dennoch zeigt sich mehr und mehr, wie sinnvoll und richtig es ist, Webentwicklern das grundlegende Handwerkszeug innerhalb des Frameworks zur Verfügung zu stellen. In YAML 3.2 wird eine neue Darstellungsmöglichkeit für Skiplinks unterstützt, die ein Überlagern des Layouts für die eingeblendeten Skiplinks ermöglicht und dadurch die sonst üblichen Probleme bei deren Integration beseitigt. Zudem wird für Webkit-basierte Browser ein JavaScript-Fix mitgeliefert, um auch Apple’s Safari und Google Chrome dazu zu bewegen, den Focus auf die angesprungene ID zu setzen.

Ein weiterer Schritt ist die konsequente Einbeziehung von WAI-ARIA. Sämtliche bei YAML mitgelieferte Beispiellayouts wurden mit ARIA-Landmarkroles versehen. Zwar handelt es sich hierbei nicht wirklich um ein Feature des Frameworks (die korrekte Auszeichnung sollte der Webentwicklers vornehmen), dennoch halte ich auch diesen Schritt für wichtig, um als Framework-Entwickler trotz der noch fehlenden Validierungsmöglichkeiten im W3C-Validator die positiven Effekte des kommenden Standards hervorzuheben. Schon heute können alle modernen Browser (einschließlich des IE8) mit WAI-ARIA umgehen und ermöglichen somit einen deutlichen Zugewinn an Barrierefreiheit auf Webseiten jeder Komplexitätsstufe.

Das “Accessible Tabs” Plugin von Dirk Ginader wird mit YAML 3.2 als Add-on ein fester Bestandteil des Frameworks. Das dahinter stehende Konzept habe ich zusammen mit Dirk Ginader bereits vor zwei Jahren entwickelt, die Umsetzung im Rahmen dieses Plugins ist mittlerweile ausgereift und umfangreich getestet. Auch dieser Baustein ist weniger als Feature des Frameworks zu sehen. Stattdessen bemühe ich mich darum, zusammen mit YAML sinnvolle Best-Practice-Lösungen zu vermitteln und die Verbreitung dieser Techniken zu fördern.

Zusammenfassung

Neben diesen großen Neuerungen/Verbesserungen stehen zahlreiche kleinere Korrekturen hier und da, über die das Changelog im Detail Ausfunft gibt. Wie mit jedem Release wurde auch die Projektvorlage “Simple Project” auf den aktuellen Stand gebracht.Der YAML Builder beherrscht momentan WAI-ARIA noch nicht und auch die neue Skiplink-Variante ist dort noch nicht implementiert, die Codeausgabe ist aber selbstverständlich kompatibel zu YAML 3.2.

Der Release-Zyklus war diesmal deutlich länger, zudem zwischen v3.1 und v3.2 keine sogenannten Maintenance-Releases eingeschoben wurden. Der Hauptgrund hierfür lag in der eng gestaffelten Veröffentlichung der aktuellen Browsergeneration, angefangen mit dem Internet Explorer 8 im Frühjahr 2009. Gerade bei diesem war es wichtig, die zuverlässige Funktion der Kernfunktionen des Frameworks ohne jegliche Hacks zu überprüfen. Nach nunmehr einem halben Jahr lässt sich dieser Fakt bestätigen. Einzig bei der Darstellung von Formularen benötigt der Internet Explorer 8 noch wenige individuelle Hilfestellung, die notwendigen Anpassungen kennt der Formularbaukasten jedoch.

Daneben stellt das 3.2-Release für mich eine weitere Schärfung des Profils von YAML hinsichtlich des modularen Aufbaus auf Basis eines sehr schlanken Kerns und der Focussierung auf flexible, barrierefreie Webseiten dar. Und die Entwicklung geht weiter ...