CSS & XHTML
Freitag25. September 2009

Gestern, am 24.9. hatte ich die Ehre, zusammen mit David Maciejewski auf dem “Best of Accessibility” Symposium über Möglichkeiten zur Optimierung der Ladezeiten von Webseiten zu sprechen. David war so freundlich und hat die Folien bereits bei Slideshares hochgeladen, sodass ich sie hier zur Verfügung stellen kann.


Dienstag25. August 2009

Seit der Version 2.8 bringt Wordpress das neues Template-Tag body_class mit, womit sich verschiedenste Abhängigkeiten und Statusinformationen des CMS als CSS-Klassen an das <body> Element heften lassen, um mittels CSS im Layout darauf reagieren zu können.

<body <?php body_class(); ?>>

Leider ist die Implementation dieser interessanten und nützlichen Funktion in Wordpress eher unglücklich gelöst. Die Jungs von WPEngineer haben bereits im Februar vorbildlich darüber informiert, welche Klassennamen das Tag ins Markup rendert. Darunter befinden sich zahlreiche allgemein gebräuchliche Klassenbezeichnungen wie:

  • archive
  • author
  • blog
  • category
  • date
  • home
  • page
  • search
  • tag

Das Problem bei der Verwendung derart gebräuchlichen Bezeichnungen sind fast zwangsläufig Kollisionen bei der Implementation bestehender CSS-Layouts in Wordpress. Gerade heute habe ich eine Mail zu diesem Thema bekommen:

Man kann sich ja mittlerweile im BODY-Tag CSS-Klassen einfügen lassen je nachdem welcher Typ von Seite aktuelle von WordPress ausgegeben wird. Dabei gibt es auch die Klasse “page” für die Seiten in WordPress. Resultat ist, dass sich das dann mit der Klasse “page” aus YAML überschneidet.

Ich kann im Moment froh sein, dass es nur eine CSS-Klasse von YAML trifft. Schon innerhalb dieses Bloglayouts hier – würde dieses Blog mit Wordpress laufen – würden weitere Klassenbezeichnungen kollidieren, denn ich verwende in meinem Bloglayout auch Klassenbezeichnungen wie “date” oder “category”. Nur sind diese Klassen in meinem Layout nicht dafür gedacht, an das body-Element geheftet zu werden. Nun könnte ich mein CSS-Framework YAML in einer nächsten Version natürlich anpassen, um der Kollision aus dem Wege zu gehen, aber ich halte dies für den falschen Weg, denn die Welt dreht sich nicht um Wordpress und YAML ist nicht allein von diesem Problem betroffen. Wordpress als Blogtool oder CMS sollte eigenständig kein Markup generieren (soweit die graue Theorie) und es sollte ebenso die Implementation bestehender Layouts nicht durch die Kollision von Klassennamen unnötig erschweren.

Ein relativ einfacher und unkomplizierter Lösungsweg heisst: Namespacing. Wordpress könnte allen dynamisch ins Markup generierten CSS-Klassen das Kürzel “wp-” voranstellen (oder dieses sogar im Backend konfigurierbar machen). Bei anderen Content Management Systemen (Bsp: TYPO3) kommt dieses Verfahren bei den meisten Extensions zum Einsatz. Auf diese Weise ließen sich die angedeuteten Probleme leicht vermeiden, während die durchaus sinnvolle Funktionalität weiterhin uneingeschränkt verfügbar bleibt. Leider bin ich selbst zu wenig bewandert in PHP und auch nur ein Gelegenheitsnutzer von Wordpress, dennoch hoffe ich, dass diese Idee auf irgendeinem Kanal an das Entwicklerteam herangetragen wird.

 


Freitag14. August 2009

Es folgt mal wieder eine Bug-Beschreibung. Firefox hat aktuell ein ausgesprochen hässliches Problem in Verbindung mit CSS Tabellen und JavaScript. Die Kombination der beiden führt in einigen Fällen zu groben Renderingfehlern wobei einzelne Zellen einer Tabellenzeile scheinbar willkürlich in eine neue Zeile umgebrochen werden.

Das Rendering der CSS-Tabellen funktioniert prinzipiell, es ist also kein einfacher CSS-Bug. Ich verwende diese Technik in YAML zur Erstellung gleichhoher Container per CSS. Das eigentlich perverse an diesem Bug - er ist extrem schwer nachvollziehbar. Ich habe die CSS-Tabellen mittlerweile in mehreren Real-Live-Situationen ausprobiert und dabei bereits im Winter erstmals Bekanntschaft mit diesem Bug gemacht. Allerdings war die Fehldarstellung meist nach einem Reload oder auch nur dem Versuch eines Elementchecks mit Firebug verschwunden. Die Ursachenfindung hat das extrem erschwert. Erst vor einigen Wochen hat dann im YAML-Forum ein User einen weiteren Tipp beigesteuert, der letztlich einen Testcase ermöglichte.

Gestern Abend habe ich mich nochmals hingesetzt und endlich einen - zumindest bei mir - funktionierenden Testcase erstellt, sowie den Bug bei Bugzilla gemeldet (Bug 510350) . Die Einzelheiten zum Wie und Warum sind übrigens im Testcase ausführlich beschrieben.

Im Testcase wird der Bug durch eine fast leere Script-Node getriggert, wobei diese hier direkt im HTML-Code der Tabelle steht. Es ist die einzige halbwegs verlässliche Möglichkeit, den Bug zu erzwingen, die ich kenne. In meinen Real-Life-Layouts reichte meist schon die pure Anwesenheit von JavaScript in Form von jQuery oder sonstigem.

Und abschließend: Dieser Bug ist derart fies, dass sein Auftreten auf wundersame Weise sogar vom Dateinamen des Testcases beeinflusst wird. Auf meinem lokalen Rechner tritt der Bug - genau wie in der Netzversion - sporadisch auf. Wenn ich den Testcase jedoch in “index.html” umbenenne, wird er plötzlich permanent getriggert. Das verstehe wer will. Ich hoffe daher, die Mozilla-Jungs finden und eleminieren die Ursache möglichst schnell.


Freitag17. Juli 2009

Einen etwas ausführlicheren Beitrag zu effizientem Code (HTML & CSS) habe ich mir schon lange vorgenommen – dieser hier ist es noch nicht. Dennoch hat mich diese kürzlich erschienene Evaluation der vier bekanntesten CSS-Frameworks zu diesem Beitrag bewogen. YAML ist wohl mit Abstand das komplexeste Framework unter den genannten und bedingt aufgrund seiner Ausrichtung (flexible Layouts) sowie der Vielzahl an Möglichkeiten, Dateien und Beispiele auch eine steilere Lernkurve. Schnell kann dabei der Eindruck entstehen, dass die Komplexität (und die umfangreiche Browserunterstützung) zu einem überbordenden Umfang des Frameworks führen. Also gehe ich dieser These hier mit einem kleinen Vergleich mal auf den Grund und verleiche das CSS-Volumen der Framework-Cores.

Der Framework-Core

Beinahe jedes CSS-Frameworks definiert sich durch so genannte Kernbausteine. Diese stellen die grundlegende Funktionalität bereit und sorgen für deren browserübergreifende Kompatibilität. Neben diesen Kernbausteinen bieten die einzelnen Projekte mal mehr, mal weniger optionale Bausteine an (Navigationsbausteine, Textformatierung, Formulare ect.), um den Entwicklungsprozess über die grobe Layouterstellung hinaus zu erleichtern. Genau in diesem Punkt klafft die Schere zwischen den einzelnen Projekten sehr weit auseinander. Diese optionalen Bausteine erhöhen zwangsläufig für den Einsteiger beim Erstkontakt die Komplexität, berühren aber eigentlich die Kernaufgabe der CSS-Frameworks (die Layouterstellung) nicht wirklich und erschweren die Vergleichbarkeit. Ich konzentriere mich deshalb beim folgenden Vergleich jeweils auf diese Kernbausteine, den so genannten Framework-Core folgender Projekte:

Den gesamten Beitrag lesen


Mittwoch08. Juli 2009

Note: This experiment began with a big portion of irony in mind, regarding CSS frameworks. But then it developed into an interesting exercise on how to code with minimal markup.

Have you ever wanted to work with a streamlined CSS framework? Here it is ...

The source code

revision 1: 109 Bytes

<!DOCTYPE html><head><title></title><style type="text/css">*{color:#000;background:#fff}</style></head><body>

No need for a download link. It even fits in a tweet on Twitter.

Revision 2: 74 Bytes

<!DOCTYPE html><title></title><style>*{color:#000;background:#fff}</style>

This is still a valid HTML 5, crossbrowser compatible document and the framework is still ready to start adding content. With revision 2 we achieve amazing 32 percent saving of markup. The source code fits on a single typewriter line.

10 exciting killer-features

  1. It’s standard compliant and only uses valid code (valid HTML 5)
  2. Completely made without any CSS hacks
  3. It’s prepared for the future by using the latest web technologies (HTML 5)
  4. It has a streamlined source code, no DIV soups or bloated CSS, no optional end-tags.
  5. It has accessibility features (maximum contrast for all elements)
  6. Premium class browser compatibility (IE 3+)
  7. Performance optimized code - only a single HTTP request
  8. No limits for webpage design (allows fixed, elastic or fluid designs and even grids)
  9. Prepared for web 2.0: Just add rounded corners, drop shadows and reflections
  10. It’s free: licensed under Gnu Public License

Many thanks to co-author Tomas Caspers for his help, hard work and contribution to make this web developers dream come true.

UPDATE:  Revision 2 is out with huge markup savings. Thanks to all commenters who helped to fall below the 100 Byte limit.


Seite 3 von 9 Seiten

 <  1 2 3 4 5 >  Letzte »