rakis lab.net

O.K. - zunächst mal der Name bzw. die Headline dieser ‘Website Gallery’: touch of beauty - PRINCSS
ouch. ;)

Aber das gehört nunmal dazu… Im sogenannten ‘web’ (genauer: ‘web development’) muss man schon irgendwie mehr oder weniger geek sein. Das ist vielleicht eine gewagte Aussage… aber liege ich da falsch?

Zurück zum Thema: PRINCSS ist eine Sammlung von ästhetischen Webseiten, die vorwiegend von Frauen entworfen / gestaltet / erstellt worden sind. Laut dem Text auf der ‘About’-Seite, haben Frauen eine spezielle Sensibilität (wörtlich übersetzt), die sie in ihre Arbeit einfließen lassen. Dies wird im weiteren Text auch mit woman’s touch betitelt. Im Prinzip finde ich eine Sammlung von schicken Webseiten schon nicht schlecht. Zumal hier auch gewisse Voraussetzungen gemacht werden, um den Stil der Seiten einzugrenzen (It is required that all sites follow the cssprincess idea, which promotes woman’s touch in design and use of light colors and symmetry.).
Allerdings finde ich den Ausdruck woman’s touch doch ein wenig irritierend. Schließlich können Männer auch schöne und ästhetische Webseiten entwerfen. Ich denke nicht, dass dies nur Frauen vorbehalten ist (gelegentliche Ausnahmen ausgenommen). Obwohl ich zugeben muss, dass Männer vielleicht mehr zum technischen Design tendieren als Frauen. ;)
Aber ich schweife ab. Schluß damit.

Da ich selbst nicht gerade sehr kreativ bin, bin ich umso mehr von den schicken Seiten angetan, die dort präsentiert werden.

Dann noch ein weiterer Link-Tipp: das ‘daily DesignBlog‘ (ist mir wegen cssprincess wieder eingefallen. Wollte ich doch schon längst in meinen RSS-Reader eingetragen haben.)

P.S. Als kleine Erklärung zu meinem Abschweifen etwas weiter oben: Ich habe nichts gegen Frauen im Web-Business. Im Gegenteil. Aber ich habe etwas gegen Schubladen. Ich will in keine gesteckt werden… und stecke daher andere da auch nicht hinein (zumindest versuche ich es)…

David Greiner von “CampaignMonitor” hat einen Artikel für “Vitamin” veröffentlicht, indem er praktische Sachen über die Erstellung von HTML-E-Mails zusammenfasst.
Dabei geht es um häufige Probleme und Umsetzungsstrategien (grosses Wort für die Frage ‘CSS oder Tabellen!?’). Wirklich sehr gelungen, wie ich finde…

HTML Emails - Taming the Beast

Firefox ist nicht zuletzt wegen dem Extension-API so beliebt. Dabei gibt es mehr oder weniger sinnvolle oder sogar performance-fressende Erweiterungen (das habe ich zumindest bei der Speicherbelegung des Firefox negativ bemerkt und in diesem Posting auch beschrieben).

Ein Juwel unter den vielen verfügbaren Extensions ist nun aber endgültig die FireBug-Extension von Joe Hewitt. Ich hatte vor einiger Zeit schonmal eine frühere Version getestet und war begeistert. Die aktualisierte Version 0.4 macht aber schon wieder einen ganz anderen Eindruck und ermöglicht ausgiebiges Debuggen von Webseiten auf der Client-Seite. Dabei trennt FireBug die Fehlermeldungen der JavaScript-Konsole nach Domain und bietet darüber hinaus noch verschiedene Filtermöglichkeiten.
Schick ist das setzen von Breakpoints in JavaScript und eine “line by line step through”-Funktion. Auch werden JS-Meldungen von FireBug in ein Log geschrieben und man kann so auf das lästige “alert()”-Debugging verzichten. Sogar ein Log für Ajax-Funktionen per XMLHTTPRequest ist vorhanden, sowie eine direktes Eingabefeld für die Ausführung von JavaScript-Code (ähnlich einer Kommandozeile).

Aber FireBug ist nicht nur ein reiner JavaScript-Debugger. Er greift auch auf den DOM-Inspector zu und stellt dessen Funktionalitäten sehr benutzerfreundlich zur Verfügung. Damit wird auch das Inspizieren von CSS vereinfacht.

Einziger Nachteil ist nur, dass sich der FireBug direkt in das Anzeigefenster mit einklinkt und nicht in einem separaten Fenster aufgeht (wie z.B. der DOM-Inspector). Da wird dann schon recht bald der Platz knapp und man sieht nur noch Ausschnitte (je nach Auflösung). Ich empfehle daher eine Auflösung mit minimal 1024px vertikal. Glück hat, wer sein Display hochkant drehen kann.

Neben der überaus beliebten “Web Developer“-Extension (auch oft “webdev”-Extension genannt) von Chris Pederick und der “inspectThis“-Extension ist FireBug eine sehr nützliche Erweiterung beim Entwickeln von Webseiten. Quasi ein “must have”. Ich will jedenfalls nicht mehr darauf verzichten!

Es ist zwar schon eine Woche her, aber das ändert wohl an der derzeitigen Akualität nichts.
Der CSS Reboot ist vollzogen. Die Teilnehmer haben wohl mittlerweile alle ihre neuen standardkonformen und CSS-basierten Websites veröffentlicht.
Die komplette Liste der sog. Rebooter kann man entweder Alphabetisch oder etwa nach Tags sowie Ländern durchsuchen. Es gibt dazu noch div. Sortiermöglichkeiten direkt auf der Startseite. Die einzelnen Reboots können kommentiert und bewertet werden (wobei ich aber das Bewertungssystem noch nicht so ganz durschschaut habe).

Es ist doch eine recht nette Veranstaltung, auch wenn ich den Halbjahreszyklus ein wenig zu kurz finde. Vielleicht ist es aber auch besser so, um die Anzahl der Teilnehmer auf einem überschaubaren Niveau zu halten. Immerhin gibt es insgesamt 15 Übersichtsseiten mit jeweils 54 Teilnehmern. Da kann man ja eigentlich gar nicht alles (ausgiebig) angucken… aber den ein oder anderen Blick ist es dennoch allemal Wert! Es sind doch sehr schicke Sachen dabei. =)

Es ist eine der Fragen, die immer wieder auftauchen. Erzeugt man automatisch generierte Emails als reinen Text oder als HTML-Emails? Beides hat seine Vorteile und Nachteile. Das eine sieht (bei weitem) schicker aus, das andere beinhaltet potentielle Sicherheitsrisiken und inkonsistente Darstellung.
Ich zumindest habe meinen Thunderbird so eingestellt, dass er mir E-Mails nur als Text darstellt und kein HTML. Sollte dann doch ein Newsletter oder so wirklich HTML-Darstellung benötigen… dann kann ich immernoch umschalten. Ich finds einfach besser so und ich glaube ich bin damit nicht die Ausnahme.

Aber was, wenn man nun doch aus irgendwelchen Gründen HTML-E-Mails erzeugen soll/muss, dann sollte die Darstellung zumindest auf den unterschiedlichen Clients einigermassen gleich aussehen (ich nehme das mal so an… weil das wohl auch der wichtigste Grund für HTML-Emails ist). Heutzutage ist semantisches HTML ‘in‘ und verzichtet auf ein tabellenbasiertes Gerüst. Mal wieder heisst das Zauberwort ‘CSS’. Es wäre damit eigentlich schon alles gut… eigentlich. Diejenigen, die schonmal ein wenig intensiver mit CSS gearbeitet haben, wissen wie schwer es ist, die Darstellung zwischen den Browsern einheitlich zu gestalten. Aber wie sieht es denn mit Email-Programmen aus? Da gibt es ja schliesslich noch mehr Vielfalt als in der Browserwelt… da hätten wir diverse webbasierte Services und unzählige weitere Programme.
Über Roger Johansson bin ich über eine Zusammenfassung von Mail-Clients gestossen und deren Fähigkeiten bezüglich CSS: A Guide to CSS Support in Email aus dem CampaignMonitor-Blog. Diese Anleitung finde ich doch sehr informativ und erweist sich bestimmt als extrem hilfreich, wenn man (aus welchen Gründen auch immer) mal HTML-E-Mails generieren muss.

Abschliessend noch ein kleines Zitat aus dem Eintrag von Roger Johansson, den ich nicht besser hätte formulieren können:

The bottom line is that unless you know for certain what email software the recipients will be using to read your newsletter, you can save yourself (and the recipients) a lot of trouble by keeping it simple.

Come to think of it, keep it simple even if you know that the recipients all use email clients with top-notch support for CSS. The people who receive your newsletter will thank you.

via: Roger Johansson - CSS support in email clients