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.


Sonntag04. März 2012

Anfang Januar, nur wenige Tage vor dem Release von YAML 4 fiel die endgültige Entscheidung darüber, in welcher Form ich zukünftig mein YAML Developer Blog betreibe. Damals, vor ca. 50 Tagen, habe ich mich für ein Experiment entschieden - eine Projektseite auf Google+.

Begeistert hat mich das soziale Netzwerk schon seit seinem Start. Ich bin mit meinem privaten Account seit Anfang an dabei und habe die Offenheit und Kommentierfreudigkeit der dortigen Community schätzen und lieben gelernt. Und obwohl ich anfangs meine Zweifel hatte, wie lange diese Euphorie wohl anhalten würde (schließlich fehlen noch immer eine gute öffentliche API und demzufolge auch Apps), bin ich bisher treu geblieben. Der zu Twitter vergleichbare Ansatz, Usern, deren Meinung man schätzt, einfach folgen zu können, führt zu einem angenehmen Klima in meiner Timeline.

Mit diesen Erfahrungen im Hinterkopf stellte sich mir Anfang Januar die Frage, wie ich beim Relaunch von YAML.de mit dem Entwicklerblog weiterverfahre. Bis dahin lief die umfangreiche, zweisprachige Website auf einer recht mühsam eingerichteten und pfegeintensiven Typo3 Installation und diese - das stand bereits fest - würde mit dem Relaunch einer Webpräsenz aus simplen statischen Seiten weichen müssen. Das alte Developer-Blog setzte auf Wordpress und damit eigentlich auf eine sehr angenehme Arbeitsumgebung. Doch es war nie wirklich erfolgreich gewesen. Einerseits sind in 4 Jahren kaum mehr als 20 Beiträge darin veröffentlicht worden, andererseits hat es auch nie eine gute Reichweite entwickelt, denn die RSS-Zugriffszahlen und Kommentare hielten sich in sehr überschaubaren Grenzen. Das waren für mich zwei gute Gründe, auch Wordpress den Laufpass zu geben und ein Experiment zu starten mit einer Projektseite bei Google+.

Die Vorteile sind dabei schnell erläutert. Der Administrationsaufwand sinkt auf ein Minimum und ich kann mich voll und ganz auf die Inhalte konzentrieren. Der Nachteil - den man immer auch im Hinterkopf haben muss - ist, ich pflege meine Inhalte nicht mehr auf meiner eigenen Domain (in meinem eigenen Haus). Für mein privates Blog wäre dieser Gedanke auch heute unvorstellbar. Für das Entwicklerblog von YAML war es bisher eine ausgesprochen gute Entscheidung.

Was ist seither passiert?

  • Ich habe 19 Blogbeiträge veröffentlicht.
  • Ich habe bisher 101 Kommentare erhalten.
  • Meine Beiträge wurden 75 Mal von anderen Nutzern geteilt,
  • und 154 Mal mit einem “+1” versehen.
  • Die Seite hat mit Stand heute 1519 Follower.

Soweit die technischen Daten. An dieser Stelle ist ein Vergleich zu Twitter interessant, denn auch dort bin ich mit dem Account @yamlcss seit Oktober 2009 aktiv und habe dort bei 143 Tweets bis heute 1897 Follower bekommen. Für mich sind beide Kanäle momentan unverzichtbar, aber es zeigt, wie rasant Google+ wächst und vor allem bin ich von der Kommentarfreudigkeit und der Gesprächskultur auf Google+ begeistert. Beides fehlt auf Twitter mehr oder minder, Twitter ist nunmal ein Push-Nachrichtenkanal, wirkliche Kommunikation stand bei diesem Dienst noch nie im Vordergrund. Und zuletzt war auch die Entscheidung, den Blog bei Google+, wie auch den Twitter-Account, in Englisch zu befüttern aus heutiger Sicht eine gute Wahl. Die Follower verteilen sich sehr gleichmäßig rund um den Globus, was mich sehr freut, denn erstmals habe ich das Gefühl, meine Zielgruppe wirklich zu erreichen.

Und das soll es als erste Einschätzung auch gewesen sein. Die ersten Schritte sind gemacht, ich fühle mich in meinem Konzept bestätigt und freue mich darauf, wie sich das Projekt in den nächsten Monaten weiterentwickelt.


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


Samstag31. Dezember 2011

Es hat nur wenige Tage gebraucht, um mit Sublime Text 2 warm zu werden. Dieser schlanke, spartanisch aussehende Editor hat es faustdick hinter den Ohren und mich erstaunlich schnell verzaubert. Das schönste daran, es gibt ihn sowohl für Windows, OSX als auch unter Linux. Es ist also überhaupt kein Problem, als Entwickler zwischen den einzelnen Welten hin- und herzuspringen, die Entwicklungsumgebung ist immer mit dabei.

Sublime Text 2 kommt mit einer ganzen Reihe verschiedener Color-Schemes daher. Ich persönlich mag dunkle UIs, weil ich oft bis tief in die Nacht programmiere und kann das Monokai-Theme empfehlen (gibt’s übrigens auch für Coda).

Eines der Highlights des Editors sind die zahlreichen Plugins. Zunächst solltet Ihr Euch aber Package Control installieren, einen bequemen Paket-Manager für Sublime Text 2. Über diesen könnt Ihr dann bequem aus Liste die zu installierenden Pakete auswählen, die Installation geschieht in der Regel vollautomatisch. Als Empfehlung hier eine kleine Auswahl der bei mir installierten Pakete:

  • Alignment - erleichtert die Ausrichtung des Quelltextes, z.B. vertikale Ausrichtung an Gleichheitszeichen
  • BracketHighlighter - Hervorhebung zusammengehöriger Klammern
  • Sublime JSLint - vollautomatisiertes Linting für JavaScript Code aus dem Editor heraus. Bequemer geht es nicht mehr
  • Tortoise - Speziell für Windows User interessant, erweitert es den Editor um Menüeinträge und Keyboard-Shortcuts zur Ansteuerung von Tortoise, dem defakto Standard-SVN-Client unter Windows
  • Zen Coding - komplexes Plugin zur Code-Vervollständigung für HTML & CSS

JSLint Konfiguration

Obgleich das JSLint Plugin auf Anbieb funktioniert (um eine Java-Runtime braucht man sich nicht kümmern, die kommt gleich mit), ist es dennoch sinnvoll, dem Linter ein wenig Wind aus den Segeln zu nehmen, um nicht von tausenden angeblichen Fehlermeldungen zugeschüttet zu werden. Die Konfiguration erfolgt über ein Config-File, welches man im Editor selbst über Preferences->Package-Settings->JSLint->Settings-Default erreicht.

Unter “jslint_options” kann man hier den Linter entsprechend der eigenen Vorlieben anpassen. Folgende Optionen habe ich gesetzt:

—predef $,document
Wer wie ich viel mit jQuery arbeitet, wird um die Option predef nicht herumkommen. Sie dient dazu, JSLint über globale Variablen zu informieren, auf die der zu prüfende Code zugreift und deren Benutzung somit nicht als Fehler gewertet wird. Für jQuery sind das mindestens $, bzw. jQuery und document.
—white
Ist meinem persönlichen Coding-Stil geschuldet, dass ich nicht von JSLint über die Verwendung von Leerzeichen belehrt werden will.
—browser
Damit werden typische gobale Variablen der Browser verfügbar, z.B. window.
—sloppy
Sollte immer aktiviert werden, solange man noch nicht mit “use strict”; arbeitet.

Das ganze sieht dann fertig so aus:

// Options pass to jslint.
"jslint_options": "--predef $,document --white --sloppy --browser"

Eine vollständige Liste der Optionen gibt es hier. Hat man das hinter sich gebracht, kann man den Linter jederzeit mit Crtl+J anschmeißen und sich anschließend gemütlich durch die Fehlerliste navigieren. So bequem hatte ich es bisher in keinem Editor.

 

 


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 5 von 44 Seiten

« Erste  <  3 4 5 6 7 >  Letzte »