Ned Batchelder hat die Demo erweitert und daraus mit ein bisschen jQuery eine Animation erstellt.

Vielen Dank an Sahanya für den Hinweis.

Verwandte Beiträge

• Die Linkschleuder (1)
• Gewinnspiel zum 1000. Beitrag (84)
• Die Linkschleuder (2)
• Die Linkschleuder (7)
• Die Linkschleuder (2)
• Die Linkschleuder (2)
• Die Linkschleuder (0)
• Webkrauts-Adventskalender Nr. 4 (1)
• Inhaltsverzeichnis mit (X)HTML und CSS (5)
• Grafik mit Gitternetz als Layouthilfe (8)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

<link rel="stylesheet" type="text/css" media="screen" href="style.css" />
<link rel="stylesheet" type="text/css" media="print" href="print.css" />

Das Ergebnis ist jedem halbwegs erfahrenem Webworker klar. Der Browser liest beide CSS-Dateien ein [1] und je nach dem im welchen Modus man sich befindet (z.B. Druckvorschau) wird die entsprechende CSS-Datei eingesetzt. Somit kann man z.B. für die Druckausgabe eine optimiertes Dokument ausgeben lassen. Hier in diesem Weblog blende ich so gut wie alles was nicht direkt zum Inhalt gehört aus. Einfach mal im Browser die Druckvorschau aufrufen oder auf den Druckvorschau-Link klicken.

Das Problem ist aber hierbei, dass viele Nutzer und unter anderem auch recht erfahrene Nutzer (da war ich vor einiger Zeit sehr überrascht) nicht davon ausgehen, dass es eine CSS-Datei für die Druckausgabe gibt und diese Lösung auch schlichtweg nicht kennen. Die Suchen krampfhaft nach einem "Drucken" oder "Druckvorschau"-Link auf der Website. Die entsprechenden Menüpunkte im Browser sind entweder völlig unbekannt oder einfach "aus den Augen, aus dem Sinn".

Was kann man den nun tun? Eine sehr einfache Lösung ist es einen Javascript-Link einzubauen:

<a href="javascript:window.print()">Drucken</a>

Diese Lösung hat zwei Nachteile. Bei ausgeschaltetem Javascript ist nix … ist logisch. Zudem ruft dieser Link nur den Druck-Dialog auf. Das ist nicht sonderlich hilfreich, denn man will vorher auch sehen was man druckt. Eine Javascript-Lösung zum Aufruf der Druckvorschau gibt es, allerdings funktioniert es nur im Internet Explorer … also recht Witzlos.

Was könnte man jetzt machen um eine browserübergreifende "Druckvorschau" zu realisieren und für die sehr erfahrenen Nutzer die CSS-datei für die Druckausgabe unangetastet zu belassen:

<?php if (isset($_GET['d']) && $_GET['d'] == 'druckvorschau') { ?>
<link rel="stylesheet" type="text/css" media="screen" href="print.css" />
<?php } else { ?>
<link rel="stylesheet" type="text/css" media="screen" href="style.css" />
<?php } ?>
<link rel="stylesheet" type="text/css" media="print" href="print.css" />

Der obere Codeschnipsel (gefunden bei maratz) realisiert genau das. Sollte der Schlüssels d des assoziativen Arrays $_GET den Wert druckvorschau haben, dann wird das Druck-CSS als das Haupt-CSS eingebunden. Ist dies nicht der Fall dann wird die "normale" CSS-Datei eingebunden. Hierbei handelt sich um kein Hexenwerk sondern es reicht folgenden Link an der entsprechenden Stelle einzubinden:

<a href="?d=druckvorschau">Druckvorschau</a>

Wenn man diesen Verweis aufruft bzw. anklickt, dann wird der Schlüsselwert-Paar d=druckvorschau abgegeben und die eigentliche CSS-Datei wird ersetzt und man bekommt im Browser das Dokument so zu sehen, wie es dann auch gedruckt werden soll.

Man könnte sich hier fragen, warum ich die print.css außerhalb der Abfrage noch einmal einbinde und zwar im media="print"-Modus. Das hat zwei Gründe. Zum einen für die Nutzer die direkt über den den Druck-Dialog oder die Druckvorschau des Browser gehen. Aber auch wenn man aus der "künstlichen" Druckvorschau druckt. In beiden Fällen sucht der Browser nach einer eventuellen CSS-Datei für die Druckausgabe. Würde ich diese nicht wie oben einbinden, würde der Browser das Dokument so drucken lassen als ob kein CSS eingebunden ist.

Das ist allerdings nicht der Sinn der Sache weil ich mit der print.css bestimmte Ziele verfolge u.a. nicht-relevante Bereiche ausblenden.

[1] Mir ist durchaus bewusst, dass man die CSS-Dateien schonender in Bezug auf Server-Abfragen einbinden kann.

Verwandte Beiträge

• Die Linkschleuder (1)
• Datum in der URL eines Beitrages (33)
• Erklärung zu "Weblogs und Usability" (8)
• "Weblogs und Usability" als Download (10)
• Blogparade: was soll in die Sidebar? (73)
• Lesezeichen-Leisten: ja oder nein? (13)
• Auflistung der Kategorien: erstes Fazit (11)
• Auflistung der Kategorien: ja oder nein? (28)
• Kommentare per E-Mail verfolgen (6)
• Beiträge im Weblog organisieren (14)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Weitere Infos gibt es bei Jens.

Verwandte Beiträge

• Die Linkschleuder (2)
• Homer Simpson macht CSS (6)
• Die Linkschleuder (2)
• Inhaltsverzeichnis mit (X)HTML und CSS (5)
• Grafik mit Gitternetz als Layouthilfe (8)
• CSS-Kompatibilität in IE7 (4)
• Titel-Attribut gestalten (9)
• Besuchte Links gestalten (2)
• Internet Explorer 5 aussperren (14)
• CSS-Hacks und die Entwickler von IE 7 (9)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Am 01. Juli 2007 um 00:00 Uhr WESZ starten alle Teilnehmer mit ihren Webseiten neu durch und geben ihnen ein neues Gesicht.

Hinter diesem Projekt stecken Felix, Benjamin und Jowra. Viel Spaß und Erfolg mit dem Projekt.

Übrigens wäre nicht ein Weblog angebracht? Für Zusatzinformationen, Stand der Dinge, wer sich angemeldet hat etc.

Nachtrag: ich habe jetzt alle Verlinkungen außer die von Felix entfernt. Weil nur er in seinem Weblog das nofollow-Attribut entfernt hat. Die anderen beiden setzen es fleißig ein und ich sehe es nicht ein auf ein Projekt zu verweisen, wo 2/3 der Verantwortlichen das nofollow einsetzen. Ne, ne Leuts, so nicht. Wenn ihr auf Backlinks hofft, dann nicht mit nofollow. Geben und nehmen heißt die Devise und nicht nur nehmen.

Verwandte Beiträge

• Leider keine verwandten Beiträge.

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Via F-LOG-GE.

Verwandte Beiträge

• Die Linkschleuder (2)
• Homer Simpson macht CSS (6)
• Die Linkschleuder (2)
• Webkrauts-Adventskalender Nr. 4 (1)
• Grafik mit Gitternetz als Layouthilfe (8)
• CSS-Kompatibilität in IE7 (4)
• Titel-Attribut gestalten (9)
• Besuchte Links gestalten (2)
• Internet Explorer 5 aussperren (14)
• CSS-Hacks und die Entwickler von IE 7 (9)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Via: SELFHTML aktuell Weblog.

Verwandte Beiträge

• Leider keine verwandten Beiträge.

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

"Internet Explorer konnte das Dokument aufgrund eines internen Fehlers nicht drucken."

Firefox, SeaMonkey und Internet Explorer 7 hatten kein Problem das Dokument auszudrucken. Nach einer kurzen Recherche habe ich dann das Problem herausgefunden. Der IE 6 störte sich an <div id="tags">...</div> da es sich bei dem Attribut-Wert tags um einen reservierten ID-Wert handelt. Nach dem der Wert umbenannt wurde, hat auch der IE 6 das Dokument ausdrucken können.

Weitere Infos bei Eric Meyer.

Verwandte Beiträge

• Hamburg: IE8 Beta 1 Launchevent (10)
• Die Microsoft-Fragestunde (14)
• Vorsicht bei UTF und Internet Explorer 7 (5)
• Internet Explorer 7 installiert (14)
• Internet Explorer 7 RC1 deutsch (14)
• Internet Explorer 7 Beta 3 (9)
• CSS-Kompatibilität in IE7 (4)
• Screenshots vom IE 7 (10)
• Internet Explorer 5 aussperren (14)
• CSS-Hacks und die Entwickler von IE 7 (9)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Ich sage es gleich vorweg: zu diesem Buch fällt mir nur wow, wow, wow! ein. Ich habe in letzter Zeit einige (sehr) gute branchenspezifische Bücher gelesen doch dieses sticht sie alle aus.

Wie der Untertitel schon sagt, geht es auch um Yet Another Multicolumn Layout (kurz YAML). YAML ist ein CSS Layout Framework, das Dirk Jesse in den letzten 1,5 Jahren entwickelt hat. Download und Infos dazu auf yaml.de. Mit YAML lassen sich standardkonforme und browserübergreifend funktionierende robuste 2 bzw. 3 Spaltenlayouts (liquide als auch fixiert) erstellen.

Wer auf dem Weg zum Web-/Frontendentwickler ist, sollte sich YAML zu Gemüte führen, denn Dirk hat ganze Arbeit geleistet und in seinem Framework wirklich jeden Browserbug berücksichtigt. YAML ist so solide wie umfangreich. Ohne fundierte CSS Kenntnisse und Überblick über alle gängigen Browserbugs war es bis dato nicht gerade zeitsparend sich in das Framework einzuarbeiten.

Das ist jetzt mit dem Buch anders geworden. Auf 400 Seiten geht Dirk auf alle wesentlichen Browserbugs sowie deren Korrektur ein. Anschließend beschreibt er das YAML Konzept eingehend und stellt vertiefend auf YAML basierende Layoutvariationen vor. Zwei Kapitel, geschrieben von TYPO3 Kenner Dieter Bunkerd, beschreiben die Anbindung von YAML an TYPO3. Ein kurzes Kapitel ist YAML und xt:commerce gewidmet.

In diesem Buch ist kein Satz zuviel oder zuwenig. Es ist erstklassig strukturiert geschrieben, exzellent lektoriert und macht es dem Leser leicht alle Kernzusammenhänge zwischen (X)HTML/CSS und Browserbugs sowie deren Korrektur nachvollziehen zu können. Zielgruppe sind professionelle Frontendentwickler (ob Freelancer oder in Webagenturen) sowie CSS Passionierte, die robuste, standardkonforme Sites aufsetzen. Dabei ist es erstmal wenig wichtig, ob dies unbedingt mit YAML passiert. CSS Layouts kann ich auch jedem ans Herz legen, der/die professionelle CSS Lösungen erlernen möchte.

Mit 29,90 EUR ist das Buch nicht gerade günstig, doch es ist jeden Cent wert!
YAML gehört sicher die Zukunft - diesem Buch und euch wünsche ich das auch.
In diesem Sinne Fröhliche Weihnachten :).

Eine kleine Einführung in YAML für Anfänger sowie eine vertiefende Buchrezension wird noch auf csshilfe.de veröffentlicht.

Zu Autorin

Alexandra Labudda ist Diplomingenieurin und Webentwicklern in Köln. Alex pflegt die deutsche Textpattern Resource textpattern [ge] und schreibt regelmäßig für das englische TXP Magazine sowie für das Kölner Blog Büro.

Verwandte Beiträge

• Die zwei Gewinner stehen fest (3)
• Zwei Bücher zu gewinnen (13)
• Weitere Infos zu meinem CSS-Buch (4)
• Mein erstes Buch (29)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Worauf bezieht sich die Abkürzung CSS in meinem Buch?

1. Center for Security Studies
2. Counter-Strike: Source
3. Cascading Style Sheets

Die richtige Antwort in diesem Fall war Cascading Style Sheets. Es haben 89 Leute eine E-Mail geschickt und alle waren kurioserweise richtig. Fazit: die Leser dieses Weblogs sind schlau. Ich habe mich dann mit dem Herren Zufallszahl beraten und hier sind die Gewinner:

1. Andrea Jaeckel
2. Christoph Hörl

Ich gratuliere den Gewinnern und im Laufe der Woche werde ich die Bücher losschicken.

Verwandte Beiträge

• CSS Layouts - Das Buch zu YAML (5)
• Zwei Bücher zu gewinnen (13)
• Weitere Infos zu meinem CSS-Buch (4)
• Mein erstes Buch (29)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Und wie sehen die Teilnahmebedingungen aus? Einfach die Antwort auf die folgende Frage auf meine E-Mail-Adresse schicken:

Worauf bezieht sich die Abkürzung CSS in meinem Buch?

1. Center for Security Studies
2. Counter-Strike: Source
3. Cascading Style Sheets

Das Gewinnspiel läuft bis einschließlich 07. November 2006. Danach werden die zwei Gewinner per Zufallsprinzip ausgewählt. Muss ich jetzt auch hierbei erwähnen, dass der Rechtsweg ausgeschlossen ist :-)? Ach ja, eure E-Mail-Adressen werden nicht weitergegeben und die Mails werden nach der Verlosung gelöscht.

Verwandte Beiträge

• CSS Layouts - Das Buch zu YAML (5)
• Die zwei Gewinner stehen fest (3)
• Weitere Infos zu meinem CSS-Buch (4)
• Mein erstes Buch (29)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Ich bedanke mich auch bei den Blogger-Kollegen für gute Wünsche und die Erwähnung. Hier eine Liste der Leute, diein Ihrem Weblog das Buch erwähnt haben:

• Christoph
• Miloš Radović
• Jens Grochtdreis
• Silke Schümann
• Sencer
• Gerrit van Aaken
• Jörg Petermann
• Web Standards in Germany
• Sascha A. Carlin
• Boris Stumpf

Verwandte Beiträge

• CSS Layouts - Das Buch zu YAML (5)
• Die zwei Gewinner stehen fest (3)
• Zwei Bücher zu gewinnen (13)
• Mein erstes Buch (29)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

CSS. Internet Intern
Jan Heinicke, Vladimir Simovic
Data Becker, 10/2006
571 Seiten (24 x 16,5cm)
gebundene Ausgabe
ISBN: 3815825989

Hier das Inhaltsverzeichnis welches ich selbst in eine (X)HTML-Datei umgewandelt habe. Ich habe auch einigen Leuten Rezensionsexemplare versprochen, vorgestern telefonierte ich deswegen mit dem Verlag und dort meinte man, die Bücher sollten diese Woche noch ankommen.

Nachtrag:

• Leseprobe (pdf)
• Inhaltsverzeichnis (pdf)
• zusätzliche Infos
• Stichwortverzeichnis
• Vorwort
• Ein Teil der Code-Beispiele (zip, 125kb)

Verwandte Beiträge

• CSS Layouts - Das Buch zu YAML (5)
• Die zwei Gewinner stehen fest (3)
• Zwei Bücher zu gewinnen (13)
• Weitere Infos zu meinem CSS-Buch (4)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Gut, der Quelltext ist zwar laut dem W3C-Validator nicht valide, aber man sollte nicht zu viel verlangen. Viel wichtiger ist es, dass die Seite auch ohne CSS lesbar und bedienbar bleibt. Und soweit ich das auf die schnelle testen konnte, ist es auch so.

Nachtrag: ich bin nicht der Einzige, der auf den Ralaunsch von Spiegel.de aufmerksam geworden … oh, was für ein Wunder … auf jeden Fall gibt es auch eine Stellungnahme von Spiegel.de dazu.

Verwandte Beiträge

• Leider keine verwandten Beiträge.

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

• Tools
• Galerien
• Layout
• Boxen
• Menüs, Listen und Navigation
• Formulare
• Image Replacement
• Optimierungstechniken
• Browser, Bugs und Hacks
• Tipps und Tricks

Zusammen mit der Linksliste The Web Developer's Handbook von Vitaly und der Liste auf Mezzoblue.com hat man somit eine sehr umfangreiche Sammlung mit wichtigen CSS-Links.

Verwandte Beiträge

• Leider keine verwandten Beiträge.

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Verwandte Beiträge

• Die Linkschleuder (2)
• Homer Simpson macht CSS (6)
• Die Linkschleuder (2)
• Webkrauts-Adventskalender Nr. 4 (1)
• Inhaltsverzeichnis mit (X)HTML und CSS (5)
• CSS-Kompatibilität in IE7 (4)
• Titel-Attribut gestalten (9)
• Besuchte Links gestalten (2)
• Internet Explorer 5 aussperren (14)
• CSS-Hacks und die Entwickler von IE 7 (9)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

<style type="text/css" media="screen, projection">
@import url( style.css );
</style>

Bis November 2005 hat sich der Validator auch an

<link rel="stylesheet" type="text/css" media="screen, projection" href="style.css" />

verschluckt. Dieser Bug ist beseitigt. Daher sollten die Leute, die Wert darauf legen das der CSS-Validator keinen "Fehler" anzeigt auf die zweite oder eine andere Variante des Einbindens wechseln.

Verwandte Beiträge

• Leider keine verwandten Beiträge.

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

• The Web Developer's Handbook
• Eine Liste mit Online-Generatoren (von CSS bis XML)
• Internet in Zahlen (Internet-Nutzung in Zahlen)
• Tutorialsammlung (von Ajax bis XML)
• CSS- und Design-Galerien
• Schriften und Typographie
• Symbole, Buttons und Icons zum Download

Verwandte Beiträge

• Leider keine verwandten Beiträge.

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Aus der Windows-Welt sind mir bisweilen nur zwei grafische Browser bekannt, die dass Link-Element bzw. dessen Inhalt innerhalb einer extra Leiste darstellen können und zwar Opera und SeaMonkey (Mozilla Websuite): Screenshot (Flickr). Für Firefox gibt es soweit ich gehört habe einen Plugin dafür. Wer es aber auf jeden Fall darstellen kann, dass sind die textbasierten Browser (Lynx, Link etc.) und das kann je nach Alter eines Wordpress-Weblogs eine kleine Qualärei sein, wie Jeena berichtete. Verantwortlich dafür ist der folgende Code-Fragment im Kopfbereich:

<?php wp_get_archives('type=monthly&format=link'); ?>

Für jeden Monat gibt es einen logischen Verweis mehr und diese Liste kann arg lang werden (siehe nochmal Flickr-Screenshot), alleine hier sind es 28 Monats-Verweise. Ist man mit einem grafischen Browser unterwegs, dann fält es garnicht auf. Ist man aber mit einem Text-Browser, wie z.B. Link unterwegs, dann kommen, die ganzen Archive, dem Besucher als erstes entgegen.

Zur meiner Verteidigung muss ich sagen, dass ich meine Seiten unter einem Lynx-Viewer teste, aber dieser mir die Monatsarchive garnicht angezeigt hat. Daher bin ich davon ausgegangen, dass die Archiv-Einträge in Form von logischen Verweisen von textbasierten Browsern ignoriert werden. Was mich auch nicht gewundert hat, da z.B. SeaMonkey viel mehr an logischen Verweisen interpretieren kann als Opera.

Wie könnte man das Problem lösen? Da ich eh eine Archiv-Unterseite habe, wo ich die Einträge nach Tags und Monaten sortiert habe, so wäre es sinvoll auch über ein logischen Verweis auf diese Unterseite zu führen. Den oberen Code habe ich gelöscht und durch folgenden ersetzt:

<link rel="archives" href="/archiv/" title="Das Archiv" />

Verwandte Beiträge

• Wie hast du das in deinem Weblog gemacht? (2)
• Die Linkschleuder (7)
• WPlite: Admin-Bereich von WordPress anpassen (12)
• Optimaler Seitentitel in Wordpress 2 (20)
• Registration deaktiviert (11)
• WordPress: nur die Startseite ansprechen (16)
• WordPress: Autor-Auswahl verschwunden (6)
• Alte Beitrags-Vorschau herstellen (16)
• Vollen Newsfeed in Wordpress 2.1 erzwingen (6)
• Themes für mehrere Versionen fit machen (6)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Die Leute aus dem Print-Bereich haben es da vergleichsweise einfach, egal aus welchen Winkel man einen Din A5-Flyer liest. An den Maßen des Flyers ändert sich nix. Und egal ob man eine Brille, Lupe oder ohne Hilfsmittel liest, aus Garamond wird nicht Verdana.

Web ist anders, Web ist anders …

Im Webbereich ist es alles etwas anders. Man hat zu wenige und vor allem relativ unzuverlässige statistische Daten und im Vergleich zum Print-Bereich ist der Webbereich noch sehr jung. So das gewisse Standards nocht nicht existieren bzw. noch nicht angewendet werden und wegen der "Jugend" fehlen auch gewisse Untersuchungen, die wir aus den klassischen Medien kennen.

Wie dem auch sei, als Webworker muss man dicke Nerven haben, sich Gedanken machen und bereit sein Kompromisse zu schliessen. Als Webworker hat man schon dadurch zu kämpfen, dass es diverse Systeme und noch mehr Einstellungsmöglichkeiten in den jeweiligen Systemen gibt.

Schon die alleine können einen in die Verzweiflung treiben, aber anscheinend ist das manchen Leuten nicht genug, die versuchen mit der gleichen HTML- und CSS-Datei alle Auflösungen und Geräte gleichermaßen gut anzusprechen. Dadurch entstehen eierlegende-wollmilch-Layouts mit superduper-Zoom und pipapo.

Jetzt bitte nicht missverstehen, ich will mich über keinen Lustig machen, hinter den meisten Layout-Demos steht viel anstrenegnde Arbeit dahinter und diese Demos und Ansätze bringen uns dazu nachzudenken. Aber ich bin mir nicht so sicher ob das alles der richtige Weg ist. Sehr oft wird gegen feste und für fluide Layouts argumentiert in dem man darauf hinweist, dass auch Nutzer mit mobilen Geräten auf eine Seite kommen könnten, genau wie Nutzer mit 22"+ Monitoren.

Flexible Layouts sind gut, feste aber auch

Aber jetzt mal im Ernst. Wie hoch ist die Anzahl der Leute die mobile Geräte zum surfen nutzen? Ich rede hier nicht davon, dass Leute mit Smartphones E-Mails lesen und diverse News-Ticker konsumieren, sondern wieviele Leute stinknormale Websites und Weblogs mit mobilen Geräten besuchen und dort auch evtl. kommentieren? Und wieviele Nutzer surfen durch die gegend mit TFT-Monitoren, die mehr als 20" haben?

Wo wir gerade bei mobilen Geräten sind. Es ist nicht einfach getan, dass man ein elastisches Layout bereit hält und schon ist der Nutzer des mobilen Gerätes zu frieden. Weit gefehlt. Gewisse Inhalte, die für diesen Nutzer irrelevant sind sollten ausgeblendet werden (große Bilder, Seitenleiste) und da hier Traffic - Menge der übertragenen Daten - im wahren Sinn des Wortes bares Geld kostet sollte dieser Auftritt schlank sein und sich auf das wesentliche konzentrieren. Hinzukommt das viele der mobilen Geräte nicht den kompletten Sprachschatz von (X)HTML verstehen (Stichwort: XHTML Basic).

Also wird es schon darauf hinauslaufen, dass man die mobile Website auslagert (Beispiele: Bloglines mobile, Google mobile etc.) um eine Website zu bieten, die auf einem Mini-Display wirklich ordentlich bedienbar ist.

Also nicht das wir uns missverstehen. Persönlich habe ich nix gegen ein flexibles Layout an sich, wirklich nicht. Aber das Argument, flexible Layouts sind den festen Layouts im signifikannten Vorteil wegen den mobilen Geräten … dieses Argument greift nicht wirklich.

Womit ich aber ein Problem habe, sind die zu langen Textzeilen bei diversen flexiblen Layouts. Ich persönlich habe auf meinem Schlepptop aka Notebook eine Bildschirmauflösung von 1280×800. Und ich surfe immer mit maximiertem Fenster und einige Websites biten mir dann den Inhalt der sich auf einer Breite von 800 bis teilweise über 1000 Pixel ausbreitet. Das ist zu viel des Guten.

Meine Augen müssen beim Lesen wandern, dass ist ungemütlich und anstrengend. Daher muss ich bei manchen Websites, die Schriftgröße und die Breite des Fensters verkleinern um ordentlich lesen zu können.

Mittlerweile habe ich festgestellt das meinem Leseverhalten eine ca. Breite von 470-550 Pixel und eine Schriftgröße von etwa 13 Pixel (Verdana, Arial) am meisten entgegen kommt. Größere Breiten und größere Schriften (15+px) empfinde ich nicht als leserlicher. Eher im Gegenteil.

Also nochmal zu festen vs. flexiblen Layouts, wobei ich so keinen Kampf sehe, beide haben ihre Daseinsberechtigungen, beide haben ihre Vor- und Nachteile … und zu guter letzt entscheidet der Kunde und je nach Fall der Grafik-Designer der die grafischen Vorlage liefert.

In erster Linie entwickelt der "Feld- und Wiesen-Webdesigner" Websites für Monitor und erst in zweiter oder dritter Linie für andere Ausgabegeräte … kann sein das sich das in 5-7 Jahren ändert, aber bleiben wir fürs erste bei heute, morgen und diesem Jahr. Also spricht fürs erste nichts dagegen ein Layot mit max. Breite von 760px zu entwerfen. Bei einem klassischen Zweispalter würde der Inhalt hierbei seine 480-530 px bekommen. Genug um ordentlich große Bilder zu unterbringen und eine leserliche Zeilenlänge zu bekommen. Die restliche Breite würde die Seitenleiste bekommen und mit etwa 200-250px kann man auch hier ordentlich viel Inhalt unterbringen. Und das ganze würde überhaupt nicht gequätscht ausschauen.

So ein Konzept eignet sich für kleine und mittelgroße Websites. Das "klein" und "mittelgroß" beziehe ich nicht nur auf die eigentliche Menge des Inhaltes sondern auch auf Menge versch. Kategorien bzw. Themen. Mit diesem Konzept nimmt man Rücksicht auf die kleinste signifikannte Breite von 800px.

Jetzt würde der eine oder andere sagen: "jahaha, aber was ist mit mobilen Geräten?". Nix ist mit diesen Geräten, die bekommen denn entweder garkein oder ein rudimänteres CSS und dann später bei entsprechender Nachfrage einen richtigen Auftritt.

"Jahaha, aber was ist mit den großen Monitoren?". Was soll mit großen Monitoren sein? "Ja, da ist dann viel Platz über". Ja und, wo ist das Problem? Muss denn immer die komplette Fläche vollgeklatscht sein? Und eines wunderrt mich dann doch immer, ein signifikanter Teil der Kritiker, die behaupten das sehr viele Leute bei großen Monitoren das Browser-Fenster nicht maximieren sondern seitlich Platz für diverse Anwendungen reservieren, behauptet wiederum bei großen Monitoren und festen Layouts würde seitlich viel Platz über bleiben.

Was den nun? Entweder es bleibt viel Platz über oder es wird bei großen Monitoren von vielen Nutzern der Browser-Fenster nicht maximiert. Beides gleichzeitig geht nicht :-).

Zuerst Inhalt, dann Layout

Ein sehr wichtiger Aspekt bei der Auswahl des Layouts und der Layout-Philosophie ist der Inhalt. Habe ich viel Inhalt, viele Autoren und streben nach einer großen Community, dann bietet sich z.B. ein dreispalter mit elastischen Elementen und viel dynamik.

Habe ich dagegen vor z.B. eine Webvisitenkarte mit max. 5-7 Unterseiten, je einem Bild und je 7-10 Sätze Text umzusetzen, dann wäre es ziemlich komisch würde ich hierbei einen dreispalter aufsetzen und eine völlig elastische Breite des Inhaltes zulassen. Wie schaut das dann auf einem 19" Monitor aus?

Ob man im Endeffekt jetzt eher zu einem festen, flexiblen oder einen Misch-Layout greift hängt von vielen Faktoren ab: der Menge und Qualität des Inhaltes, vom Kunden, vom Zielpublikum, der Arbeits-Philophie des Webworkers etc. In meinen Augen haben auch die festen Layouts durchaus ihre Daseinsberechtigung und sind in manchen Fällen eher im Vorteil. Wogegen ich etwas habe ist dogmatische Sichtweise auf diese Fragestellung, die bringt uns nicht weiter, weil sie die Fronten verhärtet. Und der Web-Bereich ist jung, so das meiner Meinung nach keiner sagen kann, dass er die Weisheit gepachtet hat.

Verwandte Beiträge

• Die Linkschleuder (1)
• Datum in der URL eines Beitrages (33)
• Erklärung zu "Weblogs und Usability" (8)
• "Weblogs und Usability" als Download (10)
• Blogparade: was soll in die Sidebar? (73)
• Lesezeichen-Leisten: ja oder nein? (13)
• Druckvorschau, CSS und die Nutzer (11)
• Auflistung der Kategorien: erstes Fazit (11)
• Auflistung der Kategorien: ja oder nein? (28)
• Kommentare per E-Mail verfolgen (6)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.

Allerdings mache ich mir schon seit einiger Wochen Gedanken zu diesem Thema und habe diesbezüglich einige Beiträge, anderer Webworker zu diesem Thema gelesen.

Ist es wirklich schlecht & böse die Schriftgröße über die Einheit Pixel zu definieren bzw. ist man automatisch ein besserer Mensch, wenn man die Schriftgröße in em oder Prozentwerten angibt? Ich gebe es zu, die Frage ist evtl. etwas zu polemisch, aber ich würde gerne über diese Fragestellung diskutieren. Mich interessiert eure Meinung zu diesem Thema.

IE kann es doch

Zuerst muss man sagen, dass die Behauptung "IE kann die Schriften bei Pixel-Angaben nicht skalieren" nicht wirklich stimmt. Bei Standardeinstellungen mag das sein, aber unter ("Extras" ») "Internetoptionen" » "Eingabehilfen" erscheint folgendes Fenster:

Wenn man den Punkt, wo der rote Pfeil eingezeichnet wurde ("Schriftgradangaben ignorieren") aktiviert, dann ignoriert IE die Angaben zur Schriftgröße und kann ohne Probleme die Schriften skalieren. Egal in welcher Einheit die Größe vorgegeben wurde. Gut, einige würden jetzt sagen, dass diese Einstellung für die allermeisten Nutzer unbekannt ist und ich gebe es zu das stimmt.

Es gibt nicht den Nutzer

Aber, wer sagt auf der anderen Seite dass die "Schriftgrad"-Einstellung einem Großteil der Normal-User bekannt sei? Ich kenne einige Leute, die im Netz unterwegs sind, mit unterschiedlichem Wissensniveau und sogar Leute die relativ erfahren sind und schon seit längerem im Web unterwegs sind kennen diese Einstellung garnicht. Als ich letztens einem Bekannten von dieser Option erzählte, also dass man im Internet Explorer die Schriftgröße ändern könnte, da meinte er nur zu mir "Aha, und wozu soll das gut sein?".

Von einer anderen Bekannten, die relativ schlecht sehen kann, weiß ich auf jeden Fall dass Sie diese Einstellung auch nicht kennt, aber sie weiß wie man Windows so einstellt, dass alles etwas größer rüberkommt.

Daher denke ich, dass man sich wahrscheinlich in eine falsche Sicherheit wiegt wenn man em anstatt Pixel für Schriftgrößen einsetzt und dabei denkt wie toll zugänglich der Text sei. Ist das wirklich so? Ich persönlich bin davon nicht mehr überzeugt. Ich habe mal testweise gesurft und dabei meine Brille abgesetzt. Ich gebe es zu, es ist schön wenn man den Text zoomen kann. So wie Geckos (Mozilla, Firefox etc.) dass immer machen und so wie IE das in manchen Fällen macht.

Schriftskalierung oder doch Seiten-Zoom

Noch viel sinvoller fand ich bei meinem Selbstversuch den Pagezoom (Lupen-Funktion) von Opera, denn da wird nicht nur der Text sondern auch Grafiken und Bilder vergrößert. Ist sehr nützlich bei grafischen Überschriften oder Funktions-Icons etc. Diesen Zoom soll auch Internet Explorer 7 bieten und für Firefox gibt es einen Zoom-Plugin.

Jetzt gibt es Leute, die sagen "Zoom ist böse, weil er bei sehr großen Vergrößerungen der horizontale Scrollbalken erscheint". OK, das ist nicht gut, aber wenn ich mal meine Brille verlegen sollte und ich dann trotzdem am Rechner arbeiten müsste, dann wäre meine kleinste Sorge das ich dann evtl. auch horizontal scrollen muss. Viel wichtiger wäre mir dabei, dass ich überhaupt arbeiten kann.

Hilfsmittel

Sehr interessant, bei meinem kleinen Selbstversuch fand ich die Lupe, die als Beigabe bei meiner neuen Microsoft-Maus dabei war:

Mit einem Mausklick auf der oberen Dauemntaste erscheint die Lupe, standardmäßig erscheint diese wie in dem oberen Screenshot. Wenn man die besagte Daumentaste gedruckt hält und die Maus bewegt, dann kann man die Lupenfläche vergrößern und wenn man die Scrolltaste bewegt, dann kann man den Zoom vergrößern bzw. verkleinern.

Mit diesem Tool, was an sich nichts besonderes ist, konnte ich viel gezielter Inhalte vergrößern als wenn ich im Browser nur die Schriften vergrößern würde. Und das ist nur der Anfang, jemand der eine bestimmte Sehschwäche hat und aus welchen Gründen auch immer auf einen Rechner angewiesen ist, derjenige wird schon wissen wie er sein System einzurichten hat und derjenige wird auch evtl. auf Hilfsmittel (z.B. eine Lupe) zurückgreifen müssen, da er mit seinem Problem nicht nur im Browser sondern auch in anderen Anwendungen zu kämpfen hat.

Jetzt will ich aber nicht, dass hier der Eindruck entsteht, dass diese Leute mir egal seien und das man sich um deren Belange nicht kümmern sollte. Was ich einfach bezweifle ist ob diesen Leuten das Konzept mit em als Einheit für Schriftgrade wirklich hilft oder ob wir uns einfach etwas einbilden und denken wie toll wir doch seien.

Fazit

Ein richtiges Fazit ist schwer zu ziehen, aber auf jeden Fall ist die Nutzung von Pixel bei der Angabe der Schriftgrößen in meinen Augen die richtige Maßeinheit … oder besser gesagt: es ist nicht falsch und es ist nicht böse Pixel als Einheit für die Schriftgröße zu verwenden.

Die Aussage, dass IE bei Verwendung von Pixel die Schriften nicht skalieren kann stimmt nicht wirklich. Zudem ist der Seiten-Zoom der Technik der Schriften-Skalierung (Schriften-Zoom) eh überlegen und wird sich auf die lange Sicht durchsetzen. Opera nutzt es schon länger, IE 7 hat es bereits implementiert und für die Geckos gibt es eine Erweiterung. Und wenn ein Browser Page-Zoom beherrscht, dann ist es wurscht ob die Schriftgröße in Pixel oder em angegeben wurde.

Aber eines bleibt trotzdem noch bestehen und zwar die Tatsache, dass man sich als Webworker immer Gedanken um die Zugänglichkeit der Website machen muss.

Verwandte Beiträge

• Die Linkschleuder (1)
• Datum in der URL eines Beitrages (33)
• Erklärung zu "Weblogs und Usability" (8)
• "Weblogs und Usability" als Download (10)
• Blogparade: was soll in die Sidebar? (73)
• Lesezeichen-Leisten: ja oder nein? (13)
• Druckvorschau, CSS und die Nutzer (11)
• Auflistung der Kategorien: erstes Fazit (11)
• Auflistung der Kategorien: ja oder nein? (28)
• Kommentare per E-Mail verfolgen (6)

© 2004-2008 Vladimir Simovic (aka Perun). All rights reserved - Alle Rechte vorbehalten.