CSS & XHTML
Mittwoch12. Juni 2013

Das Warten ist endlich vorbei. Heute am frühen Morgen (7:50 Uhr Ortszeit) hat die Version 4.1 von YAML das Licht der Welt erblickt. Für mich endet damit mehr als nur eine 6 monatige Entwicklungszeit, doch dazu mehr am Schluss dieses Beitrags. Zunächst möchte ich die neue Version vorstellen und ein wenig über die Hintergründe erzählen.

Github

Die Projektdateien von YAML liegen ab sofort auf Github. Über viele Jahre habe ich YAML in einem privaten SVN Repository gepflegt und bin damit als Einzelentwickler auch sehr gut gefahren. Doch auch wenn SVN ein, zwei wirklich liebenswerte Features hat, ist Git ein großes Stück anwenderfreundlicher, weshalb ich bei anderen Projekten schon seit Jahren mit Git arbeite. Der Umstieg bei YAML war dennoch nicht ganz einfach, weil ich lange mit mir gerungen habe, in wie weit die Versionsgeschichte aus dem SVN Repro in das Git-Projekt herüber gerettet werden sollte – schließlich geht es um mehrere Jahre nachvollziehbarer Entwicklungsarbeit. Letztlich führte eine Entscheidung an anderer Stelle dazu, dass diese Gedanken hinfällig waren und ich mit einem mehr oder minder frischen Repro gestartet bin, und zwar die, YAML 4.1 auf dem im Herbst letzten Jahres veröffentlichten Sass-Port von YAML 4.0.2 aufzubauen.

Den gesamten Beitrag lesen


Dienstag28. August 2012

Im Dezember letzten Jahres habe ich bereits über meine Erfahrungen mit Sublime Text 2 geschrieben und das eine oder andere Plugin empfohlen, welches die Arbeit mit HTML/CSS und JavaScript erleichtert. Damals habe ich mich gefreut, dass ich erstmals in einem Editor unter Windows ohne größere Verrenkungen einen Linter ans Laufen gebracht habe, um meine JavaScript-Files auf problematischen Code hin überprüfen zu können. Mittlerweile ist Sublime Text 2 in der finalen Fassung 2.0.1. erhältlich und auch beim Linting ist alles mittlerweile noch viel bequemer geworden.

Das Plugin der Stunde heisst “SublimeLinter” und liefert ein Live-Linting für JavaScript, CSS und noch zahlreiche andere Sprachen und Formate (Ruby, Java, Perl). Installiert wird es sinnvollerweise über den überaus bequemen Plugin-Manager PackageControl, der alle installierten Plugins selbstständig auf dem jeweils aktuellen Stand hält (bequemer geht’s nicht mehr).

Für Mac-Nutzer war’s das bereits, Windows Nutzer müssen sich zusätzlich Node.js installieren, um in den Genuss des Live-Lintings zu kommen. Hintergrund dafür ist, dass OS X standardmäßig eine JavaScript-Engine mit an Bord hat (genannt: JavaScriptCore), während man unter diese mit Node.js nachrüsten muss. Mittlerweile ist aber auch Node unter Windows mit bequemen 2..3 Klicks einrichtet - also keine echte Hürde mehr. Dann noch ein Neustart des Editors und es kann losgehen.

Sobald man eine JavaScript-Datei geöffnet hat, arbeitet der Linter im Hintergrund. Entdeckt er einen Fehler, so wird die entsprechende Code-Zeile mit einem weißen Rahmen umrandet, wie im Screenshot zu erkennen ist. Die einzelnen Fehler lassen sich per Tastaturkürzel (Nächster Fehler: Strg+Alt+E, vorheriger Fehler: Strg+Alt+Shift+E ) ansteuern. Ist der Cursor auf der markierten Zeile, so findet man in der Statusleiste des Editors (die befindet sich üblicherweise am unteren Rand) eine Erklärung, was der Linter auszusetzen hat und in der Codezeile ist die betreffende Stelle zusätzlich mit einem weißen Unterstrich markiert. Das Überprüfen von bestehendem Code, wie auch das Schreiben von sauberem JavaScript wird damit wirklich sehr erleichtert.

Die Konfiguration des Linters ist ebenfalls - dank Sublime Text - sehr übersichtlich gelöst. Über Preferences->Package-Settings-SublimeLinter öffnet man zunächst die Datei “Settings - Default”, kopiert sich deren Inhalt und fügt sie in die - über das gleiche Menü erreichbare - “Settings - User” ein. Anschließend kann der Linter nach Herzenslust konfiguriert werden - zumal alle Optionen dokumentiert sind.


Dienstag22. Mai 2012

Die Bewertung von fremdem Programmcode hinsichtlich Qualität, Flexibilität und Robustheit der gebotenen Features ist immer wieder knifflig, schließlich braucht es gute Kenntnisse, um sich in die fremden Quelltexte hineinzudenken und ggf. Schwachstellen zu erkennen. Das gilt für PHP oder JavaScript genauso wie für CSS (auch wenn hier nicht wirklich programmiert wird).

Ich schreibe dies auf, weil ich durch meine Arbeit an YAML und die eigene Analyse von weit über 50 CSS-Frameworks einen gewissen Blick für die Details gewonnen habe und ich mich schon mehrfach über die oberflächliche Vorstellung von CSS-Frameworks oder Vergleiche verschiedener Projekte in der Fachpresse geärgert habe. Zu oft werden ganze Scharen von CSS-Frameworks (und Dinge, die gar keine CSS-Frameworks sind) nur mit herauskopierten Textschnipseln aus deren Projekthomepages vorgestellt und viel zu selten erfolgen Empfehlungen und Bewertungen der Projekte auf der Grundlage eines wenigstens grundlegenden Code-Reviews.

Deshalb will ich heute ein paar Hinweise geben, die ich zur Evaluierung von CSS-Frameworks nutze. Ich stelle einige Kritieren vor, nach denen ich mir einen ersten Eindruck über neue Projekte verschaffe und eine Bewertung vornehme. Ich nenne in diesem Beitrag bewusst keine Beispiele, denn ich will nicht mit dem Finger auf andere Projekte zeigen, sondern aus meiner Erfahrung heraus Hilfestellung bei zur Evaluation von CSS-Frameworks geben.

Update 25.5.2012: Ich habe soeben den Kriterienkatalog gerade noch um zwei wichtige Punkte (Barrierefreiheit und “Wider den Hype”) erweitert.

Den gesamten Beitrag lesen


Donnerstag05. April 2012

Ein wenig überrascht war ich ja schon, ob der zahlreichen Reaktionen auf meinen Blogbeitrag “Von fliegenden Kühen und anderen Merkwürdigkeiten” und deshalb möchte ich mit diesem Folgebeitrag ein paar Dinge ergänzen, die mir aktuell in der aktuellen Weiterentwicklung von CSS fehlen, also die “missing parts” von CSS.

Nochmal zu Floats

Das Konzept, ein Layout zu beschreiben, indem man einzelnen Elementen eine Breite x zuweist und lediglich deren Ausrichtung links- oder rechtsbündig innerhalb des Elternelements bestimmt, ist keine Erfindung von CSS. Sowas gibt es schon sehr viel länger. Ich kenne ein solches System beispielsweise von der Erstellung von Benutzeroberflächen für den Amiga. Bei Software für dessen dessen Desktop-Oberfläche (Workbench) war schon in den 80er Jahren schlau, sich auf sehr unterschiedliche Bildschirmauflösungen und skalierbare Fonts einzustellen. Aus diesem Grund waren Floats für mich auch nie ein Mittel, welches allein zur Contentgestaltung herangezogen werden sollte. Wenn dem so wäre, hätte man im CSS Standard die Eigenschaft float auch einfach nur für das Image-Element definieren können. Dem ist aber nicht so.

Ich setze Floats seither sehr gern ein, weil ich sie mittlerweile in allen Browsern sehr robust geworden sind auch für die älteren Browsergenerationen gut dokumentierte, stabile Workarounds für die wichtigsten Bugs existieren. Nicht umsonst arbeiten die Layoutmodule von YAML mit Floats.

Dennoch wünsche ich mir eine Verbesserung der aktuellen Situation, denn auch wenn ich bisher fast jedes an mich herangetragene CSS-Problem lösen konnte, ist dies in – aus meiner Sicht zuvielen praxisrelevanten Standardaufgaben – nur mühsam zu erreichen. Als Beispiele wären da ...

Containing Floats

Wir benötigen eine Eigenschaft, die es ermöglicht, floatende Elemente durch den Elterncontainer sauber umschließen zu lassen. Aktuell nutzen wir dazu CSS-Eigenschaften wie overflow:hidden oder display:table, die diesen Effekt quasi als Nebenprodukt mitliefern. Da es uns in diesen Fällen aber gar nicht um das Verstecken übergroßer Elemente (overflow:hidden) oder das Rendern von Tabellen (display:table) geht, schleppen wir die Auswirkungen dieser Eigenschaften als störende Nebeneffekte zwangsläufig mit.

Was wir benötigen, damit Floats leichter handhabbar werden, ist CSS-Eigenschaft, die das Einschließen floatender Kind-Elemente zur Hauptaufgabe macht, wie z.B float:contain;. Die vom CSS-Standard dem am nächsten kommende Eigenschaft ist clear. Allerdings ist sie für Inhaltskonzepte konzipiert, weswegen ihre Wirkungsweise uns für Layoutzwecke solche Probleme bereitet und uns an diesem Punkt nicht weiterhilft.

Flexible Breiten & Source Order

Bei der Umsetzung flexibler (responsive) Layouts stößt man unweigerlich auf Probleme, wenn fixe und flexible Seitenbereiche nebeneinander zu platzieren sind. Wir platzieren sekundäre Inhalte typischerweise am Rand (Stichwort: Sidebar), neben den zentral gelegenen Hauptinhalten. Die Reihenfolge der Inhalte im Quelltext sollte die Relevanz natürlich widerspiegeln, womit auch hier erst der Hauptinhalt und dann die sekundären Infos folgen sollten. Diese Markupkonstellation stellt uns aber hinsichtlich des Layouts mit Floats vor ein konzeptionelles Problem, da laut CSS-Standard das Element, welches umflossen werden soll (hier bricht die inhaltsbezogene Ansatz von Floats im CSS-Standard durch), im Quelltext zwingend vor den Elementen, stehen muss, die es umfließen (man achte auf die aktive/passive Formulierung).

Das Problem sind hier nicht die Floats ansich, sondern dass wir kein Layout-Modul in CSS kennen, welches dieser Aufgabe gewachsen ist. Die Aufgabe besteht darin, die zur Verfügung stehende Gesamtbreite in einen Bereich mit definierter Breite (Maßeinheit em,% oder px) und einen flexiblen Rest zu unterteilen. Genau dieser flexible Rest ist in CSS nur für statische Elemente spezifiziert über width:auto. Auf positionierte (position:absolute|fixed) oder floatenden (float:left|right) Element lässt sich diese Breitenangabe aber nicht anwenden.

Deshalb ist es uns ohne Tricksereien nicht möglich, eine horizontale Zweiteilung durch zwei “gleichwertige” Layoutbausteine vorzunehmen. Wir greifen mangels Alternativen auf Floats zurück, wobei hierbei immer der Zwang besteht, dass das floatende Element im Quelltext vor den statischen Element stehen muss.

Natürlich ist es dennoch möglich, dieses Problem mit den aktuellen Bordmitteln zu lösen. Entsprechend Codebeispiele dafür habe ich in die Dokumentation des Spaltenmoduls von YAML aufgenommen (achtet auf die verschiedenen Layoutansätze für 2-Spalter). Das ganze geht zurück auf die cleveren Ansätze aus dem Beitrag “In Search of the Holy Grail” von A-List-Apart vom Januar 2006. Seither sind 6 Jahre vergangen, in denen sich CSS enorm weiterentwickelt hat. Dieses Grundproblem flexibler Layouts wurde jedoch bisher nicht zufriedenstellend gelöst.

User Interfaces für Webapplikationen

Als drittes möchte ich nochmal darauf hinweisen, dass gemäß der Logik der CSS-Spezifikation Webseiten eine definierbare Breite haben, in ihrer Länge aber grundsätzlich als unendlich definiert werden, weswegen es im Grunde keine Möglichkeiten gibt, den vertikalen Layoutaufbau sinnvoll zu gestalten, außer durch den linearen Aufbau des Markups und einer abschnittsweisen Gestaltung der aufeinander folgenden Elemente (Header, Content, Footer). Der CSS-Standard ist für HTML-Seiten konzipiert, das vertikale Scrollen gehört quasi zum Konzept dazu, um die theoretisch unendliche Informationsmenge einer HTML-Seite durch das Schlüsselloch Browserfenster (mit begrenzten Dimensionen) betrachten zu können. Schon für einen sticky Footer nutzen wir CSS-Kniffe, die ein Großteil von CSS-Einsteigern nicht mehr voll durchdringt und deshalb nur schwer auf die eigenen Randbedingungen anpassen kann.

Nun hat sich aber der HTML5 Standard auf die Fahnen geschrieben, HTML fit für Webapps zu machen. Befeuert wird diese Entwicklung durch potente Smartphones und Tablets. Man will eine echte Alternative zu nativen Applikationen schaffen, die naturgemäß für jedes OS separat entwickelt.

Der Gedanke ist ausgesprochen reizvoll, jedoch ist einer der grundlegenden Unterschiede, dass User Interfaces in nativen Applikationen anders funktionieren als eine Website. Niemand will auf der Suche nach einem wichtigen Funktion erst mühsam nach unten scrollen müssen, um dann für den Klick auf einen Menüpunkt wieder nach oben zu scrollen usw. Ihr versteht, was ich meine?

Es geht also um User Interfaces, die mit dem verfügbaren Platz in horizontaler und vertikaler Ausdehnung auskommen müssen/sollen – ohne Scrollen. Im CSS-Standard haben wir nichts, womit diese Aufgaben zu bewältigen wären. Der aktuelle Umweg geht hier über JavaScript. ExtJS bietet in seinen UI Komponenten so genannte Layout Manager, für jQuery gibt es das von mir hoch geschätzte Layout Plugin. Speziell auf den Mobilbereich ausgelegt, gesellen sich Projekte wie jQuery Mobile und Sencha Touch hinzu.

Diese JavaScript-basierenden Tools liefern uns die Layoutwerkzeuge, ohne die es kaum denkbar wäre, webbasierte Applikationen zu schreiben, die sich wie eine native App anfühlen. Dennoch stelle ich mir die Frage, ob wir es uns dauerhaft leisten wollen, Layoutaufgaben, die eigentlich der Browser für uns viel schneller und effizienter lösen könnte, an JavaScript auszulagern. An anderer Stelle diskutieren wir bis aufs Messer um jedes Byte, was wir aus Performancegründen weglassen können. Beim Layout jedoch sind wir jedoch JavaScript praktisch ausgeliefert, was nie so schnell werden kann wie die hardwarebeschleunigte Rendering-Engine eines Browsers (oder eben die des Betriebssystems, die jeder nativen App zur Verfügung steht). Und das hat auch die Konsequenz, dass eine native App sich – zumindest aus dieser Sicht – immer flüssiger anfühlen und reagieren wird als eine clientseitige JS-Implementation.

Damit will ich den gedanklichen Steifzug durch meine CSS-Phantasien beenden. Wichtig war mir, aufzuzeigen, dass wir Layouts aktuell noch mit vergleichsweise unausgereiften Techniken bauen, obgleich die technischen und qualitativen Anforderungen an CSS-basierte Layouts durch die heutige Vielzahl der Endgeräte enorm gestiegen ist und ich neben den tollen CSS3 Entwicklungen der letzten Jahre (Schatten, Gradienten, Webfonts, Animationen, etc), die niemand mehr missen will, hier eigentlich dringender Nachholebedarf und erhebliches Potential performantere Lösungen besteht. Auch habe ich mich bei dieser Liste ausschließlich auf die Belange des Seitenlayouts beschränkt. Schaut man sich andere Bereiche, könnte man hier sicherlich endlos weitere Wünsche ergänzen.


Dienstag03. April 2012

Vor 10 Jahren was CSS gerade mal dazu gut, Schrift- und Hintergrundfarbe von Texten festzulegen. Heute können wir dank CSS3 Transitions, Transforms und Animationen in allen modernen Browsern problemlos eine Horde gescheckter Kühe geschmeidig animiert (weil hardware-beschleunigt) über die Pixelweide treiben.

Was wir aber nicht können, sind vermeintlich simple Layoutaufgaben ohne abstruse CSS-Tricksereien realisieren. Schon vor einer kleinen Weile schlug Louis Lazaris mit seinem Blogbeitrag “CSS: The Bad Parts” in eine ähnliche Kerbe, wobei ich nur zum Teil die von ihm angesprochenen “Probleme” als solche wahrnehme.

Die Sache mit den Floats

Über den Sinn und Zweck von Floats lässt sich trefflich streiten. Vor 5..6 Jahren waren sie der Heilsbringer, der die CSS-Layouts dahin geführt hat, sich über den Layouttabellenschmarn des letzten Jahrhunderts zu erheben. Und in einem Umfeld, in dem überwiegend pixelexakte Layouts propagiert wurden, funktioniert dieser Ansatz auch leidlich. Nun hört man in den letzten Jahren – anfangs nur von Standards-Fetischisten – heute auch aus der breiten Frontendler-Masse, Floats wären ja laut Standard nie für Gestaltungsaufgaben vorgesehen gewesen und würden demzufolge für Layoutzwecke genauso missbraucht, wie seinerzeit die HTML-Tabellen.

Nun, diese Argumentation mag für Verschwörungstheoretiker brauchbar sein, für mehr aber auch nicht. Viel schwerwiegender ist doch die Erkenntnis, dass sich Floats trotz aller Widrigkeiten im Detail der Spezifikation durchgesetzt haben und wir monentan gar keine Alternativen dazu haben. Und damit bin ich wieder beim Aufhänger für diesen Blogpost. CSS 3 hat in den letzten 2 Jahren eine rasante Entwicklung hinter sich und vom Gefühl her beschleunigt diese Entwicklung noch immer. Nur passiert der technische Fortschritt auf ganz anderen Bereichen: Runde Ecken, Gradients, Schatten, Animationen, 3D, Schriften usw. usw.

All die neu hinzugekommenden CSS3 Features will man aber nun auch einsetzen und damit werden viele der Probleme, die es mit Floats gibt, erst jetzt mit Nachdruck sichbar. Umso unbefriedigender ist die Tatsache, dass mit CSS3 bisher kaum brauchbare Layoutkonzepte in die Standardisierung – geschweigedenn in die Praxis – Einzug gehalten haben.

Kein Float-Clearing ohne Nebenwirkungen

Wer bis heute der Meinung ist, die Clearing-Problematik wäre mit der Erfindung des Clearfix-Hacks gelöst, der führt zum einen ein offenbar gut behütetes Entwicklerleben und irrt zum anderen gewaltig. Schauen wir auf die aktuellen Webdesign-Trends: Responsive Webdesigns, flexible Grids und CSS3 Box-Shadows.

  • Der Clearfix-Hack hat das Ärgernis beseitigt, für das Clearing der Floats zusätzliche Elemente ins Markup stopfen zu müssen. Er hat aber schon immer das Problem, Auswirkungen auf die Positionierung anderer floatender Elemente im gleichen Kontext zu haben, was seinen Einsatzzweck zum Einschließen von Floats stark einschränkt.
  • Die Eigenschaft overflow:hidden schien zur Hochzeit von CSS2 nahezu nebenwirkungsfrei zum Einschließen von Floats. Mit der Praxistauglichkeit von CSS3 ist dieser Status dahin, denn CSS-Schatten von Child-Elementen werden an den Elementrändern gnadenlos abgeschnitten.
  • Die Eigenschaft display:table scheint auf den ersten Blick die Nachteile von overflow:hidden mit CSS3 ausgleichen zu können, denn es wird nichts abgeschnitten. Dafür ist die Implementation in den Browsern uneinheitlich, was schon damit beginnt, wie sich ein Element mit dieser Eigenschaft hinsichtlich seiner Breite verhält. Dazu kommt ein noch tiefer liegendes Problem, welches nicht immer sofort sichtbar wird. Die Eigenschaft display:table hebelt eines der grundlegenden Rendering-Prinzipien von CSS aus, dass ein Elterncontainer nicht mit der Breite seines Kind-Elementes mitwächst. Sichtbar wird dieses Verhalten, wenn man beispielsweise flexible Grids damit baut und linearisiert, ohne den einzelnen “Zellen” eine Breite zuzuweisen (wozu auch, Blockelemente dehnen sich von allein auf die Größe des Elternelementes aus). Fügt man in ein solches CSS-Konstrukt allerdings ein flexibles Bild ein, wird dieses plötzlich nicht mehr skaliert dargestellt, sondern in voller Größe und die Elterncontainer werden entsprechend ausgedehnt – genauso wie bei Tabellen. Dieses Problem ist bisher kaum bekannt. Aber ihr könnt mir glauben, es ist extrem mühsam, die eigentliche Ursache beim Debugging überhaupt zu erkennen.

Mit dem Durchbruch flexibler Layouts unter dem Deckmantel des Buzzwords “Responsive Design” werden weitere Probleme sichtbar. Wir sind bei CSS weit davon entfernt, Elemente unabhängig vom Markup im Screendesign anordnen zu können. Zahlreiche Entwickler bemerken erst jetzt bei der Umstellung von fixen Grid-Systemen auf Grids in Prozentwerten, was es heisst, mit Rundungsfehlern der Browser offensiv umzugehen. Und und und ...

Fehlende Alternativen

Tja, was gibt’s hier? Der eine oder andere weiß sicher, dass einige CSS-Frameworks (z.B.: die Grid-Komponente von YUI3) auf display:inline-block aufbauen. Auch diese Eigenschaft ist keine Lösung, denn sie wurde noch viel weniger für Layoutzwecke entworfen als Floats. Das äußert sich insbesondere darin, dass ein Grid mit diesem CSS-Konzept plötzlich höchst sensibel auf Leerzeichen und Zeilenumbrüche im Quelltext zwischen den einzelnen Grid-Zellen reagiert. Es braucht nicht viel Phantasie, um sich die Probleme vorzustellen, wenn man als Entwickler keine vollständige Kontrolle über den Quellcode hat. Und wer hat die schon? Denkt nur an verschachtelte Templates in einem CMS und die dadurch entstehenden Zeilenumbrüche im Quelltext.

CSS3 verspricht uns gleich vier neue Layout-Module: Multicolumn, Grid-Layout, Flex-Box und das Template-Modul. Das Multicolumn-Modul ist als einziges bereits beim Status “Testing” angekommen allerdings lässt es sich im Grunde nur auf Fließtext sinnvoll anwenden. Für den Bau eines Seitenlayouts im herkömmlichen Sinne ist es ungeeignet. Die anderen drei pendeln zwischen “Revising” und “Exploring”, d.h. ihre Anwendbarkeit liegt in weiter Ferne. Erschwerend kommt hinzu, dass der visuelle Seitenaufbau ein so grundlegender Baustein ist, dass sich hier kaum sinnvolle Progressive-Enhancement-Strategien realisieren lassen. Entweder die gesamte relevante Browserlandschaft unterstützt die Technik fehlerfrei oder sie ist für den Alltag noch nicht reif. Sprich: Wir lesen uns 2016 wieder.

Während wir mittlerweile selbst auf Smartphones gut und gerne 50 animierte Kühe per CSS fliegen lassen können, mühen wir uns bei den grundlegenden Gestaltungswerkzeugen im Web auch in den nächsten Jahren noch mit unzureichenden Techniken ab. Und es verblüfft mich schon ein wenig, dass wir uns so bereitwillig von all dem HTML5- und CSS3-Bling Bling blenden lassen.

Nachtrag: Für die Zweifler unter Euch: Zwar keine fliegenden Kühe, dafür nicht minder knuffige, fliegende Schweine. (gefunden und mir zugetragen von Christian Heilmann).


Seite 1 von 9 Seiten

 1 2 3 >  Letzte »