Spaces. Smartes Cloud Hosting für anspruchsvolle Webprojekte. Loslegen und Spaces testen. Von Mittwald.
Gastautor 12. Juni 2008

Flexible Layouts – die Herausforderung der Zukunft

Kein Beitragsbild

Ein Gastbeitrag von Dirk Jesse, Erfinder von YAML, was im letz­ten Abschnitt deut­lich wird. Der Beitrag wur­de von Vitaly Friedman bear­bei­tet und erscheint dem­nächst in eng­li­scher Sprache im Smashing Magazine.

Die aktu­el­le Browsergeneration mit Firefox 3, Opera 9 und dem Internet Explorer 7 kommt mit einem Feature daher, wel­ches auf den ers­ten Blick die Arbeit für Webdesigner in der Zukunft um ein Vielfaches ein­fa­cher machen könn­te – dem Seitenzoom. Anstelle der Möglichkeit, die Schriftgrößen einer Webseite nach­träg­lich zu ver­grö­ßern, ska­liert die neue Technik das geren­der­te Layout samt Bildern und Hintergrundgrafiken pro­por­tio­nal. Dadurch wird jedes pixel­ba­sier­te Layout “ska­lier­bar”, Inhalte bre­chen nicht mehr aus ihre Boxen aus, Inhalte über­la­gern sich nicht plötz­lich, nur auf­grund des ein­ge­stell­ten Zoom-Faktors – rea­le Vorteile der neu­en Technik.

Doch ist die neue Zoomtechnik wirk­lich so vor­teil­haft, dass wir kei­ne fle­xi­blen Layouts mehr benö­ti­gen? In Blogs in aller Welt stel­len sich Webentwickler wie­der häu­fi­ger die “ewi­ge” Frage des Webdesigns und beant­wor­ten sie mit “Ja”. Die Entwicklung eines fixen Layouts geht dem Webdesigner leich­ter von der Hand, sie erlau­ben pixel­ge­naue Postionierung (der Traum vie­ler Grafiker) und der Anwender kann sich das Layout jeder­zeit auf sei­ne Wunschgröße zoo­men.

Ich den­ke nicht, dass die­ser Weg zu bes­se­ren und zugäng­li­che­ren Webseiten führt und möch­te des­halb in Erinnerung rufen, war­um fle­xi­ble Layouts heu­te und in der Zukunft mehr den je eine Daseinsberechtigung haben.

Wo der Seitenzoom nicht weiterhilft …

Der ent­schei­den­de Unterschied zwi­schen fixen Layouts (px-basiert) und fle­xi­blen Layouts (%-basiert) ist, dass Sie sich im Rahmen der vom Designer fest­ge­leg­ten Grenzen auto­ma­tisch der Breite des Browserfensers anpas­sen und sich dadurch ohne Zutun des Anwenders per­fekt an unter­schied­li­che Fensterbreiten und Ausgabemedien anpas­sen kön­nen. Fixe Layouts kön­nen dies nicht. Der Seitenzoom ermög­licht dem Anwender ledig­lich, die vom Browser geren­der­te Webseite nach­träg­lich in Eigeninitiative sei­nen Bedürfnissen anzu­pas­sen. Und beden­ken Sie auch, selbst heu­te noch hat der IE6 eine Verbreitung von ca. 40%, womit fast jeder zwei­te Anwender nicht ein­mal die­se Möglichkeit hat.

In der nahen Zukunft müs­sen wir laut w3schools.com mit höhe­ren Auflösungen als Standard rech­nen.

Noch pro­ble­ma­ti­scher ist das Vertrauen in den Seitenzoom und die Selbstständigkeit der Anwender aus Sicht der Barrierefreiheit, denn es trans­por­tiert unter­schwel­lig die Botschaft: Lieber Anwender, Dein Browser kann mein fixes Layout doch zoo­men – also hilf Dir selbst! Mit die­sem Argument ver­lei­tet sehr schnell, den beque­men Weg zu gehen auf Kosten der Zugänglichkeit. Denn ist dann unge­fähr so als gäbe es im Klamottenladen nur noch Hosen in Größe 32. Wem die nicht pas­sen, der darf sich gern auf dem Wühltisch kos­ten­los Stoffkeile, Nadel und Faden mit­neh­men und sich die Hose zuhau­se sel­ber umnä­hen. Und beden­ken Sie: Um ein fixes Layout mit einer Breite von 960 Pixeln auf 150% zu zoo­men und es wei­ter­hin ohne hori­zon­ta­le Scrollbalken genies­sen zu kön­nen, bau­chen Sie eine Auflösung von 1440px und einen Browser im Fullscreenmodus. Soll sich das Web wirk­lich in die­se Richtung ent­wi­ckeln?

Flexible Layouts sind zu auf­wän­dig und durch dem Seitenzoom wird eh jedes fixe Layout ska­lier­bar.

Richtig, es wird ska­lier­bar – aber eben nicht fle­xi­bel. Also war­um muss der Browser etwas kor­ri­gie­ren, was wir bei der Layouterstellung selbst in der Hand haben?

Flexible Layouts sind unkontrollierbar? Von wegen!

Wann immer jemand gegen fle­xi­ble Layouts argu­men­tiert, kommt fol­gen­de These zu Beginn jeder Diskussion:

Bei fle­xi­blen Layouts läuft der Text beim Aufziehen des Browserfensters unkon­trol­liert in die Breite, was ihn letzt­lich unan­sehn­lich und schwer les­bar macht.

Dieser Umstand ist sicher­lich unschön anzu­se­hen (s. Bild unten), doch Schuld dar­an ist der Ersteller des Layouts, nicht die fle­xi­ble Breite. Denn für attrak­ti­ves fle­xi­bles Webdesign hat der CSS-Gott die Eigenschaften min-width und max-width erschaf­fen. Und schon hören wir die Zwischenrufe, dass der IE6 die­se Eigenschaften doch nicht unter­stüt­ze. Na und? Der IE6 hat auch Eigenarten wie hasLayout und ein feh­ler­haf­tes Float-Modell. Hält das irgend jeman­den davon ab, Layouts für die­sen Browser zu erstel­len? Zur Simulation von max-width gibt es zahl­rei­ches Workarounds (JS Expressions), für min-width sogar eini­ge rei­ne CSS-Lösungen. Halt, Stop! JavaScript kön­ne deak­ti­viert sein! Auch das stimmt, jedoch wird ein fle­xi­bles Layout ohne max-width nicht auto­ma­tisch unbe­nutz­bar, es wird im schlimms­ten Fall etwas brei­ter – Progressive Enhancement ist doch wirk­lich was fei­nes, also setzt es doch auch ein.

So gestal­ten Sie die Breitenangaben eines fle­xi­blen Layouts opti­mal:

  • Layoutbreite: Verwenden Sie width:auto oder eine belie­bi­gen Prozent-Wert, damit sich das Layout auto­ma­tisch der ver­füg­ba­ren Breite des Browserfensters anpasst.
  • Minimale Breite: Verwenden Sie einen Wert in der Einheit Pixel (z.B.: 760px). Auf die­se Untergrenze soll­ten Sie alle pixel­ba­sier­ten Inhalte abstim­men, sodass sie auch bei mini­ma­ler Layoutbreite noch feh­ler­frei posi­tio­niert wer­den kön­nen.
  • Maximale Breite: Verwenden Sie hier­für einen Wert in der Einheit EM (z.B. 90em). Dadurch haben Sie den Textfluss immer unter Kontrolle, d.h. Absätze wer­den nicht über­mä­ßig breit. Gleichzeitig ska­liert der Maximalwert mit der Schriftgröße.

Und beden­ken Sie auch, wir haben als Webdesigner nicht wirk­lich die Kontrolle über das Layout. Über die Darstellung ent­schei­det maß­geb­lich der Anwender durch Browserwahl, Schriftgrößeneinstellungen (gern auch direkt über das Betriebssystem), alter­na­ti­ve Nutzer-Stylesheets und so wei­ter.

Ein fixes Layout lässt sich für den Rechner und Lieblingsbrowser des eige­nen Chefs oder des Auftraggebers opti­mie­ren, aber eben nicht für die gren­zen­lo­se Vielfalt der Nutzeranforderungen im Internet.

Die heilige Photoshop-Vorlage …

Das wohl häu­figs­te Argument für den Einsatz fixer Layouts sind die Photoshop-Vorlagen der Grafiker und der Wunsch des Auftraggebers nach pixel­ge­nau­er Umsetzung. Da sei kein Spielraum für Diskussionen oder Abweichungen von der Vorlage. Dieses Argument wiegt wirt­schaft­lich gele­gent­lich schwer, doch es ist mit Sicherheit nicht immer im Sinne der Anwender.

Das Layout soll ja nach der Fertigstellung nicht nur einen schö­nen Screenshot im eige­nen Portfolio abge­ben son­dern dem Anwender einen mög­lichst attrak­ti­ven und gleich­zei­tig unge­hin­der­ten Zugang zu den Informationen der Seite bie­ten. Werfen Sie einen Blick in eine der zahl­lo­sen CSS-Galerien tes­ten Sie die ver­link­ten Layouts. Nur all­zu oft ver­blasst die Attraktivität pixel­ba­sier­ter Designs im Angesicht der Funktion zur Schriftskalierung im Browsers. Texte wer­den abge­schnit­ten oder bre­chen aus dem Layoutraster aus, dass ledig­lich durch opu­len­te Hintergrundgrafiken vor­ge­gau­kelt wird. Nicht in jedem Fall lässt sich eine Designvorlage in ein fle­xi­bles Layout umwan­deln aber in vie­len Fällen ist es den Versuch oder zumin­dest eine Überlegung wert. Transparenzen, klein­for­ma­ti­ge Muster, geschickt als Hintergrundgrafiken ver­wen­de­te Farb- und Graustufenverläufe kön­nen in Zusammenarbeit mit einem guten Grafiker zu exzel­len­ten Ergebnissen füh­ren.

In den meis­ten Fällen ent­wer­fen wir Webseiten nicht, um ein Design zu prä­sen­tie­ren, son­dern mit­hil­fe des Designs sol­len Inhalte best­mög­lich prä­sen­tiert wer­den. Grafisch anspruchs­vol­le fle­xi­ble Layouts ver­lan­gen sicher­lich ein höhe­res Maß an Planung und Verständnis für die mög­li­chen Schwierigkeiten bei Grafikern und Webdesignern. Aber die­sen Aufwand kommt allen Anwendern zugu­te und macht das Design ein gro­ßes Stück medi­en­un­ab­hän­gi­ger.

Handy-Browser – Denn sie wissen nicht, was sie tun

Nun ja, über das Thema Mobiles Internet und die damit ver­bun­de­nen grö­ße­ren und klei­ne­ren Probleme lässt sich sicher end­los phi­lo­so­phie­ren. Noch vor einem Jahr hat­te mein dama­li­ges Handy zwar Internet-Zugriff, war zum brow­sen jedoch kaum zu gebrau­chen. Dank mei­nes iPhones hat sich dies mitt­ler­wei­le gra­vie­rend geän­dert. Noch vor nicht all­zu lan­ger Zeit war das CSS Mobile Profile mit dem Medientyp @media handheld der erhoff­te Heilsbringer, doch bis heu­te unter­stützt kaum ein Handy die­sen Standard. Und mal ehr­lich: wir wol­len auch gar kei­ne abge­speck­te, und schlecht opti­mier­te Online-Version sehen. In den letz­ten zwei Jahren haben Mobilbrowser (z.B.: Opera Mini oder Safari auf dem iPhone) stark auf­ge­holt und ren­dern mitt­ler­wei­le ganz selbst­ver­ständ­lich das nor­ma­le Screenlayout – weit­ge­hend feh­ler­frei, ver­steht sich. Mein iPhone, zum Beispiel, passt fle­xi­ble Layouts auto­ma­tisch opti­mal dem Hoch- oder Querformat an, wäh­rend wir Seiten mit fixem Layout ein ums ande­re Mail auf­zoo­men müs­sen, damit sie den Bildschirm voll aus­fül­len. Und was für mobi­le Geräte gilt, gilt eben­so für Drucker: Nur komi­scher­wei­se wider­spricht hier in der Regel nie­mand, wenn man von den Vorteilen der Flexibilität bei der Druckausgabe redet – obwohl es sich für den Browser nur um ein wei­te­res Ausgabemedium mit etwas ande­ren tech­ni­schen Daten dar­stellt. Woran das wohl liegt? Durch fle­xi­bles Design kann bei der Druckausgabe das Blattformat (Portrait / Landscape) opti­mal aus­ge­nutzt wer­den.

Der Verzicht auf ein fixes zuguns­ten eines fle­xi­blen Layouts ver­bes­sert also nicht nur die Zugänglichkeit am Desktop-PC son­dern bewirkt ohne zusätz­li­che Handgriffe eine weit­ge­hend medi­en­un­ab­hän­gig robus­te und feh­ler­freie Darstellung. Denn durch Vorgabe von fle­xi­bler Gestaltungsregeln (Relative Maßeinheiten, Mindestabstände, Ausrichtung usw.) anstatt fes­ter Pixelvorgaben, kann der Browser beim Rendering auf die Wünsche des Nutzers bzw. auf die Eigenheiten des Ausgabemediums ein­ge­hen.

Die Zukunft, das unentdeckte Land

Wie eben ange­spro­chen, das mobi­le Internet wird immer wich­ti­ger wer­den. Fangen wir des­halb wie­der an, Layouts für 640x480 oder 800x600 Pixel zu opti­mie­ren, oder? Die Bildschirmauflösungen wach­sen rasant, die Preise für hoch­auf­lö­sen­de LCDs fal­len wei­ter. Parallel dazu steigt eben der phy­si­ka­li­sche Auflösung der Geräte auch die Punktdichte (dpi) immer wei­ter, wodurch sich die abso­lu­te Größe eines Pixels zusätz­lich ver­rin­gert. Es ist daher nicht ver­wun­der­lich, dass pixel­ba­sier­te Größenangaben immer weni­ger aus­sa­ge­kräf­tig und zeit­ge­mäß sind.

Die Schere zwi­schen nied­rig- und hoch­auf­lö­sen­den Ausgabemedien hat sich in den letz­ten 10 Jahren nicht geschlos­sen. Ganz im Gegenteil: Sie geht immer wei­ter auf. Allein schon die­ser Fakt ver­deut­licht, wie wich­tig fle­xi­ble Layoutansätze heu­te und in der Zukunft sein wer­den und wie wenig hier fixe Layouts in Zukunft noch ein Optimum für die Mehrheit der Nutzer sein wer­den. Wir brau­chen rela­ti­ve Maßeinheiten im Webdesign, wenn wir die­se Vielfalt im Griff bekom­men wol­len.

Ein Lösungsansatz … YAML

YAML (“Yet Another Multicolumn Layout”) ist ein (X)HTML/CSS Framework, das spe­zi­ell für die Anfordungen fle­xi­bler Layouts ent­wi­ckelt wur­de. YAML wur­de erst­mals im Oktober 2005 ver­öf­fent­licht, damals noch aus­schließ­lich in deut­scher Sprache. Seit Juni 2007 steht das Framework in der Version 3 mit einer Dokumentation in Englisch und Deutsch zur Verfügung. Die meis­ten CSS-Frameworks wie etwa Blueprint CSS oder YUI Grids stel­len dem Anwender ein System aus CSS-Klassen zur Verfügung, mit denen er auf ein­fa­chem Wege Grid-basier­te Layouts erstel­len und nach sei­nen Vorstellungen optisch gestal­ten kann. Dabei erstellt der Anwender sein Layout, indem er eine HTML-Struktur ent­wirft und die CSS-Klassen des Frameworks den Containern zuord­net, vom CSS Raster hält er sich hin­ge­gen fern.

YAML geht einen ande­ren Weg. Das Framework unter­stützt sowohl die Erstellung spal­ten­ba­sier­ter Layouts als auch die Erstellung eines Grids – jeweils mit dem Focus auf fle­xi­ble Layouts. Für spal­ten­ba­sier­te Layouts stellt es eine Quelltextstruktur mit 3 Spalten, Header und Footer zur Verfügung, die vom Anwender durch Löschen nicht benö­tig­ter HTML-Elemente an sei­ne Wünsche ange­passt wer­den kann. Die eigent­li­che Gestaltung, die Anordnung der Spalten (Stichwort: any orde­red columns) erfolgt aus­schließ­lich per CSS. Klarer Vorteil für den Designer ist die Gestaltungsfreiheit und freie Wahl der Maßeinheiten. Auf der Grundlage der HTML-Struktur fängt YAML den Großteil der bekann­ten IE-Bugs prä­ven­tiv ab, und erlei­chert damit die Layouterstellung und das Bugfixing für eine Vielzahl mög­li­cher Layoutvariationen.

Einen Überblick über die grund­sätz­li­chen Positionierungsmöglichkeiten lie­fern die mit­ge­lie­fer­ten Layoutbeispiele. Weiterhin stellt YAML ein Set an fle­xi­blen, ver­schach­tel­ba­ren Grid-Bausteinen zur Verfügung, mit denen die Raumaufteilung inner­halb der Spalten wei­ter unter­glie­dert wer­den kann oder mit des­sen Hilfe kom­ple­xe fle­xi­ble Grid-Layouts erstellt wer­den kön­nen. Als Beispiel kön­nen Sie sich die Demo-Seite von Blueprint CSS anschau­en, die von von Dirk Jesse mit­hil­fe der fle­xi­blen Grid-Elementen von YAML nach­ge­baut wur­de: über­zeu­gen Sie sich selbst. Die Skalierung funk­tio­niert selbst im IE 5.5, samt min-width und max-width. Neben der Layoutgestaltung lie­fert YAML Stylesheets für das Drucklayout, sowie Bausteine zur Erstellung fle­xi­bler hori­zon­ta­ler und ver­ti­ka­ler Navigationen.

YAML erfor­dert auf­grund sei­ner Funktionsvielfalt und der Komplexität fle­xi­bler Layouts zwangs­läu­fig eine gewis­se Einarbeitungszeit. Das Konzept hin­ter YAML wird jedoch in der Online- und PDF-Dokumentation aus­führ­lich erläu­tert, um den Anwender mit den zahl­rei­chen Features und Freiheiten, sowie deren effek­ti­vem Einsatz ver­traut zu machen. Für die prak­ti­sche Anwendung des Frameworks und schnel­le Ergebnisse steht zusätz­lich mit dem YAML-Builder ein prak­ti­sches visu­el­les Werkzeug bereit, mit dem Anwender die Quelltextstruktur und grund­le­gen­de CSS-Einstellungen in einer kom­for­ta­blen Drag & Drop-Oberfläche ent­wer­fen kön­nen. Der YAML-Builder gene­riert auf Knopfdruck den HTML- und CSS-Code Layouts, ein­schließ­lich der JS-Expressions für die Simulation von min-width und max-width (eben­falls für belie­bi­ge Maßeinheiten).

46 Kommentare

  1. Man kann z.B. in “Artisteer” unter “Layout” die Seitenbreite fix oder “flu­id” ein­stel­len, aller­dings sind die Ergebnisse nicht per­fekt.

    Man muss zum einen die Breite in Prozent ange­ben, und dann die mini­ma­le und maxi­ma­le Breite.

    Ich tes­te­te es mit 100%, min. 648 und max. 972, und expor­tier­te zum WordPress-Theme.
    Das wären 720 bis 1080 minus 10%.
    Das Menü soll nicht bis an den Rand rei­chen.
    Evtl. habe ich da auch was falsch ver­stan­den.
    Auf 1024x768 sind zwar alle Menüelemente zu sehen, aber der Menübalken geht bis an den Rand.
    Und der Webseitentitel ist links und Rechts aus dem Bild.
    Und das, obwohl es 1024 Breite ist.

    Wenn man aller­dings das Browserfenster mit der Maus in der Breite ver­klei­nert, dann schal­tet er irgend­wann auf eine alter­na­ti­ve Ansicht um.
    Die zwei Wörter des Titel ste­hen dann unter­ein­an­der, und die Menüelemente sind über einen zen­tra­len Button zu öff­nen.
    Das kann man für die klei­ne­ren Auflösungen noch akzep­tie­ren, bes­ser als feh­ler­haf­te Darstellung.
    Allerdings pas­siert das auch wenn man auf einem Samsung-Windows-Tablet hoch­kant dreht, und die Native Auflösung ist 1366x768. Also über dem Minimum.

    Gibt es aktu­ell DIE emp­feh­lens­wer­ten Werte für Prozent, Minimum und Maximum?

    Die Alternative ist die fixe Breite.
    Z.B. 720, bzw. 648 (-10%), damit der Menübalken nicht bis zu den Seiten geht. Unter 648 Breite haben die Nutzer dann halt mobil Pech gehabt.
    Ja, der Webseitentitel soll noch etwas über Anfang und Ende des Menübalken ragen.
    Allerdings wird es dann auch eng mit der Anzahl der Menüs.
    Man muss für die Elemente auch noch das “Horizontale Padding” (Abstand zwi­schen den Menüpunkten) wäh­len.
    Wenn man bis zum Maximum geht (eine Stufe bevor der letz­te Menüpunkt in eine neue zwei­te Zeile rutscht), ist das Problem dass wenn man z.B. per “qtrans­la­te x” eine Übersetzung der Menüpunkte vor­nimmt, nur ein Buchstabe mehr (z.B. Medien statt Media) dafür sorgt, dass nun dort die Darstellung auf zwei Zeilen ver­teilt wird.
    Mit dem Webseitentitel über den Menüpunkten, so dass sie nicht mehr anklick­bar sind…
    Also nicht nur ein opti­schen Problem (aber schon das sieht übel aus).

    Wenn die Browser heu­te ska­lie­ren kön­nen, dann soll­te das auch auto­ma­tisch gesche­hen, statt eine Webseite zu ver­un­stal­ten.
    Man könn­te ja in die Knopfleiste des Browser einen dann blin­ken­den Knopf mit einem kur­zen “Baloon-Hinweis” ein­bau­en, dass der Nutzer es dann deak­ti­vie­ren kann. Diese Deaktivierung wird dann im Browser für die­se Seite bei der Bildschirmauflösung gespei­chert.

  2. Lustig!

    solan­ge es um bau­ern­sei­ten wie doc­tor web geht
    is es doch egal ob fix oder flex.

    wür­den die pro­gra­m­ie­ren und die her­stel­ler sich zusam­men set­zen-gäbe
    es die­se stein­zeit­brow­ser gar nicht mher-und eine comon uni­ver­sal spra­che
    wür­de die abso­lu­te frei­heit der gestal­tung erlau­ben.
    ein­schal­ten-gucken-aus.
    99% der inte­net­sei­ten sind auf 2 designs zurück zu füh­ren-und gera­de die
    css-ler qat­schen den gan­zen tag- geht doch..
    und in 3 oder 4 jah­ren war alles nur noch app-kei­ne sau wird mehr
    web oder so… vor­ges­tern. echt vor­ges­tern.

  3. Toller Ansatz, vie­len Dank!

  4. Interessante Diskussion…aber auch mir ist nicht bekannt, dasBilder ver­nünf­tig ska­liert wer­den können…somit ist ein kom­plett fle­xi­bles Layout recht schwie­rig

  5. Ist zwar arg spät, aber ich habe es heu­te erst ent­deckt wäh­rend mei­ner Suche nach Artikel über Layouts in em.

    Als Erstes sor­ry für die Rechtschreib- und Grammtikfehler, aber ich bin Niederländer.

    Ich muss ers­tens sagen, dass der Artikel mich sehr inter­es­siert hat, aber dass es auch wirk­lich die Verherrlichung von YAML ist. Fast reli­gi­ös…

    Ich bin kein Freund von pixel­ge­naue Layouts und die habe ich so unge­fähr vor 4 Jahren langsa,m aber ste­tig den Rücken gekehrt.

    Bis Dato habe ich mei­ne Webseiten in % erstellt, was zur Folge hat dass mei­ne Freunde (die sich nun wirk­lich alle mit der Handhabung eines Computers aus­ken­nen) mir sag­ten dass es tie­risch nervt, wenn sich dann Texte in die “Ewigkeit” zie­hen.

    Ich den­ke wirk­lich dass man eine gewis­se Breite des Designs ruhig fest­le­gen darf, damit User die mit 1024x768 durch das Internet hop­peln, die Seite kom­plett ohne Scrollbalken am unte­ren Fensterbrowser sehen. Die Leute, die dann unbe­dingt mit 1600 Bildschirmauflösung mit maxi­ma­le Fenstergrösse Surfen müse­en, haben dann echt Pech gehabt.

    Auch mit ein min-width & max-width lege ich “Grenzen” fest und “bevor­mun­de” den User. Aber wenn ein Verlag in bestimm­tes Buch in eine extrem klei­ne Schriftgrösse druckt, kann der geschätz­te Leser auch nicht irgend­wo auf dem Buchrücken ein Knöpfchen drü­cken und die nach sei­nen bedürf­nis­se anpas­sen.

    Was die Barrierefreiheit anbe­langt, fin­de ich lang­sam dass es zur hys­te­rie wird. Man benimmt sich mitt­ler­wei­le der­mas­sen bemut­ternd, als ob jeder mit ein Handycap leicht debil wäre.

    Falsch! Derjenige kann nicht sehen (oder sieht anders als die meis­ten Menschen) oder er kann sei­ne Motorik nicht kon­trol­lie­ren. Das macht ihm aber nicht geis­tig min­der­be­mit­telt! Und ich bekom­me das Gefühl, dass Viele sagen “Ach der arme klei­ne Blinde/Spastiker. Er kann nicht mit­ma­chen. Na dann sind wir doch nett und las­sen ihm auch spie­len.”

    Das ken­ne ich von mei­nem Ex-Freund der als Verkäufer gear­bei­tet hat und der sich immer auf­reg­te, wenn die Begleitperson sag­te was der Mann im Rollstuhl für eine Hose will, ohne dass der Mann im Rollstuhl zu Wort kam. Danns agte mein Ex “Wollen Sie die Hose, oder der Herr? Dann kann ich mich ja mit ihm unter­hal­ten. Er kann zwar nicht lau­fen, aber sehr wohl reden, oder?”

    Mittlerweile glau­be ich, dass vie­le Webdesigner nur zei­gen wol­len “Schau her! Ich kann bar­rie­re­freie Webseiten bas­teln! Bin ich kein Crack? bewub­dert mich”, anstatt wirk­lich den Anspruch zu haben, es eine Gruppe von Internetuser zu erleich­tern Informationen zu erhal­ten. So wie vor ein paar Jahren jeder unbe­dingt ein Flash-Intro haben muss­te, nur um zu zei­gen dass er ein biss­chen Flash gese­hen hat.

    Menschen mit einer kör­per­li­chen Behinderung sind genau so blö­de oder genau so intel­li­gent wie jeder ande­re Internetbesucher. Mit dem Unterschied, dass die­se Leute meis­tens spe­zi­el­le tech­ni­sche Vorrichtungen haben die das Surfen im Internet für Ihre kör­per­li­che(!) Einschränkungen kom­for­ta­bler machen.

    Ich wage sogar zu behaup­ten, dass die­se User ein Tick pfif­fi­ger unter­wegs sind als der Otto Normalsurfer, weil sie wis­sen wie ein­ge­schränkt sie sind und Erfahrung damit haben.

    Überdies ist es völ­lig egal ob eine Seite pixel­ge­nau oder flu­id gestal­tet wur­de, denn es kommt auf die Sturkturierung das (X)HTML Dokuments an, weil die User die wirk­lich Blind sind und ein Screenreader ver­wen­den, sowie­so kei­nen Schimmer haben, wie die Seite aus­sieht… Und wenn alles in dem Dokument ordent­lich geglie­dert und eine logi­sche Reihenfolge hat und die rich­ti­ge Tags (H1, Q, abbr, ect.pp) ein­gest­zt wur­den und man bei Links einen Title, bei Bilder einen alt mit­gibt und irgend­wo oben skip-links ein­baut, ist alles wun­der­bar.

    Man kann es ansons­ten wirk­lich über­trei­ben mit der Rücksichtnahme und wenn man wirk­lich nur noch dar­auf ach­tet, lei­det der Besucher ohne Behinderung weil man in sei­ne Gestaltung sehr ein­ge­schränkt ist.

    Was “nor­ma­le” User angeht, habe ich kei­ne Illusionen. Der durch­nitts User denkt dass Windows ein Browser ist (“Welchen brow­ser nut­zen Sie?” “Windows” *heul*) und nicht Wenigen geben bei Google die kom­plet­te URL ein um auf eine Seite zu gelan­gen.

    Es gibt erschre­ckend vie­le Menschen die nicht mal copy-and-pas­te ken­nen und die “komi­sche Knöpfchen” im Browser haben sie zwar gese­hen, aber “da gehe ich nie ran, man weiss ja nicht was man alles kaputt­ma­chen kann”. Viele User haben regel­recht Angst vor dem PC und den­ken bei jeden Tastendruck oder Buttonklick, dass sie etwas “kaputt machen” kön­nen.

    Eine ande­re Sache ist die der Browser selbst. Wenn es nach eini­gen Webdesigner gin­ge, wür­den wir noch für Netscape 4.7 und IE3 Seiten bas­teln.

    Dann neh­men wir doch mal die bei­spie­le WII und was es sonst nich an Spielie-Dingsies gibt. Dort bekommt man haar­ge­nau vor­ge­schrie­ben, wel­chen TEUREN Software man gefäl­ligst zu kau­fen hat, damit man das TEURE Spiel auch spie­len kann. Es wird ÜBERHAUPT kei­ne Rücksicht genom­men und der Kunde bekommt “Friss’ oder stirb!” gesagt.

    Genauso mit Fernsehenr, DVD- oder Blu-Ray-Player. Entweder packst Du die bedie­nung, oder du hast Pech gehabt.

    Aber wir müs­sen jeden Trottel gefal­len und jeden User, der sich zwar den feins­ten Laptop kauft, aber sich nicht damit befasst, es so ein­fach wie mög­lich machen. Dan soll er sich auch den neu­et­sen Browser run­ter­la­den, die GRATIS ist. Man kann ja Firefox anprei­sen auf sei­ne Webseite und sogar die Vorzüge in einem Artikel kund­tun.

    Ich bin dafür, dass man ein default.css macht und par­al­lel (je nach­dem wie de Farben des default Design sind) ein Design mit gros­sen Kontrast, die man mit­tels ein Styleswitcher akti­vie­ren kann (Ich weiss, das geht über JS und funzt nicht wenn das deak­ti­viert ist, und IE Nutzer sind dann arm dran. Aber man ein­fach nicht ALLEN Herren die­nen!). Darüberhinaus mache ich ger­ne ein Print.css die nur die Hauptbeiträge zeigt. Diesen wand­le ich dann noch­mal um, sodass auf die “zwei­te” Version die Navigation zu sehen ist (als ein­fa­che Textlinks ganz oben am Dokument). Die ermög­licht dann Besucher die Texte ohne Bilder (aus­ser die in den Beiträge) zu lesen und durch die bei­trä­ge der Website zu sur­fen.

    Ansonsten tes­te ich mei­ne Seiten in Lynx, den IBM-Screenreader und las­se mit­tels klei­ne Porgramme die Farben tes­ten für User die Blau-, Rot-, Grün- oder Farbblind sind oder die grau­en Star haben (Colour Contrast Analyzer. Nettes Tool!). Und natür­lich das Web Developer Tool, Firebird und Fangs für Firefox.

    Was viel­leicht nicht schlecht wäre, wäre ein Browser Tutorial mit ein paar Screenshots und die Anleitung wie man IE und Co bedient. Da könn­te man dann auch die Features der Seite erklä­ren. Damit die User nicht dumm ster­ben ;-)

    Meiner Meinung nach hat man dann alles gemacht was im Machbaren ist. Schliesslich kann man noch 10.000 ande­re Aspekte berück­sich­ti­gen und jedes ein­zel­ne Feature muss man dann in 9 brow­sern tes­ten (wenigs­tens mache ich das so) und ist dann drei jah­re an einem Projekt am ackern.

    So, nun wer­de ich mich mal wie­der um das küm­mern was ich gera­de suche ;-)

    Rob

  6. Halte die Grundmessage zwar für rich­tig,
    fin­de aber auch eini­ge Aussagen durch­aus frag­wür­dig.

    Auf der einen Seite sol­len wir den IE 6 igno­rie­ren, weil er max-width und min-width nicht unter­stützt, aber doch bit­te fle­xi­ble lay­outs unter­stüt­zen, weil 60% IE 6 nut­zen und dem­nach noch nicht die über­ar­bei­te­te Zoomfunktion nut­zen kön­nen. Wiederspruch!

    Nächstes Problem, wir sol­len die max-width in em ange­ben. Hier spal­ten sich die Geister, auf 456bereastreet.com (eigent­lich sehr ange­se­hen) wur­de vor kur­zer Zeit gesagt, man sol­le die max-width in % ange­ben, weil em bei der Vergrößerung der Schriftgröße (wir errin­nern uns, Problem der 60%) das Layout über die Seite hin­aus wächst. Hier ist es zwar als max-width ange­ge­ben, aber was hilft das, wenn wir damit die maxi­mal gren­ze ins uner­mess­li­che wach­sen las­sen. Ergo die Zeilen wer­den unglaub­lich lang.

    Letztes Problem, es wird zwar abge­strit­ten, aber fle­xi­ble Layouts haben immer einen sehr eige­nen Charakter. Gewisse Elemente las­sen sich ein­fach nicht fle­xi­bel umset­zen. Ebenso haben gefix­te oder em-Layouts einen spe­zi­el­len Charakter. Wenn ich eine Website haben will, die dem fle­xi­blen Charakter wider­spricht, dann muss ich ein gefix­tes neh­men. Ich bin hier also ande­rer Meinung als der Autor, nicht jede Art von Design lässt sich fle­xi­bel umset­zen.

    Noch ein Zusatz, die mobi­len Browser wer­den zuneh­mend bes­ser, eben­so wie die “nor­ma­len” Browser sel­ber. Ich bez­wei­le das ein paar bekehr­te Webdesigner den Mainstream schnel­ler ändern, als die Programmiere die Interpretation der Browser.

    Zum Abschluss möch­te ich erwäh­nen, dass der Autor mit Barrierefreiheit in den Kampf zieht. Sozusagen die Trumpfkarte eines jeden Autors, nie­mand darf wider­spre­chen, denn es geht um die armen Minderbemittelten. Ganz im Ernst, ich habe noch nie einen solch schlech­ten Platz gese­hen um Barrierefreiheit als Argument zu ver­wen­den. Mag sein, dass eini­gen Leute damit gehol­fen wird, aber im Ernst, dadurch dass man die Verantwortung des Zooms dem Nutzer ent­zieht, ent­zieht man dem erfah­re­ne­ren Nutzer auch die Kontrolle. Ein Browser der ledig­lich die Schriftgröße ändert und nicht wirk­lich zoomt, kann ein 100% Layout nicht klei­ner machen. Ich den­ke man soll­te den Leuten eher bei­brin­gen, die ihnen gege­ben Werkzeuge rich­tig zu nut­zen, als sie wei­ter­hin “dumm” zu las­sen und Ihnen Verantwortung aber auch Kontrolle zu ent­zie­hen! Das ist das Prinzip, wel­ches Windows bzw. Microsoft seit sei­nen Anfängen ver­folgt und mal im Ernst… wer von den Menschen die es beur­tei­len kön­nen mag Windows??? (Verständlich erklärt?! :P)

  7. Leider kann ich als Webdesigner nicht immer alles so gestal­ten, wie ich es ger­ne möch­te. Die meis­ten gro­ße Firmen haben ihr Corporated Design. D.h., sie wol­len oft pixel­ge­naue Seiten erstellt haben. Schrift, Farbe, Ausrichtung, Hintergrund, Linkfarbe usw. sind deter­mi­niert, sie müs­sen den gedruck­ten Vorlage so nahe kom­men, wie mög­lich. Wenn dann noch vie­le Bilder rein­kom­men erüb­rigt sich die fle­xi­ble Aufteilung meist sowie­so.

    Außerdem nervt mich auch manch­mal, wie flic schreibt, dass Seiten wie Spiegel, Sueddeutsche, Zeit, Focus usw. sich nur auf die Bildschirmmitte kon­zen­trie­ren. Heutzutage benut­zen über 90% der User eine Auflösung von min­des­tens 1024x768. Da soll­ten die nicht so viel Platz “ver­schen­ken”.

    Clauso

  8. Scheinenja vie­le Webdesigner hier ihre Kommentare zu hin­ter­las­sen. Ich gebe mal mei­ne Meinung als Surfer ab.

    Ich benut­ze einen 20″-Bildschirm mit 1600x1200er Auflösung. Alles im Vollbild-Modus, da mich ein­zel­ne Fenster nur ablen­ken (habs pro­biert, geht ein­fach nicht).

    Mit den Voraussetzungen hat man gute Chancen auf einem Großteil der Seiten von Leere ange­starrt zu wer­den. Bei klei­nen Blogs und ande­ren Seiten, wo nur kur­ze Texte ste­hen ist das ok.

    Wenn ich aber auf einer Nachrichtenseite eine län­ge­ren Artikel lese nervt es ein­fach nur. Alle Großen (Spiegel, Sueddeutsche, Zeit, Focus, …) sind extrem schmal (meist 800px) und auch noch links ange­ord­net. Der eigent­li­che Text ist durch Werbung/Navigation noch­mal schma­ler, zieht sich dafür aber ewig lang nach unten. Da könn­te der Textbereich auf einem brei­ten Bildschirm schon etwas grö­ßer sein. Muss ja nicht die gan­ze Breite aus­fül­len. Alternativ könn­te man ja auch ein Layout ent­wi­ckeln wo, wie in der gedruck­ten Zeitung, der Artikel in Spalten auf­ge­teilt ist. Je nach Größe des Bildschirms ste­hen dann halt 1,2 oder 3 Spalten ein und des­sel­ben Textes neben­ein­an­der.

    Allgemein gefällt mir der fle­xi­ble Ansatz mit Mindest- und Maximalbreite sehr gut. Sicher nichts für gra­phisch aus­ge­fal­le­ne Seiten, aber etwas wo der Text und Inhalt im Vordergrund steht.

  9. Ich würe jedem geplag­ten Umsetzer emp­feh­len, die beschränk­ten Möglichkeiten der CSS back­ground pro­per­ty rich­tig aus­zu­lo­ten, und sei­mem Pixelgestalter die Konfliktherde beim Wachsen und Schrumpfen zu kom­mu­ni­zie­ren – für jedes GUI-Element. Zum abschre­cken­den Beispiel zer­schos­se­ner Layouts käme dann der Satz: „Guck mal, so könn­te dein Pixelwunder aus­se­hen, wenn .. weil ..“

    Wer sich aus­gie­big den CSS ems, %en, und floats aus­setzt, fin­det nach etli­chen Mühen die poten­ti­ell elas­ti­schen Stellen im Layout – dif­fe­ren­ziert, pro­fes­sio­nell halt.

    Professionell ist auch das Bewusstsein, dass die visu­el­le Wirkung gar nicht da wäre, wenn sie den Weg durch eini­ge Programmroutinen, die bewer­ten, klas­si­fi­zie­ren, indi­zie­ren, fil­tern, etc. nicht über­stan­den hät­te. Ein paar Gedanken zur Semantik des Markups, der auch in andern Klamotten das Liedchen wie­der­auf­find- und -erkenn­bar wie­der­ge­ben kann, sind sicher nicht ver­schwen­det.

  10. schön wäre auch, wenn das fle­xi­ble umset­zen von lay­out auch per­fekt funk­tio­nie­ren wür­de
    doch lei­der ist das auf­grund der brow­ser nicht mög­lich
    ich habe schon auf­wen­di­ge sei­ten fle­xi­bel ange­fan­gen, bin aber an vie­len stel­len geschei­tert

    lag es an run­dungs­feh­lern von fire­fox, das lay­outs beim ver­grö­ßern dann irgend­wann doch zer­bro­chen sind
    oder stei­fe goog­le wer­bung, die immer gleich groß blieb…

    und am ende inter­es­siert es doch kein schwein, ob es ein fle­xi­bles lay­out ist
    bzw. bezah­len tut den auf­wand kein schwein

    der grund­ge­dan­ke ist aber an sich schon rich­tig
    (so wie für opfer von natur­ka­ta­stro­phen spen­den auch)

  11. Nutze schon seit eini­ger Zeit YAML und bin sehr zufrie­den damit! Die Entwicklung läuft rei­bungs­lo­ser und schnel­ler ab. Kann ich jedem nur emp­feh­len.
    LG

  12. Der Ansatz ist ja rich­tig, hat­te mir beim Css Design für Typo3, auch schon mei­ne Gedanken dazu gemacht. Die Möglichkeiten stel­len aber noch kein wirk­lich befrie­di­gen­des Ergebnis dar. Zufällig gera­de gese­hen, dass in der Zeitschrift “PhP Journal” auch ein schö­ner Beitrag zum Thema drin ist-spon­so­red by Yaml ;) . Naja trotz­dem, über fle­xi­ble Layouts soll­te man sich im Auge behal­ten.

  13. Ups.… So einen aus­führ­li­chen Beitrag habe ich hier noch nie ent­deckt und dafür Respekt, auch wenn die­ser von Dritten stammt.

    Das Thema ist wirk­lich sehr inter­es­sant. Dies ist in mei­nen Augen auch an der Anzahl und der Qualität der Kommentare sicht­bar.

    Ich selbst nut­ze schon län­ge­re Zeit fle­xi­ble Layouts und habe wahr­schein­lich eher Probleme mit fixen ;)

    Ralph

  14. @Sarah
    Neben dem von Jochen bereits erwähn­ten Blitzblank-Theme gibt es wei­te­re WordPress-Umsetzungen mit YAML bei Michael Preuß. Er hat einer­seits ein Tutorial zur Integration von YAML in WordPress ver­fasst und vor weni­gen Wochen auch ein sehr viel­sei­tig kon­fi­gu­rier­ba­res Theme mit dem Namen “YAML Green Theme” ver­öf­fent­licht. Beides ist sicher einen nähe­ren Blick wert.

    Und auch für ande­re CMS-Systeme (Typo3, Drupal, Joomla ect.) haben sich enga­gier­te Entwickler gefun­den, die ihrer­seits ein­satz­fer­ti­ge YAML-Implementationen ent­wi­ckelt haben und der Community bereit­stel­len.

    Gruß
    Dirk

  15. @sarah

    Ja es gibt Umsetzungen für YAML und WordPress, dar­über habe ich hier schon mal geschrie­ben: http://www.drweb.de/weblog/weblog/?p=907

    Beachte aber den Kommentar, das dort ange­spro­che­ne Theme “blitz­blank” gibt es mit­ler­wei­le in der Version 2

  16. Auch nicht die eier­le­gen­de …, aber ein inter­es­san­ter Ansatz für fle­xi­bles Layout bei unter­schied­li­chen Bildschirmgrößen, wie er bei Gerrit van Aaken zu fin­den ist: http://praegnanz.de

    Einfach mal mit dem Browserfenster spie­len, Schriften ska­lie­ren und am Fensterrand zie­hen. Geht in dem Fall ganz ohne JS.

  17. Finde die Argumente stel­len­wei­se zu “Akademisch”. Gerade das “ewi­ge Vollbild” set­ze ich beim brow­sen mit hoher Auflösung bewußt nicht ein. Und dann am Ende plötz­lich die­ser Text über yaml. Da erscheint mir der gan­ze Beitrag doch eher wie Werbung! Außerdem: die Layoutbeispiele von yaml ver­wen­den bewor­be­ne Technik über­haupt nicht!

  18. Dieser Gastbeitrag von Dirk Jesse sorgt für kon­tro­ver­se Kommentare. Zu Recht! In den Köpfen vie­ler Webseitenersteller ist bis heu­te nicht ange­kom­men, dass fle­xi­ble Layouts die Besucher von Webseiten weni­ger bevor­mun­den und sich mit fle­xi­blen Layouts auch bar­rie­re­är­me­re Webseiten rea­li­sie­ren las­sen.

    Damit die Lesbarkeit nicht zu sehr lei­det, kann man min-width und max-width sowie ent­spre­chen­de Workarounds für den alten IE 5 bis 6 ein­set­zen.

    Fotos und Grafiken wie Icons kann man eben­falls ska­lier­bar machen, auch wenn die ska­lier­te Darstellungsqualität natür­lich nicht an die Originalauflösung kommt.

    Die von Jens in den Kommentaren 7. und 8. genann­te Lösung Multidesign funk­tio­niert lei­der nur bei ein­ge­schal­te­tem JavaScript und ist für mich des­halb kei­ne ech­te Alternative.

    Letztendlich kann man nur hof­fen, dass mög­lichst bald CSS 3 kommt und in den Browsern umge­setzt wird. Damit soll­te dann das Erstellen und Pflegen von fle­xi­blen Layouts deut­lich ein­fa­cher wer­den.

  19. Von jeman­dem, der mit einem iPhone tele­pho­niert, lass’ ich mir nichts über Layout erzäh­len…

  20. Auf der vol­gen­den Homepage kann man sich eini­ge CSS Beispiele von Liquid Design anse­hen.
    Da sind ein paar ganz net­te Webseiten dabei…

    http://www.cssliquid.com/

  21. Fritz Weisshart: Fuer sol­che Faelle gibt es ja schliess­lich noch die CSS media types. Oder bas­telst Du Dein Screen-CSS so, dass es auch auf A4 noch gut aus­sieht?

  22. net­te dis­kus­si­on ;)

    mal ehr­lich, über die­se Geschichten machen sich doch nur wir Webler Gedanken. Barrierefreiheit und Handy-Surfen hin oder her – 95% der Nutzer rea­li­siert die Möglichkeiten doch nicht und wür­de den Unterschied zwi­schen Fix und Flex nicht mal mer­ken.

    Es han­delt sich hier eher um Spielereien. Barrierefreiheit ist für fixe Seiten genau­so umsetz­bar wie eine Abfrage ob die Seite über ein Handy oder ande­res mobi­le Medium abge­fragt wird und ein ent­spre­chen­des CSS grei­fen soll.

    so, die­ser Kommentar darf zeris­sen wer­den :)

  23. @bvgdfg: hast recht, hät­te eher “aus­rei­chend” schrei­ben sol­len. Zumindest ska­liert er rich­tig, wenn min-height den Wert “auto” bekommt.

  24. “über­las­se ich dem Browser die Skalierung” …

    Ich ken­ne kei­ne Browser-Engine, die Bilder wirk­lich gut hoch- oder run­ter-sam­pled, hab ich da was ver­passt :D ?

  25. Auf einer Internetseite wer­den doch meist Texte gel­sen und Bilder ange­schaut. Das fle­xi­ble Layout hebt alle Errungenschaften der Typografie auf. Wäre es für die Zukunft nicht wich­ti­ger, wenn Brwoser Zeilen bes­ser umbre­chen könn­ten? Wo liegt die Schwierigkeit, beding­te Trennstriche ver­ar­bei­ten zu kön­nen wie jedes Textverarbeitungsprogramm? Das eigent­li­che Hinternis sehe ich aber de Bildern. Nicht jeder will nun­mal das Einheits-Blog-CSS-Design. Ein gro­ßes Fotos auf der Seite bringt jedes fle­xi­ble Layout zu Fall.
    Ich will auf das gro­ße Foto nicht ver­zich­ten. Wo wäre es ange­brach­ter als auf einem 1440px-TFT-Display?
    Ich bin gegen CSS. Funktionierte das Internet mit PDF oder etwas Ähnlichem, könn­ten Webseiten intui­ti­ver und attrak­ti­ver erstellt und vom Betrachter stu­fen­los ska­liert wer­den.

  26. @DerKritiker: Auch mal in den Quellcode geschaut?

    1. OK, die Anpassung selbst funk­tio­niert nur mit JS, was spricht dage­gen? Es wird immer­hin ein Standard-CSS gela­den (im Beispiel das für die 800er Auflösung) und das Design ist somit unab­hän­gig von JS!

    2. kaum jemand wird aller paar Sekunden sei­ne Fenstergröße ändern. Darum brauch er auch nie auf Reload/Refresh kli­cken! Das muss man höchs­tens, um im Test zu sehen wie es wirkt. Und dafür habe ich ja die ent­spre­chen­den Links drin.

    Wie schon ande­re sag­ten: Es wird NIE die per­fek­te Lösung geben. Meine hat einen ent­schei­den­den Vorteil: ICH behal­te die Kontrolle über das Design! Eine Sache, die von den meis­ten Auftraggebern und Grafikern gewollt wird.

    PS: Lieber DerKritiker, Kritik ist immer Willkommen, mit Ausdrücken wie “seri­ös” wäre ich aber ein wenig vor­sich­ti­ger…

    wegen Bildskalierung: Ich neh­me für die klei­ne­ren Auflösungen fol­gen­de CSS-Anweisung: “#con­tent img” wei­se ich mit max-width eine maxi­ma­le Breite zu und mit max-height: auto; über­las­se ich dem Browser die Skalierung. Und das funk­tio­niert!

  27. Ich bin ganz klar PRO FIX!
    Warum? Ich bin Designer und möch­te das mei­ne Seite so aus­se­hen wie sie aus­se­hen sol­len und nicht auf einem 24″ ins uner­mess­li­che ver­brei­tert wer­den.

    Wenn fle­xi­bel so super wäre war­um wird es dann nicht häu­fi­ger ein­ge­setzt? 90% der Seite die ich ken­ne nut­zen ein­fach ein fes­tes Layout. Meistens sind es nur Foren die auf % Layouts set­zen.

    naja…

  28. @Jens:
    Also ich muss zuge­ge­ben ich bin prin­zi­pi­ell kein Freund von JavaScript, aber wenn dann Stylesheets damit gela­den wer­den hört es bei mir auf!!!
    Damit errei­che ich viel­leicht, dass ich für eine Vielzahl (alle wer­de ich nie errei­chen) an Auflösungen die StyleSheets anpas­se, habe damit aber das nächs­te Problem – JavaScript. Mit die­ser Lösung ver­la­ge­re ich das Problem höchs­tens. Wo der Sinn besteht, wenn ich erst Refreshen muss um ein ver­klei­ner­tes Fenster auch kor­rekt dar­ge­stellt zu bekom­men erschließt sich mir auch nicht.
    JavaScript (fürs CSS) hal­te ich für einen seriö­sen Webdesigner genau­so für Pfusch wie eine kom­plet­te Website aus Flash zu bau­en! Aber die JS-Wiedergeburt in Verbindung mit dem Web2.0-Schmarrn wer­de ich wohl nie nach­voll­zie­hen. Sicherlich an eini­gen Stellen not­wen­dig, aber für jeden noch so klei­nen Mist sowas ein­zu­set­zen kann ich abso­lut nicht nach­voll­zie­hen…

  29. wenn man sich wenigs­tens etwas mühe gibt bekommt man gute, in gän­ze ska­lier­ba­re web­sites hin. sie­he unse­re: http://spiekermannpartners.com/

    :)

    dazu: pixel­ge­nau­es design – war­um soll­te man so etwas unbe­dingt wol­len? so fast alles ande­re an einem web­pro­jekt ist wich­ti­ger als die­ses merk­mal.

  30. @Tim:
    Flexibles oder sta­ti­sches Layout?

    Ich ver­su­che inner­halb die­ses Artikels aber kei­nes von bei­den zu bevor­zu­gen, son­dern die Dinge objek­tiv zu betrach­ten.

    Gruß
    Professor Web

  31. Apropos unles­bar – bes­tes Beispiel ist Dr. Web selbst. So sind die Artikel auf einem Breitbildschirm rich­tig schick in die Breite gezo­gen und damit rich­tig schlecht les­bar. Die Kommentare hin­ge­gen sind ok und lesen sich ganz gut. Ich hal­te den brow­ser­ba­sier­ten Zoom für einen ganz prag­ma­ti­schen Ansatz, denn hier ent­schei­det wirk­lich der Nutzer und nicht der Designer.

  32. @Tim

    In dem Artikel geht es kei­nes­wegs dar­um, fixe Layouts zu ver­teu­feln. Es ist klar, dass im Alltag der Kunde meist sehr genaue Vorstellungen und Wünsche hat. Der Artikel rich­tet (sie­he 2. Absatz) sich allein gegen die pau­scha­le Aussage, auf­grund des Seitenzooms sei­ne fle­xi­ble Layouts nicht mehr erfor­der­lich.

    Betrachte die Argumentation im Artikel als einen Blick aus der Sicht der Seitennutzer. Auftraggeber, Grafiker und Webdesigner sind genau 3 Personen. Zwischen die­sen drei Parteien ist ein Konsens bezüg­lich Aufwand, Kosten, gestal­te­ri­schem Anspruch noch ver­gleichs­wei­se ein­fach zu erzie­len.

    Die spä­te­ren Nutzer sind in die­sem Entscheidungsprozess nicht direkt ein­be­zo­gen, sie leben mit den Entscheidungen der drei Parteien. Daher sol­len die hier gestell­ten Fragen zum Nachdenken anre­gen, denn die Nutzer – über deren Zusammensetzung und per­sön­li­che Vorlieben man als Entwickler nur sehr wenig weiß – sind mit­ent­schei­dend für den Erfolg.

    Auch wenn es sich der Artikel Konkreten um fixes oder fle­xi­bles Layout dreht, geht es im Allgemeinen dar­um, die Belange der Webseitennutzer in sol­che Entscheidungsprozesse mehr ein­zu­be­zie­hen. Daher ist es auch kei­ne Kritik an Webdesignern, die auf­grund der Kundenwünsche fixe Layouts erstel­len. Vielleicht ließt hier ja auch der eine oder ande­re zukünf­ti­ge Auftraggeber mit und wird dadurch auf­ge­schlos­se­ner gegen­über einer fach­li­chen Beratung durch den Webdesigner, bevor die Umsetzung vetrag­lich fixiert wird.

  33. “Kann mir jemand ein über­zeu­gen­des Argument FÜR pixel­ba­sier­tes Layout nen­nen”

    Ja wenn das Kunde das wünscht und das pas­siert öfters als hier man­che den­ken…

  34. Hallo,

    inter­es­sant, dass die­se Diskussion anschei­nend nie ein Ende fin­det.
    Da ich (auch geschäft­lich) immer häu­fi­ger mein Handheld benut­ze, wün­sche ich mir ein­fach Seiten, die auch auf dem PDA ver­nünf­tig benutz­bar sind.
    Und damit ist pixel­ba­sier­tes Layout ein­fach out.

    Ach ja: Kann mir jemand ein über­zeu­gen­des Argument FÜR pixel­ba­sier­tes Layout nen­nen – außer Unfähigkeit oder Faulheit des Seitenerstellers?

    Schönen Gruß
    FW

  35. Solange fle­xi­ble Layouts immer noch an eini­gen Stellen kran­ken (Bildskalierung wur­de genannt, fle­xi­bler Spaltenumbruch wae­re etwas, das mir jetzt noch ein­fal­len wuer­de), sind sie nun mal ein­fach nicht ueber­all ver­wend­bar. Und ganz ehr­lich: Wer sich auf sei­nem tol­len neu­en 24″-Monitor eine Webseite im Vollbildmodus anguckt, dem ist doch nun wirk­lich nicht mehr zu hel­fen.
    Hohe Aufloesungen haben fuer mich nur den Vorteil, dass man end­lich mal meh­re­re Applikationen im Auge behal­ten kann, ohne auf einen zwei­ten Monitor zuru­eck­grei­fen zu mues­sen.

  36. Solange ich kei­ne ver­nünf­ti­ge Möglichkeit sehe, Grafiken mit der Website “mit­wach­sen” bzw. “mit­schrump­fen” zu las­sen, sind fle­xi­ble Layouts IMHO nur sehr begrenzt ein­setz­bar.

    Ansonsten strotzt der Artikel vor alten Vorurteilen, berück­sich­tigt Entwicklungen in SaaS-Richtung nicht und wird in kei­ner Weise einem kom­ple­xen Thema wie Interface-Design gerecht. Sry, noch­mal von vorn bit­te !

  37. Eigentlich eine müßi­ge Diskussion. Je mehr Flexibilität ich dem Nutzer bie­te, des­to bes­ser – so zumin­dest mei­ne Meinung.

    Ob die Lösung dann letzt­end­lich in Frameworks wie YAML zu fin­den ist, steht auf einem ganz ande­ren Blatt. Ich fin­de YAML fast ein wenig zu kom­pli­ziert, zu ver­schach­telt und zu wenig strict. Aber so ist es halt, wenn man sich eigent­lich mit dem Code und der Logik ande­rer Programmierer her­um­schla­gen muß: man löst nicht das Problem, son­dern arbei­tet sich erst­mal in gedank­li­che Strukturen ein, die auch in der weni­ger nut­zer­freund­lich redak­tio­nier­ten Anleitung schwer nach­voll­zieh­bar gemacht wer­den. Aber das ist ein ande­res Problem.

    Flexibilität ver­leiht einem Layout größt­mög­li­che Freiheit, das stimmt. Aber ich kann auch so man­chen Kunden ver­ste­hen, der sein Produkt in einem ganz bestimm­ten, fest­ge­füg­ten Rahmen prä­sen­tiert wis­sen möch­te. Wer einen grö­ße­ren Bildschirm hat, der hat dann halt mehr schön gestal­te­ten Hintergrund. Ob das sinn­voll ist, ist für den Designer oder Programmierer unwe­sent­lich, denn es ist manch­mal ein­fach der Kundenwunsch.

    Nur von einem soll­ten wir uns lang­sam mal ver­ab­schie­den: den Nutzer für ein fau­les, dum­mes Wesen zu hal­ten. Wenn das Browserfenster klei­ner ist, als der fixe Inhalt, dann kann jeder und macht auch jeder das Browserfenster grö­ßer, sofern ihn der Inhalt inter­es­siert. Hinter der Bemerkung “wird auto­ma­tisch an die aktu­el­le Fenstergröße angepaßt” steckt lei­der auch viel Abfälligkeit. Damit kom­men wir näm­lich zum Hauptproblem der Internetseiten: Wenn der Content stimmt, dann macht der Nutzer alles dafür, um die­sen zu sehen zu bekom­men, egal ob fix oder nicht. Das Layout ist nur eine Krücke und kein Heligtum.

  38. Ups, der Link ist weg. Also hier noch ein­mal ohne Tag: http://www.piske.de/portfolio/multidesign.php

  39. Amiga oder Atari? PC oder Mac? Windows oder Linux? fle­xi­bel oder fixes Layout?…

    Klasse, sind wir wie­der mal beim Thema. ;-)

    Und wie auch bei die­sem Thema strei­ten sich die Geister. Vielleicht darf ich erwäh­nen, dass ich eine ganz ande­re Lösung für die­ses Problem gefun­den habe, und wie mir mei­ne Erfahrungen damit zei­gen, den Designer UND Programmierer glück­lich machen! Vielleicht will sich der Autor und der geneig­te Leser ja auch das mal anschau­en und die­se Lösung in die Diskussion mit ein­be­zie­hen?

    LG,
    Jens

  40. Ich stim­me Cortex zu. Der Artikel stellt fixe Layouts in ein sehr schlech­tes Licht und geht kei­nes­wegs auf die Vorteile die­ser Layouts ein.

    Für mich scheint der Artikel eine klei­ne Werbemaßnahme für das eige­ne Framework zu sein.

    Ich fin­de es gut kri­tisch den fixen Layouts ent­ge­gen zu ste­hen, aber nicht so ver­nich­tend wie in die­sem Beitrag.

    Gruß
    ProfessorWeb

  41. dies könn­te ein guter bei­trag sein über ein the­ma, das uns immer wie­der beschäf­ti­gen wird in einem online-maga­zin, in dem FACHLICHE bei­trä­ge lei­der immer sel­te­ner wer­den.

    statt des­sen ist die dar­stel­lung:

    1. ein­sei­tig

    fixes lay­out = böse
    fle­xi­bles lay­out = gut

    2. pole­misch

    bsp. a)
    was will uns der aut­hor sagen, wenn er die zugäng­lich­keit einer web­site mit shop­ping im kla­mot­ten­la­den ver­gleicht?

    bsp. b)
    wel­cher zusam­men­hang exis­tiert zwi­schen fixen lay­outs und pho­to­shop; war­um ist die ps-vor­la­ge hei­lig?

    3. sub­jek­tiv

    gott sei dank gibt es eine lösung für das pro­blem, das uns alle bewusst oder unter­be­wusst quält. es heisst YAML, wobei ich immer dach­te, der begriff wäre seit ewig­kei­ten mit “Yet Another Markup Language” belegt.

    http://de.wikipedia.org/wiki/YAML

    nichts für ungut – ein paar new­bies wer­den für den ein­blick in das unbe­kann­te land des bes­se­ren web­de­signs dank­bar sein.

    cx

  42. Solange sich Bilder nicht ver­lust­frei mit ska­lie­ren las­sen, sind auch fle­xi­ble Layouts nicht das Nonplusultra. Fazit: die eier­le­gen­de Wollmilchsau gibt es nicht. Auch mit fle­xi­blen Layouts habe ich Zugänglichkeitsprobleme (wie mit allen ande­ren Varianten) und ich wer­de die­se mit nichts voll­stän­dig lösen kön­nen.
    Angenommen ich bin stark fehl­sich­tig und schaue mir Vivabit mit einer Extremauflösung von 640x480 an und ver­grö­ße­re dazu noch die Schrift, dann ist es egal, wel­che Layoutvariante ich ein­ge­baut habe. Als Anwender muss ich damit leben, extrem zu scrol­len. Es liegt in der Flexibilität des Mediums Bildschirm, dass wie nie die fina­le Lösung für alle fin­den wer­den.
    Diese Faktoren las­sen sich tech­nisch nicht unter einen Hut bekom­men:
    * Auflösung
    * Browserfenstergröße
    * indi­vi­du­el­le System-Schriftgröße
    * typo­gra­fisch sinn­vol­le Zeilenlänge
    * kein hori­zon­ta­les Scrollen
    Ich las­se mich gern vom Gegenteil über­zeu­gen. Die Lösung dürf­te dann bei der BIENE 2008 ein Doppelgold bekom­men.
    Nichtsdestotrotz: YAML ist ein gutes Werkzeug für die­je­ni­gen, die schnell zum Ergebnis kom­men wol­len und/oder nicht erfah­ren genug sind. Fraglos ist das Framework über­frach­tet, um auch wirk­lich alle Eventualitäten erfül­len und abfan­gen zu kön­nen. Allein dass die meis­ten Templates tran­si­tio­nal sind zeigt, dass es offen­sicht­lich Probleme gibt, strict-Varianten sau­ber zu imple­men­tie­ren. Hier ist ein­fach viel Hand(nach)arbeit erfor­der­lich.

  43. déjà vu

    2008

    “Bei fle­xi­blen Layouts läuft der Text beim Aufziehen des Browserfensters unkon­trol­liert in die Breite, was ihn letzt­lich unan­sehn­lich und schwer les­bar macht.”

    2005

    “A com­mon argu­ment against flu­id lay­outs is that lines can beco­me so long that reada­bi­li­ty is decrea­sed. ”
    von http://www.456bereastreet.com/archive/200504/about_fluid_and_fixed_width_layouts/

    Die Debatte um das Thema ist schon recht alt und mitt­ler­wei­le habe ich die ganz per­sön­li­che Meinung das die Diskussion an der Realität vor­bei geht, mei­ne Gründe :

    Handys bzw. Handheld devices sind für “nor­ma­le” Webseiten ein Horror, man ist stän­dig nur am suchen und zoo­men, das Problem löst ein fle­xi­bles oder auch adap­ti­ves Layout(float the boat..) nur sehr unzu­rei­chend. Das liegt mei­ner Meinung nach dar­an, dass Informationen für klei­ne Bildschirme ganz anders auf­ge­ar­bei­tet wer­den müss(t)en.

    Typographie, ja klar eine Internetseite ist kein Buch, aber solan­ge die Adaptionsmöglichkeiten der Browser bzw. die CSS Spec. (obwohl 3.0 hier eini­ges brin­gen wird) nicht aus­rei­chen um (lan­ge) Texte in allen Lebenslagen tat­säch­lich “les­bar” zu hal­ten und gleich­zei­tig die Intentionen der Designer zu berück­sich­ti­gen, sind “fle­xi­ble” (Akkordeon-Effekt passt bald bes­ser) Layouts nur eine Krücke.

    Wohlgemerkt das Thema Schriftgröße mit “em” ist damit nicht gemerkt, ich bezie­he mich nur auf das Layout.

    Zu guter Letzt wird in naher Zukunft wohl nicht mehr der Designer das Aussehen der aller­meis­ten Seiten bestim­men, son­dern der “Benutzer” der mit­tels XML Möglichkeiten Informationen abruft und selbst (bwz. der Feedreader oder ähn­li­ches) das Aussehen fest­legt.

    noch ein Zitat von 456bereastreet was wohl “pro” fle­xi­ble Layout gedacht war, aber eigent­lich dage­gen spricht

    “I just don’t get why some peop­le are so hell-bent on let­ting their brow­ser win­dow fill the ent­i­re screen.”

    “Would you still push it if you had a 30”Apple Cinema Display with a reso­lu­ti­on of 2560 by 1600 pixels?”

  44. Ein wirk­lich inter­es­san­tes Thema. Da ich gera­de erst über die HTML-Ebene auf die CSS-Ebene “wach­se”, ist die­ser Ansatz für mich ein völ­lig neu­er – aber sehr attrak­ti­ver.

    Könnten Sie mir kurz sagen, ob es (grundsätzlich/für mich) mög­lich ist, die­se Layouts irgend­wie mit WordPress zu ver­bin­den?

    Herzlichen Dank

  45. Zum Glück ent­wick­le ich bereits seit 1.5 Jahren aus­schliess­lich fle­xi­ble Layouts! :-)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.