coldheat.deTutorials – coldheat.de

jQuery – Flash of Unstyled Content

Chris_ — Fri, 13 Mar 2009 11:33:18 +0000

Seit Ewigkeiten mal wieder ein winziges Tutorial von mir zur Lösung eines durchaus nervigen kleinen Problems. Nutzt man jQuery im großen Stil mit dynamisch geladenen Inhalten und aufwendigerem CSS, kann es zum Effekt kommen, den man Flash of unstyled Content nennt. Der Browser lädt Inhalte, die noch nicht vollständig mit Stilen und Klassen versehen sind und zeigt somit Inhalte in falscher Form an. Mein Archiv war hier ein Musterbeispiel, welches mittlerweile aber ausgebessert ist. Zugegeben nur ein Schönheitsfehler aber einer, der sich ganz einfach beheben lässt.

Ich bin nicht der Erste, der dieses Problem versucht zu lösen. Wer danach googled wird viele Lösungen finden. Auch ich habe nur eine Lösung zu meiner gemacht. Zwei Vorrausettzungen sind zu erfüllen. Zum einen möchte ich so wenig zusätzlichen Quellcode und zum anderen solle es eine pure Javaskript-Lösung sein, die Nutzer mit deaktiviertem Javaskript ignoriert. Im schlimmsten Fall versteckt man mit CSS Elemente, die nur angezeigt werden, wenn Javaskript aktiv ist. Diesen Fall möchte man vermeiden.

Grundsätzlich laufen alle Lösungen nach dem gleichen Prinzip. Beim Laden der Seite werden ungestylte Elemente versteckt und nach dem jQuery seinen Zauber hat wirken lassen, zeigt man diese Elemente wieder an. jQuery selbst bietet dafür nicht grundlos eine document.ready-Funktion, die praktisch dafür geschaffen ist. Wir brauchen 2 Zeilen jQuery und 1 Zeile CSS.

Die Javaskript-Frage koppeln wir an die CSS-Regel, die somit nur greift, wenn Javaskript aktiv ist. Dafür schlägt learningJQuery das HTML-Tag vor. Also verpasst man diesem Tag einfach eine neue CSS-Klasse/ID:

    $('html').addClass('js');

basiert darauf CSS, um das gewünschte Element zu verstecken

    .js #zuVersteckendesElement {display: none;}

und entfernt die .js-Klasse vom HTML-Tag, wenn das Dokument fertig geladen ist:

    $(document).ready(function(){
        $('html').removeClass('js');
    });

Was hier passiert ist schnell und einfach beschrieben:

Dokument beginnt zu laden
.js-Klasse wird HTML-Tag zugewiesen
CSS-Klasse greift somit und versteckt das gerade geladene Element
Dokument ist fertig geladen und strukturiert
.js-Klasse wird entfernt
Element erscheint auf der Seite

Das ist mal wirklich einfach. Kleine Probleme kann es geben, wenn man verschiedene jQuery-Module mit der Lösung kombiniert, was mir im Archiv passiert ist. Hier habe ich etwas rumgedoktort, wie die CSS-Regel aussehen muss, damit das Element versteckt, das jQuery-Tabs aber nicht beeinflusst werden. Abgesehen davon, eine sehr elegante Lösung.

Feedback: 0 Kommentare

Skript zum Einbinden von RSS-Feeds auf Webseiten

Chris_ — Tue, 11 Mar 2008 11:43:24 +0000

Meine Link-List auf der Start-Seite bzw. der dazugehörige Feed, sind nichts anderes, als meine Empfehlungen im Google-Reader. Ein Klick im Reader und die Überschriften erscheinen auch hier. Zwar bietet Google dafür extra eine vorgefertigte Lösung, die mir aber zu aufgebläht in der Struktur und insgesamt zu unflexibel ist. Google bietet aber auch eine eigene API zum Sammeln und ausgeben von Feeds auf Webseiten, damals noch einfach Google Feed API genannt, heute schon als Google AJAX Feed API betitelt.

Der Zusatz AJAX sorgt für noch aufgeblähteren Quellcode und völlig fehlende Semantik, weshalb ich auch hier wieder einen großen Bogen um die fertigen Lösungen mache und was Eigenes bastle. Es folgt ein kurzes Tutorial zum Javaskript der Feed-Darstellung.

Inhalte verlinken nicht stehlen

Nichts gegen die immer beliebter werdenden Feed-Aggregatoren – Webseiten, die praktisch nur Inhalte anderer Seiten mit Hilfe derer Feeds bei sich darstellen – ich halte eine solche Praxis für aüßerst fragwürdig. Hier entsteht der Eindruck fremde Inhalte als eigene verkaufen zu wollen. Links zur Quelle hin oder her, falsch bleibt falsch. Komplette Feed-Items sollte man einfach nicht absaugen und einfach so bei sich darstellen, das ist einfach schlechte Schule. Gute Schule dagegen ist ein einfacher Link der Überschrift, hin zur fremden Seite. Nichts anderes bringt das folgende Skript mit.

warum keine fertige Lösung?

Fertige Lösungen gibt es zwar viele, aber bei allen bin ich immer irgendwo eingeschränkt. Sei es viel zu komplexer Quellcode, langsame Skript-Performance, oder Grenzen bei der CSS-Gestaltung. Nur bei einer eigenen Lösung ist man alle Probleme los. Hinzu kommt, dass es kinderleicht ist, mit Google’s APIs zu arbeiten. Was man als erstes benötigt ist ein API-Schlüssel von Google, der sich hier holen lässt. Meine Version ist damals noch mit der alten Version dieser API entstanden, gehe aber mal stark davon aus, dass Schlüssel und API abwärtskompatibel sind und somit mein Skript, auch mit neuen Schlüsseln funktioniert.

Dieser API-Schlüssel wird dann auf der jeweiligen Seite, mit einem Skript-Verweis im Head aktiviert:

feed-display.js

Das fertige Skript auf den eigenen Server packen und auf der eigenen Seite, wie schon den API-Schlüssel einbinden:

Nun kann man mit folgender Syntax munter Feeds auf der eigenen Seite darstellen lassen. Wer zum Beispiel eine Liste mit Links zu den letzten 5 Einträngen dieser Seite, in einer Div mit der id „cold-heat“ haben möchte, bekommt es mit folgendem Aufruf im HTML:

Die Ausgabe mit HTML sieht dann wie folgt aus:



    Titel des Blogs
    Blog-Beschreibung
    Titel des Artikels
    2
    3
    4
    5

Eine einfache valide Struktur, ohne große Schnörkel. Für jeden Feed benötigt man dann einen separaten Aufruf des Skripts. Wer unbedingt die kompletten Inhalte nutzen möchte, sollte sich das Skript genauer anschauen, es beinhaltet alle Zutaten auch komplette Inhalte der Links darzustellen. Die Schlüssel-Zeile ist im Skript ausreichend kommentiert.

Feedback: 5 Kommentare

Google Chart API

Chris_ — Mon, 10 Dec 2007 11:29:03 +0000

Man kann über Google so viel schwarzmalen wie man möchte, aber die immer neuen APIs sind immer wieder einfach besser als die Konkurrenz. Die nun offene Chart API ist da keine Ausname. Es ist die eierlegende Wollmilchsau geworden. Einst exklusives internes Tool für Google, steht es nun jedem Anwender offen, sofern man sich mit 50.000 Abfragen pro Tag begnügt.

Für diese Seite sind die Pie-Charts am interessantesten. Nach kurzem Lesen der Instruktionen, bekomme ich aus den alten Daten dieses Eintrags, sowas heraus:

Hierzu ein winziges kurzes Tutorial, das kurz die API erklären soll. Da diese Art von Diagrammen die sicherlich einfachsten der API sind, bietet sich mein Beispiel auch bestens an. Im Gegensatz zu anderen Google APIs braucht man hier keinen API Key, sondern arbeitet einzig und allein mit URLs. Jede URL baut sich aus mehreren Paramentern auf. Fangen wir mal einfach an mit einem einfacherem Diagramm:

Die URL für dieses Diagramm besteht aus 4 Parametern, die durch ein Ampersand-Symbol verbunden, in der URL an das API übergeben werden. Die Parameter hierfür lauten:

1. cht=p3
2. chs=468x242
3. chd=s:1cs
4. chl=Label-1|Label-2|Label-3

Zeile 1 definiert die Art des Diagramms. Zeile 2 beschreibt die Größe, alle Diagramme werden als normales Bild ausgegeben. Zeile 3 beschreibt die eigentlichen Werte und Zeile 4 schließlich die Beschriftung dieser Werte. Die URL umschreibt also: „Zeichne ein Diagramm der Art 3D Pie-Chart, in den Maßen 468 Pixel breit und 242 Pixel hoch. Gebe dem Diagramm 3 Werte – 53, 28, 19 – und beschrifte diese Werte mit Label-1, Label-2 und Label-3.“ Soweit so einfach.

Etwas abstrakter wird es bei der eigentlichen Beschreibung der Werte. Google bietet hier drei Methoden, alle umschreiben eine andere Art der Kodierung. Mein einfaches Beispiel funktioniert mit dem was Google als Simple Encoding betitelt und was der String chs= in der URL einleitet. Hier die Regeln zum Simple Encoding:

Upper case A = 0, B = 1 and so on to Z = 25.

Lower case a = 26, b= 27 and so on to z = 51.

Zero (0) = 52 and so on to 9 = 61.

Specify a missing value with an underscore (_).

If you have more than one set of data, separate each set with a comma (,).

Meine 3 Werte (53, 28, 19) werden in dieser Kodierung also als „1cs“ beschrieben.

1 = 53
c = 28
s = 19

Wer diesen Schritt einmal durchschaut hat, der hat das Schlimmste hinter sich. Viel mehr gibt es eigentlich nicht zu schreiben. Diese API ist äußerst einfach für diese simplen Diagramme. Komplexer wird es erst bei anderen Diagramm-Arten.

Neben dem dreidimensionalen Pie-Chart, gibt es natürlich auch die klassische zweidimensionale Variante:

Man darf das Ganze auch einfärben. Entweder mit einem Farbwert, welcher dann abgestuft wird:

Oder auch mit je einem separaten Farbwert für die einzelnen Abschnitte:

Kann nur jedem empfehlen sich die API mal näher anzuschauen. Glaube da wird man hier bei mir in Zukunft mehr von sehen. Daumen hoch für Google’s Chart API. Kleines aber feines Detail am Rande: Läd man eine dieser URLs für sich separat, dann ist das Favicon im Browser auch wirklich eine verkleinerte Ansicht des jeweiligen Diagramms.

Feedback: 1 Kommentar

Diagramme im Web – zweiter Teil

Chris_ — Tue, 29 May 2007 10:11:39 +0000

Ich mach es kurz für heute. Was wir hier sehen ist ein 100% freiskalierbares Balkendiagramm, mit leicht geänderter Ausrichtung als das letzte. Was hier so einfach aussieht, hat diesmal wirklich etwas mehr Zeit in Anspruch genommen, dank einer nicht wirklich funktionierenden vertikalen Ausrichtung bei CSS-Formaten.

Wert 1: 46%
Wert 2: 24%
Wert 3: 89%
Wert 4: 62%
Wert 5: 29%

Ich bin zufrieden mit dem Ergebnis. Leider ist das Markup diesmal etwas komplizierter geworden, primär eben weil im CSS schlecht bis garnicht vertikal zu positionieren ist. Problem war, dass ich mit CSS nur sehr schwer an einer Grundlinie (in diesem Falle der Definitionsliste) ausrichten kann, die Balken in dieser Art Diagramm aber eben nach oben wachsen sollen und nicht nach unten. Der Trick besteht diesmal darin, dass was optisch als Balken wahrgenommen wird, nicht auf dem eigentlich Wert der Liste zu legen. Was hier als Balken gesehen wird, ist das Ergebnis von überlagertem dt und dd-Tag der Definitionsliste.

Grafik zum besseren Verständnis vom Markup des Diagramms

Die Farbe des Balken bringt also diesmal das dt-Tag und das dd-Tag deckt dieses ab. Um nun den darzustellenden Wert zu erzielen bekommt das dd-Tag diesmal eine Höhe, welche 100% minus des darzustellenden Wertes entspricht. Im Quellcode sieht das dann so aus:

Wert 4
62%

Zwar erscheint nun mit passendem CSS der Balken, aber die einzelnen Werte und die Bezeichnung sind noch deplaziert. Hier kommt nun zusätzliches Markup in Form von span-Tags hinzu. Leider habe ich keine andere Lösung gefunden, die völlige Skalierbarkeit garantiert, aber dazu gleich mehr. Der Quellcode samt span-Tags sieht dann so aus.

Wert 4
62%

span

Die span-Tags nutze ich nun um die Werte dank z-index nach vorn zu holen und an die richtige vertikale Stelle zu schieben. Positionierung und Bemaßung dieses Diagramms findet nur mit Prozent-Werten statt, was eben den Vorteil hat, dass ich später die Liste insgesamt (dl-Tag) egal wie bemaßen kann und der Inhalt sich immer perfekt anpasst, egal ob das Diagramm 200 oder 2000 Pixel hoch/breit sein soll, alles passt sich automatisch an. Wer hier liesst wird sich sicherlich rudimentär mit CSS auskennen. Vertikale Anpassung ist in dem Fall kein Problem. Anspruchsvoller dagegen die Horizontale, da sich eben auch die Anzahl der Balken ändert. Es gibt ein paar Schlüsselwerte:

.content dl.data-2 dt,
.content dl.data-2 dd {
width:12%;
}
.content dl.data-2 dd {
margin:0 0 0 -12%;
}
.content dl.data-2 dt {
margin:0 0 0 4.7%;
}

Die 12% entsprechen jeweils der Breite und dem negativen Margin beide Elemente der Liste. Die 4.7% sind der horizontale Abstand zwischen den Balken des Diagramms. Ich wünschte ich könnte eine schöne mathematische Herleitung des Wertes bringen, aber irgendwie ist diese bei der Arbeit am Diagramm verloren gegangen.

Wichtig ist dennoch, dass man grundlegend zählen sollte wieviele Werte darzustellen sind, das ganze verdoppeln, Wert notieren und die 100% durch Wert-X teilen. Somit bekommt man einen recht guten Wert für die Breite der Balken. Die 100% ergeben dann jeweils X-Anzahl Balken und X-Anzahl Zwischenräume. In meinem Beispiel 512+54.7=83,5. Wie man sieht habe ich in meinem Beispiel noch etwas Luft nach oben.

Vor- und Nachteile

Problematisch hierbei ist eine Verteilung der Stildefinitionen auf CSS und Inline-Elemente. Dadurch erhält man bei wechselnenden Wertemengen auch immer jeweils separate CSS-Klassen bzw. IDs. Jedes Diagramm bekäme sein eigenes CSS-Format, was eigentlich dem Sinn von CSS etwas verfremdet.

Dem gegenüber steht jedoch eine Darstellung von Diagramm-Werten, die auch ohne CSS erschließbar bleiben und sich leicht für jedes andere Medium formatieren lassen.

Feedback: 0 Kommentare

Balken-Diagramme im Web-Design

Chris_ — Thu, 26 Apr 2007 15:52:20 +0000

Reine Neugier, ein entstehender Eintrag zu WoW und viele schlechte fremde Beispiele, sind Grund für das folgende kleine Tutorial. Diagramme im Web reduzieren sich zu 90% auf hübsch gemachte Bild-Daten. Meist hochkompromierte Jpegs aus höchstkomplizierten Excel-Diagrammen. Solche Daten sind zum einen langweilig und zum anderen nicht wirklich barierefrei zugänglich. Das möchte ich nun hiermit ändern.

Ich gebe zu, dass ich hier mit dem Titel Diagramme einen Bruchteil aller möglichen Diagramm-Arten verarbeite: Balkendiagramme. Der Grund ist simpel. Zum einen deckt man mit dieser Art fast alle möglichen darzustellenden Daten ab und diese Art eignet sich perfekt, um sie einfach, sauber und dennoch ansehnlich mit HTML und CSS darzustellen.

Struktur

Die erste wichtige Frage lautet, wie baue ich ein Balken-Diagramm inhaltlich korrekt, zugänglich und valide auf, um es anschließend möglichst variabel mit CSS zu stylen?

Optisch sehr gelungen sind für meinen Geschmack, Diagramme auf den Produkt-Seiten von Apple. Ein Augenschmauß, der seine Schwächen im HTML versteckt. Nehmen wir dieses Beispiel. Wer in den Quellcode schaut, entdeckt Gutes und Schlechtes. Apple’s Webdesigner strukturieren hier ausladend mit Div- und span-Elementen innerhalb einer Definitions-Liste. Andere Lösungen für Diagramme setzten ebenfalls auf komplizierte Span-Div-Gebilde oder auch die immer beliebten normalen Listen.

Beispiel für die Anwendung von Diagrammen im Web: Apple Produkseite zum MacPro

Wer hier öfters liest, wird mitbekommen haben, dass ich immer für möglichst einfache und effektive Lösungen bin. Zwar ist mein Beispiel sicherlich schon zu einfach, aber es zeigt hoffentlich die grundlegende Herangehensweise. Meine Wahl für die HTML-Struktur eines solchen Diagramms fällt wie auch bei Apple auf eine Definitions-Liste.

Fraglich ist, ob eine solche Liste inhatlich auch korrekt für diese Art der Daten ist. Für meinen Geschmack ist es das geeignetste Element zur Darstellung von Diagramm-Daten. Inhatlich hat man einen Namen samt Wert und diese Zuordnung ist auch vom W3C ausdrücklich gestattet.

Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content.

[…]

Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.

Solch eine Definitionsliste hat zwei wesentliche Vorteile: sie bietet sowohl von in Struktur als auch vom Inhalt, zwei zusammengehörige Tags: dt und dd. Für ein solches Balkendiagramm deshalb perfekt geeignet, um jeweils den Namen und Wert der darzustellenden Daten zu tragen.


Wert 1
46%

Wert 2
24%

Wert 3
89%

Wert 4
62%

Wert 5
29%

Viel einfacher kann man solche Daten sicherlich nicht mit HTML umsetzen. Mit solch einer Struktur habe ich erstmal alles was ich brauche: eine dl-Liste samt einer Klasse und jeweils passenden dl- und dd-Tags. Spans und Divs sind erstmal überflüssig, was nicht überflüssig ist, sind noch ein paar zusätzliche style-Definitionen innerhalb der dd-Tags, da diese später den eigentlichen Balken darstellen sollen.


Wert 1
46%

Wert 2
24%

Wert 3
89%

Wert 4
62%

Wert 5
29%

Ein so einfache Stuktur lässt sich besonders auch ohne CSS ohne Bilder oder sonstiges sinnvoll auswerten, jeder Wert besitzt eine eigene Angabe. Wir nennen sowas barierefrei. Diese Informationen funktionieren schon jetzt, was fehlt ist nur noch eine bessere Visualisierung. Hier kommt wie immer CSS ins Spiel.

CSS

Auch das CSS ist wirklich einfach gestrikt. Ich definiere eine Breite für das DL-Tag, floate anschließend sowohl dt- als auch dd-Tags, lasse dt-Tag den Float clearen und verpasse beiden dann etwas Farbe und Kante. Zur besseren Übersicht hier jeweils nur die wichtigsten CSS-Zeilen:

dl.data-1 {
margin:20px 20px 10px 20px;
overflow:auto;
}
dl.data-1 dt {
border-right:0;
height:18px;
clear:left;
float:left;
text-align:center;
width:15%;
}
dl.data-1 dd {
text-align:center;
font-weight:bold;
float:left;
clear:none;
height:18px;
}

Da entsteht nun ein kleines Problem, sofern ich mein dt-Tag direkt neben dem dd- floaten möchte. Das dt-Tag braucht zum Floaten eine feste Breite, die dd-Tags daneben varieren aber in der Breite, durch die inline-style-Definitionen aus dem Schritt zuvor. Es gilt nun eine Lösung zu finden, die dem dt-Tag eine fixe Breite ermöglicht, ohne jedoch über die 100% der Gesamtbreite der Liste zu stossen. Angenommen ich gebe den dt-Tags eine feste Breite von 20%, dann habe ich ein Problem mit dem 3ten Wert im Diagramm, welches eine Breite von 89% darstellen soll. 20% + 89% = 109%. Ups.

An dieser Stelle lobe ich mir, dass zumindestens ein paar Dinge aus dem guten alten furchtbaren Mathematik-Unterricht hängen geblieben sind. Die Lösung besteht darin, der style-Breite den Wert der dt-Breite abzuziehen und schon kommen wir wieder auf die maximalen 100%. Angenommen ich möchte dem dt-Tag eine Breite von 15% geben, dann ändern sich die style-Werte wie folgt:


Wert 1
46%

Wert 2
24%

Wert 3
89%

Wert 4
62%

Wert 5
29%

dt- und dd-Tag besitzen nun zusammen die endgültige Breite, des darzustellenden Wertes. Der Rest ist ein kleiner farblicher Anstrich.

Beispiel Diagramm

Wert 1: 46%
Wert 2: 24%
Wert 3: 89%
Wert 4: 62%
Wert 5: 29%

Zugegeben dieses Diagramm besitzt ein paar Einschränkungen, die in einem zweiten Teil hierzu behandelt werden. Was ich hier zeigen wollte war die Einfachheit von Balken-Diagrammen mit validem HTML und CSS, ohne aufgeblähte Struktur oder gar Grafiken. Das Thema bietet noch viel mehr… deshalb bis zum zweiten Teil.

Feedback: 14 Kommentare

1024.2 – Tanz auf dem Raster

Chris_ — Tue, 10 Apr 2007 15:52:46 +0000

Eigentlich sollten die wertvollen Osterfeiertage auch genutzt werden um die neue Gestaltung hier einen Schritt vorran zu bringen, aber wieso oft blieb vom guten Vorsatz nicht viel übrig. Statt dessen kämpften DVDs und ein paar DS-Spiele um meine Aufmerksamkeit. Besonders dieses teuflische Filmwerk hat seine Spuren hinterlassen. Ich habe E.T. nun seit ein paar Jahren nicht mehr gesehen und hoffte der Film hätte seine Wirkung verloren, aber falsch gedacht. E.T. ist bei mir wie auf Knöpfe drücken mit dem Ergebnis nasser Augen. Ich liebe und hasse diesen Film dafür, wird Zeit für ein E.T.-Eintrag samt Kindheits-Erinnerungen zum ersten Kino-Besuch meines Lebens. Aber genug dazu…

Als nachträgliche Erleuterung zum ersten Teil noch ein paar Details zum neuen/alten Grundraster. Wirklich viel verändert hat sich nicht, d.h. die grundsätzlichen Maße bleiben alle bestehen. Hier nochmal die Illustration vom alten Tutorial:

Neu hinzugekommen ist eine vierte „große“ Spalte bzw. eine zusätzliche Teilung der alten Spalten in neue Kleinere. Warum? Einfach um etwas mehr Freiheit bei der Anordnung auf dem Raster zu erhalten, mal schauen wieviel Spielraum ich habe:

Das erweiterte Raster ist nun feiner und insgesamt breiter.

Das Problem mit zusätzlichem Platz ist eine sinnvolle Nutzung. Nicht jeder Inhalt funktioniert plötzlich auf mehr Raum besser. Ich hatte nie wirklich Probleme mit der noch aktuellen schmalen Breite der Seite. Im Gegenteil, es sitzt alles so optimiert an seinem Platz, dass es schwer ist nun eine neue Ordnung hinein zu bringen.

Die Idee war, die zusätzliche Breite auch auf den jeweiligen Inhalt – und somit primär den Text-Blöcken – zu nutzen. Die Breite eines Text-Blocks ist jedoch eine sehr sensible Eigenschaft. Ich möchte mich zwar nicht selbst loben, aber die Lesbarkeit dieser Seite ist wirklich gut und die Breite der Text-Blöcke ist daran nicht unschuldig. Dennoch lohnt es sich immer zu Testen. Dank CSS eine Frage von wenigen Minuten.

Zum Vergleich zwei Möglichkeiten Text und Bild auf der Seite neu anzuordnen.

Diese Grafik zeigt zwei Versuche irgendwie sinnvoll die neuen Maße des Raster zu nutzen. Jeweils Rot markiert, Bereiche die ich für problematisch halte, wo optisch eine Unruhe oder ein Loch entsteht, genau was ich mit einem Raster vermeiden möchte.

Auf der linken Seite, nutze ich die volle neue zusätzliche Breite, auf der rechten Seite hat sich praktisch im Vergleich zum jetzigen Stand nichts verändert. Links geht Lesbarkeit und Ruhe abhanden, Rechts dagegen wirkt die Seite stark ungleichgewichtig, besonders im oberen Teil. Der logische Schritt wäre also eine Mischung aus beiden Lösungen.

weniger ist mal wieder mehr

Allein schon an der Anzahl und Größe der optischen Probleme dieses Layouts scheint dies die beste Lösung bisher zu sein. Ich kann nur jedem Empfehlen auch im Webdesign mal „Abstand“ von dem Layout zu nehmen. Ich habe hier einfach mal Screenshots der Seiten verkleinert und plötzlich kommen Schwächen ans Licht, die man bei der normalen Bildschirm-Betrachtung oft sehr spät entdeckt.

Alle obskuren Versuche, mit der Brechstange die Inhalte in die Breite zu ziehen, verursachen mehr Schaden als Verbesserungen. Die Gestaltung fühlt sich einfach nicht mehr so ausgeglichen an. Sicherlich mögen die Seiten insgesamt dann kürzer werden und wir bekommen ja auch an jeder Ecke gesagt, dass Scrolling schlecht sei. Noch schlechter sind allerdings miese Lesbarkeit und optische Unruhe. Ich opfere gern Seitenlänge und zwinge zum Scrollen, wenn dafür das Verständnis für den Inhalt steigt.

Ein aktueller Stand zeigt zusätzlich ein paar veränderte Details. So ist meine Spalte für Marginalien/Bildunterschriften und Überschriften erstmal auf die Hälfte geschrumpft. Daraus resultiert auch, dass ich die Text-Ausrichtung ändern kann, weil ich nun kaum viel Weißraum zum Text überspielen muss wie jetzt vielleicht noch. Eine rechte Textausrichtung macht plötzlich wenig Sinn. Ob die kleinen Überschriften weiterhin so links fließen werden sei mal noch dahingestellt. 102 Pixel sind verdammt wenig, vermutlich rücken die Zwischenüberschriften somit noch klassisch in die eigentliche Text-Spalte hinein.

So wie momentan die eigentlichen Inhalte auf der Seite stehen, bin ich wirklich zufrieden damit. Der visuelle Rhythmus stimmt sowohl vertikal als auch horizontal, zumindestens beim eigentlichen Eintrags-Inhalt. Drumherum herrscht noch Chaos, aber das wird in den kommenden Tagen beseitigt.

Feedback: 2 Kommentare

1024.1 – Dokumentation zur neuen Gestaltung

Chris_ — Thu, 05 Apr 2007 09:54:34 +0000

Was hier schonmal Erwähnung fand und die rätselhafte Bezeichnung 1024.1 trägt, ist eine Artikel-Serie für die nächsten paar Wochen, mit dem Ziel, dieser Seite einen kleinen neuen Anstrich zu verpassen. Dies ist also der erste Teil, auf dem Weg zu einem funktionierenden 1024 Pixel breitem Webdesign. 1024.1 halt.

Das Ganze fing so simpel an und entwickelt sich langsam zu echten Herausforderung. Die Idee war recht einfach, eine zusätzliche Spalter für das Grundraster, dort hinein die üblichen Randspalten-Daten des Blogs und fertig. Nun daraus ist nun offensichtlich mehr geworden. Das Raster hat sich verändert bzw. ist feiner geworden und damit kommen die Probleme.

Im Gegensatz zu vielen anderen gebe ich hier offen zu woran ich mir bei der Gestaltung so orientiere. Die Times (also das Printmagazin Times) hat neulich ein Redesign auf die Beine gestellt, was einfach gnadenlos gut funktioniert. Wer die Chance hat sollte mal einen Blick riskieren. Es gibt es einen kurzen Online-Artikel drüber.

mehr Platz, mehr Probleme

Statt einfach eine neue Spalte reinzuknallen versuche ich die Seite insgesamt harmonischer in die Breite wachsen zu lassen. Dabei ergeben sich immer wieder neue Lücken, die es zu füllen gilt. So zum Beispiel wird das Formular für die Kommentare auch neu angeordnet werden müssen:

Layout Kommentar-Eingabe

Lässt sich das Formular noch relativ einfach auf das neue Raster legen, so fällt dies bei anderen Elementen schwerer. Was den Kopf der Einträge angeht, so werde ich hier noch mehr vereinfachen. Zur Zeit gibt es noch viele Einschränkungen für mich. Es gibt einen Grund wieso ich keine großen Bilder zu Beginn eines Eintrags integrieren kann, weil diese Bilder mit den Rand-Informationen an gleicher Stelle überlagern würden. Dies ist der aktuelle Stand des neuen Seiten-Kopfes eines Eintrags:

Layout Seiten-Kopf

Ein offensichtliches Problem entsteht dann, wenn das Grundraster ausgeblendet ist, denn dann findet das Auge eine unansehnliche optische Lücke zwischen den Randinformationen und dem eigentlichen Mittel-Teil. Die Idee war nun, die Breite für Texte und Bilder eines Eintrags ein klein wenig zu erhöhen und so die Lücke zu schließen. Was gut klingt funktioniert nur teilweise sehr gut, denn ich habe ich mich nun was die Bilder betrifft auf eine Größe festgelegt, genau so breit wie der Text-Block. Wenn ich diesen nich breiter angelege passen die Bilder nicht mehr.

Wenn der Text breiter läuft als bisher kommt es zu Problemen.

Andererseits funktioniert es, wenn die gleichen Bilder eine Bildunterschrift besitzen:

Genau an dieser Stelle hänge ich nun fest. Ich fürchte auch dieses Problem so schnell nicht lösen zu können. Vermutlich wird trotz eines breiteren Layouts, die Breite der Eintragsinhalte gleich bleiben. Es gäbe zwar Lösungen, aber die wären alle zu umständlich und unflexibel für meinen Geschmack. Irgendwie habe ich mir die Sache einfacher vorgestellt, diese zusaätzlichen Pixel bringen mehr Arbeit mit sich, als ich dachte.

Feedback: 13 Kommentare

Lightbox-Skript bei AJAX-Inhalten

Chris_ — Tue, 07 Nov 2006 14:25:56 +0000

Ich bin immer noch am Rumwerkeln meines Online-Portfolios, nun allerdings nähert sich das Ganze zumindestens funktional der Fertigstellung oder einfach formuliert: es funzt alles. Was hat diese Geschichte nun so kompliziert gemacht?

Das Portfolio ist ein separater Blog in der gleichen Movable-Type Installation wie auch der Hauptblog hier oder der Linkblog. Mein Wunsch war es, so möglichst einfach das Portfolio verwalten zu können, ohne groß manuell neue Links setzen zu müssen, so wie bei der jetzigen Galerie.

Schreibe ich nun einen neuen Eintrag in den Portfolio-Blog, dann werden auch die Archive dieses separaten Blogs aktualisiert. Diese Archive hole ich mir dann mit Hilfe von AJAX in den Hauptblog hier. Dank Movable-Type kann ich das Portfolio sogar sehr einfach nach Kategorien verwalten und mit genau diesen Kategorie-Archiven arbeitet die Hauptseite.

Klickt der Besucher dann zum Beispiel den Link Non-Print, dann holt sich die Seite das Kategorie-Archiv Non-Print vom Portfolio-Blog und lädt es in die aktuelle Seite des Browsers. Soweit nicht allzu kompliziert. Probleme kamen, als ich das Lightbox-Skript zum Vergrößern der Portfolio-Bilder nutzen wollten.

Lightbox initialisiert sich beim Laden der Seite im Browser und kann dann genau mit den Inhalten arbeiten, die zu dieser Zeit vorhanden sind. Wenn ich nun mit AJAX die Kategorie-Archive in die Seite lade, dann ändern sich die Inhalte, aber Lightbox bekommt davon nichts mit und kann somit nicht damit arbeiten. Ein paar Google-Suchen später, brachten zwei Links Licht ins Dunkel, denn so gut sind meine Javaskript-Kenntnisse dann auch nicht, um so ein Ding zu lösen.

Folgende Funktion wird zusätzlich in die Seite eingefügt, die auch die AJAX-Links beinhaltet:

function pollC(id, load){
if (!load&&document.getElementById(id)){
document.getElementById(id).id='';
return;
}
else if (load&&document.getElementById(id)){
if (id=='loadedmarker')  //optional
initLightbox();  //required
return;
}
else if (load&&!document.getElementById(id))
setTimeout("pollC('"+id+"', 'load')", 60);
}

Entscheidend bzw. anzupassen ist Zeile 7. Man muss Lightbox dann neu initialisieren, wenn der HTML-Code der Kategorie-Archive dank AJAX in die Seite integriert wurde, so dass Lightbox, denn Code neu parsen kann und so die Stellen findet, wo es gebraucht wird.

Um zu wissen, wann alle Inhalte geladen sind braucht es eine Art Markierung. Dieser Marker – ein einfaches – befindet sich ganz am Ende vom Template des Kategoriearchivs:




<$MTEntryBody safe_urls="1"$>
"><$MTEntryTitle$>
<$MTEntryMore safe_urls="1"$>

Wenn also alle richtigen Inhalte geladen sind, sieht dieses Poll-Skript den Marker und initialisiert Lightbox neu.

Nun funktioniert Lightbox zwar, aber nur auf den ersten Blick. Lade ich die gleiche Seite ein zweites Mal mit AJAX, dann erinnert sich das Poll-Skript daran und intialisiert Lightbox nicht mehr. Einfach ausgedrückt muss Lightbox jedes mal neu intialisiert werden, wenn sich der Inhalt ändert. Ob die Inhalte bereits vorher cached wurden oder nicht, spielt keine Rolle. Lightbox braucht aktuell für jede Änderungen des HTML-Code eine neue Intialisierung. Dieses Problem löst das Poll-Skript indem es zusätzlich alte, bereits einmal gelandene IDs löscht.

Die eigentliche AJAX-Links, die den Ablauf dann auslösen werden somit etwas länger:

Non-Print

Bei onmousedown löscht er die Marker-ID bzw. setzt den Status auf unbekannt, um wirklich jedesmal neu zu intialisieren. Bei onmouseup werden die externen Inhalte in das Div mit der ID ajax-container geladen um darin den Marker – das span mit der loadedmarker – zu finden und den Status auf geladen zu setzen, woraufhin Lightbox neu initialisiert wird. Aufwendiger als gedacht, aber nun funzt’s. Jetzt ehlen nur noch die echten Inhalte^^

Jede Skript-Spielerei die eine nächträgliche Initialisierung bei AJAX-geladenen Inhalten benötigt, lässt sich mit diesem Skript richten. Lightbox hier ist nur ein klassisches Beispiel.

Feedback: 3 Kommentare

tricky sticky Footer

Chris_ — Wed, 09 Aug 2006 14:35:30 +0000

Bei der Arbeit am Portfolio, zeigte sich ein nerviges, altes und immer ignoriertes Problem. Der Footer dieser Div-Struktur klebt leider nicht immer schön am Fuß des Browserfensters… nun ja nun tut er es. Das soll kein episch langer Text werden. Wer bei Google nach sticky footer sucht, erhält als erstes Ergebnis gleich die perfekte Lösung. Die perfekt einfache Lösung?

Hier zu sehen die Grundstruktur der Seite, bestehend aus nur vier Divs.

Nun für meinen Aufbau der Seite, schien diese Lösung leider nicht wirklich fehlerlos zu funktionieren. Vor Monaten hatte ich diesen CSS-Code schon einmal versucht in die Seite zu integrieren, jedesmal mit wenig Erfolg, weshalb der kleine Fehler bis heute existierte.

Die dort beschriebene Methode ist in der Tat perfekt, wieso nur funktionierte es nicht für meine Seite? Ein Blick auf den Aufbau der Div-Struktur offenbart das Problem dann doch recht schnell. Die dort angebotene Lösung, setzt einen etwas anderen Aufbau der Divs vorraus. Mein Problem ist die fast schon zu simple Stuktur, bei der das #header-Div, ein Problem darstellt, da es nicht innerhalb des #container-Divs liegt. Leider ist dieser #container mein vom Tutorial bezeichnetes #nonFooter-Div.

Mit meiner Struktur funktioniert es leider nicht ohne Anpassung:

So dagegen würde es problemlos funktionieren:

Bekommt div#container einen Höhen-Wert von 100%, dann ergibt sich für die Gesamthöhe der Seite ein Wert aus 100% Fenster-Höhe, samt Höhe des Headers und Höhe des Footers. Nur einen zusätzlichen Wert kann ich durch den negativen Margin-Wert der Sticky-Footer Methode negieren, den des Headers leider nicht, genau dies war das Problem.

es klebt

Ich hab in sinnlos komplizierte Richtungen überlegt. Negative Margins samt Script-Berechnung für die Höhe des #container-Divs, die alle das Ziel haben sollten, die Höhe des Headers, aus der Höhe der Seite insgesamt zu entfernen. Wie nimmt man ein Element aus dem Flow der Seite? position:absolute;

Wieso fallen einem die einfachsten Lösungen so spät ein. Dieses position:absolute; ist die halbe Miete zur Lösung, der Footer ist sofort sticky. Von hier an spielt wie so oft, ein simpler Zufall die entscheidende Rolle. Ich hatte da immer dieses zweite Div (#content) innerhalb des #containers, primär angelegt um grafische Spielerein auch strukturell im #container-Div zu belassen. Geplant war mal Intro-Bilder für die jeweiligen Kategorien zu zeigen. Dieses #content-Div war schon immer da und konnte endlich eine Aufgabe bekommen.

Durch den nun absolut positionierten Header, klebte auch das #container-Div am oberen Rand der Seite. Ein oberes Padding auf diesem Element hätte theoretisch funktionieren sollen, praktisch tat es das nicht, da verschiedenste Browser wieder unterscheiden und das Padding mal zur Höhe addieren und mal nicht. Das #content-Div war bereit seine Hauptrolle zum Besten zu spielen. Dieses Div musste nun nur einen größeren margin-top Wert bekommen, nämlich zusätzlich genau den Wert der Höhe des Headers. Schon sitzt wieder alles an seinem Platz und der Footer klebt fest am Boden eures Browser-Fensters.

Die vom Mann in Blau angebotene Methode funktioniert in der Tat perfekt, braucht nur manchmal ein bischen Anpassung an das jeweilige Beispiel, besonders dann, wenn man wirklich jedes überflüssige Div einsparen möchte. Wie konnte ich so eine simple Lösung nur so lange übersehen. Peinlich, peinlich.

Feedback: 4 Kommentare

CSS-Microformats – Trennung von Form, Form, Form und Inhalt

Chris_ — Fri, 30 Jun 2006 08:55:43 +0000

Diesmal gibt es ein kleines Vorwort. Der folgende Text hat sich in Minuten vom absoluten Krampf, zu einem Eintrag entwickelt, der die Veröffentlichung hoffentlich wert ist. Ich bitte daher zu entschuldigen, wenn sich das Ganze noch sehr sinnentleert liest, dieser Text war lange Zeit ohne echte Substanz, da ich kein Freund von zu viel Sorgfalt beim Bloggen bin, geht das hier so ungefärbt online. Das ist also mal ein Schnellschuss zum Ende der Woche.

Ich habe die HTML Struktur dieser Version, mal zur Abwechslung mit größerer Sorgfalt angelegt. Waren die früheren Versuche noch Markups, jeweils für die individuelle Version, so hoffe ich diesmal eine länger haltbare Basis gefunden zu haben. Ich möchte versuchen, das Ganze am Beispiel zu erklären. Auch wenn es nun mittlerweile Standard geworden ist Form und Inhalt zu trennen, so gibt es auch dafür, mehr als eine Möglichkeit der Umsetzung.

Ich weiß selbst noch nicht genau, ob der Text den Eintrag wert ist. Vielleicht ist es die Fortsetzung der Raster-Tutorials, vielleicht auch nicht. Die Geschichte dahinter liest sich wie folgt: ich komme immer wieder in die Situation, bei der ich unsicher bin, auf welches HTML-Element, die später zu formatierende CSS-Klasse oder ID gehört. Wo ist diese ID nun logischer? Bei welcher Lösung habe ich später mehr Möglichkeiten? Die Antwort auf alle Fragen, beantwortet mir meist der Quellcode dieser Startseite hier. Ich denke hier eine relative flexible HTML/CSS-Struktur gefunden zu haben, die sich auch gut skalieren lässt und nicht nur für so ein paar Inhaltseiten funktioniert.

Wer die Entwicklung dieser Gestaltung von Anfang an verfolgt hat, wird mitbekommen haben, wie oft und schnell ich die vielen Listen auf der Startseite neu angeordnet habe. Genau das begründet sich auf der Markup-Struktur der Seite, in Kombination mit einer sehr effizienten Verteilung von CSS-IDs und Klassen. Ich mag es schnell auch kompliziertere Elemente neu positionieren zu können, auch deshalb wurde diese Listen speziell dafür optimiert, besonders in Hinsicht auf ihre Struktur Markup.

Praxis

Grundlage für die Arbeit am Quellcode dieser Seite, war wie auch bei der Gestaltung, das Grundraster. Folgende Tabelle ist erste Anlaufstelle, wenn ich ein neues inhaltliches Element in die Seite integrieren möchte.

1 Spalte	2 Spalten	3 Spalten	4 Spalten
244 Pixel	488 Pixel	732 Pixel	976 Pixel
224 Pixel	488 Pixel	732 Pixel	976 Pixel
204 Pixel	204 Pixel	204 Pixel	204 Pixel

Hier zu sehen, Kenndaten um Elemente auf dem Raster zu positionieren. Diese Tabelle beinhaltet alle wichtigen Größen um alle Spalten des Raster abdecken zu können. In weiser Voraussicht, existieren auch schon Werte für eine mögliche 4-Spalten Version, bei einer 1024 Pixel breite Darstellung.

Alles noch recht unspektakulär, aber diese kleine Tabelle beinhaltet alles was notwendig ist um schnell, einfach und pixelgenau die Listen neu anzuordnen. Es ist problemlos möglich alle nur erdenklichen Listenformate, auf dieses Raster zu bringen. Wer sich etwas mehr umschaut, wird auch sehen, dass die Listen hier und da in ein anderes Format wechseln und das mit ganz geringem Aufwand. Ein Ausschnitt des Quellcodes zeigt diesen Aufbau:


Letzte Kommentare

...

An dieser Stelle die erste Überlegung. Wäre es nicht vielleicht sinnvoller, der Liste die ID zu geben und nicht extra dafür eine DIV anzulegen? Nun ja eigentlich wär dies die Puristen-Lösung, für all jene, die jedes zusätzliche DIV-Element meiden, wie Vampire das Licht. Zwar gehöre auch ich zu den sehr nihilistischen HTML-Codern, aber für meine Seite ist diese Lösung perfekt. Warum?

ein kleiner Schritt zurück

Ein Blick zurück in den zweiten Teil des Raster-Tutorials. Eine Aussage dieses Textes ist, dass ich jedes Element auch auf dieses Raster passend, floaten lassen kann. Mit dieser Erkenntnis sind nun alle Listen auf dieser Seite gleich formatiert: alles fließt und passt. Jede Liste hat ihr eigenes mit einer ID versehenen DIVs. Nun braucht man sich, beim Blick auf das Stylesheet dieser Seite, nicht mehr über solche ellenlangen Aufzählungen wundern:

/*    globale Listenformate
=========================================== */
#lastComments,
#last10,
#qlinks,
#adverts,
#archive,
#themed,
#footcategory,
#prenextBottom,
#mostComments,
.sideDetail,
.side-caption  {
width:244px;
float:left;
margin-left:0;
display:inline;
}

#lastComments ul,
#qlinks ul,
#last10 ul,
#archive ul,
#themed ul,
#footcategory ul,
#mostComments ul {
padding:0;
list-style-type:none;
margin:0;
width:224px;
float:left;
display:inline;
}

#lastComments ul li,
#last10 ul li,
#qlinks ul li,
#archive ul li,
#themed ul li,
#footcategory ul li,
#mostComments ul li {
font-size:90%;
margin-left:20px;
width:206px;
float:left;
display:inline;
padding-left:18px;
}

Hier passieren nur ganz grundsätzliche Sachen, nichts Spannendes. Dennoch sieht man hier die Grundlage für jede Liste dieser Seite. Die DIVs dienen mir nun ausschließlich dazu, die Listen hin und her zu schieben und ihre Layout zu verändern. Man kann drüber streiten, ob es der Logik entspricht, Element so indirekt zu formatieren, denn ich definiere diese Listen primär über ihren Container und führe so einen einen gewissen Teil überflüssigen CSS-Code mit. Die separaten Anpassungen der jeweiligen Liste, überschreiben nämlich die oben dargestellten Formate. Wenn die Archivlisten plötzlich über 3 Spalten fließen sollen, muss ich die Breiten ändern:

#archive,
#archive ul {
width:732px;
}

Dennoch hat es mehr Vorteile als Nachteile, vorher eine globale Formatierung vorzunehmen und diese dann individuell anzupassen. Selbst ohne die individuellen Formate, sitzen diese Elemente perfekt auf dem Raster und durch diese Struktur ist der Aufwand viel geringer Änderungen vorzunehmen.

Wer sich die Raster-Tutorials durchgelesen hat, wird feststellen, dass ich für Floats auf einem Raster, Probleme ergeben können. Dies ist auch hier der Fall. Ich werde nun nicht im Detail aufzeigen wo, wie und was auch hier schief läuft. Man soll ja immer seine Schokoladenseite offenbaren und nicht die dreckigen Ecken. Nur soviel, hier und da kommt mal ein Spaltenzwischenraum hinzu und muss mal wieder vom der Floatbreite subtrahiert werden. Wer sich die Tabelle oben anschaut erkennt schon das Problem, auch hierbei helfen mir die zusätzlichen DIV-Elemente.

Stylesheet Format

Es gibt zweifellos die Möglichkeit diese jetzige Code-Struktur effektiver anzuordnen. Auch hier bin ich nicht auf der Jagd nach einzusparenden Bytes, sondern nach Logik und Handling, wie es so schon neudeutsch heißt. Ich weiß wie gern ich kleine Veränderungen benutze, also lege ich diese Seite auch darauf an.

Sicherlich wäre es platzsparender statt:

#lastComments ul,
#qlinks ul,
#last10 ul,
#archive ul,
#themed ul,
#footcategory ul,
#mostComments ul {
....
}

eine neue alles beinhaltende DIV zu generieren und dann ganz einfach so zu stylen:

#ganzNeueDIV ul {
....
}

Um das Ganze noch dynamischer zu machen wären IDs und Klassen auf den Listen an sich ebenfalls vorstellbar. So könnte ich das absolut gleiche Ergebnis, mit weniger Code erzielen:

#ganzNeueDIV ul#lastComments {
....
}

Dennoch bleibe ich bei der jetzigen Variante, die auf den ersten Blick aufgeblähter und weniger optimiert wirkt, aber auf den zweiten Blick und spätestens beim Redesign ihre vollen Stärken offenbart. Ich sehe immer wieder Beispiele (ich werd mich hüten Links zu setzen, zu viele Referer-Dramen in der letzten Zeit), wo durchaus ansprechende Gestaltung präsentiert wird, das Ganze jedoch auf wenig dynamischen Code-Strukturen basierend. CSS ID und Klassen-Monster, die zu Handhaben es einen wahren Zeichendeuter braucht. Ich verstehe dabei natürliche den Sinn bei Auftragsarbeiten, leichter als durch wenig transparente und komplexe Code-Strukturen, kann man den Kunden nicht an sich binden.

CSS + Microformats = CSS-Microformats?

Zwar erscheint in jedem zweitem meiner Texte, der große Hammer mit der Aufschrift „Weniger ist mehr!“, aber wie man sieht, kann etwas mehr manchmal doch auch seine Vorteile haben. Ich hab mich die letzten Wochen verstärkt mit Mikroformaten beschäftigt, eine höchst interessante Angelegenheit und mit Sicherheit der nächste große Zug, auf den viele aufspringen werden. Für alle die nicht wissen was Mikroformate sind, versuche ich es kurz zu erläutern.

Microformats are markup that allow expression of semantics in an HTML (or XHTML) web page. Programs can extract meaning from a standard web page that is marked up with microformats.

Existing XHTML (and HTML) standards allow for semantics to be embedded and encoded within them. This is done using specific HTML attributes:

class

rel

rev

Adding microformats to a standard HTML web page allows machines to process HTML text and to possibly load data into remote databases. This would allow programs such as web crawlers to find items such as contact information, events, and reviews on web pages.

Man stelle sich eine neue Norm vor, die vorschreibt wie man Informationen innerhalb zu strukturieren hat. Diese Norm sind Mikroformate. Vorteil dabei? Informationen werden universell und denoch zugänglicher. Beispiel: wenn ich eine heute bei Google nach einer CD Kritik suche, gebe ich meist den Interpreten, den Titel und das englische Wort für Rezension „Review“ ein. In vielen Fällen kommt dabei Unbrauchbares zu Tage. Nun gibt es genau dafür schon ein Review-Mikroformat, welches mit absoluter Sicherheit bessere Suchergebnisse liefern würde als Google, sofern ein Microformats-Google existieren würde.

div#reviews ul, ul#reviews, ul li.reviews, ul li a.reviews …

Im gewissen Rahmen habe ich kleine Mikroformate, so genannte Nanoformate /joke, für den CSS-Code dieser Seite geschaffen, mit eben den gleichen Vorteilen wie bei Mikroformaten. Ich muss nicht schauen welche ID, welche Klasse oder wie der Code an dieser Stelle ist. Es gibt ein festes CSS-Format, welches mir die Arbeit ungemein erleichtert. CSS Stylesheets können schon heute unglaublich komplex werden und mit Sicht auf CSS-3, wird sich das auch nicht mehr ändern. Zeit darüber nachzudenken auch hier feste Formate zu entwickeln? Ich für meine Arbeiten beantworte diese Frage mit ja. Für viele mag dieser „Ansatz“ trivial sein, für mich ist er relativ neu und die Überlegung wert, sorgfältig weiter entwickelt zu werden.

Feedback: 3 Kommentare