Grundsatzdebatten, heute: Schriftgrößen in CSS

Eine immer wieder gern geführte Diskussion: wie skaliert man Schriften in CSS richtig? Die einen sagen, in Pixeln wäre die korrekte Art, schließlich sind Pixel die Maßeinheit für Monitore. Dumm aber, dass der Internet Explorer in px skalierte Schriften nicht mehr skalieren will. Also doch lieber relativ zur vom Benutzer gewählten Standardgröße über die Verwendung von em oder %? Was aber, wenn der User seinen Browser so konfiguriert hat, dass eben kleinere Schriften als in der Standardeinstellung verwendet werden? Dann wird alles zu klein… Kommen wir zur Radikal-Lösung: gar nicht im CSS skalieren: Fliesstext bekommt einfach die vom Benutzer eingestellte Standardgröße (100%) – dumm nur, dass wohl ein großer Teil der Benutzer die Einstellungen gar nicht ändert – und normaler Text mit 16px Größe?
Kurz zusammen gefasst: es gibt nicht die richtige Lösung:

Welche Methode wir auch wählen, wir müssen mit dem berechtigten Unmut einer gewissen Benutzerschar rechnen. Wir sollten damit souverän umgehen und diese Schwächen nicht leugnen – schon gar nicht, wenn wir anderen irgendeine Methode empfehlen.

Da isse nun…

So, die neue Site ist online. Ein paar Sachen werde ich später noch ändern, aber soweit gefällt es mir schon ganz gut. Auf jeden Fall mal was anderes und ein paar Seiten mit Infos für die Leute, die mich noch nicht kennen 🙂
Für die, die es interessiert: die statischen Seiten bearbeite ich jetzt mit RapidWeaver. Vor allem bei den Fotoalben ist das ganz praktisch, da auch RapidWeaver direkt die Fotos aus iPhoto verwenden kann (und ich möchte was wetten, dass es bald auch ein Photocast-PlugIn für RapidWeaver gibt). Mal schauen, was ich jetzt mit dem ganzen Platz auf .Mac mache – dort hatte ich ja bisher die Fotos.

Neubau

imageSchon länger wollte ich meine Seiten mal neu bauen – wird ja auch langsam Zeit. Ist ja auch nicht mehr so ganz passend, wenn man unter dobschat.de direkt hier im Weblog landet. Nach einigen Tests der aktuellen Beta von Sandvox und dem neuen iWeb bin ich wieder zurück zu Rapidweaver gekommen. Nichts gegen die beiden anderen Tools, aber zum einen kenne ich Rapidweaver schon länger und besser, Rapidweaver hat ein Theme, das mir recht gut gefällt und der HTML-Export von Rapidweaver ist ein Stück besser zu lesen und zu bearbeiten – nicht ganz unwichtig, schließlich soll das Weblog hier ja dann zum Rest der Site passen. Heute wird es aber nichts mehr mit dem Relaunch: erst mal brauche ich doch noch ein wenig Schlaf und heute Nachmittag kommt dann Götz vorbei. Das wird eine lange Nacht, zum einen besprechen, was dieses Jahr auf seinen Seiten so alles passieren soll, den neuen Shop bauen und auch ein paar Ideen zu liedermaching.de durchgehen. Aber die nächsten Tage sind meine neuen Seiten dann endlich online…
BTW: sowohl iWeb als auch Sandvox sind durchaus interessante Lösungen, auch wenn sie für genau dieses Projekt im Moment für mich noch nicht ideal sind.

Zu cool für IE… oder einfach zu faul?

imageDie Buttons der “Too cool for IE”-Kampagne sieht man ja inzwischen immer öfter. Jetzt gibt es die Gegeninitiative dazu: “Zu faul für CSS” bzw. “Cool genug für IE”. Hintergrund ist einfach, dass die meisten der “zu coolen” Seiten diesen Button nur aus einem Grund zu haben scheinen: die Entwickler waren zu faul die Seiten ordentlich zu entwickeln.

Jeder Webmaster bzw. Entwickler wünscht sich andere Finessen, sowie ausgefallene Gimmicks für seine Website und hat auch eine andere Vorstellung, was das Design und die Nutzung angeht. Aber den Ast absägen, auf dem man sitzt, muss das sein? Wir fragen uns, wie aufgrund des fixed Selektors eine Webseite “ZU COOL FÜR IE” sein kann. Denn ein Großteil der coolen Websites wird gerademal in einem Browser richtig dargestellt und auch im HTML / XHTML (Seitenquelltext) weisen die coolen Sites jede Menge Fehler auf.

Klar kann man auf seiner privaten Seite den IE ignorieren, aber zumindest wer sich als Profi in diesem Bereich bezeichnet sollte solche Spielchen unterlassen – immerhin könnte man ja vielleicht glauben, dass man es einfach nicht kann und wenn ein potentieller Kunde so was denkt wäre das gar nicht gut. Auch wenn es wirklich keinen Spass macht, Seiten so zu bauen, dass sie in allen Browsern möglichst gleich oder zumindest gut aussehen.
Welches Vorgehen sich da bei mir bewährt hat: erst nur für Safari/Firefox bauen und anschliessend für den IE anpassen – ohne dabei die Darstellung in Safari/Firefox kaputt zu machen. Nicht ganz einfach, aber machbar.

(via Thomas Gigold)

SELFHTML braucht Unterstützung der Mac-Community

Das Projekt SELFHTML braucht Unterstützung der Mac-Community:

Inbesondere soll das gesamte HTML-Kapitel getestet werden, welches momentan erst ab Safari 1.2 getestet wurde und entsprechende Icons zur Browserunterstützung besitzt. Da die meisten HTML-Features, die Safari 1.2 unterstützt, mit Sicherheit auch in Safari 1.0 funktionieren, ist dies nicht allzu arbeitsintensiv.
Hinzu kommen vereinzelte Tests in der JavaScript-Objektreferenz. Neben geänderten Beispielen, die bisher nur mit Safari 2.0 getestet wurden, sollten die dortigen Safari 1.2-Icons kurz überprüft werden.

(via mac.delta-c)

Das wird ein riesiger Spass mit dem IE7

Also die gute Nachricht: der IE7 soll endlich mal ein IE sein, der sich an Standards hält. Eigentlich ist das doch gut, wenn da nicht eine Kleinigkeit wäre: IE7 wird nicht mehr kompatibel sein zum IE6 was die verschiedenen Hacks angeht. Das wird ein Haufen Arbeit für viele Menschen, die jede Menge Hacks in ihre Seiten gebaut haben, damit der IE damit klar kommt. Jetzt heisst es wieder Ausnahmen für die Ausnahmen zu bauen und testen und… oder einfach den IE vergessen und nur noch standardkonform bauen? Wäre doch auch eine Idee – wenn der IE7 ja sowieso standardkonform werden soll wäre das doch die ideale Lösung, oder nicht?

(via Alp Uçkan)

Hover Buttons mit CSS optimiert

Animierte Buttons mit CSS oder JavaScript sind nichts neues, einen Nachteil haben diese Methoden aber meistens: beim ersten Überfahren eines solchen Buttons muss der Browser das alternative Bild erst mal laden. Das kann man mit CSS vermeiden. Der Trick ist einfach: Man packt beide Buttons in ein Bild und verschiebt das dann einfach entsprechend…