Webdesign
Mittwoch16. November 2011

Der Beitrag “6 Things I Learned About Print Stylesheets From HTML5 Boilerplate” hat mich daran erinnert, dass ich schon lange mal ein paar Worte über das HTML5 Boilerplate verlieren wollte. Ich halte dieses Projekt abseits des HTML5 Hypes für eine geniale Sache, insbesondere wegen seines umfangreichen und ausgeklügelten Build-Skripts und der mitgelieferten Apache-Konfiguration per .htaccess. Bei den CSS-Definitionen finde ich die Einbindung des Normalize.css Projekts sehr viel sinnvoller (wenn auch recht umfangreich) als die vielseits beliebten Reset-Stylesheets von Eric Meyer oder YUI.

Die Vorgaben des Print-CSS kann ich allerdings weniger empfehlen (ist aber auch weniger dramatisch). Speziell geht es mir um die “Print Friendly Links”, wie es der oben zitierte Beitrag nennt. Hier der betreffende Auszug aus dem HTML5 Boilerplate.

a[href]:after { content: " (" attr(href) ")"; }
abbr[title]:after { content: " (" attr(title) ")"; }
.ir a:after, a[href^="javascript:"]:after,
a[href^="#"]:after { content: ""; } /* Don't show links for images, or javascript/internal links */

Ich habe Vergleichbares (Automatische Auszeichnung von URLs, Akronymen und Abkürzungen) seit vielen Jahren in den YAML Druckstylesheets integriert, allerdings bin ich recht schnell wieder einen Schritt zurück gegangen, indem ich diese Regeln nur noch auskommentiert mitliefere und das aus gutem Grund.

Es ist auf den ersten Blick sicher nachvollziehbar, dass verlinkte URLs beim Druck verloren gehen und man als zuvorkommender Webentwickler diese deshalb hinter dem Linktext mit ausdrucken will, damit für den Anwender der Quellenverweis erhalten bleibt. Doch mal ehrlich: Wie oft hat jeder von Euch im letzten Jahr eine auf Papier abgedruckte URL in den Browser eingetippt? Und wie oft war diese dann länger als 10 Zeichen? Ist die pauschale Ausgabe von URLs also wirklich sinnvoll?

Aus dem anvisierten Komfort für den User wird in der Praxis schnell ein Nerv-Feature – und meist auch der Regelfall. Im Gegensatz zum Print arbeiten wir im Netz nicht mit Quellenverzeichnissen am Ende des Textes, sondern verlinken Schlagworte oder ganze Sätze direkt und im Idealfall auch recht umfangreich. Allerdings steht im Netz die Querverlinkung dem Lesefluss und -genuss auch nicht im Wege. Ausgedruckt ist ein solches Dokument allerdings nur noch bedingt gut lesbar, wenn der Fließtext regelmäßig durch lange, kryptische, nicht umbrechbare URLs unterbrochen wird. Ganz zu schweigen davon, dass sich die Mehrzahl der Anwender eben nicht diebisch darüber freut, eine neue URL zum Abtippen gefunden zu haben.

Gleiches gilt für die Anzeige der title-Attribute von Abkürzungen. Gute Schreibe gebietet, dass Abkürzungen bei ihrem ersten Auftauchen im Text eingeführt/erläutert werden. Aber eben nur beim ersten Mal (vielleicht noch beim zweiten, dann ist aber gut). Das Einpflegen von Akronymen und Abkürzungen erledigt im HTML aber fast niemand von Hand - weil es recht lästig und umständlich ist. Dafür gibt es bei vielen Content Management Systeme entsprechende Plugins, die diese Aufgabe automatisch anhand von Wortlisten übernehmen. Auch daran gibt auf den ersten Blick nichts auszusetzen, denn schließlich wird das title-Attribut nur angezeigt, wenn der Anwender das Element mit der Maus ansteuert und darüber verweilt. Aber schon Nutzer von Screenreadern dürften derartige Automatismen stören, wenn z.B. in einem Webdesign-Fachtext hinter jedem jedem HTML (Hypertext Markup Language) steht/vorgelesen wird. Und Lesern eines ausgedruckten Dokuments geht es da nicht anders.

Die sichtbare Auszeichnung von URLs und Abkürzungen ist per Definition weder unnütz noch schädlich. Allerdings ist sie eben nur dann sinnvoll, wenn die Inhalte entsprechend sorgfältig dahingehend aufbereitet sind, in dem beispielsweise nur die URL von besonders gekennzeichneten Links ausgegeben wird. Genauso wie der Ausdruck der title-Attribute von Abkürzungen nur dann für den User sinnvoll ist, wenn die Texte auch entsprechend sorgfältig aufbereitet werden. Andernfalls kann beides schnell zum billigen Werbefeature des Entwicklers werden, welches u.U. deutlich an den Interessen des Lesers (Internetausdruckers) vorbei geht.

Und so versteckt sich auch im HTML5 Boilerplate die eine oder andere Regel, deren Nutzen mehr Schein als Sein ist, wenn man sie gedankenlos übernimmt.


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


Mittwoch01. Dezember 2010

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


Donnerstag14. Oktober 2010

In den Abenstunden des gestrigen Tages war es endlich soweit, YAML 3.3 – das lange angekündigte und erwartete Update meines (X)HTML/CSS Frameworks ging endlich online.

Wohin geht die Reise?

Wie sich unter aufmerksamen Lesern und Barcamp-Besuchern bereits herumgesprochen haben sollte, arbeite ich seit längerer Zeit an einem Nachfolger des YAML-Builders. Mit der Veröffentlichung dieses neuen Projektes wird gleichzeitig (bzw. kurz davor) YAML 4.0 das Licht der Welt erblicken. Diese Version 4.0 ist die Basis für die Arbeit an meinem JavaScript-Projekt und daher ebenfalls schon seit längerem in der Entwicklung und reift langsam heran, allergings wird bis zur geplanten öffentlichen Betaphase noch einige Zeit ins Land gehen.

Damit einher gehen aber einige größere Veränderungen des Frameworks, die eine Abwärtskompatibilität zu dem 3er-Releasestrang unmöglich machen. Aus meiner Erfahrung dürfte das den wenigsten Nutzern weh tun, da die Mehrzahl der Entwickler einen Versionswechsel nur in Verbindung mit neuen Projekten vornimmt. Dennoch habe ich mich entschlossen, einige der für YAML 4.0 geplanten Verbesserungen in der Version 3.3 vorzuziehen, um auch den 3er-Strang zukunftsfähig und für die nächsten 2 Jahre praxistauglich zu halten.

Den gesamten Beitrag lesen


Dienstag27. Juli 2010

Dieser Beitrag zu Validität und ihrer Bedeutung in der aktuellen Webentwicklung liegt mir schon seit Monaten auf der Zunge. Bisher gab es immer genug Ablenkungen, ihn nicht zu schreiben. Heute ist das anders, denn heute hat mich eine Anfrage im YAML-Forum dazu gebracht, dieses Thema endlich mal wieder auf den Tisch zu bringen.

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

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

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

Hallo Zusammen!

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

Dazu wurde folgender Codeschnipsel mitgeliefert:

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

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

Den gesamten Beitrag lesen


Seite 3 von 13 Seiten

 <  1 2 3 4 5 >  Letzte »