Das Tutorial zum Balkendiagramm gehört zu den stillen Klickfallen der Seite. Über Google kamen dann doch mehr Besucher auf die Seite, als gedacht. Ein Kommentar hat das Thema wieder aktuell werden lassen und ist für mich Anlass, das Thema mal zu überarbeiten. Ich präsentiere Balkendiagramm 2.0 oder so ähnlich.

Ich bleibe bei der HTML-Struktur. Eine Definitionsliste bietet sich hier mehr an, als eine normale Liste, die ich bei anderen Lösungen oft sehe. Es gibt allerdings vor und Nachteile, besonders mit Blick auf Internet Explorer, der jedoch schneller und schneller an Popularität verliert. Eine Definitionsliste hat den großen Vorteil gleich zwei HTML-Tags für einen Wert zu bieten. In einer normalen Liste wird zusätzlich oft mit spans-Tags gearbeitet, um mehr Struktur zu bekommen. Eine dl-Liste braucht sowas nicht. Der große Nachteil lässt sich aber nicht verschweigen. In einer dl-Liste existieren zwar zwei separate Tags, aber diese sind nicht logisch miteinander vom Rest der Liste abgetrennt. Kein Problem für moderne Browser, aber IE kommt wieder und wieder durcheinander, wenn man einzelne Elemente der Liste floatet. Wenn ich Vor- und Nachteile abwiege, bleiben klar mehr Argument für eine dl-Liste übrig. Drum ändern sich am HTML fast nichts.

“D’oh”

Der größte Makel meiner bisheringen Lösung war der Unterschied zwischen echtem Wert der Liste und Breitenwert des HTML-Elements. Wenn ein Element einen Wert von 89% darstellen soll, dann sollte es auch 89% breit sein. Alles andere ist unlogisch und war nur ein Herumarbeiten um das eigentliche Problem. Dieser Makel ist nun behoben. DD-Tags sind nun so breit, wie der Wert den sie darstellen sollen.

<dl class="data-1">
<dt>Wert 1</dt>
<dd style="width:46%;">46%</dd>

<dt>Wert 2</dt>
<dd style="width:24%;">24%</dd>

<dt>Wert 3</dt>
<dd style="width:89%;">89%</dd>

<dt>Wert 4</dt>
<dd style="width:62%;">62%</dd>

<dt>Wert 5</dt>
<dd style="width:29%;">29%</dd>

<dt>Wert 6</dt>
<dd style="width:81%;">81%</dd>

<dt>Wert 7</dt>
<dd style="width:41%;">41%</dd>

<dt>Wert 8</dt>
<dd style="width:72%;">72%</dd>

<dt>Wert 9</dt>
<dd style="width:19%;">19%</dd>

<dt>Wert 10</dt>
<dd style="width:56%;">56%</dd>
</dl>

Zweites Problem war bisher der mögliche Platz für das Label. Hier habe ich zwei Fliegen mit einer Klappe erwischt. Zum einen sind Label und Wert nun so positioniert, dass sie völlig (fast) unabhängig voneinander positioniert werden, was zum Zweiten dem Label endlos viel Platz verschafft.

Die Details sind wichtig, aber es sind wenige. Label (dt) und Wert (dd) sind nun übereinander positioniert, Z-Index sei Dank. Trickreich ist nur eine Sache und zwar die Einrückung der Schrift des Labels, zwar im CSS dokumentiert, aber hier noch exlizit erwähnt. Linker Margin-Wert und Breite des dt-Elements, entsprechen summiert dem negativen linken Margin des dd-Elements. In meinem Beispiel sind es 25% (24% width + 1% margin-left). Die Prozentzahlen zeigen es schon, das Diagramm skaliert mit der Breite einer Seite mit.

Es existiert noch ein winziger Fehler, oder vielleicht sogar zwei. Border und padding des dd-Elements fügen dem Wert ein paar Pixel in der Breite hinzu, die kombiniert mit dem darzustellenden Wert, immer ein paar Pixel mehr darstellen, als eigentlich richtig wäre. Ich nenne es mal “künstlerische Freiheit” und effektiv sind es in meinem Beispiel jeweils 6 Pixel zu viel, ein Wert der zu verschmerzen ist.

CSS3

So ein Diagramm schreit förmlich nach neuen CSS3 Werkzeugen. Neue Pseudo-Selektoren lassen jeden einzelnen Wert im Diagramm adressieren, ohne zusätzliches HTML in die Liste zu schreiben. Optisch lassen sich abgerundete Ecken, wie auch Verläufe integrieren.

Solide

Schaue ich mir alle Fehler und Stärken der Lösung an, komme ich zu einem sehr soliden Ergebnis. Das HTML ist sehr sauber und entspricht der Semantik einer Definitionsliste, der Fehlerquotient liegt im Rahmen, es gibt genug Freiheiten für CSS und die Lösung skaliert relativ gut auf gängigen Browsern. Es soll nur ein Vorschlag sein, einer der sich wunderbar erweitern lässt, um seine Schwächen auszumerzen. Ideal wäre ein zusätzliches Tag im dt-Tag, um den Inhalt absolut zu positionieren, relativ zum dt-Tag. So bekommt man völlige Freiheit bei Länge der Label und Relation zum darzustellenden Wert. Lange Labels für kleine Werte sind ein Problem, dass sich so lösen lässt.

Feedback: 0 Kommentare

Dynamische Gestaltung existiert online seitdem es Javaskript gibt. Spätestens seit jQuery ist es nicht mehr unüblich, ein wenig Intelligenz in die Schnittstelle zwischen Nutzer und Inhalt zu basteln. Zeit Online zeigt dem Neuanstrich, dass solche Ansätze wohl auch bereit für ihren großen Auftritt sind. Ich finde damit öffnet sich die Büchse der Webdesign-Pandora, doch einen winzigen Spalt breit. Plötzlich ist es nicht mehr unrealistisch auch abseits des Browserhacks, für mehr als einen möglichen Fall zu gestalten.

Bin gespannt, wie der weitere Weg hier aussehen wird. Für diese Lösungen gibt es definitiv ein Problem, nur sucht man es derzeit noch mit der Lupe. Klar ist, dass man solche Lösungen klar am Anfang planen muss. Ein trendmäßiges Draufklatschen skalierender Elemente auf ein bestehendes Design, dürfte der falsche Weg sein, auch weil man sein CSS um einen solchen Ansatz strukturieren muss. Welche Eigenschaften kommen zum Element, welche zur ID und welche zur Klasse?

Bisher nehme ich eher Abstand von flexiblen Layouts. Bisher bedeutete dies alle Elemente mit relativen Größen zu bemaßen und dann alles hübsch schrumpfen und wachsen zu lassen. Damit ein Grundraster einzuhalten, ist sehr schwierig. Jene 2-Phasen Skalierung wiederum, lässt viel präziseres Planen zu und somit sind auch Raster wieder einzuhalten. Ein paar Dinge habe ich schon getestet, um eine möglichst elegante Lösung zu finden. Mein Ansatz ist das Zuweisen bzw. Entfernen von CSS-Klassen auf den jeweils zu verändernden Elementen, hier eine Testseite dafür.

Abbildung auflösungsabhängiger Layouts. Links die schmale und rechts die breite Variante.

Die Umsetzung ist einfacher als vermutet. jQuery überprüft die Fenstergröße, weist je nach Ergebnis eine entsprechende CSS-Klasse zu und wechselt diese, wenn auch das Fenster seine Größe verändert. Alles Nötige steckt in diesen Zeilen. In meinem Beispiel bekommt die Div mit der ID “content” je nach Auflösung eine unterschiedliche zusätzliche Klasse. Schlüsselwert ist die Horizontale des Browserfensters. Bei weniger als 1096 Pixeln wird die CSS-Klasse “schmal” zugewiesen und die Klasse “breit” entfernt. Sind die 1096 Pixel vorhanden, werden die Klassen ausgetauscht.

$(document).ready(function() {
    function elementResize() {
        var browserWidth = $(window).width();
        if ((browserWidth) < '1096'){
           $('#content').addClass('schmal');
           $('#content').removeClass('breit');
        } else {
           $('#content').addClass('breit');
           $('#content').removeClass('schmal');
        }
    }

    elementResize();

    $(window).bind("resize", function(){
        elementResize();
    });
});

Worin liegt der Unterschied zwischen der Verwendung relativer Größen und dieser Lösung? Man behält hier die volle Kontrolle über jeden einzelnen Pixel, allerdings auf Kosten eines zusätzlichen CSS-Wasserkopfs. Es entstehen zwei Varianten, die beide komplett durchgestaltet werden möchten. Ganz klar findet man auch hier kein Allheilmittel für sämtliche möglichen Problemfälle, aber ein wirklich effizientes Werkzeug, um ein Layout ein Stückchen mitdenken zu lassen.

Das CSS3 Spalten-Modul bietet hierfür sicherlich große Angriffsfläche. Mehrspaltigkeit setzt voraus, dass man den Text auch ohne zu scrollen komplett lesen kann. Dafür braucht es nun mal eine bestimmte Auflösung, die man mit so einem kleinen Skript effektiv auch kleineren Formaten zugänglich machen kann, ohne das die Typografie aus dem Ruder läuft. Falls ich mich auf der eigenen Seite mal satt gesehen habe, sehe ich gute Chancen auch mal auf so eine Lösung zu setzen.

Feedback: 0 Kommentare

Statt einen riesigen Text mit Details vollzustopfen, die nur einen Bruchteil der Leser interessieren, pflücke ich das Ganze etwas auseinander. Heute möchte in ein paar Worte zum Raster und zum Kopf der Seite verlieren. Das Grundraster ist nur eine Erweiterung des alten Rasters. Man muss sich vor Augen halten, dass diese Gestaltung einmal für eine Auflösung von 800x600 Pixeln vorgesehen war, was erklärt, wieso in einigen alten Artikeln, die Bilder so winzig sind. Losgelegt habe ich hier einmal mit einer Hauptspalte von 468 Pixeln. Auf dieser alten Bildbreite basiert heute noch das Raster, was schließlich nun aus 18 Spalten mit je 41 Pixel Breite und einem Spaltenabstand von 20 Pixeln besteht. In dieses Raster passen alle alten Inhalte und ich habe genug Spielraum, um alles völlig variable zu platzieren. Keine Allround-Lösung, aber meine Lösung für diese Seite.

Ein Wort zum Grundlinien-Raster. Grundlinien-Raster ist eines dieser Schlagworte, die sich in der Praxis nicht 100% umsetzen lassen. Spätestens wenn Bilder den Float in eine halbe Zeile zwingen, brechen alle folgenden Elemente aus dem Raster. In Frage käme alle Bilder in der Höhe passend zu bemaßen, aber da rechtertigt der Aufwand niemals den Nutzen. Auf dieser Seite passiert zuviel Ungewöhnliches, um ein Grundraster wirklich konsequent durchzuziehen.

Kopfelement

Der Kopf hat hier schon eine sehr durchlebte Vorgeschichte. Selbst bei der vorherigen Version brauchte es 3 verschiedene Ansätze, bevor schließlich gefunden war, was sich ein gutes Jahr bewährt hat.

Kopf der vorherigen Version, der damals auch schon mehrfach verändert wurde.

Die alte Version hat für die Startseite selbst gut funktioniert, für eine einzelne Inhaltsseite aber weniger gut. Wenn ich gar eine einzelne Seite individuell gestaltet habe, war der Kopf immer viel zu dominant und wirkte deplaziert. Dies musste ich ändern. Der Kopf sollte so neutral wie nur möglich sein, ohne aber jemals als Kopf ignoriert zu werden. Essentiell war, endlich die Teaser-Bildchen angemessen darzustellen und obendrein musste alles noch so rund wirken, dass es auf jeder Ebene der Seite funktioniert.

Die Größe und Position dieser ganz wenigen Elemente im Kopf so festzulegen wie sie jetzt dargestellt werden, hat praktisch die längste Zeit der Gestaltung in Anspruch genommen. Ich habe irgendwann aufgehört zu zählen, bei welchem Versuch ich nun war. Bis schließlich dies hier zu sehen war:

Was übrig bleibt sind wirklich nur Elemente, die ich hier für essentiell halte. Warum dieser Kasten oben links? Gleichgewicht zum Teaserbild und Überbrückung zum Logo. Ohne diesen Kasten entsteht da ein Loch auf der Startseite, dass einfach nicht funktioniert.

Logografik

Zuvor hatte ich das Problem das Kopfelemente auf verschiedensten Hintergründen funktionieren müssen. Dafür brauche ich logischerweise auch mal die Negativ-Version des Logos, vorher eine separate Grafik. An diesem Punkt möchte ich auch betonen, dass hier nur ein echtes 24-Bit PNG in Frage kommt. Gerade für diese Zwecke ist dieses Format perfekt.

Diesmal wollte ich alles richtig machen und habe eine einzige Grafik erstellt. Die beinhaltet alle benötigten Tonwerte, welche dann am Schluss mit CSS in die richtige Position gerückt werden. Klingt komplizierter als es ist. Wichtig ist nur eine einzelne Grafik und ein wechselnder CSS-Wert lassen das Logo auf wirklich allen Hintergründen funktionieren. Unter dem Begriff CSS Sprites findet man dazu endlos viele Tutorials. Statt halt alle möglichen Grafiken separat zu laden, packt man alle in ein großes Bild und positioniert dieses, so wie man es braucht.

Feedback: 2 Kommentare

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:

1. Dokument beginnt zu laden
2. .js-Klasse wird HTML-Tag zugewiesen
3. CSS-Klasse greift somit und versteckt das gerade geladene Element
4. Dokument ist fertig geladen und strukturiert
5. .js-Klasse wird entfernt
6. 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

Wieder ziemlich viel gelernt beim Machinist-Eintrag, was WordPress und CSS betrifft. Wie üblich waren eigentlich nur die Details schwieriger. Ich glaube es war an der Zeit mal mehr auszuprobieren. Gleichzeitig habe ich jedoch auch aus dem Wechsel von Movable Type zu WordPress gelernt, wie wichtig es ist, Daten möglichst neutral zu halten, skalierbar, importierbar…

Drum mein Ansatz auch diesmal, Änderungen Ja mit einem dicken Aber hinterher. Ziel ist es, jeden noch so individuell gestalteten Eintrag, auch ohne seine eigenen Änderungen, also mit den Standard-Formaten, funktionieren zu lassen. Grundlage dafür ist, sämtliche Änderungen der Optik, fern vom WordPress-Backend zu halten. Kein Skript und kein CSS soll mit dem Inhalt vermischt werden.

Schon jetzt löse ich diese kleinen Bildchen bei neuen Einträgen mit WordPress’s Customfields/Spezielfeldern. Diese kleine versteckte Option beim Schreiben neuer Einträge. Damit ist es möglich, Einträgen zusätzliche Daten zu verpassen und diese an beliebiger Stelle abzufragen. Dafür reichen sogar meine sperlichen PHP-Kenntnisse.

Um also einem Eintrag ein individuelles Stylesheet zu verpassen, habe ich eine neue Variable generiert. Diese lautet ‘entry_css’ und dafür existiert nun auch ein Custom-Field im Backend von WordPress:

Spezialfelder im WordPress-Backend

Jetzt gilt es, diese Variable im Template zu testen, abzufragen und entsprechend für Fall-X, den gewünschten HTML-Code einzufügen. Die Variable entry_css soll überprüft werden und im Fall eines entsprechendes Eintrags soll anschließend ein Stylesheet geladen werden. Stylesheets werden im head-Tag der Seite geschrieben, also das Header-Template rauskramen und diese wenige Zeilen einfügen:

[RAW]
<?php // teste entry-css
    $entrycss = get_post_meta($post->ID, 'entry_css', $single = true); ?>
<?php if($entrycss !== '') { ?>
<link rel="stylesheet" href="<?php echo get_option('home') ?>/archiv/entry-styles/<?php echo $entrycss?>.css" type="text/css" media="all" />
<?php } else { echo ''; } ?>
[/RAW]

Der Zauber findet in Zeile 2 und 3 statt. Zeile 2 generiert eine neue Variable Namens ‘entrycss’, dafür liest es das Custom-Field ‘entry_css’ aus, aber auch nur, für den Fall, den WP als Single-Archive definiert. Einfach ausgedrückt, ich brauche dieses Stylesheet nur, wenn die Seite allein betrachtet wird. Diese Aufgabe übernimmt dieses kleine $single = true in der zweiten Zeile. Zeile 3 wiederrum leitet eine kleine if-Abfrag ein. Ich brauche den zusätzlichen HTML-Code nur, wenn ‘entrycss’ einen Wert enthält. Findet die Abfrage einen Wert, wird Zeile 4 ins Template geschrieben. Falls ‘entrycss’ leer ist, wird auch nichts Zusäzliches ins Template geschrieben (Zeile 5).

Die vorherige Lösung, sah vor, dem body-Tag jeweils eine andere ID zu geben und diese in solch ein Spezial-Feld zu schreiben. Allerdings ist man damit recht unflexibel und schreibt endlos viele Styles in das Standard-Stylesheet. Damit geht nach kurzer Zeit die Übersicht komplett flöten und man findet zu einer Klasse/ID dutzende verschiedene Formate. Keine gute Lösung und drum lieber ein separates Stylesheet. Das war schon alles an Vorarbeit, der Rest ist Gestaltung.

der eigentliche Aufwand - Gestaltung

Der Gestaltung geht immer erst die Erfassung vom Inhalt vorraus. Im Falle von The Machinist, war es schon eine Weile her, dass ich den Film gesehen habe, also DVD einlegen, Bierchen holen, Film genießen und Notizen machen. Meistens notiere ich mir ein paar wichtige Zeit-Marker im Film (um später schneller Bilder zu finden), Zitate und erste kleine Denkansätze, was man wie formulieren könnte.

Das reine Schreiben der Texte, erstreckt sich meist über mehrere Tage. Je nach Lust und Zeit. Manchmal fließen die Wörter und manchmal eben nicht. Steht der Text, habe ich einen Überblick über den Umfang. Bilder werden oft immer ganz zum Schluss gemacht, das ist so ziemlich das Unangenehmste an der ganzen Prozedur.

Lange Zeit sah die Überschrift so aus. Ebenfalls zu sehen, ein Versuch die Pullquotes wieder mit einer Serifen-Schrift zu setzen. Passte aber nicht wirklich zum Rest der Seite und wurde deshalb ersetzt.

Ist der Text erfasst und die Bilder vorbereitet, kann ich mir Gedanken, über das Layout machen. Ich bin kein Vorreiter, was Individualisierung einzelner Seiten im Web betrifft. Da waren schon viele vorher dran. Gemeinsamkeiten sind jedoch sofort erkennbar. Bei fast allen Beispielen bleibt das Grundrastergleich. Variation findet man primär bei:

• Schriften
• Farben
• Position der Elemente auf dem Raster (wobei sekundäre Elemente nicht varrieren)

Dieses Beispiel brachte so ziemlich gute Vorrausetzungen mit. Die Optik des Films bietet sich zu sehr an. Was fehlte war ein passendes Hintergrundbild. Stock.XCHNG bietet hier eine sehr große Auswahl an Bildern, die kostenlos für solche Zecke wie meinem, genutzt werden können. Nach wenigen Minuten waren mehr tolle Bilder gefunden, als ich verwerden konnte.

So oder so ähnlich sieht mein Dokument aus, dass alle gesammelten Bilder für die Gestaltung enthält. Wenn ich hier was Interessantes finde, dann definiert sich daraus automatisch die Farbigkeit und auch die Typografie. Der Rest ist Finden und Ausfeilen von Details.

Die Bilder landen im Bildbearbeitungsprogramm, bis ich einen optischen angenehmen “Haken” für die Seite finde. Daraus entwickeln sich ein paar kleine Skizzen auf Papier, um dann im Indesign deren Funktion zu testen. Das klappt erstaunlich gut bisher. Die Bilder lassen sich leicht rüberziehen und platzieren, während ich gleichzeitig die Schrift zum Bild testen kann. Einziger Haken ist die Darstellung oder genauer gesagt die Größe. Für Indesign sind halt alle Elemente skalierbar und so sieht entsprechend die Darstellung aus, für meinen Zweck jedoch, funktioniert es.

Farbigkeit, Details und Stolperfallen

Mit heller Schrift auf dunklem Hintergrund ist gute Lesbarkeit schwieriger zu erzielen. Trickreich ist ein angenehmer Kontrast und die richtige Schriftgröße. Im normalen Stil, hat meine Schrift eine Größe von 12 Pixeln. Bei umgekehrtem Kontrast, erschien mir die Lesbarkeit mit 12 Pixeln einen Tick zu klein. Es mag nur 1 Pixel sein, aber dieser sorgt für deutliche angenehmere Lesbarkeit. Ein weitere winzige Änderungen ist die Laufweite bei heller kursiver Schrift auf dunklem Grund. Hier habe ich im CSS einen Tick (einen halben Pixel im genau zu sein und ja das funktioniert) den Abstand zwischen den Buchstaben (letter-spacing) erhöht.

Den Trailer direkt am Anfang zu zeigen funktioniert eigentlich relativ gut und wird sicherlich in einem anderen Beispiel Anwendung finden.

Der Kopf bzw. die Überschrift hat auch knapp ein Dutzend Versionen gesehen. Irgendwie erschien mir keine wirklich passend. Wenn schon, denn schon, also mal was ganz anderes. Weg mit der Übrschrift und rein mit einem Bild. Die Schrift ist per CSS nur mikroskopisch verkleinert und trägt eben jenes Titelbild des Films, als Hintergrundgrafik.

Zweispaltigkeit war kurze Zeit ein Thema. Mit aktuellen CSS-Methoden jedoch, ist hier schlicht nichts zu gewinnen. Man schreibt den Text für’s Layout und nicht umgekehrt. “Ich habe X-Anzahl von Wörtern, für diesen Absatz.” Lösung wäre, einen langen Absatz zu schreiben, dann allerdings scrollt man wie blöd und ohne passendes 2-Spalten-CSS, wäre die Lesbarkeit unterirdisch. 2-Spalten kommen, wenn der Text es zulässt. Der Machinist-Text war nah dran, aber eben noch nicht nah genug. Spalten bleiben ein Thema, aber hier hat es noch nicht geklappt.

4 Absätze gefloated. Leider funktioniert ein CSS-Fluss nicht so wie unser gewohnter Lesefluss. Um einen solchen zu erziele brauch es entweder zusätzliches Markup oder perfekt aufeinander bemaßte Absatzlängen. Für besser funktionierende Text-Spalten, muss man wohl auf CSS3 warten.

Das Bild zur Überschrift war eine späte Idee, die schließlich auch jetzt zu sehen ist. Das Bild in diesem Beispiel war farblich perfekt. Hier auch zu sehen, nochmal die zwei Spalten im Text. So wäre es geblieben, wenn nur diese Spalten einfacher und sinnvoller zu beherrschen wären.

Pullquotes, sIFR und die Folgen

sIFR steht für salable Inman Flash Replacement und ist sicherlich die bisher effektivste Lösung, jeden beliebigen Font auch auf einer Website darzustellen, unabhängig davon, ob dieser auf dem Rechner des Nutzers ist. Man erstellt ein Flash-Filmchen der die Schrift enthält. Ein Javaskript schaut dann, welches HTML-Element für sIFR bestimmt ist, versteckt dieses mit CSS und ersetzt es mit dem Flash-Film, der den Text des HTML-Tage bekommt.

Pullquotes mit sFIR, leider mit zu vielen Einschränkungen.

sFIR funktioniert eigentlich auch wirklich gut. Mir machte es kleine Sorgen, weil ich 1) sFIR nur auf dieser Seite nutzen möchte und 2) der Aufruf des Javaskripts nicht im Template oder im Inhalt der Seite stehen soll. Somit rufe ich sFIR und alles was dafür nötig ist, auch über solch ein Spezialfeld auf. Dafür gibt es eine neue Variable, die den Namen des Javaskripts trägt. Findet das Template diesen Wert, lädt es alles, was sIFR so braucht. Für den Fall, wieder auf ein Standard-Design wechseln zu wollen, nehme ich den Aufruf der zusätzlichen Variablen raus und weder zusätzliches Stylesheet noch sIFR-Daten werden geladen.

sIFR nutze ich im ersten Beispiel nur für die Zwischenüberschriften (H3). Eigentlich sollten auch die Pullquotes mit dieser Schrift ersetzt werden, aber leider erlaubt mir CSS hier noch mehr Optionen als sFIR. Was im HTML mit einem em-Tag makiert und mit CSS leicht anders gefäbrt ist, als der Rest dieses Elements, lässt sich so nicht bzw. nur sehr schwer mit sIFR realisieren. An dieser Stelle hab ich deshalb auf die Flash-Lösung verzichtet und der HTML-Variante dem Vorzug gegeben. Premiere hat dabei der Lucida-Font auf dieser Seite. Lucida ist immer noch ein Tabu, denn noch immer statten viele Seiten, damit in winzigen Größen ihre Mengentexte aus und schauen sich das Ganze wohl nicht mal auf einem PC an. Lucida ist in kleinen Größen der Erzfeind von Windows ClearType-Technologie.

Die Pullquotes an sich haben bestimmt ein knappes Dutzend verschiedene Gestaltungen gesehen. Einige davon finden sicherlich den Weg in kommende Einträge. Auch wenn sFIR an dieser Stelle irgendwie versagt, finde ich es sehr einfach in der Anwendung und ideal auch für meine Seite hier.

das Wichtigste zum Schluss

Auch wenn alles irgendwie länger gedauert hat, es war die Mühe wert. Ich hatte durchaus Spaß am Schreiben und Gestalten. Auch deshalb wird dies nicht der letzte Eintrag seiner Art sein. Ein neuer ist schon fertig geschrieben (deutlich kürzer im Umfang) und wartet drauf jetzt den richtigen gestalterischen Haken verpasst zu bekommen. Hab diesmal noch nicht das Richtige gefunden.

Im ersten Versuch ist schon alles drin was ich drin haben wollte: großformatige Bilder, transparente PNGs, Flash-Fonts mehr Details bei den Pullquotes. Auch ist alles schön separat geblieben. Wenn ich mal wieder die Seite grundlegend ändern möchte, muss ich nich manuell im Inhalt stehende Klassen, IDs oder Skripte entfernen. Es ist auch gelungen, die Seite weiterhin validiert zu sehen

Ich glaube auch, dass sich der zusätzliche Aufwand lohnt. Sofern man hier einmal einen richtigen Workflow gefunden hat, hält einem nur die eigentliche Idee auf, aber das ist überall der Fall, nicht nur in diesem Medium. Anzumerken sei vielleicht noch, dass solch eine Gestaltung weder den reinen Gestalter, noch den reinen Programmierer verlangt, sondern irgendeine gute Mischung aus beidem. Man muss wissen, was im Rahmen von HTML/CSS/Flash möglich ist und was nicht und dies ganz gezielt beim praktischen Gestalten beachten. Auch im Web wachsen die gestalterischen Bäume nicht in den Himmel, höher als in anderen Medien aber durchaus. Textlich gibt es Einschränkung, die man halt so gut wie möglich ausgleichen muss. Es wäre wünschenswert wenn auch abseits der privaten Blogs, mehr Abwechslung dieser Art zu finden wäre.

Feedback: 3 Kommentare

Via Codecandies konnte ich diese durchaus lesenswerte Frage beantwortet bekommen: Grid-Layouts – das neue Tabellenlayout? Ich komme nicht herum, hier meinen Blickwinkel festzuhalten. Für meinen Geschmack nähert sich der Artikel, dem Thema aus einer ungünstigen perspektive: des Programmierers. Grids oder Raster, sind ein Werkzeug zur Gestaltung. CSS ist der Buntstift des Webdesigners. Vorgefertigte Grid-Lösungen wie Yahoo’s oder Blueprint, sind jedeglich Mahlen nach Zahlen.

Raster sind ein Konzept, dass vielen Anfängern sicherlich zu uneffektiv erscheint. Statt die eigene CSS-Lösungen zu entwickeln, setzt man auf die schnelle vorgefertigte Lösung. Grids sind nicht Blueprint.

Richtig ist, dass eine rasterbasierte Gestaltung, auch im CSS mehr Arbeit bedeutet, für einen weniger sichtbaren Vorteil. Der hippe Wedesigner, verbringt sicherlich lieber mehr Zeit im Photoshop-Template, wo Änderungen schneller sichtbar sind, als Zeit für ein Raster im CSS zu verschwenden.

Für meinen Fall, käme eine Lösung mit diesen Frameworks nicht in Frage, weil man aufgeblähten Quellcode bekommt. Quellcode, der in der Tat eine Einbahnstraße ist. Wer solche Frameworks nutzt, scheint nicht willig, die Zeit zu investieren, die es braucht, um die Vorteile von Grids, HTML und CSS zu nutzen. Die schnelle Lösung beinhaltet immer Nachteile und diese schildert der Artikel wirklich gut.

Raster grundsätzlich zu verteufeln ist völlig absurd. Je dichter die Informationsfülle wird, umso essentieller werden Grundraster und auch bei wenigen Informationen, bieten sie eine unsichtbare optische Führung. Raster bedeuten noch immer deutlich mehr Aufwand, möchte man als Webdesigner, alle deren Vorteile nutzen und gleichzeitig weiter flexibel bleiben.

Fazit? CSS Frameworks sind sehr mit Vorsicht zu genießen. Zum Layouten gänzlich drauf verzichten und mehr Zeit in das eigene Raster/CSS investieren. Ich fürchte das Thema spaltet sich beim Nutzer. Wer mehr der Programmierer ist, wird wohl eher zur Fast-Food-Lösung greifen, die auf lange Sicht ungesünder ist. Der Gestalter dagegen wird ganz schnell realisieren, wieviel mehr Freiheit, eine eigene Raster-Lösung bietet. CSS-Frameworks ruhig verteufeln, Grundraster im Webdesign nicht. Wie überall belohnen Raster im Webdesign auch nur das gute Handwerk.

Feedback: 0 Kommentare

Microsoft’s IE Plattform ingnorieren?! Ein Wunschtraum, ausgelöst von der Ausbeutung des CSS2 Standards. Als wir mit CSS nur ein paar Farben und Fonts definiert haben, schien es kein solches Problem zu geben. Damals gab es sogar mehr Browser als heute und niemand hat nach Erlösung geschrien.

Nun jedoch bleibt es nicht bei Fonts und Farben. CSS ist zu dem Pinsel für Webseiten geworden, der auf unterschiedlichen Leinwänden nun eben zu unterschiedlichen Ergebnissen führt. Früher war CSS nur das Finish vom Bild, heute ist es alles. Ich bin kein Verfechter von “Verbannt den Internet Explorer!”. Für viele ist es die erste Plattform ins Internet und wir wissen alle, wie prägend die ersten Erfahrungen so sein können.

Ich halte es auch für illusorisch und elitär, eine so dominierende Marktmacht, ignorieren zu wollen. Das Problem IE wird sich ganz von allein lösen, wenn auch wir, wie jetzt schon die Japaner, mehr auf kleinen Bildschirmen (Mobile Web) online sind, als vor der großen grauen Kiste. Damit kommen so viele neue Probleme, dass IE’s CSS Macken lächerlich erscheinen werden.

no, no, no

Ich halte diese Frage für viel entscheidender. Die Zeiten, in denen Internet-Seiten wirklich auf jeder Plattform gleich aussahen, sind vorbei, wenn sie denn jemals Realität waren. Ob eine Seite “gut” aussieht ist sekundär. Ob sie auf jeder Plattform funktioniert, ob Daten korrekt strukturiert sind, ist essentiell. Die Gestaltung nun zu verkrüppeln, um IE-User zu strafen erscheint mir seltsam. Seltsam ist auch, für praktisch jede Plattform eine separate Lösung entwerfen zu wollen. Mein Eintrag wenige Tage zuvor, scheint sich wieder zu bewahrheiten: Webdesign ist der kleinste gemeinsame Nenner.

Das Thema ist auch bei mir hier wieder sehr aktuell. Das versprochene kleine Update wird sich wohl verzögern, denn alle drei getesteten Browser, auch zu drei unterschiedlichen Ergebnissen führen. Safari unter OSX macht alles richtig, Firefox führt nur unter Windows zu einem hässlichen Flackern der fixierten Body-Grafik und IE7 braucht eine komplette Eigenlösung, naja fast. Man muss sich das mal genau vor Augen halten. Selbst gleiche Browser (Safari/Firefox) führen auf unterschiedlichen Betriebssystemen zu unterschiedlichen Ergebnissen.

Weder eine Plattform ignorieren, noch den heiligen Gral suchen. Wer die absolute Kontrolle über sein Werk haben möchte, sollte in die älteren Medien wechseln. Klar ist es unangenehm, mit Standards arbeiten zu müssen, die keine sind, aber es ist nun mal was es ist. Hoffnung ist ja in Sicht, Firefox baut kontinuerlich den Marktanteil aus und kommt in Europa auf teilweise beachtliche Zahlen. Es wird alles gut.

Feedback: 3 Kommentare

Diese Woche gibt es vermutlich ein kleines neues Update, primär der Seiten-Kopf, wenn ich es schaffe auch das Archiv. Ich sitze seit letzter Woche dran, sofern es die Zeit zulässt, noch weiter zu otpimieren. Die jetzige Kopfzeile mit den Bilder-Links ist wirklich sehr effektiv. Mehr als jeder zweite Besucher, der sich auf die Seite verläuft, klickt auch einen dieser oberen Links. Als ich damals mit WordPress anfing, hatte ich ein solches Element nicht in Planung. Nun funktioniert es, wirkt aber deplaziert, genau dies soll sich ändern.

Folgende These nach den letzten Tagen. Webgestaltung, inhaltlich und visuell, von der Eimilchlegendenwollmilchsau, oder wie Ben es neulich als Simic bezeichnete, ist der kleinste gemeinsame Nenner aus Programmierer, Autor und Designer.

Klassisch ist der Weg von der Skizze, über das Photoshop-Template hin zum Stylesheet. Skizze und Template finden bei mir nur noch im Kopf statt, zumindestens bei den Projekten, wo ich völlige Kontrolle habe. Ich weiß was gestalterisch geht und was nicht. Ich weiß genau, was ich hier ändern möchte. Es wäre einfach, eine Grafik vorzubereiten und diese dann ganz einfach zu platzieren, mit CSS den Text verstecken und gut: image replacement. Der Grafiker in mir schreit ja, der Webgestalter nein, der Autor hält sich da raus.

Wenn ich mit dieser kleinen Geschichte fertig bin, dann wird man sehen, dass ich natürlich keine Grafik verwende, sondern nur mit HTML und CSS Elementen arbeite. Der Aufwand dafür und die immer sichtbarer werdenden Grenzen (Browser-Kompatibilität) sind der beste Lehrer, wenn es um Webgestaltung geht. Keine noch so alte Schule, kann die Realität ersetzen. Trial&Error scheint hier ein guter Lehrer.

Unterhaltsam ist dieser Artikel von Michael Preidel aus der letzten Woche. Alles was dort steht ist 100% korrekt. Der Artikel verschweigt jedoch Details, wie z.B. den Unterschied im Schriftbild bei serifen- und serifenlosen Schriften. Nicht umsonst wählt der Artikel eine serifenlose Schrift und überhaupt kann diese schöne Anleitung auch leider nicht über Schriftdarstellung auf Windows-Systemen, hinweg trösten. Egal ob echte oder falsche Kapitälchen, auf Windows-Systemen wird alles zermatscht. Auch wenn ich mit überteuerten Macs wenig anfangen kann, allein die Schriftdarstellung unter OSX wird dafür sorgen, dass mein nächster privater Rechner, ein Apple wird.

Web-Typografie scheint die Suche nach der Nadel im Heuhaufen. Das Regelwerk scheint grenzenlos, ebenso jedoch auch die Ergebnisse. Typografie ist für mich die Kontrolle von Schrift. Irgendwie scheine ich jedoch im Grenzfall nur kontrollieren zu können, wie unterschiedlich, dass Ergebnis in allen Browsern ist. Merken könnte man sich:

• Span-Elemente absolut zu positionieren hat klare Grenzen
• line-height scheint bei großen Schriftgrößen von Browser zu Browser immer unterschiedlicher auszufallen. Kein Drama bei Mengentext, aber kritisch für pixelgenaues Positionieren großer Schrift-Elemente
• relative Schriftgrößen sind auch immer noch ein rotes Tuch, wenn es im wirklich exakte Positionierung geht, die alle Browser gleich darstellen sollen
• große Schriften und Kontrast um Himmelswillen vermeiden. Window’s ClearType kotzt sonsts eimerweise den Raum voll
• Internet-Explorer 6 ist keine wirklich ernstzunehmende Plattform mehr

Und die Moral von der Geschicht? Vetrau CSS bei Schriften nicht. Für wirklich solide Typo-Spielereien fehlt noch immer eine Basis an wirklicher Browser-Kompatibilität. Es bleibt weiter einfacher nur’ne Grafik zu machen, als zu versuchen echte HTML-Schriften pixelgenau zu positionieren. Ich hoffe für mein Beispiel die goldene Mitte gefunden zu haben.

Feedback: 3 Kommentare

So langsam aber sicher erschließen sich mir die kleinen Details von WordPress. Ersteinmal werden die Intro-Bildchen neuer Einträge als separates Element gepflegt, damit fliegen sie erstmal aus dem Feed raus, was aber so gewünscht ist, denn echtes Inhalts-Element sind sie nicht. Ältere Einträge ohne Bilder bekommen ein Standard-Bild. In einigen Loops wird dieses Bild mit abgefragt, meistens jedoch, sollte es vernachlässigt werden. Viele Wege führen nach Rom, um genau diesen Effekt zu errreichen, hab ich vorher versucht Bilder in Auszügen zu aktivieren, das klappt relativ einfach über eine kleine extra Funktion in der functions.php. Komischerweise vermisse ich im Backend Option für diese Excerpt-Funktion, wer hier was ändern möchte fummelt in den Core-PHPs von WordPress herum, was zukünftige Updates zur reinen Nervensache machen dürfte.

Verändert sind auch kleine unsichtbare Details. Alle Feeds sollten nun im Header verlinkt sein. Das Title-Tag der HTML-Seiten sollte nun ebenfalls besser lesbar sein. Das Archiv hat wieder eine kleine Übersicht über die Schlagwörter, auch wenn ich damit noch nicht zufrieden bin.

Auf der Test-Seite probiere ich mal wieder was mit jQuery, allerdings verhindert der Semantik-Coder in mir, diese Tabs-Funktion so einfach übernehmen, was mich zu einer grundsätzlichen Problematik bei der Nutzung von Skript-Spielerein bringt.

jQuery als Stolperfalle

Im Feed-Reader tauchte gestern in diesem Eintrag, ein Link auf, der nicht so einfach stehen gelassen werden kann. jQuery mag in der Tat so kinderleicht zu benutzen sein, wie das Tutorial es dem Leser vermitteln möchte, aber diese ganzen Effekte, bringen durchaus Stolperfallen mit sich, wenn es um Semantik geht.

Wenn wir langsam aber sicher wirklich an den Punkt kommen, wo Webseiten ihre Inhalt korrekt strukturieren, Überschriften H-Tags bekommen, Absätze separat in p-Tags gepackt werden, Listen auch wirklich HTML-Listen sind, dann zwingt einem jQuery wieder einen Schritt zurück. Ganz einfaches Beispiel dafür ist die Tabs-Funktion, basierend auf einer eher subtoptimalen Semantik, bei der eine Liste mit Anker-Links, Elemente steuert, die strukturell garnichts mit ihr zu tun haben. Es mag jetzt nicht grundlegend falsch sein grundlegend korrekt ist es jedoch auch nicht.

Weiterhin habe ich ein grundsätzliches Problem so stark auf Java-Skript zu bauen. Ich nutze privat grundsätzlich das NoScript-Plugin für Firefox, was grundsätzlich erstmal alle Skripts auf allen Seiten deaktiviert. Jedes Skript muss dann manuell erlaubt werden. Auf der eigenen Seite dann mit schlechtem Beispiel vorran zu gehen und Javaskript fast essentiell werden zu lassen, ist zu hinterfragen. Bin wirklich unsicher, wie weit man jQuery in die Seite integrieren sollte. Keine Frage solche Tabs sind extrem effiziente Nutzung der Fläche, nur logisch und strukturell korrekt integriert sollten sie sein. Auch im Archiv würde sowas unter Umständen sinnvoll sein. Mal schauen.

Bilder skalieren ja/nein

Der Eintrag zum Skalieren von Bildern zeigt ein grundsätzliches Problem. Man entwickelt immer für eine Million verschiedene Systeme, Browser, Versionen und zumindestens für meine kleine Nische hier, bin ich in der glücklichen Lage, nicht für den kleinsten gemeinsamen Nenner entwickeln zu müssen. IE6 wird hier vollständig ignoriert, IE7 bekommt nur die notwendigstens Sonderbehandlungen. Um jedoch allen Windows-Systemen, ein offensichtlich rückständiges OS, hier perfekt zu bedienen, müsste ich mit Blick in die Zukunft zuviele Eingeständnisse machen.

Speicherplatz wird immer günstiger, Display-Auflösungen steigen mehr und mehr, Browser und andere Programme werden immer fortschrittlicher. Damit ist klar, dass ich den Qualitätsverlust bei der Bilddarstellung auf einigen Systmen, in Kauf nehme, mit der Zuversicht zukünftig mehr Spielraum zu haben. Das größte Problem beim Wechsel auf ein breiteres Layout waren die plötzlich zu kleinen Bilder. Ein solcher Fehler soll hier nicht mehr stattfinden. Darum bleibe ich dabei: Bilder werden größer gespeichert als ich sie eigentlich aktuell brauche.

Würde ich bei Bildern anfangen, müsste ich auch Schriften überdenken, denn auch hier hinken die Windows-Systeme deutlich hinterher. Ich bin wirklich kein Apple-Fanatiker, aber das muss man einfach mal so erwähnen, OSX deklassiert die Windows-Systeme, wenn es um die Darstellung von Schriften geht. Windows XP’s (erst manuell zu aktivierendes) ClearType hat zugegeben nun schon die Rente erreicht, aber auch das verbesserte ClearType bei Vista lässt Wünsche offen.

was fehlt noch?

Ändern wird sich noch was im Archiv und auf der Start-Seite. Auch das Kommentarformular wird wohl noch einen Java-Skript-Anstrich bekommen. Erstmal funktioniert alles und von der weniger ist mehr Linie, möchte ich eigentlich auch nicht weg. Die Start-Seite mit Tabs zupflastern missfällt mir irgendwie dann doch noch.

Inhaltlich kommt auch was. Relativ fertig geschrieben ist ein neuer Eintrag über einen nicht unbekannten Sci-Fi-Film, Bilder sind gemacht, wollen nur noch angepasst werden. Thematisch brach liegt World of Warcraft bisher, obwohl es mehr als genug zu behandeln gäbe. Auch hier wird sich bald was ändern. Zum Patch 2.4 ist ein Monster-Text geschrieben, der aber auf mehrere Texte verteilt werden möchte. Die Woche sollte es da schon was zu lesen geben. Ich spiele noch, wenn auch weniger. Thematisch gibt WoW noch viel her und diese Texte finden immer die meisten Leser. Die Nachfrage möchte bedient werden. Wird sie bald.

Feedback: 3 Kommentare

Vielleicht dem ein oder anderen schon aufgefallen, möchte ich zukünftig mehr Bildmaterial verwenden und auch die ein oder andere Illustration. Eigentlich war ich zuversichtlich, die Bilder größer als ich sie brauche anzulegen, um sie anschließend vom Browser auf die endgültige Größe herunterskalieren zu lassen. Auch mit Blick in die Zukunft und immer größer und feiner werdenden Auflösungen bzw. Displays, macht das mehr als Sinn. Allerdings habe ich da wohl die Leistung aktueller Browser überschätzt.

Verschiedene Browser, verschiedene Betriebssysteme oder eine Kombination aus beidem, führen zu unterschiedlichsten Ergebnissen. OSX arbeitet mit sämtlichen Browsern sehr sauber. Vermutlich greift Quartz hier ein und glättet das Bild. Windows-Systeme variieren stark. Seltsamerweise arbeitet Opera auf Windows-System sehr sauber und sticht hier Firefox und IE deutlich aus.

Im Bild zu sehen einmal Firefox auf dem Mac, einmal Windows PC. Wer da unsauber arbeitet ist mir noch nicht ganz klar. Es scheint, dass sowohl Browser als auch OS da ihre Finger im Spiel haben. Bei normalen Fotos hält sich die fehlerhafte Darstellung in Grenzen, bei solchen Vektor-Illustrationen jedoch, kommt es zu doch sehr hässlichen Treppeneffekten. Ob Windows Vista ähnlich gut wie OSX arbeitet kann ich leider nicht testen. Ich habe eine Test-Seite mit 2 Bildern erstellt, zum Vergleichen verschiedener Browser/OS.

Feedback: 2 Kommentare