Gerade stieß ich via Jens (@flocke) auf die Seite IE7NoMORE, die dazu aufruft, den Internet Explorer 7 zu vergessen, weil wir nicht in der Vergangenheit leben können.

Nachdem also jetzt der IE6 erfolgreich bekämpft wurde, geht es jetzt dem IE7 an den Kragen. Ich frage mich aber, warum es eine Motivation geben sollte, ältere Browser bekämpfen zu wollen? Dahinter kann eigentlich nur der Irrglaube stecken, dass Websites in allen Browsern gleich aussehen müssen.

Während IE7NoMORE einige tolle Beispiele auflistet, was seit CSS2 und vor allem CSS3 alles möglich ist, ist die Intention, den IE7 zu vergessen, total fehl am Platze. Dank hilfreicher Tools wie Modernizr können wir sehr gut ältere Browser ansprechen. Das ein oder andere Polyfill wie zum Beispiel Selectivzr kann (bei gemäßigtem Einsatz) ebenfalls sinnvoll sein.

Gepaart mit dem richtigen Verständnis, dass man für ältere Browser ein reduziertes Layout anbietet und toleriert, dass es auch ziemliche Unterschiede im Layout zwischen den Browsern geben kann, erzielt man bessere Ergebnisse. Die kommen natürlich dem Nutzer zugute, der die Inhalte vernünftig erfassen kann, statt vor einem nicht behandelten zerschossenen Layout zu stehen.

Man muss ältere Browser nicht ignorieren, um moderne Websites zu bauen.
Man muss nur wissen, wie man vernünftig mit ihnen umgeht.

Ich arbeite gerade an einer Website (ecompunk.com), für die ich mir den Vorteil der CSS Eigenschaft background-position-y zunutze machen wollte, um Zeit und Code zu sparen beim Positionieren eines CSS-Sprites:

li a {
	background:url(img/socials.png) no-repeat;}
li:nth-of-type(1) a {
	background-position:0 0;}
li:nth-of-type(2) a {
	background-position:-35px 0;}
li:nth-of-type(3) a {
	background-position:-70px 0;}
/* One hover declaration fo all li-elements */
li a:hover {
	background-position-y: -30px;}

Es funktionier wunderbar in Safari/Chrome, IE, aber überraschender weise nicht in Firefox und Opera.

Ein wenig Recherche später fand ich raus, dass diese nützliche CSS-Eigenschaft nicht mal in einer Spezifikation auftaucht.
Jonathan Snook schrieb auch über dieses Thema vor einem Jahr und wundert sich ebenfalls. Einige Kommentare verdeutlichen schön das Problem.

Soweit ich weiß gibt es also keine Möglichkeit, nur die X- oder die Y-Positionsangabe zu schreiben ohne auch gleich die andere angeben zu müssen. Irgendwie ärgerlich, zu mal es für mich keinen ersichtlichen Grund gibt, es nicht in die CSS-Spezifikation aufzunehmen. Vielleicht kennt jemand von euch einen Workaround?

Webkit hat seine Schreibweise für CSS-Verläufe kürzlich angepasst. In diesem Zusammenhang möchte ich neben der neuen Syntax auch auf den Entwicklungsprozess eines neuen Webstandards eingehen.

Vor ein paar Monaten schrieb ich einen Artikel für drweb.de über Tabellenlayouts mit CSS3 (Teil 1, Teil 2). Dort hatte ich bei den verwendeten CSS-Verläufen auf die unterschiedlichen Schreibweisen hingewiesen, wobei die von Webkit umfangreicher und komplizierter war:

background:-webkit-gradient(linear, left top, left bottom, from(#656e70), color-stop(50%, #515b5c), color-stop(50.1%, #465153), to(#323e40)); 
background:-moz-linear-gradient(top, #656e70, #515b5c 50%, #465153 50.1%, #323e40);
background:linear-gradient(top, #656e70, #515b5c 50%, #465153 50.1%, #323e40);

Webkit hat nun ebenfalls seine Schreibweise der offiziellen des W3C angeglichen, weshalb wir in Zukunft schreiben können:

background:-webkit-linear-gradient(top, #656e70, #515b5c 50%, #465153 50.1%, #323e40);
background:-moz-linear-gradient(top, #656e70, #515b5c 50%, #465153 50.1%, #323e40);
background:linear-gradient(top, #656e70, #515b5c 50%, #465153 50.1%, #323e40);

Dadurch erhalten wir nun eine Vereinheitlichung. Haken an der Sache ist allerdings, dass Safari und Chrome das noch nicht verstehen und zumindest bis zum nächsten größeren Update die alte Schreibweise benötigen. Zurzeit funktioniert es nur in den Webkit Nightly Builds.

Auch wenn die Veränderungsprozesse manchmal etwas nervig sind, zeigt dieses Beispiel sehr schön die Entwicklung eines neuen Standards. Die ursprünglich von Webkit erdachte Implementierung von CSS-Verläufen wird von anderen Browserengines übernommen (mit verbesserter Syntax) und schließlich auch Teil des CSS3-Standards. Im Laufe der Entwicklung passt nun Webkit seine Syntax an, sodas eine Vereinheitlichung entsteht.

Hieran wird deutlich, dass neue Funktionen nicht, wie oft angenommen, vom W3C initiert werden, sondern zunächst von den Browserengines erdacht und umgesetzt werden. Die Aufgabe des W3C ist anschließend die Standardisierung einer neuen Funktion, sofern auch weitere Browserengines diese übernehmen.

Außerdem sieht man an diesem Beispiel, wie sinnvoll die sogenannten »vendor prefixes« (die Präfixe der Browserengines wie -webkit, -moz, -o, -ms) sind. Denn obwohl sie in Zeiten des Übergangs zu einer neuen Technologie mehr Schreibaufwand erfordern, zeigen sie an, dass eben jederzeit noch Änderungen möglich sind und auf welche Browser sich diese auswirken. Weiterhin ermöglichen Sie uns, neue Funktionen in verschiedenen Browsern bereits zu nutzen, auch wenn noch keine Einigkeit über Implementierung und Ausgabe besteht.

Ich höre jetzt schon die CSS3-Verweigerer, die genau diese Veränderungen als Bestätigung sehen, dass es sich lohnt, auf neue Funktionen zu warten, bis sie zum Standard geworden sind (oder vor allem der IE das auch kann). Ich nehme das aber gerne in Kauf, da ich mich lieber auf die Vorteile konzentriere, die mir (und meinen Kunden) neue Technologien in modernen Browsern bringen.

Während Villarriba schon CSS-Verläufe feiert, schrubbt Villabajo noch den IE 6 ;-)

Michael van Laar hat kürzlich einen Artikel über Webstandards als Verkaufsargument verfasst und kommt zum dem Schluss, dass die oft von Webworkern propagierten Argumente eigentlich keine sind. Nils Pooker greift in den Kommentaren das eigentliche Problem dahinter auf, dass nämlich Webstandards in der Kundenkommunikation keine Rolle spielen. In einem älteren, aber dennoch weitgehend zeitgemäßen Artikel schreibt er über die richtige Kundenansprache, wie man Vorteile von Webstandards besser vermittelt.

Ich möchte an dieser Stelle noch einen »Standard« ergänzen: Grafikdesign. Mike Kus hat hierüber mal einen kurzen Vortrag gehalten: Graphic Design: The Forgotten Web Standard. Hier geht’s vor allem darum, dass Technik und Code nicht alles ist, sondern vielmehr nur ein Hilfsmittel zur Darstellung. An sich nichts neues, aber vielleicht ein Anstoß, dass die Diskussion mehr auf den visuellen Output gelenkt wird, vor allem im Gespräch mit dem Kunden.

Vor einiger Zeit bloggte Tim van Damme über -webkit-font-smoothing und schlug vor,
-webkit-font-smoothing: antialiased zu verwenden, um das Font-Rendering bei Safari am Mac zu verbessern. Zu dieser Zeit gab es Safari 5 noch nicht und es scheint, dass die neue Version die Schriftdarstellung verbessert hat.

Um der Laus mal genauer in den Hintern zu schauen, habe ich Tim’s Safari-4-Screenshots aus seinem zuvor erwähnten Artikel mit einem aktuellen aus Safari 5 verglichen:

(1) zeigt das alte Standard-Rendering in Safari 4, (2) zeigt das neue Standard-Rendering in Safari 5 und (3) zeigt das antialiased-Rendering (das sich scheinbar nicht verändert hat von Safari 4 zu 5).

Ich habe eine Testseite erstellt, wo man das noch einmal vergleichen kann. Ich denke das jetzt in Safari 5 die Standard-Methode subpixel-antialiased Vorteile hat gegenüber antialiased wenn es um schräge Linien geht, wie beim Kursiv gestellten Texten oder Großbuchstaben wie A, M, N, Z.

Müssen wir überhaupt noch die Rendering-Methode ändern?

Ja, und zwar, wenn wir hellen Text auf dunklem Hintergrund haben. Dabei stellt die Standardmethode den Text meistens etwas zu fett dar und die Schrift wird leicht unleserlich. Hier macht -webkit-font-smoothing:antialiased Sinn.

Kritisch wird es bei kursivem Text auf dunklem Hintergrund, hier ist von Fall zu Fall zu entscheiden, was besser lesbar ist. Manche Schriften brechen weg und die Standardversion ist besser, manche Schriften werden aber kursiv immer noch zu fett dargestellt und die antialiased-Version ist besser.

Überprüfen kann man das wie bereits erwähnt auf der Testseite.

Vor ein paar Wochen bat mich mein Freund Roman sein englisches Blog etwas aufzupolieren. Das bis dato verwendete, ein modifiziertes kostenloses Wordpress-Theme, hatte seinen Zweck erfüllt, aber Roman wollte ein individuelles Theme mit mehr Persönlichkeit und ohne den ganzen Schnick-Schnack den Standardthemes in der Sidebar mit sich rumschleppen.

Das Logo

Statt nur einen Namensschriftzug wollte Roman auch eine Bildmarke haben, also habe ich auch den Initialen ein Signet erstellt das die Buchstaben »r« und »z« enthält und zusammen ein großes »R« ergibt.

Das Layout

Dann ging’s los mit der Website. Alles was ich hatte waren ein paar Fotos und ein unfertiges Farbschema, das verwendet werden sollte. Außerdem sollte die Seite aufgeräumt, klar, reduziert auf das Wesentliche und auf keinen Fall wie eine typische Business-Website daher kommen.

Ich erstelle ein Basis-Layout mit zwei Spalten, klar und einfach. Um das ganze etwas interessanter und gegenständlicher zu machen, habe ich für die einzelnen Seiten verschiedene Papiermetaphern gewählt. Diese wurden auf jeder Seite entsprechend dem Inhalt geändert um die Gestaltung abwechslungsreich zu halten, mal als kleiner Papierstapel, mal ähnlich einer alten Zeitung oder mit Eselsohren versehen, alles allerdings dezent, ohne den aufgeräumten Look zu stören.

Typografie

Um den lockeren Stil der Website zu untermauern, habe ich bei Typekit nach einer passenden Schrift gesucht und bin bei der Ronnia, einer freundlichen humanistischen Serifenlosen gelandet, einer Schrift von typetogether.
Zurzeit wird sie allerdings nur am Mac angezeigt, weil sie unter Windows XP nicht so gut aussieht. Je nachdem, wie sich die Nutzerstatistiken entwickeln und die XP-User zurückgehen, wird es vielleicht in Zukunft die Ronnia auch auf Windows angezeigt.

Der Code

Obwohl bisher noch einige IE-Nutzer auf dem Blog unterwegs waren, hatte Roman glücklicherweise kein Problem, einen Schritt nach vorne zu machen und den IE weitestgehend links liegen zu lassen. So konnte ich problemlos HTML5-Elemente sowie CSS3 verwenden, was für Safari und Firefox kein Problem darstellt. Dem IE 8 wird dazu mittels Modernizr auf die Sprünge geholfen, die Vorgängerversionen 6 und 7 erhalten das Universal IE stylesheet von Andy Clarke. Hierbei wird lediglich pure HTML-Darstellung mit etwas CSS aufgepäppelt, sodass alle Inhalte zugänglich sind.

Zusammenfassung

Einige Wochen und ein paar durchgemachte Nächte später ist also nun die neue Website pünltlich zum Buchstart des Magento-Entwicklerbuches online. Gefällt sie euch? Lasst es mich wissen!

Remember that the original problem that CSS sprites solved was having too many HTTP requests for images. Data URIs also solve that problem, and solve it in a much more manageable way. Instead of using a single extra request to get the large sprite image, you use zero extra requests to get the images to use. What’s more, there’s no need to combine all of the images – you can keep the images separate and use them as normal background images.«

Den ganzen Artikel von Nicholas C. Zakas darüber gibt es hier. So ganz bin ich noch nicht überzeugt, ob das unbedingt die richtige Vorgehensweise für meinen Arbeitsablauf ist, aber eine sehr interessante Alternative ist es auf jeden Fall.

Wenn man z.B. ein Suchformular erstellt, möchte man in der Regel das Eingabefeld gleich hoch wie den Button gestalten. Zumindest, sofern beide nebeneinander stehen. Leider verhalten sich überraschender Weise Safari und Firefox unterschiedlich und der Internet-Explorer ist diesmal nicht der Böse.

Um es gleich vorweg zu nehmen, es geht gerade einmal um 2 Pixel, die aber manchmal ganz schön störend werden können. Aber es gibt eine CSS-Lösung dafür.

Nehmen wir mal folgendes Suchformular:

<form method="get" id="sampleform1" action="search">
	<h2><label for="s">Search</label></h2>
	<input type="text" value="" name="s" id="s" />
	<input type="submit" id="searchsubmit" class="submit" value="Search" />
</form>

(Man kann statt »input« auch ein »button«-Element für den Such-Button verwenden.)

Das Problem

Gestylt mit etwas CSS (Siehe die Beispielseite für Details) erhält man das Folgende Ergebnis. Hierbei wurde etwas »padding« zu beiden Input-Elemeten hinzufügt, um die gewünschte Höhe zu erhalten:

Wie man sehen kann ist der Button höher als das Eingabefeld in Firefox, der IE8 verhält sich wie Safari. Man könnte versuchen, das ganze mit hinzufügen einer Höhenangabe »height« zu lösen, dann aber passiert folgendes:

Immer noch sieht’s in Safari gut aus, aber im Firefox ist der Eingabe-Text nicht mehr vertikal zentriert. Außerdem steht der Text im Button etwas zu tief. Eine Höhenangabe ist also keine Alternative, wie auch die erwähnte Beispielseite zeigt.

Die Lösung

Wir gehen noch einmal zurück und nutzen doch »padding«. Das Problem liegt innerhalb der form.css von Firefox’ Benutzer-Stylesheet. Hier erhält der Button einen zusätzlichen Rand (»border«) für die Fokus-Pseudo-Klasse (»:focus«). Durch hinzufügen von

input[type="submit"]::-moz-focus-inner {border:0;}

zu unserem CSS können wir diesen zusätzlichen Rand entfernen und die Höhe des Buttons ist gleich hoch wie in Safari:

Weil wir nun keinen »:focus«-Stil für Tastaturnutzer mehr haben, müssen wir diesen natürlich ergänzen, in diesem Fall habe ich einfach eine andere Hintergrundfarbe gewählt.

input[type="submit"]:focus {background:#333;}

Nun, das wär’s.

Wann braucht man das?

Wir sprechen hier grade mal über zwei Pixel und man kann natürlich einfach sagen, das ist nicht so schlimm. Es kann aber dann wichtig werden, wenn man den Button innerhalb des Suchfelds platzieren möchte, um eine geschlossene Einheit zu bilden, wie das folgende Beispiel zeigt:

Wenn in diesem Fall die Höhe nicht stimmt, sieht es nicht mehr gut aus.

Eine andere Lösung wäre die Verwendung von Bildern als Button. Da es aber eine CSS-Lösung gibt und mittlerweile auch mittels CSS3 schöne Buttons gestaltet werden können, muss nicht immer ein zusätzliches Bild her.

Weil ich gerne über die Termine und Anstoßzeiten unserer Nationalmannschaft informiert bin und ich keine Lust habe, ständig danach zu suchen, habe ich kurzerhand ein iPhone-Hintergrundbild erstellt, das die deutschen Spiele der Vorrunde enthält. Der Pokal stammt aus einem Icon-Set des brasilianischen Designers und Illustrators Dirceu Veiga.

Nun, der Mai allein hat nicht gereicht, um meinem Blog ein frisches Aussehen zu verpassen. Nachdem ich nun seit Februar an dieser Website arbeite, habe ich es nun endlich geschafft, eine (fast) fertige Version online zu stellen.

Dabei habe ich mich ehrlicherweise etwas übernommen, denn neben einem neuen Design, das fast ausschließlich im Browser entstanden ist, habe ich außerdem HTML5 und CSS3 eingesetzt, mit CSS-3D-Transitions experimentiert, die ich auf meiner Buchseite eingesetzt habe (geht nur im Safari), sowie Textpattern komplett zweisprachig umgebaut mit dem genialen Multi-Lingual-Publishing-Paket (MLP). Alles in allem etwas viel, aber es hat geklappt und ist geschafft!

Wichtig für mich war es, ein flexibles Layout zu haben, das es mir ermöglicht, gegebenenfalls Artikel mit einem individuellen Layout zu versehen, dort wo es angebracht ist und den Inhalt bereichert.

Zudem habe ich eine Tumblelog ähnliche Struktur erstellt, bestehend aus den Kategorien Artikel, Posts, Links, Zitate und Bilder. Hoffentlich hilft mir das, regelmäßig Inhalte zu veröffentlichen :)

Sollte jemand mit dem Internetexplorer vorbei surfen und sich beschweren: Sorry, aber den hab ich noch nich berücksichtigt, wird aber zumindest für Version 8, nachgeholt.

So, jetzt wäre es schön, euer Feedback zu meiner Webstite zu bekommen, danke!
Ansonten bin ich an eurer Meinung interessiert, was ihr von meinem Bücherregal im speziellen und von CSS3-Spieleren im allgemeinen haltet?