Freitag21. Oktober 2011

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.

Den gesamten Beitrag lesen


Mittwoch05. Oktober 2011

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.


Montag18. Juli 2011

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.

 


Dienstag26. April 2011

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

 

Den gesamten Beitrag lesen


Mittwoch02. März 2011

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.

Den gesamten Beitrag lesen


Seite 6 von 44 Seiten

« Erste  <  4 5 6 7 8 >  Letzte »