High Resolution Weblog Das Weblog über Digitale Fotografie // Bildbearbeitung // Webdesign von Dirk Jesse 2012-01-18T22:31:35+00:00 ExpressionEngine Copyright (c) 2012, Dirk Jesse YAML 4 Release - Generationswechsel eingeläutet tag:highresolution.info,2012:weblog/11.1410 2012-01-18T11:39:34+00:00 2012-01-18T22:31:35+00:00 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. 2012-01-18T11:39:34+00:00 Dirk Jesse http://www.highresolution.info YAML, Webdesign 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.

Namespaces

Eine der häufigsten Quellen für Probleme bei der Frontendentwicklung in Verbindung mit Content Management Systemen, speziell bei größeren oder über Jahre gewachsenen Projekten, sind Kollisionen von ID- und Klassennamen der bestehenden Inhalte mit dem neu zu integrierenden CSS Framework. Dies fängt bei so beliebten Systemen wie Wordpress an, welches per default (und nicht ganz einfach zu unterbinden) die CSS Klasse .page an das <body>-Element vergibt und damit bereits mit der gleichlautenden Klasse von YAML 3.x kollidiert.

Ein weiteres Problem waren große, gewachsene Webprojekte. CSS-Klassen, wie .wrapper oder .col1 sind seit vielen Jahren gebräuchlich. Hat ein Projekt erst einmal eine gewisse Größe erreicht (ich rede hier von einigen tausend Seiten), ist die Wahrscheinlichkeit sehr gering, dass bei einem Relaunch wirklich alle Inhalte auf den neuesten Stand gebracht werden können. Im Regelfall wird man es neben einigen frisch aufbereiteten Seiten mit viel Legacy-Code zu tun haben, der unvorhersehbares Konfliktpotential mit sich bringt.

In YAML 4 werden daher die CSS-Klassen (IDs werden durch das Framework nicht mehr definiert) der Kernbestandteile des Frameworks mit dem Präfix ym- versehen. Nicht jeder wird sich über diese Regelung freuen, denn zumindest ein wenig leidet immer auch die Lesbarkeit der Klassennamen. Entsprechend des Anwenderfeedbacks der letzten Jahre überwiegt in diesem Fall aber klar der Nutzen.

HTML5, CSS3 und veraltete Browser

Aus technischer Sicht gibt es im Grunde kaum eine Neuheit, denn YAML unterstützt bereits seit Version 3.3 von Hause aus HTML5 und auch für den Umgang mit CSS3 waren die 3.x Versionen technisch bereits bestens gerüstet. Dennoch hat sich hier eine Kluft zwischen der Codebasis des Frameworks und dem äußeren Eindruck des Projektes ergeben, denn die alte YAML-Seite und insbesondere die Layoutbeispiele waren optisch tief und fest im Erstellungsjahr 2007 verankert und wirken seit einiger Zeit angestaubt und altbacken. Und so war es nur logisch, dass YAML nicht nur den CSS-Support für die neuen HTML5 Elemente mitbringt, sondern dass die beiliegenden Layoutbeispiele diesen Weg auch aktiv beschreiten.

Der Internet Explorer 6 wird von YAML noch immer unterstützt. Hier gibt es keine qualitativen Einschnitte im Kern des CSS Frameworks. Das ist auch nicht notwendig, denn YAML hat die notwendigen Anpassungen für den IE6 und 7 schon immer separat (in der Datei iehacks.css) verwaltet. Geändert hat sich jedoch die Verwendung dieser Datei. In YAML 4 gibt es darüber hinaus keine gesonderten Patch-Stylesheets für den IE mehr, die iehacks.css wird fortan direkt über den Conditional Comment eingebunden. Das bedeutet andererseits, dass ich in den Beispiellayouts keine Anstrengungen mehr unternehme, den bei Spaltenlayouts typischen 3-Pixel-Bug manuell zu fixen oder per JS-Expression einen Ersatz für den fehlenden Support für min-width / max-width mitliefere. Für letzteres gibt es bei Bedarf effektiven Ersatz in Form von Respond.js. Wer darüber hinausgehend weiterhin auf den Feinschliff für den IE6 nicht verzichten will, dem steht der 3.x Versionspfad von YAML, einschließlich des YAML Builders auch weiterhin zur Verfügung. Man kann sich dort auch weiterhin noch an den verwendeten Techniken bedienen.

Für den HTML5 Support im IE6-8 setze ich auf html5shim. In diesem Projekt gibt es aktuell viel Bewegung, es ist daher jedem, der tiefer in HTML5 einsteigen will empfohlen, sich mit den aktuellen Diskussionen und der Weiterentwicklung des Projekts zu beschäftigen.

Flexibilität eines CSS Frameworks

YAML wurde in der Vergangenheit als ein System beschrieben, welches ein mehr oder weniger umfangreiches bzw. fertiges Basislayout mitliefert. Aus diesem löscht der Anwender, was er im jeweiligen Projekt nicht benötigt. In Version 1 konnte YAML nicht viel mehr, weshalb dieses Erklärmodell in der Anfangszeit durchaus stimmig war. Über die nachfolgenden 6 Jahre hat sich das Projekt jedoch deutlich weiterentwickelt. Der Framework-Charakter wurde immer stärker herausgearbeitet und das Projekt durch zahlreiche optionale Bausteine (Grid-Elemente, Formulare, usw.) ergänzt.

Heute erwarten die Anwender eines CSS Frameworks eine klare Trennung der Framework-Logik vom Screen-Design. Eine Sammlung, aufeinander abgestimmter Bausteine (Layout, Navigation, Typographie, Formulare, Print), um effektiv und schnell Prototypen realisieren zu können. Flexibilität, nicht zwingend im Screen-Design selbst, sondern in Handhabung des Frameworks ist gefragt. Ein Wechsel des Gridrasters von 12 auf 24 Spalten oder der Wechsel von einem fixen Grid auf eine fluides, sollte nicht dazu zwingen, auch das CSS Framework selbst wechseln zu müssen. Wer ein Layout wahrhaft responsive gestalten will, braucht kein «Responsive Framework» mit einem willkürlich vorgegebenen Linarisierungspunkt, welcher sich an der Displayauflösung aktueller Smartphones ausrichtet – diese sind unter Umständen in 6 Monaten bereits wieder veraltet. Der Umbruch der einzelnen Layoutvarianten eines adaptiven Layouts sollte individuell für jedes Design bestimmt werden. Frontententwickler benötigen hierfür möglichst praktische und einfach zu handhabende Werkzeuge – das ist die Aufgabe des CSS Frameworks. Und in diesem Sinne habe ich YAML weiterentwickelt.

YAML 4 bietet deswegen keinen fest vorgegebenen Wert zur vollständigen Linearisierung der Layout-Module. Stattdessen wähle ich den Weg über eine progressive Linearisierung des Layouts in mehreren Stufen. Über die Anzahl der Stufen und die Übergangspunkte hat der Anwender vollständige Kontrolle und, obwohl das recht komplex klingen mag, die Anwendung ist letztlich sehr einfach und komfortabel. Was YAML nicht mitliefert, sind technische Lösungen für die bandbreitenoptimierte serverseitige Auslieferung von Medien (Bildern, Videos). Das ist erstens nicht die Aufgabe eines CSS Frameworks, zweitens gibt es zahlreiche Projekte, auf die im Bedarfsfall zurückgegriffen werden kann.

Die neue Website

«Eat your own dog foot» ist nicht nur ein geflügelter Satz, es war schon immer Programm in meinen Projekten. Es ist deshalb nur logisch, dass es mit YAML 4 sowohl eine neue Website, als auch neue Layoutbeispiele geben musste, die sich auf dem aktuellen Stand der Technik bewegen, nämlich HTML5, CSS3 und Responsive Design. Drei Schlagworte, die im letzten Jahr leider z.T. Buzzword-Charakter angenommen haben, worüber ich ja auch schon ein paar Worte hier im Blog verloren habe. Unabhängig davon finde ich jedoch, dass ein CSS Framework nicht nur versprechen, sondern auch zeigen sollte, was die angebotenen Features zu leisten im Stande sind – und zwar im Produktivbetrieb und nicht nur in einfachen HTML-Demos.

Lizenzbedingungen und ein neues Lizenzmodell

Mit dem Release von YAML 4 veröffentliche ich auch neue, anwaltlich geprüfte Lizenztexte für die beiden bisherigen kommerziellen Lizenzmodelle von YAML, die Projektlizenz und die Generelle Lizenz. Bei Erstellung der Texte wurde darauf geachtet, dass der Status Quo der Nutzungsrechte erhalten bleibt und sich für bestehende Projekte und Lizenznehmer keine Änderungen ergeben. Die Lizenztexte sind auf YAML.de vollständig in englischer Sprache hinterlegt. Neben der englischen Fassung gibt es die Lizenztexte natürlich auch in Deutsch - nachzulesen in Kürze (1..2 Tage brauchen wir noch) im YAML-Shop.

Neu hinzugekommen und sicherlich interessant für CMS-Projekte, Templateshops oder Theme-Frameworks ist die OEM-Lizenz. Über dieses neue Lizenzmodell wird es möglich, YAML fest in andere Projekte zu integrieren und die Nutzungsrechte an Endkunden übertragbar zu gestalten. Als Beispiel hierfür sei das Wordpress-Framework Xtreme One genannt, welches bereits seit dem Sommer 2011 mit einer solchen OEM-Lizenz ausgestattet ist und Endanwendern automatisch die vollen Nutzungsrechte für YAML sichert.

Nachtrag: Die offiziellen (etwas knapper gefassten) englischsprachigen Release Notes gibt es hier drüben. Die YAML Website auf Google+ wird zukünftig auch der von mir favorisierte Nachrichtenkanal sein. Deutschsprachiges und persönlich angehauchte Infos gibt’s natürlich weiterhin hier.

]]> Sublime Text 2 und JSLint tag:highresolution.info,2011:weblog/11.1409 2011-12-31T18:07:41+00:00 2011-12-31T18:09:42+00:00 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). 2011-12-31T18:07:41+00:00 Dirk Jesse http://www.highresolution.info CSS &amp; XHTML, JavaScript, Software 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.

 

 

]]> Vom Schein und Sein eines Print-Stylesheets tag:highresolution.info,2011:weblog/11.1408 2011-11-16T13:30:56+00:00 2011-11-16T15:19:57+00:00 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 &ndash; 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. 2011-11-16T13:30:56+00:00 Dirk Jesse http://www.highresolution.info CSS &amp; XHTML, Webdesign, Zugänglichkeit 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.

]]> Kurzreview: jQuery-Workshop bei Undsoversity tag:highresolution.info,2011:weblog/11.1407 2011-10-21T18:39:29+00:00 2011-10-23T08:10:30+00:00 jQuery hat zweifelsfrei für viele Anwender und vor einigen Jahren auch für mich den Weg zum Verständnis von DOM Scripting und JavaScript geebnet. Insofern ist es wenig verwunderlich, dass mehr und mehr Lehrmaterial für jQuery auf den Markt kommt, welches sich gezielt an Einsteiger richtet und mit schnellen Ergebnissen begeistern will. Das neueste Projekt in dieser Hinsicht ist ein sechsstündiger jQuery Video-Workshop von Gerrit van Aaken, der seit ein paar Tagen bei Undsoversity zum Kauf bereit steht und sich ausdrücklich an Einsteiger richtet. Um sich vor dem Kauf einen Eindruck vom Gebotenen verschaffen zu können, stehen insgesamt drei Kapitel (Events und EventListener, Inline-Bildergalerie und ein interaktiver HTML5-Videoplayer) mit einer Gesamtlänge von fast 2 Stunden (fast 1/3 der Gesamtlänge) kostenfrei auf YouTube bereit. Aufgebaut sind die einzelnen Themenblöcke als Live-Coding Sessions in denen zu Beginn eine Aufgabe vorgestellt wird, die im Anschluss als “Blick über die Schulter” des Tutors mit HTML, CSS und eben jQuery (Anm: JavaScript sage ich hier bewusst nicht, denn JavaScript scheint kaum thematisiert zu werden) gelöst werden. Die Art und Weise der Präsentation finde ich von Konzept her gelungen und besonders interessant für Autodidakten (wie mich), die lieber durch Probieren als durch dumpfes Lesen neue Dinge lernen. Der Zuschauer kann die schrittweise Entwicklung des Programmcodes anhand konkreter Aufgabenstellungen miterleben und so dessen Logik sehr viel einfacher nachvollziehen, als beispielsweise aus einem spärlich kommentiertem, 2-seitigen Abdruck eines fertigen Quelltextes in einem Buch. 2011-10-21T18:39:29+00:00 Dirk Jesse http://www.highresolution.info Tutorials, jQuery jQuery hat zweifelsfrei für viele Anwender und vor einigen Jahren auch für mich den Weg zum Verständnis von DOM Scripting und JavaScript geebnet. Insofern ist es wenig verwunderlich, dass mehr und mehr Lehrmaterial für jQuery auf den Markt kommt, welches sich gezielt an Einsteiger richtet und mit schnellen Ergebnissen begeistern will.

Das neueste Projekt in dieser Hinsicht ist ein sechsstündiger jQuery Video-Workshop von Gerrit van Aaken, der seit ein paar Tagen bei Undsoversity zum Kauf bereit steht und sich ausdrücklich an Einsteiger richtet. Um sich vor dem Kauf einen Eindruck vom Gebotenen verschaffen zu können, stehen insgesamt drei Kapitel (Events und EventListener, Inline-Bildergalerie und ein interaktiver HTML5-Videoplayer) mit einer Gesamtlänge von fast 2 Stunden (fast 1/3 der Gesamtlänge) kostenfrei auf YouTube bereit.

Aufgebaut sind die einzelnen Themenblöcke als Live-Coding Sessions in denen zu Beginn eine Aufgabe vorgestellt wird, die im Anschluss als “Blick über die Schulter” des Tutors mit HTML, CSS und eben jQuery (Anm: JavaScript sage ich hier bewusst nicht, denn JavaScript scheint kaum thematisiert zu werden) gelöst werden. Die Art und Weise der Präsentation finde ich von Konzept her gelungen und besonders interessant für Autodidakten (wie mich), die lieber durch Probieren als durch dumpfes Lesen neue Dinge lernen. Der Zuschauer kann die schrittweise Entwicklung des Programmcodes anhand konkreter Aufgabenstellungen miterleben und so dessen Logik sehr viel einfacher nachvollziehen, als beispielsweise aus einem spärlich kommentiertem, 2-seitigen Abdruck eines fertigen Quelltextes in einem Buch.

Weniger gut gelungen ist die Umsetzung dieses Konzepts. Das Live-Coding ist eine hohe Kunst und offenbart immer dann seine Tücken, wenn der Tutor nicht auf den Punkt vorbereitet ist. Ein bewusst eingebauter Logikfehler im Code zum Zwecke der Demonstration des Debuggings oder eines wichtigen logischen Schritts, ist sicherlich sinnvoll und lässt den Workshop authentisch und “lehrreich” wirken. Zuviele kleine Korrekturschleifen in zu kurzer Abfolge (speziell im Video-Kapitel) wirken hingegen mit der Zeit eher störend. Beim Herauskopieren von Code-Schnipseln aus anderen Webseiten rinnen die Minuten der erkauften Zeit sehr viel schneller als man denkt. In einem kostenlosen Screencast, ist sowas kein Problem. In einem kostenpflichtigen Lernvideo wünsche man sich dann doch ein etwas zielgerichtetes Arbeiten und Erklärungen mit mehr Tiefgang anstatt reinem copy/paste (Stichwort: Mediaelement.js).

Gerrits Workshop richtet sich an Einsteiger ohne JavaScript-Kenntnisse. Der Einstieg erscheint auch butterweich, allerdings hätte ich mir gewünscht, dass man über 18 Kapitel nicht nur die Komplexität der Aufgaben, sondern auch den Anspruch an den Coding-Stil schrittweise steigert. So hätte man meiner Meinung nach nicht gänzlich auf das eine oder andere Standard-Pattern für eine strukturierte JS-Programmierung verzichten müssen. Selektoren, die innerhalb weniger Zeilen 4..5 Mal aufgerufen werden (teilweise auch innerhalb von Schleifen), darf man schonmal cachen. Das mag für die konkreten Beispiele nicht lebenswichtig sein, hilft aber auch Einsteigern ein Gefühl für mögliche Performance-Probleme zu entwickeln für den Fall, dass auch mal größere Mengen an DOM-Manipulationen von Nöten sind. Guten Stil muss man nicht zwingend theoretisch belehrend herunterbeten, gerade Einsteigern kann man ihn leicht vermitteln, indem man ihn einfach vorlebt.

Deutliche Kritik muss man an dem Kapitel zum interaktiven HTML5-Videoplayer üben, denn dessen Codequalität ist wirklich erschreckend schlecht. In diesem Kapitel sollen Produktinformationen zeitsynchron zu einem Video angezeigt werden. Die dafür erforderlichen Daten werden per Ajax vom Server dynamisch nachgeladen. Allerdings wird auf das Ergebnis dieses Ajax-Requests zugegriffen, ohne überhaupt auf dessen Existenz zu prüfen, bzw. auf seine Verfügbarkeit zu warten. Eine Callback-Funktion für einen Ajax-Error (sowas soll’s ja auch geben) gibt’s ebenfalls nicht. Die Daten werden einfach als “verfügbar” erklärt. Variablen werden nicht deklariert (sie werden dadurch zwangsweise global), eine Strukturierung des Codes – auch im Sinne einer einfacheren Wiederverwendung – findet nicht statt. Die globalen Variablen sind schon deshalb ein Problem, weil bereits bei einem zweiten Video gleicher Art auf der Seite, das Script sich zwangsläufig selbst die Werte überschreibt. Dass dieses Codebeispiel überhaupt funktioniert, ist mehr als glücklich. Denn die Asynchronität der success-Callbacks, die sich aus dem Ajax-Request, wie auch aus der Initialisierung des Videoplayers ergeben, wird weder angesprochen, noch im Code berücksichtigt und ich bin mir nicht sicher, ob dem Autor das Problem vollständig bewusst ist. Hier hat mindestens die Qualitätskontrolle versagt, wenn es denn eine gab.

An einer Stelle wird “unobtrusive JavaScript” erwähnt, kurze Zeit später jedoch Teile einer Webseite initial per JavaScript, sorry: jQuery, ausgeblendet, die nur bei Interaktion sichtbar werden sollen. Damit wird das Konzept von unobtrusive JavaScript auf den Kopf gestellt, denn das Ausblenden funktioniert ohne JavaScript nunmal nicht, genauso wie das zugehörige interaktive Feature. Das ist ein konzeptioneller Fehler, der ebenfalls vermeidbar gewesen wäre. Auf diese Weise summieren sich kleine und große Unsauberkeiten.

Ich arbeite nun schon seit über vier Jahren mit jQuery und habe in den Anfangszeiten neben einigen schnellen Erfolgen auch massenweise Fettnäpfe erwischt, in die ich mangels besseren Wissens, schlechter Tutorials und unperformanter Plugins gestolpert bin. Gerade wenn mit dem Rückenwind der ersten Erfolgen der Mut wächst, sich an größeren Aufgaben zu versuchen, ist ein sauberer Stil und ein solides Grundwissen nicht zu ersetzen. Deshalb hat mich Gerrits schnippische Antwort auf einen berechtigten, kritischen Kommentar von Alexander Farkas (welcher auf weitere Probleme aufmerksam macht) aus seinem eigenen Blog sehr gewundert. Zitat:

Was ist schon schlechter Programmierstil? Und vor allem: Was ist guter? Darüber wirst du viele verschiedene Meinungen finden. 

Richtig ist, dass man vieles aus dem Workshop eleganter und effizienter lösen kann. Aber es ist ein Einsteiger-Workshop mit einem gewissen Crashkurs-Charakter. Da kann man nicht stundenlang über Code-Qualität theoretisieren. [...], denn in ein paar Stunden »Über die Schulter gucken« bringt man den Leuten eben am besten solche Dinge bei, die sie sofort anwenden können.
[...]
Das Schöne an jQuery ist doch gerade, dass damit Einsteiger schnell (und dreckig) zu tollen Ergebnissen kommen. [...] Würden alle Webdesigner deine Maßstäbe anlegen, gebe es deutlich weniger spannende Anwendungen von jQuery.

Das (und ganz besonders die von mir fett hervorgehobenen Passage) hat mich vom Hocker gehauen. Es ist das eine, was man im Alltag mit jQuery/JavaScript anstellt. Es ist aber etwas anderes, wenn man vorgibt, Einsteigern etwas beizubringen zu wollen und sein Wissen zu Geld machen will. Da führt um Sorgfalt und Qualität kein Weg herum.

Egal, wie viel oder wenig Zeit man für die Vermittlung von Wissen hat. Man kann einen Einsteiger auf irgendeinen Weg führen oder auf den Richtigen. Man wird ihn auf beiden Wegen nur ein paar erste Schritte begleiten können und man kann ihm auf beiden Wegen schnelle Erfolge präsentieren. Der Unterschied besteht in der Zeit danach, wenn die Käufer eines mit 39,99 EUR (Einstiegspreis: 34,99 EUR) im Vergleich zu den Videotrainings einiger renomierter Verlage nicht unbedingt günstigen Video-Workshops, eigenständig weiterlaufen sollen. Jede Handwerker-Lehre beginnt damit, dass die Azubis lernen, dass man sein Werkzeug ordentlich behandelt und den Arbeitsplatz regelmäßig aufräumt. Schwer vorstellbar, dass in einem Video-Workshop für angehende Webentwickler derartige Werte keinen Platz mehr finden müssen.

Gerrit weist in seinem Blogbeitrag ausdrücklich auf die angenehmen wirtschaftlichen Rahmenbedingungen bei Undoversity hin:

Timo erledigt Produktion, Marketing, Vertrieb, Technik und Controlling in Eigenregie und ist dadurch mehrere Dimensionen effizienter als ein beliebiger Verlag es je sein könnte. Und das kommt natürlich auch den Tutoren zugute. Dass mein Anteil am Verkauf signifikant höher ausfällt als die 3–5%, die man sonst so bekäme, ist logisch.

Dem Lob an die Undsoversity-Macher schließe ich mich uneingeschränkt an, allerdings mit dem persönlichen Nachsatz: Die Verlage, mit denen ich bei bisher als Autor oder Fachgutachter bei verschiedenen Projekten zusammengearbeitet habe, legen großen Wert auf die inhaltliche Qualität und deren Kontrolle. Es ist schön, wenn die gesteigerte Effizienz zu höheren Einnahmen der Autoren führt – reich wird mit Fachbüchern oder Videotrainings nämlich niemand. Aber die Qualität der Produkte sollte in keinem Fall leiden, denn im Direktvertrieb ist eben auch direkt und ausschließlich die eigene Reputation in Gefahr. Deshalb meine Empfehlung an Gerrit: die Schwachstellen identifizieren und den Workshop überarbeiten.

Ich weise darauf hin, dass sich meine Meinung ausschließlich auf die drei Probekapitel des deutlich umfangreicheren jQuery-Workshops stützt und die hier formulierte Kritik auch nur diese drei Kapitel betrifft. Zu den weiteren 15 Kapiteln kann ich nichts sagen, denn gekauft habe ich den Video-Workshop nicht.

]]> Hurra, ein CSS-Framework ... und ein Rant tag:highresolution.info,2011:weblog/11.1405 2011-10-05T17:49:47+00:00 2011-10-06T06:29:48+00:00 Man sollte eigentlich meinen, dass man heute mit dem tausendsten Abklatsch des einfachen CSS-Grid Konzepts nicht viel mehr als seine Freunde beeindrucken kann. Zumindest sollte man das vermuten, wenn man, wie bei Toast, auch noch lesen muss: “... and it also sets some nice default styles for inline elements, such as links, emphasis, strong, small print, marks, abbr, and lists!” Schon traurig, wenn Derartiges als “Feature” herausgestellt und dann auch noch in der Fachpresse beklatscht wird. Selbst zu den Anfangszeiten hatten die meisten Projekte dieser Art höhere Ziele. Es ist nicht so, dass es beim Blick auf den Quelltext von Toast nichts zu sagen gäbe. Da wäre zum einen, dass Toast eben nicht, wie fälschlich bei T3N geschrieben, mit einem Standard-Reset daherkommt. Stattdessen setzt man nämlich, und das ist zumindest lobenswert, auf Normalisierung, statt auf Eric Meyers CSS-Dampfwalze, die oft genug in der Kritik stand. Ein weiteres erwähnenswerte Detail ist der Umstand, dass Toast für seinen flexiblen Grid-Ansatz mal eben auf eines der mit CSS3 neu eingeführten Box-Modelle baut (ohne darauf hinzuweisen, wohlgemerkt). Das macht die Arbeit mit flexiblen Breiten oder unterschiedlichen Einheiten in aktuellen Browsen ausgesprochen angenehm - solange man sich nicht um den Internet Explorer 6 und 7 kümmern muss. Denn diesen dürfte das Grid bei Verwendung irgendeines horizontalen Padding oder Border-Eigenschaft um die Ohren fliegen. Das muss man nicht zwingend negativ sehen, erwähnenswert ist es aber schon (zumal die Codebasis überschaubar ist). Ich persönlich mag da altmodisch denken, aber innerhalb eines Frameworks, halte ich das auch heute mindestens für problematisch, denn die Folgen in alten Browsern können drastisch ausfallen. Ebenfalls wäre durchaus diskussionsbedürftig, ob es aus Design-Sicht sinnvoll ist, wenn ein CSS-Framework unter “responsive” nichts anderes versteht, als das Grid unterhalb von 775 Pixeln vollständig zu linearisieren (was im übrigen nicht nur Toast, sondern auch andere Projekte betrifft). Aus meiner Sicht stellt sich beispielsweise die Frage, ob ein CSS-Framework für flexible Layouts überhaupt eine solche fixe Grenze vorschreiben sollte? Denn gerade flexible Layouts funktionieren erst richtig gut, wenn man die einzelnen Abstufungen des Layouts individuell auf dessen grafische Elemente abstimmt und sich nicht sklavisch einer fixen Zahl unterwirft, deren Ursprung vor vielen Jahren seine Relevanz verloren hat. Alle diese Punkte spricht der Beitrag bei T3N aber leider nicht an. Stattdessen bleibt er oberflächlich und nichts-sagend, denn Statements wie “Toast ist nicht für jedes Projekt geeignet. Textlastige Websites können durch den Einsatz des Frameworks an Übersichtlichkeit und Bedienbarkeit gewinnen.” ist ohne Begründung nichts wert. Das eine oder andere wenig technische Detail oder gar eine kritische Anmerkung zur x-ten Kopie der Kopie des Grid-Ansatzes sind offensichtlich zuviel verlangt. Stattdessen werden einfach die Infotexte der Toast-Webseite abgetippt, übersetzt und nicht gerade subtil bebildert - fertig ist der neue Fachbeitrag und genauso schnell sind die Infomeldungen darüber bei Twitter, Facebook, Google+ untergebracht. Dieses Schema taugt auch für die nächsten 50 CSS-Frameworks, soviel ist klar. Nun, wir haben im deutschsprachigen Raum leider nur eine sehr überschaubare Anzahl von Magazinen, die sich der Frontendentwicklung widmen. Deshalb ich finde es ehrlich gesagt jammerschade, dass die Jungs von T3N sich nicht mehr die Zeit nehmen, den Inhalt der Beiträge vor dem Schreiben genauer unter die Lupe zu nehmen. Hauptsache raus, die gierige Meute im Social-Network-Zirkus will bespaßt werden. Sorry T3N, ihr macht Euch uninteressant und entbehrlich. 2011-10-05T17:49:47+00:00 Dirk Jesse http://www.highresolution.info Frameworks Man sollte eigentlich meinen, dass man heute mit dem tausendsten Abklatsch des einfachen CSS-Grid Konzepts nicht viel mehr als seine Freunde beeindrucken kann. Zumindest sollte man das vermuten, wenn man, wie bei Toast, auch noch lesen muss: “... and it also sets some nice default styles for inline elements, such as links, emphasis, strong, small print, marks, abbr, and lists!” Schon traurig, wenn Derartiges als “Feature” herausgestellt und dann auch noch in der Fachpresse beklatscht wird. Selbst zu den Anfangszeiten hatten die meisten Projekte dieser Art höhere Ziele.

Es ist nicht so, dass es beim Blick auf den Quelltext von Toast nichts zu sagen gäbe. Da wäre zum einen, dass Toast eben nicht, wie fälschlich bei T3N geschrieben, mit einem Standard-Reset daherkommt. Stattdessen setzt man nämlich, und das ist zumindest lobenswert, auf Normalisierung, statt auf Eric Meyers CSS-Dampfwalze, die oft genug in der Kritik stand.

Ein weiteres erwähnenswerte Detail ist der Umstand, dass Toast für seinen flexiblen Grid-Ansatz mal eben auf eines der mit CSS3 neu eingeführten Box-Modelle baut (ohne darauf hinzuweisen, wohlgemerkt). Das macht die Arbeit mit flexiblen Breiten oder unterschiedlichen Einheiten in aktuellen Browsen ausgesprochen angenehm - solange man sich nicht um den Internet Explorer 6 und 7 kümmern muss. Denn diesen dürfte das Grid bei Verwendung irgendeines horizontalen Padding oder Border-Eigenschaft um die Ohren fliegen. Das muss man nicht zwingend negativ sehen, erwähnenswert ist es aber schon (zumal die Codebasis überschaubar ist). Ich persönlich mag da altmodisch denken, aber innerhalb eines Frameworks, halte ich das auch heute mindestens für problematisch, denn die Folgen in alten Browsern können drastisch ausfallen.

Ebenfalls wäre durchaus diskussionsbedürftig, ob es aus Design-Sicht sinnvoll ist, wenn ein CSS-Framework unter “responsive” nichts anderes versteht, als das Grid unterhalb von 775 Pixeln vollständig zu linearisieren (was im übrigen nicht nur Toast, sondern auch andere Projekte betrifft). Aus meiner Sicht stellt sich beispielsweise die Frage, ob ein CSS-Framework für flexible Layouts überhaupt eine solche fixe Grenze vorschreiben sollte? Denn gerade flexible Layouts funktionieren erst richtig gut, wenn man die einzelnen Abstufungen des Layouts individuell auf dessen grafische Elemente abstimmt und sich nicht sklavisch einer fixen Zahl unterwirft, deren Ursprung vor vielen Jahren seine Relevanz verloren hat.

Alle diese Punkte spricht der Beitrag bei T3N aber leider nicht an. Stattdessen bleibt er oberflächlich und nichts-sagend, denn Statements wie “Toast ist nicht für jedes Projekt geeignet. Textlastige Websites können durch den Einsatz des Frameworks an Übersichtlichkeit und Bedienbarkeit gewinnen.” ist ohne Begründung nichts wert. Das eine oder andere wenig technische Detail oder gar eine kritische Anmerkung zur x-ten Kopie der Kopie des Grid-Ansatzes sind offensichtlich zuviel verlangt. Stattdessen werden einfach die Infotexte der Toast-Webseite abgetippt, übersetzt und nicht gerade subtil bebildert - fertig ist der neue Fachbeitrag und genauso schnell sind die Infomeldungen darüber bei Twitter, Facebook, Google+ untergebracht. Dieses Schema taugt auch für die nächsten 50 CSS-Frameworks, soviel ist klar.

Nun, wir haben im deutschsprachigen Raum leider nur eine sehr überschaubare Anzahl von Magazinen, die sich der Frontendentwicklung widmen. Deshalb ich finde es ehrlich gesagt jammerschade, dass die Jungs von T3N sich nicht mehr die Zeit nehmen, den Inhalt der Beiträge vor dem Schreiben genauer unter die Lupe zu nehmen. Hauptsache raus, die gierige Meute im Social-Network-Zirkus will bespaßt werden. Sorry T3N, ihr macht Euch uninteressant und entbehrlich.

]]> Date.toLocaleString() Bug in Chrome und Safari tag:highresolution.info,2011:weblog/11.1404 2011-07-18T09:45:32+00:00 2011-07-18T13:18:33+00:00 Datums- und Zeitangaben zu formatieren ist immer wieder eine eher lästige Angelegenheit im Programmieralltag. Speziell, wenn später Anwender von verschiedenen Orten dieser Welt darauf zugreifen und damit einfach umgehen sollen. Schon die feinen Unterschiede in der Datumsschreibweise zwischen dem deutsch- und dem englischsprachigen Raum stiften oft genug Verwirrung. Ein Beispiel: In allen drei Varianten ist der gleiche Tag gemeint &ndash; ohne die Landeszuordnung dahinter, ist eine eindeutige Zuordnung von Tag und Monat gar nicht so einfach. 6/15/2009 (en-US)15/06/2009 (fr-FR)2009/06/15 (ja-JP) Um diesem Problem zu begegnen, unterstützen alle halbwegs modernen Browser (und damit auch der IE) die Methode Date.toLocaleString(), welche Datum &amp; Zeit anhand der Browsereinstellungen im jeweils landestypischen Format ausgibt. Aus dem eher hässlichen Standard-GMT-String “Mon Jul 18 2011 11:56:29 GMT+0200” wird hierzulande “Montag, 18. Juli 2011 11:56:29”. Weniger schön ist, dass im Chromium-Projekt seit langer Zeit ein ungefixter Bug (Issue 29779, eingetragen im Dezember 2009) schlummert, der statt “Monday, 18 January 2010 4:47:42 PM” eine solche Ausgabe provoziert “Mon Jan 18 2010 16:47:42 GMT+1100 (AUS Eastern Daylight Time) “. Nicht nur, dass keine Umformung in ein lokales Datumsformat stattfindet, durch die zusätzliche ausformulierte Zeitzonen-Angabe wird der String sogar noch länger und damit schwerer zu handhaben. Und da sich sowohl Google Chrome als auch Safari bei diesem Projekt bedienen, erben die beide Browser eben jenese Problem. Ein Workaround &ndash; der eigentliche Aufhänger für diesen Blogpost &ndash;&nbsp; ist dabei gar nicht schwer. Denn das was Date.toLocaleString() ausgibt, ist lediglich eine Aneinanderreihung von lokalem Datum ( Date.toLocaleDateString() ) und lokalem Zeitformat ( Date.toLocaleTimeString() ) und für beides gibt es spezielle &ndash; und vor allem bugfreie &ndash; Methoden. Also einfach die beiden Einzelstrings miteinander verketten und fertig. var date = new Date(); var localeString = date.toLocaleDateString()+" "+date.toLocaleTimeString(); Ich hoffe, dem einen oder anderen hilft dieser kleine Tipp. &nbsp; 2011-07-18T09:45:32+00:00 Dirk Jesse http://www.highresolution.info JavaScript Datums- und Zeitangaben zu formatieren ist immer wieder eine eher lästige Angelegenheit im Programmieralltag. Speziell, wenn später Anwender von verschiedenen Orten dieser Welt darauf zugreifen und damit einfach umgehen sollen. Schon die feinen Unterschiede in der Datumsschreibweise zwischen dem deutsch- und dem englischsprachigen Raum stiften oft genug Verwirrung.

Ein Beispiel: In allen drei Varianten ist der gleiche Tag gemeint – ohne die Landeszuordnung dahinter, ist eine eindeutige Zuordnung von Tag und Monat gar nicht so einfach.

  • 6/15/2009 (en-US)
  • 15/06/2009 (fr-FR)
  • 2009/06/15 (ja-JP)

Um diesem Problem zu begegnen, unterstützen alle halbwegs modernen Browser (und damit auch der IE) die Methode Date.toLocaleString(), welche Datum & Zeit anhand der Browsereinstellungen im jeweils landestypischen Format ausgibt. Aus dem eher hässlichen Standard-GMT-String “Mon Jul 18 2011 11:56:29 GMT+0200” wird hierzulande “Montag, 18. Juli 2011 11:56:29”.

Weniger schön ist, dass im Chromium-Projekt seit langer Zeit ein ungefixter Bug (Issue 29779, eingetragen im Dezember 2009) schlummert, der statt “Monday, 18 January 2010 4:47:42 PM” eine solche Ausgabe provoziert “Mon Jan 18 2010 16:47:42 GMT+1100 (AUS Eastern Daylight Time) “. Nicht nur, dass keine Umformung in ein lokales Datumsformat stattfindet, durch die zusätzliche ausformulierte Zeitzonen-Angabe wird der String sogar noch länger und damit schwerer zu handhaben. Und da sich sowohl Google Chrome als auch Safari bei diesem Projekt bedienen, erben die beide Browser eben jenese Problem.

Ein Workaround – der eigentliche Aufhänger für diesen Blogpost –  ist dabei gar nicht schwer. Denn das was Date.toLocaleString() ausgibt, ist lediglich eine Aneinanderreihung von lokalem Datum ( Date.toLocaleDateString() ) und lokalem Zeitformat ( Date.toLocaleTimeString() ) und für beides gibt es spezielle – und vor allem bugfreie – Methoden. Also einfach die beiden Einzelstrings miteinander verketten und fertig.

var date = new Date();
var localeString = date.toLocaleDateString()+" "+date.toLocaleTimeString();

Ich hoffe, dem einen oder anderen hilft dieser kleine Tipp.

 

]]> Rapid Prototyping live im Browser - Testpiloten gesucht tag:highresolution.info,2011:weblog/11.1401 2011-04-26T07:00:39+00:00 2011-04-28T17:47:40+00:00 Ostern ist gerade vorbei, doch ich habe noch eine kleine Überraschung. Seit der Veröffentlichung des YAML Builders 1.0 im Februar 2008 war mir klar, dass dies die Richtung ist, in die ich mit meinen zukünftigen Projekten verfolgen wollte. Zum einen bin ich selbst ein eher visuell orientierter Mensch, zum anderen wollte ich schon damals nicht akzeptieren, dass die Community zwar täglich Webapplikationen wie Google Mail &amp; Docs sowie die Vorzüge von HTML5 hypt, der normale Webentwickler aber seine CSS-Layouts in der Regel auch heute noch im Texteditor schreibt und immer wieder den Browser anklickt, F5 drückt, um sein Getipptes alle paar Minuten auf Fehlerfreiheit zu überprüfen. Das kann nicht die Zukunft sein. Also habe ich angefangen, darüber nachzudenken, wie sich das Konzept hinter dem YAML-Builder sinnvoll aufbohren lässt. Nach zahlreichen Diskussionen, Tests und JavaScript-Lernerei habe ich angefangen. Dieser Beginn meines neuen Projektes &raquo;Thinkin’ Tags&laquo; liegt nun ca. 2 Jahre zurück und es ist Zeit, die ersten Ergebnisse der Programmierarbeit der letzten zwei Jahre vorzustellen. Das Projekt &raquo;Thinkin’ Tags&laquo; &raquo;Thinkin’ Tags&laquo; ist eine völlig neuartige, browserbasierte Entwicklungsumgebung für das schnelle Erstellen von Layout-/Webseiten-Prototypen mit bisher einzigartigen Features. &raquo;Thinkin’ Tags&laquo; 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 &amp; 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 &raquo;entwerfen&laquo;, 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 &raquo;Thinkin’ Tags&laquo; 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 &nbsp; 2011-04-26T07:00:39+00:00 Dirk Jesse http://www.highresolution.info Thinkin' Tags, Software, Webdesign Ostern ist gerade vorbei, doch ich habe noch eine kleine Überraschung. Seit der Veröffentlichung des YAML Builders 1.0 im Februar 2008 war mir klar, dass dies die Richtung ist, in die ich mit meinen zukünftigen Projekten verfolgen wollte. Zum einen bin ich selbst ein eher visuell orientierter Mensch, zum anderen wollte ich schon damals nicht akzeptieren, dass die Community zwar täglich Webapplikationen wie Google Mail & Docs sowie die Vorzüge von HTML5 hypt, der normale Webentwickler aber seine CSS-Layouts in der Regel auch heute noch im Texteditor schreibt und immer wieder den Browser anklickt, F5 drückt, um sein Getipptes alle paar Minuten auf Fehlerfreiheit zu überprüfen. Das kann nicht die Zukunft sein.

Also habe ich angefangen, darüber nachzudenken, wie sich das Konzept hinter dem YAML-Builder sinnvoll aufbohren lässt. Nach zahlreichen Diskussionen, Tests und JavaScript-Lernerei habe ich angefangen. Dieser Beginn meines neuen Projektes »Thinkin’ Tags« liegt nun ca. 2 Jahre zurück und es ist Zeit, die ersten Ergebnisse der Programmierarbeit der letzten zwei Jahre vorzustellen.

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

 

Video & Screenshots

Die nachfolgenden Screenshots aus dem aktuellen Entwicklungsstand des Projekts zeigen zentrale Funktionen der Applikation. Ein Klick auf die Bilder öffnet die Großdarstellung.




30 Testpiloten gesucht

Vor dem Start der Betaphase ist es mir wichtig, die bisher implementierte Funktionalität ausgiebig zu testen und deren Grenzen auszuloten. Ich suche daher max. 30 Testuser, die in den kommenden Wochen die Applikation ausgiebig testen und dabei Bugtracker, Feature-Wunschliste und das Nutzerforum mit möglichst ebenso ausführlichem Feedback befüllen.

Wer darf mitmachen?

Wer sich also um einen Testaccount bewerben möchte, sollte folgende Voraussetzungen mitbringen:

  • Umfassende Kenntnisse im Umgang mit YAML (Projekterfahrung sollte über 2-3 Referenzen nachgewiesen werden)
  • Gute Kenntnisse im Umgang mit dem aktuellen YAML Builder
  • Interesse/Begeisterung an visuellen Arbeitsmethoden zur Layouterstellung
  • Ausdauer und Erkundungswillen eines “unfertigen Produktes”, denn eine Dokumentation gibt es nicht - aber vieles zu entdecken
  • Verlässlichkeit in Bezug auf ehrliches, ausgiebiges Testen und die Bereitschaft, ebenso ausführlich Feedback über Schwächen und Stärken der Applikation weiterzugeben.
  • Eure Monitorauflösung sollte deutlich oberhalb von 1280 Pixeln Breite liegen
  • Die englische Sprache sollte für Euch kein Hindernis sein
  • Die Testtätigkeit an die Akzeptanz einer Vertaulichkeitserklärung gebunden

Bewerbung für den Testzugang

Bewerbungen sendet Ihr bitte per Email an office[at]highresolution.info mit dem Betreff “TT-Alpha”.  Die Testaccounts werden dann ab nächster Woche verteilt.

Da vermutlich nicht jeder, der sich auf diesen Aufruf meldet mit einem Testaccount versorgt werden kann: bitte nicht böse sein. Ihr werdet zu einem etwas späteren Zeitpunkt mit einem Beta-Account versorgt werden - versprochen.

]]> YAML 4.0 - Zwischenstand tag:highresolution.info,2011:weblog/11.1400 2011-03-02T15:00:34+00:00 2011-03-02T16:25:35+00:00 Die ersten Hinweise auf den Entwicklungszweig für YAML 4.0 habe ich ja bereits im Oktober letzten Jahres gegeben. In dem damaligen Beitrag habe ich allerdings noch nicht wirklich Informationen zur Version 4 gegeben sondern eher über die Dinge berichtet, die aus dem 4.0er Zweig in die Version 3.3 vorgezogen wurden. Heute hingegen werde ich ein bisschen aus dem Nähkästchen plaudern, wo die Reise bei YAML 4 hingehen wird. Und damit gehts auch gleich los ... Namespaces [Status: 85% fertig] Eines der häufigsten Quellen für Probleme bei der Frontendentwicklung in Verbindung mit Content Management Systemen, speziell bei größeren oder über Jahre gewachsenen Projekten, sind Kollisionen von ID- und Klassennamen. Beileibe nicht jedes CMS gestattet die vollständige Kontrolle über das ausgelieferte Markup. Wordpress weist beispielsweise dem &lt;body&gt; Element dynamisch eine Vielzahl von CSS-Klassennamen zu, was sich für Normalanwender auch kaum unterdrücken lässt. JavaScript Widgets wie Slider, Galerien etc. benötigen für den Zugriff auf ihr Markup sinnvolle IDs und Klassennamen &ndash; gleiches gilt für CSS Frameworks. Für den Entwickler ist es gleichermaßen wichtig, möglichst selbsterklärende und konsistente Bezeichnungenzu verwenden, um die langfristige Wartbarkeit des Codes zu sicherzustellen. Eingänglich klingende, kurze Bezeichnungen wie “wrapper”, “post”, “page” usw. haben daher großes Konfliktpotential. Auf YAML bezogen kollidiert beispielsweise die von YAML verwendete CSS-Klasse .page mit der Verwendung, die Wordpress für die CSS-Klasse “page” vorsieht, die es dem &lt;body&gt; Element standardmäßig zuweist. Die Lösung hierfür heisst: Namespaces. In YAML 4 werden daher die CSS-Klassen und IDs der Kernbestandteile des Frameworks mit einem Präfix versehen werden. Ein einheitlicher Namespace hat zudem den Vorteil, dass er (wir reden schließlich bei HTML/CSS von einfachen ASCII-Dateien) bei Bedarf leicht angepasst werden kann. 2011-03-02T15:00:34+00:00 Dirk Jesse http://www.highresolution.info Die ersten Hinweise auf den Entwicklungszweig für YAML 4.0 habe ich ja bereits im Oktober letzten Jahres gegeben. In dem damaligen Beitrag habe ich allerdings noch nicht wirklich Informationen zur Version 4 gegeben sondern eher über die Dinge berichtet, die aus dem 4.0er Zweig in die Version 3.3 vorgezogen wurden. Heute hingegen werde ich ein bisschen aus dem Nähkästchen plaudern, wo die Reise bei YAML 4 hingehen wird. Und damit gehts auch gleich los ...

Namespaces

[Status: 85% fertig] Eines der häufigsten Quellen für Probleme bei der Frontendentwicklung in Verbindung mit Content Management Systemen, speziell bei größeren oder über Jahre gewachsenen Projekten, sind Kollisionen von ID- und Klassennamen. Beileibe nicht jedes CMS gestattet die vollständige Kontrolle über das ausgelieferte Markup. Wordpress weist beispielsweise dem <body> Element dynamisch eine Vielzahl von CSS-Klassennamen zu, was sich für Normalanwender auch kaum unterdrücken lässt. JavaScript Widgets wie Slider, Galerien etc. benötigen für den Zugriff auf ihr Markup sinnvolle IDs und Klassennamen – gleiches gilt für CSS Frameworks.

Für den Entwickler ist es gleichermaßen wichtig, möglichst selbsterklärende und konsistente Bezeichnungenzu verwenden, um die langfristige Wartbarkeit des Codes zu sicherzustellen. Eingänglich klingende, kurze Bezeichnungen wie “wrapper”, “post”, “page” usw. haben daher großes Konfliktpotential. Auf YAML bezogen kollidiert beispielsweise die von YAML verwendete CSS-Klasse .page mit der Verwendung, die Wordpress für die CSS-Klasse “page” vorsieht, die es dem <body> Element standardmäßig zuweist. Die Lösung hierfür heisst: Namespaces.

In YAML 4 werden daher die CSS-Klassen und IDs der Kernbestandteile des Frameworks mit einem Präfix versehen werden. Ein einheitlicher Namespace hat zudem den Vorteil, dass er (wir reden schließlich bei HTML/CSS von einfachen ASCII-Dateien) bei Bedarf leicht angepasst werden kann.

Grids sind Grids sind Grids

[Status: 100% fertig] Es ist immer eine gute Idee, Dinge bei ihren richtigen Namen zu nennen. Umschreibungen führen nur zu Missverständnissen. Nun, vor mehr als 4 Jahren erhielt YAML seine “Subtemplates”. Damals war YAML nicht viel mehr als eine universelle Vorlage für flexible 2- und 3-Spalten-Layouts und die “Subtemplates” kamen dem vielfach an mich herangetragenen Wunsch nach, auch innerhalb der Spalten eine einfache Möglichkeit zur horizontalen Gliederung von Inhaltsblöcken zu haben.

2006 war das Thema Grids noch ein volles Jahr von seinem internationalen Hype entfernt und so gab es mit der damals gewählten Bezeichnung keine Schwierigkeiten. Doch mit den immer populärer werdenen Grid-Layouts wurde auch klar, dass der Name “Subtemplates” alles andere als glücklich gewählt war, denn – und dass lässt sich in zahllosen internationalen Blogbeiträgen nachlesen – die Grid-Komponente wird nur selten auf den ersten Blick wahrgenommen, obwohl die Subtemplates bis heute eine der robustesten, mir bekannten Implementationen für flexible Grids sind. Aus diesem Grund wird es in YAML 4 eine Umbenennung der Klassennamen geben, um zukünfig Missverständnisse zu vermeiden: Aus der Bezeichnung “subtemplates” wird deshalb “grids”.

Auch in technischer Hinsicht wird das Grid-Modul von YAML 4 weiterentwickelt. Zwar war es schon bisher ausgesprochen robust und bot über die simple Zusatzklasse .equalize sogar die Erstellung gleichhoher Container auf Basis einer reinen CSS-Implementation an. Doch auf der anderen Seite war die Änderung/Erweiterung der im Framework-Kern mitgelieferten Raumaufteilungen für Frameworkanwender nicht gerade eingängig und einfach. Mit dem Grid-Modul von YAML 4 wird dieses Problem verschwinden. Indiviudelle Grids können dann mit einem CSS-Einzeiler erstellt werden, ohne dass die oben beschriebene Funktionalität eingeschränkt wird. Ein “Nachbau” eines pixelgenauen Gridlayouts mit YAML wird dann mit wenigen zusätzlichen Zeilen CSS zum Kinderspiel. Die aus meiner Sicht seit je her unsinnige Fragmentierung Grid-basierter Frameworkprojekte anhand der Basisbreite des Grids (950 Pixel, 960 Pixel, 978 Pixel, 1140 Pixel) ist damit für YAML-Anwender endgültig vom Tisch. Flexible, wie pixelgenaue Grids jedes beliebigen Rasters lassen sich mit weitgehend identischem Markup sehr einfach umsetzen.

Formulare, überall Formulare ...

[Status: 75% fertig] Die überwiegende Mehrzahl von Webseiten würde ohne Formulare gar nicht funktionieren. Wer kommt heute noch ohne mindestens ein Such- und Kontaktformular aus? Wenn Formulare aber so essentiell sind, warum sind sie dann noch kein Bestandteil des YAML-Cores? Gute Frage!

In YAML 4 werden die layoutunabhängigen Bestandteile des Formularbaukastens fest in den YAML-Core integriert. Mit dieser Umstellung geht auch eine leichtere Handhabung dieses Bausteins her, denn die Gestaltung der Formulare ist nun mehr oder weniger ein echtes Theming - die Austauschbarkeit bzw. Wiederverwendbarkeit individuell gestalteter Formulare wird damit deutlich einfacher.

API-Doku statt Lehrbuch

[Status: 5% fertig] Die Dokumentation ist seit vielen Jahren eine meiner größten Baustellen. Sie ist über die Jahre kontinuierlich gewachsen und hat mit > 130 PDF-Seiten eine Größe erreicht, die eher einem stetig aktualisiertem Online-Buch ähnelt als einer Dokumentation des Frameworks. Diese ausführliche Art der Projektbeschreibung ist für Neulinge zum einen sehr hilfreich, weil die Funktionsweise der einzelnen Bausteine bis ins Detail beschrieben ist, zu einem Großteil auch die Fallstricke der Problembrowser. Zum anderen ist es für jeden Neueinsteiger aber auch extrem mühsam, diese Informationsmengen zu durchforsten, wenn man sich mit dem System vertraut machen will. Zum dritten erzeugt der hohe Detailgrad (man denke auch an die Zweisprachigkeit und die parallele Verfügbarkeit online und als herunterladbares PDF) einen enormen Pflegeaufwand. Dieser ist mit den letzten Versionen immer mehr auf ein unverhältnismäßig hohes Maß angestiegen und ich muss hier gegensteuern.

Ich plane daher, die aktuelle Doku abzulösen durch eine Art Cheatsheet oder eine Kurzdoku, die nurmehr die Eigenschaften und Anwendung der einzelnen Bausteine des Frameworks beschreibt (also eine Art API-Dokumentation), jedoch nicht mehr das warum für jede einzelne CSS-Eigenschaft dokumentiert. Die bisherige Dokumentation wird als Entwicklerdokumentation in wahrscheinllich leicht verkürzter Form erhalten bleiben, jedoch nicht mehr mit jedem Pointrelease aktualisiert werden.

Projektstruktur

[Status: 25% fertig] Eines der größten Hürden für Neueinsteiger war und ist die aktuelle Struktur des YAML-Downloadpakets. An sich ist das keine neue Information, den derartige Diskussionen gab es schon früher – damals mit der Konsequenz, dass ich das “Simple Project” eingeführt habe, welches auch die Basis für die Arbeit mit dem YAML Builder liefert und seither für den Einstieg empfehle. Leider hat das bisher nicht so funktioniert wie gedacht. Deshalb wird es auch hier eine Umstellung geben.

Das Downloadpaket wird zukünftig mehr oder weniger dem entsprechen, was heute das Simple Project darstellt. Mit diesem Paket kann sofort gearbeitet werden, Pfadanpassungen sind nicht erforderlich. Die zahlreichen Layoutbeispiele sollen zukünftig in einem gesonderten Zip-Paket zum Download bereitgestellt werden. Diese Trennung ist schon deshalb sinnvoll, da in der Vergangenheit kleine Fehlerkorrekturen in den Layoutbeispielen ein neues Downloadpaket des Frameworks erzwungen haben.

Die Ordner- und Dateistruktur innerhalb des YAML-Ordners bleiben hingegen unangetastet, denn sie haben sich bewährt.

Darüber hinaus möchte ich auch die Beispiele etwas entschlacken. Dabei steht nicht im Vordergrund, zwingend deren Anzahl zu reduzieren aber doch das eine oder ander sinnvoll zusammenzufassen. Dafür sollen einige neue komplexere Beispiele hinzukommen, die u.a. den Umgang mit Media Queries zur Anpassung an verschiedenste Ausgabemedien zeigen. Auch hier ist YAML mit seinem flexiblen Ansatz extrem wandlungs- und anpssungsfähig.

Und wann geht’s los?

Anhand der Statuswerte lässt sich ja zum Teil abschätzen, wie weit die Arbeiten in den einzelnen Bereichen fortgeschritten sind. Was sich indess jetzt schon sagen lässt ist, dass mir momentan vorschwebt, der Version 4.0 eine öffentliche Betaphase zu gönnen und diese ist nicht mehr allzu weit entfernt.

Gute, ausgereifte Frameworks leben von ihren klaren Strukturen. Nur große Versionssprünge wie der von v3.x auf v4.0 erlauben es, größere Änderungen/Weiterentwicklungen in einem solchen Projekt vorzunehmen und aufgrund der wunderbar großen Nutzerbasis möchte ich an dieser Stelle mit einer öffentlichen Betaphase die Tür ausdrücklich offen stehen lassen für weitere Vorschläge aus der Community, die durchaus noch in die Version 4.0 einfließen können.

In diesem Sinne, 2011 wird spannend ...

]]> JavaScript und die Pointer tag:highresolution.info,2011:weblog/11.1399 2011-01-28T10:47:25+00:00 2011-01-28T13:33:26+00:00 Ich bin ganz sicher nicht der klassische Programmierertyp und so lerne ich Programmiersprachen &ndash; im konkreten Fall JavaScript &ndash;, in dem ich mich herausfordernden Projekten stelle, um dabei Neues zu lernen. Leider ist dieses “Neue” nicht immer ganz logisch und führt schonmal dazu, dass sich Stirn und Tischplatte unaufhaltsam anzuziehen scheinen. So auch das Thema Pointer in JavaScript, welches mir gestern Abend aufgestoßen ist. Wenn man ein wenig Erfahrung aus anderen Programmiersprachen wie C mitbringt, dann ist einem der Unterschied zwischen einem Objekt und dem Pointer auf ein Objekt bekannt. Das entscheidende dabei: Bei C kann man sehr einfach festlegen, ob man einer Variable eine Objektkopie zuweist oder nur einen Pointer auf das Originalobjekt erzeugt. Bei JavaScript sieht das etwas anders aus. Obgleich in JavaScript so ziemlich alles als Objekt betrachtet werden kann, so gibt es doch feine aber entscheidene Unterschiede, wie diese intern behandelt werden. Folgender Code machte mich stutzig: var layoutCSS = { 'width': 'auto', 'min-width': '720px', 'max-width': '80em' }; var minSettings = layoutCSS; minSettings['max-width'] = 'none'; console.log(minSettings); //"none" console.log(layoutCSS); //"none" Wie man sieht, wird in diesem Beispiel nicht etwa eine Kopie des Objekts layoutCSS in minSettings angelegt, sondern lediglich ein Pointer auf das Originalobjekt. In der Konsequenz ändert sich der Inhalt des OriginalObjekts layoutCSS bei Zuweisungen an minWidth. Gut zu wissen, denn in JavaScript ist dieses Verhalten auf Arrays und Objekte begrenzt. Strings hingegen werden kopiert, obwohl sie intern ebenfalls wie Objekte behandelt werden. Aufklärung darüber, wie JavaScript mit Pointern umgeht, liefert der Artikel Understanding Pointers in JavaScript. Soweit so nervig gewöhnungsbedürftig. Wie aber kommt man jetzt zu seiner Kopie bzw. Clone eines Arrays oder eines Objekts? Leider ist es auch hier so &ndash; ähnlich wie beim Versuch, ein assoziatives Array zu sortieren &ndash; dass JavaScript den Programmierer bei dieser Frage weitgehend im Stich läst. Handarbeit ist demnach angesagt. Einen ersten Lösungsansatz liefert der Artikel von Brian Huisman "How to copy arrays and objects in Javascript", der eine .clone() Methode einführt: Object.prototype.clone = function() { var newObj = (this instanceof Array) ? [] : {}; for (item in this) { if (item == 'clone') continue; if (this[item] && typeof this[item] == "object") { newObj[item] = this[item].clone(); } else newObj[item] = this[item] } return newObj; }; Speziell für jQuery-Nutzer gibts von John Resig höchstpersönlich noch einen kürzeren Vorschlag über die jQuery.extend(): // Shallow copy var newObject = jQuery.extend({}, oldObject); // Deep copy var newObject = jQuery.extend(true, {}, oldObject); Zwar finde ich persönlich diese Inkonsistenz bei JavaScript etwas nervig, dass man selbst nicht über Kopie oder Pointer wählen kann, aber was soll's. Wenigstens gibt es halbwegs einfache Lösungswege aus diesem Dilemma. An dieser Stelle ein ganz dickes Dankeschön an das kalifornische JavaScript-Lexikon Dirk Ginader, der mir mit diesen Links den Abend gerettet hat. 2011-01-28T10:47:25+00:00 Dirk Jesse http://www.highresolution.info JavaScript Ich bin ganz sicher nicht der klassische Programmierertyp und so lerne ich Programmiersprachen – im konkreten Fall JavaScript –, in dem ich mich herausfordernden Projekten stelle, um dabei Neues zu lernen. Leider ist dieses “Neue” nicht immer ganz logisch und führt schonmal dazu, dass sich Stirn und Tischplatte unaufhaltsam anzuziehen scheinen. So auch das Thema Pointer in JavaScript, welches mir gestern Abend aufgestoßen ist.

Wenn man ein wenig Erfahrung aus anderen Programmiersprachen wie C mitbringt, dann ist einem der Unterschied zwischen einem Objekt und dem Pointer auf ein Objekt bekannt. Das entscheidende dabei: Bei C kann man sehr einfach festlegen, ob man einer Variable eine Objektkopie zuweist oder nur einen Pointer auf das Originalobjekt erzeugt. Bei JavaScript sieht das etwas anders aus.

Obgleich in JavaScript so ziemlich alles als Objekt betrachtet werden kann, so gibt es doch feine aber entscheidene Unterschiede, wie diese intern behandelt werden. Folgender Code machte mich stutzig:

var layoutCSS = {
    'width': 'auto',
    'min-width': '720px',
    'max-width': '80em'
};
var minSettings = layoutCSS;
minSettings['max-width'] = 'none';
console.log(minSettings); //"none"
console.log(layoutCSS); //"none"

Wie man sieht, wird in diesem Beispiel nicht etwa eine Kopie des Objekts layoutCSS in minSettings angelegt, sondern lediglich ein Pointer auf das Originalobjekt. In der Konsequenz ändert sich der Inhalt des OriginalObjekts layoutCSS bei Zuweisungen an minWidth. Gut zu wissen, denn in JavaScript ist dieses Verhalten auf Arrays und Objekte begrenzt. Strings hingegen werden kopiert, obwohl sie intern ebenfalls wie Objekte behandelt werden. Aufklärung darüber, wie JavaScript mit Pointern umgeht, liefert der Artikel Understanding Pointers in JavaScript.

Soweit so nervig gewöhnungsbedürftig. Wie aber kommt man jetzt zu seiner Kopie bzw. Clone eines Arrays oder eines Objekts? Leider ist es auch hier so – ähnlich wie beim Versuch, ein assoziatives Array zu sortieren – dass JavaScript den Programmierer bei dieser Frage weitgehend im Stich läst. Handarbeit ist demnach angesagt. Einen ersten Lösungsansatz liefert der Artikel von Brian Huisman "How to copy arrays and objects in Javascript", der eine .clone() Methode einführt:

Object.prototype.clone = function() {
  var newObj = (this instanceof Array) ? [] : {};
  for (item in this) {
    if (item == 'clone') continue;
    if (this[item] && typeof this[item] == "object") {
      newObj[item] = this[item].clone();
    } else newObj[item] = this[item]
  } return newObj;
};

Speziell für jQuery-Nutzer gibts von John Resig höchstpersönlich noch einen kürzeren Vorschlag über die jQuery.extend():

// Shallow copy
var newObject = jQuery.extend({}, oldObject);

// Deep copy
var newObject = jQuery.extend(true, {}, oldObject);

Zwar finde ich persönlich diese Inkonsistenz bei JavaScript etwas nervig, dass man selbst nicht über Kopie oder Pointer wählen kann, aber was soll's. Wenigstens gibt es halbwegs einfache Lösungswege aus diesem Dilemma. An dieser Stelle ein ganz dickes Dankeschön an das kalifornische JavaScript-Lexikon Dirk Ginader, der mir mit diesen Links den Abend gerettet hat.

]]> Die Adventskalender kommen tag:highresolution.info,2010:weblog/11.1398 2010-12-01T09:43:42+00:00 2010-12-02T12:10:43+00:00 Seit einiger Zeit ist es in Bloggerland Tradition, den liebgewonnenen, schokoladengetriebenen Türchen-Wahn der Vorweihnachtszeit in leicht abgewandelter Form (Pralinen zu Blogbeiträgen) auch im Internetz aufleben zu lassen. Und so finden sich jedes Jahr an verschiedenen Stellen Autoren zusammen, um ihren Lesern mit 24 Blogposts den einen oder anderen Tipp für die tägliche Arbeit mit auf den Weg zu geben. Und da es jedes Jahr mehr werden, hier eine kleine - sicherlich unvollständige - Liste: Webkrauts Adventdskalender 2010Der Adventskalender der Webkrauts erscheint bereits seit 2005 und widmet sich in jedem Jahr einem übergeordneten Thema. In diesem Jahr sind dies die “Kunden”24ways 2010Was 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 WebdesignWPEngeneers - Advent CalendarMeines Wissen zum zweiten Mal starten die Programmierprofis ihren Adventskalender rund um das Thema “Wordpress”Maddesigns CSS3-AdventskalenderSven Wolfersmann ist ein ganz harter Bursche und zieht dieses Jahr einen Adventskalender zum Thema CSS3 fast alleine durch. Ich bin gespannt ...HTML5-Demos-AdventskalenderWie es der Name schon sagt ... it’s all about HTML5 Na denn, für Lesestoff ist gesorgt ... 2010-12-01T09:43:42+00:00 Dirk Jesse http://www.highresolution.info Tutorials, Webdesign Seit einiger Zeit ist es in Bloggerland Tradition, den liebgewonnenen, schokoladengetriebenen Türchen-Wahn der Vorweihnachtszeit in leicht abgewandelter Form (Pralinen zu Blogbeiträgen) auch im Internetz aufleben zu lassen. Und so finden sich jedes Jahr an verschiedenen Stellen Autoren zusammen, um ihren Lesern mit 24 Blogposts den einen oder anderen Tipp für die tägliche Arbeit mit auf den Weg zu geben. Und da es jedes Jahr mehr werden, hier eine kleine - sicherlich unvollständige - Liste:

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

]]>