Weblog

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 ...

Der geneigte Leser mag sich denken: Selber schuld, wenn man bei der Wohnungssuche nicht auf die DSL-Verfügbarkeit achtet. Tja, haben wir aber als gebrannte Kinder. Und seit Juli - damals habe ich erstmals versucht, einen Internetanschluss für unsere neue Berliner Wohnung zu bestellen - hat sich der offizielle Ausbaustatus der Telekom sogar noch verbessert.

Aktuell sieht es so aus, dass wir nahezu mittig innerhalb eines vollständig mit VDSL erschlossenen Wohngebietes wohnen. Die Webseite der Telekom zeigt denn auch vor lauter Magenta kaum noch andere Farben.

Leider nützt das alles wenig, einschließlich der wirklich freundlichen Mitarbeiter des Twitterkanals @telekom_hilft, wenn der Ruf nach Problemlösung wie folgt beantwortet wird:

...

Ich habe mir mal deinen Anschluss angesehen und habe festgestellt, dass wir dir aus technischen Gründen keine VDSL Leitung bereitstellen können, da die Dämpfungswerte zu hoch sind.

Gerne hätte ich dir eine VDSL Leitung gebucht, aber das ist leider nicht möglich. Ich weiß, dass du laut dem Verfügbarkeitstool die Möglichkeit hättest. Wir möchten dir jedoch eine einwandfreie Leitung bereitstellen und das können wir mit den Werten nicht. Es tut mir leid, dass ich dir nichts anderes sagen kann.

...

So schön die Worte auch sind. Es sind mehr oder weniger die gleichen Informationen, die ich schon im September bei der ersten Absage per Telefon erhalten habe. Meine eigentliche Hoffnung beim Kontakt zu @telekom_hilft war jedoch nicht wohlformulierter Trost, sondern dass sich jemand dieses Problems annimmt. Wohl zuviel gewollt.

Und damit besteht leider die traurige Vermutung, dass sich an dieser Situation auch in nächster Zukunft nichts ändern wird. Alternativen sind leider nicht vorhanden, denn auch Kabel Deutschland hinkt mit dem Netzausbau hinterher. Und so haben wir nun vorläufig einen DSL3000 Anschluss, der zu Spitzenzeiten (diese sind irgendwo zw. 01:00 und 06:00) sogar die volle DSL3000-Geschwindigkeit bringt.

Liebe Telekom, es nervt!

Fünf Jahre ist das nun her – ein halbes Jahrzehnt. YAML war damals eines der ersten Projekte, die den Begriff CSS-Framework zur Umschreibung des zugrunde liegenden Konzepts verwendeten. Ich erinnere mich an zahlreiche, lebhafte Diskussionen über den Sinn und Unsinn eines solchen Vorhabens. Heute sind diese Diskussionen weitgehend verstummt. Das Framework wurde stetig weiterentwickelt, begleitet von zusätzlichen Werkzeugen wie dem YAML Builder und YAML Debug. Es hat sich über die Jahre eine beeindruckend hohe Akzeptanz im professionellen Webdesign erarbeitet. Aktuell gibt es Tutorials oder vorgefertigte Implementationen für mindestens 28 verschiedene Content Management Systeme, darunter einsteigerfreudige Systeme wie Joomla und Wordpress genauso wie CMS-Schwergewichte, z.B. CoreMedia CMS oder Open Text (ehemals RedDot). In den letzten beiden Runden (2008 und 2009) des Biene-Awards zur Auszeichnung barrierefreier Webseiten vertrauten zahlreiche Preisträgern auf das Framework.

Besonders beeindruckt hat mich eine URL, auf die mich gestern Abend Michael Preuß eher nebenbei aufmerksam gemacht hat: http://www.yamlchina.com. Offensichtlich hat sich im Verlauf der letzten 4 Monate in China eine begeisterte Community formiert, die eine weitgehend vollständige Übersetzung der Online-Dokumentation sowie darüber hinaus zahlreiche Anwendertutorials verfasst hat und voller Respekt auf das Original verlinkt. Es lohnt sich wirklich, die Seite mit der automatischen Übersetzungsfunktion von Google Chrome zu besuchen.

Ich möchte mich deshalb an dieser Stelle bei allen Wegbegleitern bedanken, die durch Ihre Unterstützung, ihre konstruktiven Kritik, ihre Bugmeldungen, ihre Blog- und Zeitschriftenartikel, Zuschriften und Vorträge zu diesem Erfolg beigetragen haben.

Und auch nach fünf Jahren ist ein Ende der Entwicklung nicht abzusehen. Erst vorgestern ist die neue Version 3.3 online gegangen und ein erster Ausblick auf die Version 4.0, die sich parallel bereits in Entwicklung befindet, und deren Hintergründe gegeben. Es bleibt also spannend, das kann ich versprechen.

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.

Worum geht es? Vor langer Zeit als die Welt noch schwarz-weiß ... als das Web noch jung und HTML4 Quellcode noch fürchterlich chaotisch und gefühlt frei jeglicher Stilregeln geschrieben werden konnte, da kamen einige schlaue Webschaffende auf die Idee, dass es doch ein wirklicher Fortschritt wäre, wenn sich die Entwicklergemeinde an Standards halten würde. Webstandards kamen in Mode und der Ruf nach sauberem, validem Code drang selbst in die hintersten Gassen. XHTML 1.0 war damals der große argumentative Renner, denn XHTML zwang Webentwickler zu Ordnung und Sauberkeit im Code. Tags mussten geschlossen, Attributwerte zwingend in Anführungszeichen gesetzt werden. Die jahrelange Arbeit mit XHTML hat mir zwar XML an sich kein noch so kleines Stückchen sympathischer gemacht (aufgrund seiner Fehlerintoleranz) aber es hat mich gelehrt sauberen Code zu schreiben.

Und da auch ich zu denen gehöre die Bücher veröffentlichen, um mein Wissen um HTML & CSS weiterzugeben, bin ich auch nicht ganz unschuldig an der Situation, die sich uns Entwicklern heute bietet. Seit vielen Jahren predigen wir: Validiert Euren Code! Wenn irgendetwas nicht funktioniert und Ihr jemanden nach Hilfe fragen wollt: Erst validieren – dann jemanden fragen! So oder so ähnlich liest man es in jedem CSS-Buch (und davon gibt es mittlerweile reichlich). Leider haben offensichtlich die wenigstens Autoren es bisher geschafft, den ahnungslosen Neulingen in einfachen Worten zu vermitteln, was Validität eigentlich bedeutet und was die Ausgaben der Validierungsdienste des W3C (HTML | CSS) wirklich bedeuten.

Dieser Umstand ist mir so richtig klar geworden, als ich vorhin über folgendes Foreneintrag gestolpert bin:

Hallo Zusammen!

Ich habe per CSS folgende Codes eingefügt um einen Text vertikal darzustellen. Soweit funktioniert das auch. Jedoch bei der W3C Validierung werden diese CSS Anweisungen als Fehler deklariert. Gibt es hierzu auch eine valide Möglichkeit?

Dazu wurde folgender Codeschnipsel mitgeliefert:

-webkit-transform: rotate(-90deg); 
-moz-transform: rotate(-90deg);    
-o-transform: rotate(270deg);

Ein Einsteiger präsentiert sauberes CSS3, denkt bei den Vendor-Präfixes an alle wichtigen Browser, freut sich zurecht über den Erfolg (”...Soweit funktioniert das auch…”) und wendet sich anschließend trotzdem verzweifelt an ein Forum weil der W3C-Validator ihm ein schlechtes Gewissen eingeredet hat. Das muss definitiv aufhören, denn spätestens wird das ehemalige Mantra der Pflicht-Valität zum Boomerang für uns erfahrenere Entwickler, denn hier werden die Aussagen des Validators fehlinterpretiert.