Im Rahmen meiner Arbeit bin ich derzeit dabei eine verbindliche Checkliste zu entwerfen, die bei Ausschreibungen und Auftragsvergaben von Webanwendungen und Webauftritten Anwendung finden soll.
Die Checkliste soll verhindern, daß Webverantwortliche Aufträge an Firmen vergeben ohne dabei verlässliche Kriterien zu haben. Die Checkpunkte sind dabei so gestaltet, daß sie auch von unerfahrenen Personen verstanden und überprüft werden können.
Hintergrund ist dabei im wesentlichen der, daß in der Vergangenheit sehr viele Firmen, Agenturen und Dienstleister eine höchst eigenwillige Interpretation davon hatten, was Barrierefreiheit im Bereich der IT bedeutet. Es reichte leider offenbar, mit Hilfe einer schönen Präsentation und einer „Chefgerechten Lösung“ aufzutreten um für viel Geld wenig zu leisten. Wenn ein durchstylter Vertreter einer Agentur (Abteilung Marketing) den Auftraggeber sagte, daß die Lösung Barrierefrei ist, dann hat dieser es halt geglaubt…
Die Checkliste gibt -auch mit Hilfe von KO-Kriterien- einige harte Punkte vor, bei denen sich niemand herausreden können sollte.
Für seriöse und professionelle Webagenturen sollte die Checkliste kein Problem sein. Andere jedoch dürften damit ihre liebe Not haben.
Die jetzige Fassung des Entwurfs ist nunmehr in einem Zustand, daß ich diese einem größeren Kreis zur Diskussion stellen möchte. Anzumerken ist, daß der Entwurf zum großen Teil auf eine Version zurückgeht, die von der Stadt München seit Anfang des Jahres 2006 verwendet wird.
PDF: Checkliste für Webanwendungen
Im Anhang des Entwurfs (nicht beigelegt, da noch nicht Tippfehlerbereinigt) befindet sich eine Erklärung zu allen einzelnen Punkten mit Angabe der zugehörigen BITV-Richtlinien.
Ich bin offen für Feedback.
Ich bin skeptisch, dass die Fragen „auch von unerfahrenen Personen verstanden [..] werden können“ – so bin ich der Meinung, dass einige schon bei der Frage Frames aussteigen. Erleichtern könnte man dies mit einer Relativ einfachen Test-Suite, die einen unterstützt. Es gibt da zwar einige Tools, aber ich denke da an so was, wo man die URL eintragen kann und dann auf die Einzeln Sachen Testen kann. Z.B. um auf 800×600 zu Testen, dass ganze in einen Frame Packen. Bei den Stylesheets einfach die Stylesheets rausschmeißen, alle Bilder mit den Zugehörigen Texten auflisten lassen, Neben alle Header ein Hx – Icon daneben machen etc. Diese Suite muss ja nicht unbedingt Barrierefrei sein und kann denn ich recht schnell in einer beliebigen Skriptsprache geschrieben werden..
Ein Großteil der Funktionen wird ja auch durch die Web Developer Extension (http://chrispederick.com/work/webdeveloper/) unterstützt. Evtl könnt man die einfach so aufbohren, dass man nur noch „Test1“ etc auswählen muss.
>ActiveX und VBScript dürfen nicht verwendet werden. Wird dies eingehalten?
Das halte ich für kritisch, wenn im IE 6 AJAX verwendet wird (was ja nicht unbedingt schlecht ist, wenn es eine Alternative gibt). Ich würde das eher so formulieren, dass bei Verwendung von JavaScript / VBScript / ActiveX / Java / Flash eine Alternative angeboten werden muss. Manche Sachen sind – je nach Anwendung – eben von diesen Typen besonders elegant zu lösen. Warum also verbieten, wenn es geht?
@Morty: Hatte vergessen zu erwähnen: Diechliste selbst wird von der Webagentur ausgefüllt. Die muss eigentlich alles ohne Erklärung verstehen können. Für die Auftraggeber gibt es einen Anhang (wie gesagt – Tippfehler – traue ich noch nicht herauszugeben), wo jeder Punkt erklärt wird.
Ein Verweis zu Tools gibt es auch, wobei der Verweis auf die Werkzeugübersicht zum BITVTest weist. Diese Werkzeugliste ist ganz gut.
@Matthias:
Es gibt hinsichtlich der Verwendung von clientseitigen Skripts kein explizites Verbot (kein KO). In der Erklärung hab ich zu Punkt
Skript&Applets 1 folgendes notiert:
Aber das wird auch in den darauf folgenden Checkpunkt auch nochmal abgeprüft.
Hm, wenn ich es jetzt öfters durchlese, dann vermisse ich noch wesentliche Punkte. Du bist eigentlich nur auf Punkte der Barrierefreiheit eingegangen. Aber das ist ja nicht alles, was ein Manager bei einem Web-Auftritt berücksichtigen muss. Wenn du das jetzt nem Manager an die Hand gibst, wird er nur das prüfen und ungeachtet vom Rest evtl. das Produkt absegnen.
Meiner Meinung nach fehlen:
– Webseiten-Struktur wurde mittels Struktur-Diagramm zur Verfügung gestellt (bzgl. Wartung).
– bei Scripten wurde ein Klassen-Struktur-Diagramm angefertigt
– Alle Script-Dateien enthalten einen Kommentaur zur Funktionserklärung der Datei
– beabsichtigte Ziele der Website wurden festgehalten
– wesentliche Usability-Tests wurden durchgeführt. So wurde mit einer Benutzergruppe (unterschiedliche Vorkenntnisse) sichergestellt, dass diese grundlegende Aufgaben (Ziel der Website) in angemessener Zeit erfüllt werden konnten.
Ich finde also, etwas zu einseitig auf Barrierefreiheit. Das ist sicher wichtig, aber das allein macht keine gute Website aus. Und du kennst Manager, wenn sie eine Checkliste haben.
>Es gibt hinsichtlich der Verwendung von clientseitigen Skripts kein explizites Verbot (kein KO)
Doch, in der PDF-Datei steht hier KO. Die Frage ist natürlich, wann trifft das KO.
@Matthias #4: Hast recht; Das ist aber Absicht. Für richtige Webanwendungen gibt es natürlich weitergehende Anforderungen. Im orginal bei München ist diese Checkliste auch selbst wieder ein Unterpunkt einer Meta-Checkliste zu Webanwendungen. In der werden dann zur Anwendung selbst noch System- und Prozessbezogene Fragen gestellt. Und eben ob der Fragebogen zur barrierefreien Gestaltung ausgefüllt ist (ja/nein- KO).
Das kann man also davon noch zusätzlich machen (und sollte man auch). Aber die Fragen die man dort stellt, sind sehr Einrichtungsbezogen (z.B. bei der nach den Webservern: „Wird Apache in den Versionen 2.0 oder 2.0 genutzt?“ oder: „Der MS-IIS kann nicht verwendet werden. Wird dies eingehalten?“)
@Matthias #5: Nö, Das KO ist bei den Checkpunkten 3 und 3.
*grummel* Vertipper: „Das KO ist bei den Checkpunkten 3 und 4„
Was bedeutet:
Sind die nicht mittlerweile sowieso alle variabel seit dem der IE7 zoomt?
Netter Ansatz – apropos Tippfehler:
Hier aus der Seite sind einige Adjektive (hoffe, dass das so stimm – wollte nicht „Wie-Wörter“ schreiben ;-) ) , die klein geschrieben werden sollten: Tippfehlerbereinigt, Barrierefrei …
Guter Ansatz Wolfgang!
Eines erscheint mir unlogisch, wenn nicht sogar widersprüchlich:
Wenn die Seiten ohne CSS funktionieren, warum dann die Anforderung, für Handheld und Printer gesonderte CSSse zu verwenden?
Viele Grüße, Rolf
@Jeena: Jein. Es gibt im IE7 zwar die Funktion zur Adaption der Schriftgrößen, aber mal Hand aufs Herz: Wer vertraut darauf, daß der IE7 es auch wirklich richtig macht in allen Fällen?
Ansonsten muss man aber auch sagen, daß der IE7 ja nur ein Browser unter vielen ist. Und im Bereich der Universitäten in D sind die IE zudem noch in der Minderheit.
@roro: Weil sich die optische Darstellung bei den verschiedenen Medien unterscheidet. Insbesondere bei Small Screen Devices ist dies wichtig.
das ist mir schon klar Wolfgang, aber demgegenüber steht die Anforderung, dass eine Seite auch ohne CSS funktioniert.
Drehen wir uns im Kreis?
Viele Grüße, Rolf
Wozu werden denn noch Grafiken als Abstandshalter akzeptiert. Für mich ein eindeutiges K.O. Merkmal. Akzeptiert werden sollten Grafiken aber als Hintergrundbild.
Desweiteren würde ich die Schriftgröße noch anfügen. Sie sollte nicht nur variabel sondern im Anfangsstadium ebenfalls nicht zu klein sein.
Wem hilft explizit die korrekte Ausgabe auf PDA weiter? Wird der Bogen hier nicht überspannt? Oder was heisst korrekte Ausgabe? Scrollbalken sind wohl eher nicht zu verhindern.
@roro: Die Punkte sind nicht als Anforderungen und erst recht nicht als Lastenheft zu verstehen, sondern als Frage, was vom Anbieter erfüllt wird und was nicht.
Daher sind alle Checkpunkte – mit Ausnahme der KO-Kriterien- informativ für den Auftraggeber, damit er anhand derren einen Anhand hat um verschiedene Angebote vergleichen zu können.
Wenn die Seite also sowohl ohne CSS geht ist gut. Wenn zusätzlich noch Mediendarstellungen beigebracht werden, dann ists es nur um so besser. Ein Widerspruch ist das nicht.
@Heike: ich hab in der Klammer mit den Beispielen wann Grafiken keine/leere ALT-Attribute haben sollten geändert. Zukünftig lautet der Checkpunkt:
Die Verwendung von Abstandsgrafiken an sich muss sich aber nicht als eine Barriere für Benutzer auswirken. Daher ist die Verwendung solcher Grafiken nicht mit einem KO verbunden.
(Wohl aber könnte man die Verwendung als ein negatives Qualitätsmerkmal betrachten. )
Die Aussage wem die Unterstützung vom PDA weiterhilft, stellt sich nicht. Barrierefreiheit bedeutet im wesentlichen: Unbeschränkter Zugang für alle mit allen (standardkonformen) Medien.
Wenn ich wieder beginne einzelne Medien auszuschließen, verletze ich das Prinzip und am Ende bin ich wieder bei browseroptimierten Websites.
Allerdings: Es reicht wirklich, daß Inhalte lesbar sind. Es muss nicht so schön sein, wie auf dem richtigen Monitor!
Gute Idee. Allerdings wird es naturgemäß eine Weile dauern, bis so eine Checkliste einigermaßen wasserdicht ist. Desweiteren muß so eine Checkliste angepasst werden, so wie sich die Webtechnik weiter entwickelt.
Aber es ist gut, daß sich da mal einer dranmacht.
Hallo! Die Checkliste ist eine tolle Sache. Ich hoffe es ist o.k. wenn ich von meinem Weblog verlinke.
@Elke: Klar ists ok. Bedenke aber, daß die Liste oben ein Entwurf war. Inzwischen wurden ja auch einige Punkte umformuliert. Ich hoffe das ich Ende dieser Woche eine erste Beta fertig hab.
hi,
also der sinn der liste ist mir nicht wirklich klar, dass wird insbesondere an der letzten frage deutlich, welche auf eine weitere abhackliste verweist, welche bereits alle zuvor genannten punkte bereits enthält. (nein ich habe jetzt nicht punkt für punkt abgeglichen).
statt nun neue listen mit nuancen zu entwicklen, sollte man sich vielleicht drüber gedanken machen generell den bitv-kurztest durchzugehen. auf dessen grundlage kann man dann schreiben zusätzlich zum bitv-kurztest muss noch folgendes berücksichtigt werden bzw. der bitv-kurztest ist in folgender richtung abzuändern etc..
nicht valide seiten sind also mit dem ko kriterium versehen. da stellen sich mir doch ein paar fragen:
1. welcher checker ist denn grundlage des tests (tidy gibt mir 20 fehler bei deiner seite, ko?) – eigentlich schon; oder einigen wir uns auf einen checker der möglichst keine fehler findet?
2. eine seite, die in ihren links & statt & benutzt ist also gleich ko-mäßig schlecht
etc.
ähnliches gilt für layouttabellen. layouttabellen werden von den hippen webworkern mit teilweise fragwürdigen argumenten verteufelt. layouttabellen sind aber entgegen landläufiger meinung grundsätzlich keine barriere!!! (im gegensatz zu deinem kommentar formular, den prüfungspunkt hast aber eh ausgelassen).
ich kann dir heute noch design aufgaben stellen, die du ohne layouttabellen nicht wirst anständig lösen können
bis denne
alex
@alex: Der Hauptsinn der Liste besteht darin, daß Agenturen ihre unerfahrenen Auftraggeber nicht mehr aufs Kreuz legen sollen. Viele (alle) Agentuern behaupten, daß sie Barrierefreiheit können und das das produkt, welches abgegeben wird, solches ist. Ein unerfahrener Auftraggeber kennt sich damit nicht aus und hat meist auch keine Lust oder Zeit es zu prüfen.
Die Liste soll es solchen Leuten ermöglichen, einen rechtlich haltbaren Forderungskatalog zu haben, bei den sich niemand rausreden kann!
Die letzte Frage (BITV-Kurztest) ist eine Rückkontrolle, daß die oberen Fragen wahrheitsgemäß ausgefüllt wurden. Denn bei Angabe von „Ja“ bei den KO-Kriterien ist es nahezu ausgeschlossen, daß jemand weniger als 80 Punkte erhält.
Zu 1: Welcher Checker: Steht dabei: Der Validator vom WC3.
Zu 2: Ja, und?
Zu Layouttabellen: Der Fragebogen bezieht sich nicht allein auf die Barrierefreiheit. Es gibt einen serh engen Zusammenhang mit Wirtschaftlichkeit und Nachhaltigkeit. Bei den meisten Webauftritten (im öffentlichen Dienst) muss davon ausgegangen werden, daß derjenige der Webseiten erstellt nicht immer ewig da ist.
Der Nachfolger erhält jedoch meist keine vernünftige Schulung.
Nun die Quizfrage: ist es einfach eine komplexe Struktur aus mehreren ineinander verschachtelten Tabellen oder eine simple HTML-Struktur a la 1996 zu verstehen?
Die Aufgabe, die ich ohne Layouttabelle nicht lösen kann, hätte ich gern hier gestellt.
ja, bei css-layouts wird html einfacher das css wird dagegen deutlich schwerer. oder willst du mir erklären, dass du ne komplexe css datei – ohne ordentliche dokumentation oder schulung – sofort verstehst?
im übrigen:
1. das html in cms-systemen wird über templates erstellt und kommt nur einmal vor -> ähnlich wie bei css ist i.d.R. nur die änderung einer datei notwendig
2. bei einem realign von css-basierten webseiten, wird sich die agentur i.d.R. auch nicht nehmen lassen auch das html zu ändern. (wir sind ja nicht im css-zengarden)
aufgabe bereite ich vor. bin echt gespannt und würde mich freuen, wenn du das valide, cross-browser und vor allem semantisch packst (darf ich dir auch das semantisch, valide html vorgeben?).
damit wir uns nicht falsch verstehen: meiner meinung nach sind css-basierte layouts und valider, semantischer html-code sehr wichtig und i.d.R. auch vorteilhafter gegenüber killerwebseiten ist. -> in aktuellen projekten arbeite ich ausschließlich css-basiert.
aber ich bin der meinung, dass die vorteile deutlich übertrieben und die nachteile verschwiegen werden.
wir sind uns aber einig, wenn es heisst dass es in einigen jahren, wenn browser wie der ie6 nicht mehr zu berücksichtigen sind(->sie – wie ns4 – ein styleloses html bekommen kann), es gar keinen grund mehr für layouttabellen gibt.
@Alex:
Das will ich auch gar nicht.
Der normale Autor soll nur das simple HTML bearbeiten (über CMS, Editor oder Redaktionssystem). Das CSS gehört in Profihände.
Leider nur bei guten Systemen.
Bei vielen Systemen sind Teile des HTMLs doch noch im Code drin, so daß Templates nicht richtig wirken.
Zudem sind viele Templates auch „dumm“, da sie keine komplexen Bedingungen ermöglichen.
Beispielsweise das kleine Problem mit den Links auf Seiten auf die man sich bereits befindet.
Ich bin der Meinung, daß der Kunde entscheiden muss, was er kriegt.
Ich hab in den letzten Monaten mit einigen Agenturen gearbeitet um Webdesigns erstellen zu lassen und hab auch Ausschreibungen dazu gemacht.
Es ist möglich, HTML-Templates vorzugeben und zu fordern, daß lediglich ein CSS erstellt wird, ohne das das HTML angefasst werden darf.
Ebenso geht dies andersrum.
Vorraussetzung ist jedoch, daß das Markup semantisch richtig und umfassend ist.
Und das die Agentur sich mit hierarchischen CSS auskennt und nicht div-Wüsten benötigt :)
Wenn man ein gutes Markup, wie beispielsweise YAML vorgibt, kann sich kein gutes Designer drum drücken. Denn es gibt genug gute Konkurrenz die es ansonsten kann.
Dito natürlich bei CMS: Wenn der CMS-Anbieter drauf beharrt, daß er alleine das Design und das Markup bestimmt, dann ist das für mich eher ein Zeichen, das da was faul im Busch ist von wegen echter Trennung von Markup und Design.
Bedenke eines: Die Checkliste oben ist nicht dafür gedacht, einer Webagentur oder Webworkern das Leben einfacher zu machen. Sie ist dafür gedacht, unerfahrene Auftraggeber vor Abzockern zu bewahren (die den seriösen und guten Webworkern wiederum das Geschäft versauen).
ok, anbei die aufgabe:
http://pfirsichmelba.de/tabellen-challenge.zip
ach ja, ich habe die aufgabe in eine webseite eingebungen, die ich mal erstellt hab. da ich mir die mit ff-erweiterung gesaugt habe, hat er einiges am html und css geändert ( = etwas unübersichtlicher bzw. komische code änderungen)
relevante dateien index.html (tabelle nicht zu übersehen) und index.css (relevantes css davon ganz am ende).
bzgl. div wüsten manchmal ist es ok, wenn der coder mehr divs einsetzt als er eigentlich benötigt. das macht später änderungen flexibler, wenn man die divs braucht. (und ein paar divs stören die unübersichtlichkeit nicht wirklich)
Nur zur Klarstellung, weil ich etwas verwirrt bin:
Du meinst nicht die Seite als ganzes, sondern nur die HTML-Tabellen im Inhalt?
Und die Vorgabe besteht daraus, daß du eine Umsetzung der Tabellen mit Hilfe von Listen haben willst?
Ausserdem: Was meinst du mit den Satz „1 [nicht 2] geordnete Listen + muss valide sein.)“
Ich würde die Aufgabe schwerer machen – bzgl. der Vermeidung von div-Wüsten, die an einer STelle kritisch zu sehen sind:
divs durfen nicht eingesetzt werden um alle vorher für Tabellen verwendeten Tags zu ersetzen.
Also sowas wie
<div class=“tabelle“><div class=“zeile“><div class=“spalte“>…. usw.</div></div></div>
ja im prinzip geht es darum das du nicht mit pixeln sondern mit % arbeiten musst.
wenn sich die liste bei allen auflösungen und schriftgrösseneinstellungen anpasst, dann hast du das gemacht. (letztendlich kannst du das auch ausserhalb der seite basteln, soll sich nur in einer fluiden und elastischen umgebung sauber verhalten)
das ist bereits in punkt 3 enthalten. kann ein redakteur das mit tinymce umsetzen? und bei derartigen div wüsten entsteht zwangsläufig ein fehler. ich habe ja schon probleme denen zu erklären, dass ein absatz nur weil er so ähnlich wie eine überschrift hervorgehoben sein soll, nicht als überschrift ausgzeichnet werden darf.
eine möglichkeit die man machen könnte wäre folgendes
1.punkt
2.punkt
3.punkt
4.punkt
die liste soll aber im prinzip nur so aussehen:
1.punkt
2.punkt
3.punkt
4.punkt
ups ol und li sind auch erlaubt (hoffe das gilt nicht auch für script)
@xwolf
und schon ne idee?
@alex. Nein, nicht eine, sondern einige :) Aber noch keine Zeit gehabt. (Du hattest mich vorhin auch darauf hingewiesen, daß die Kommentarfunktionen hier noch sch…lecht sind; Das wollte ich -zusammen mit noch einzubauenden Mikroformaten auch noch machen); Ausserdem hab ich an der Liste weiter gearbeitet (siehe neuer Artikel oben)
Grundsätzlich ist die Liste nicht unbedingt schwer.
Der Schnelligkeit wegen, könnte ich ja mal in der css-liste (Yahoogroup) deine Frage posten. :)
Es gibt mehrere Lösungsansätze die mir einfallen; Was ich als erstes versuchen würde, ist, <ul> schonmal eine feste Breite (propertional oder angepast an Ränderabständen versteht sich) zu geben. Dann erhalten die Listelemente ein float und ein display: inline. Listelemente werden weggemacht, genauso wie ueberflüssige margins. Dafür Paddings erhöht und Border eingefügt.
Als width wird ein Prozentwert gegeben, sofern machbar. Wobei es hier wegen dem Borderbox-Modell der Schrottplorer mit CondCOmments eine IE-Weiche geben muss.
Bei der komplizierteren Tabelle könnte man den Doppelborder auch über einen Background im List-Element realisieren.
Mit CSS3 wäre das ganze noch einfacher, wegen den kalkulierbaren Breiten. Aber mit etwas aufpassen, sollte es bei CSS2 auch gehen.
Ich bin mir sicher, daß ich in meinen Bookmarks irgendeo eine Siete hab, worin verschiedene Table2CSS-Lösungen vorgestellt wurden. Darunter war auch Tables wie deine.
Deswegen schau ich jetzt aus Faulheit mal die Bookmarks durch.
Little Boxes geht zwar in die richtige RIchtung, aber nicht unbeidngt weit genug, oder?
dein ansatz ist für den anfang schon mal gut. soweit war ich ungefähr auch schon. was ich bei deinem vorschlag nicht verstehe, warum gibst ul eine feste breite soll ja immer 100% sein und was bewirkt 1% weite bei li in dem zusammenhang.
von meinem ansatz her, der von den angaben sehr ähnlich ist kann ich folgende probleme schildern, die auf dich zukommen:
es entstehen 2 probleme, für die gerade das fehlende box-model aus css3 wichtig wäre(und warum man den ie6 wegen dem verfehlten boxmodel im quirks sehr gut nutzen kann). du kannst keine % und px werte mischen und in einer fluiden umgebung sagen das sind immer 100% (anders als in einer elastischen mit % und em werten und statisch ist ja sowieso klar). damit die li´s nicht ineinanderklappen musst du dich mit einer spanne zufrieden geben die nicht auffällt (ca. 99.99%- 95). Ich bin mir sicher, daß ich in meinen Bookmarks irgendeo eine Siete hab, worin verschiedene Table2CSS-Lösungen vorgestellt wurden. Darunter war auch Tables wie deine.
Deswegen schau ich jetzt aus Faulheit mal die Bookmarks durch.
Little Boxes geht zwar in die richtige RIchtung, aber nicht unbeidngt weit genug, oder?
jo, wäre cool. kannst mir ne mail schicken, wenn sich an der front was getan hat? auf die technik wäre gespannt und dann lern ich gern davon, wobei ich ja befürchte, dass es der anforderung nummer 3 nicht gerecht wird, die ist da bei heutioger css unterstützung ein richtiger killer.
dein ansatz ist für den anfang schon mal gut. soweit war ich ungefähr auch schon. was ich bei deinem vorschlag nicht verstehe, warum gibst ul eine feste breite soll ja immer 100% sein und was bewirkt 1% weite bei li in dem zusammenhang.
von meinem ansatz her, der von den angaben sehr ähnlich ist kann ich folgende probleme schildern, die auf dich zukommen:
es entstehen 2 probleme, für die gerade das fehlende box-model aus css3 wichtig wäre(und warum man den ie6 wegen dem verfehlten boxmodel im quirks sehr gut nutzen kann). du kannst keine % und px werte mischen und in einer fluiden umgebung sagen das sind immer 100% (anders als in einer elastischen mit % und em werten und statisch ist ja sowieso klar). damit die li´s nicht ineinanderklappen musst du dich mit einer spanne zufrieden geben die nicht auffällt (ca. 99.99%- 95). [pfeil]- das ist ein kleiner nachteil.
damit nicht sichtbar wird, dass du nur ungefähr 100% erreichst, darf das ul, welches praktisch immer 100% hat kein border bekommen und dadurch kommst du in die nächste falle. die border der list-elemente verdoppelt sich an den stellen, wo sie aufeinander treffen. da keine css3-selektoren (even/odd) verwendet werden können, ist dieser ansatz dann gescheitert. und das auszeichnen jedes zweiten lis kann nicht vom redaktuer erwartet werden.
soweit so gut, das 2. kernproblem wurde dabei noch nichteinmal berücksichtigt: wie bekommen ich das jeweils gerade li mit dem ungeraden li auf gleiche höhe?
jo, wäre cool. kannst mir ne mail schicken, wenn sich an der front was getan hat? auf die technik wäre gespannt und dann lern ich gern davon, wobei ich ja befürchte, dass es der anforderung nummer 3 nicht gerecht wird, die ist da bei heutioger css unterstützung ein richtiger killer.
hi, mein langer post wurde nun geschluckt. weil ich einen pfeil verwendet habe. (oben markiert. überprüfe noch mal deine regexp).
@alex
Ich möchte dich keinesfalls abwürgen – aber da der Thread hier schon lang wird und auch offtopic – dafür aber speziell auf CSS wird – wie wäre es, wenn wir die Diskussion in der CSS-Expertenliste verlagern?
(Ich meine diese: css-design@yahoogroups.de . Falls du da nicht drin bist, kannst du dich ja da mal kurzfristig subscribieren über yahoogroups.de)
Mit Mailclients (und Threadanzeige) ists auch bestimmt leichter zu diskutieren als in diesen eher dummen Kommentarscriptchen :)
Bei aller Liebe, aber ein Tabellenlayout ohne Tabellen darstellen zu wollen ist Blödsinn. Zumal es auch sematisch korrekt ist, ihr sprecht die ganze Zeit von Tabellenlayout und wollt kein Tabellenelement verwenden?
Das Problem bei Tabellen versus CSS Layout ist, daß es mit reinem CSS sehr schwer bis unmöglich ist, voneinander abhängige Bereiche zu schaffen.
Insofern ist die Aussage Layouttabellen sind manchmal leichter! völlig korrekt, wenn ein Tabellenlayout umgesetzt werden soll.
Wenn man kein CSS-Layout will, dann ist das ok und es spricht nichts gegen den Einsatz von Tabellen. Aber ein CSS Layout ist schöner ;-)
@Struppi:
„Bei aller Liebe, aber ein Tabellenlayout ohne Tabellen darstellen zu wollen ist Blödsinn. Zumal es auch sematisch korrekt ist, ihr sprecht die ganze Zeit von Tabellenlayout und wollt kein Tabellenelement verwenden?“
Ich glaub, du bist da einem dummen und falschen Gerücht aufgesessen; Niemand will Tabellen verbieten! Das wäre wirklich Blödsinn.
Die Forderung geht aber dahin, Tabellen nur für tabellarische Daten zu verwenden. Also genau dafür wofür Tabellen gedacht sind.
Ansonsten: Definiere Tabellenlayout? Mit CSS läßt sich jede grafische Vorlage umsetzen. Ob es dabei auf rechteckig-strukturierte Bereiche basiert oder nicht.
Und dies ist deswegen leichter und wirtschaftlicher, weil ich wegen der Möglichkeit der festen Positionierung nicht 3 oder mehr Tabellen ineinander verschachteln muss und jederzeit ohne Änderung des Quellcodes die Optik verändern kann.
(Bei einem Wechsel von Tablelayout zu CSS-Layout darf man aber natürlich nicht den Fehler machen, den alten Code als Grundlage zu verwenden bei Forderungen zur Umsetzung. A la „ich hab genau dies Tabellengerüst, nun bilde es in einer Liste nach“.
Das ist unsinn und unnötig. Denn auf den Code kommt es nur sekundär an. Als erstes will man eine optische Gestaltung umsetzen. Das diese durch eine 4 mal verschachtelte Table gemacht wurde ist unwichtig. Es kommt nur drauf an, daß die Optik dieselbe bleibt. Ob ich das dann mit gefloateten divs oder mit anderen Blocklevelelementen mache, ist unwichtig.)
Überleg einfach: Was passiert wenn ein unbedarfter Autor bei einem Tabellenlayut ein <td> an die falsche Stelle setzt? Und vorallem: Wie leicht passiert dies? Und geh nicht von dir als versierten Webworker aus, sondern von den üblichen DAU, der im SELFHTML-Forum fragt ohne vorher die Anleitungen zu lesen oder das Archiv zu bemühen :)