06. März 2009
Was habt ihr am 27. August 2001 eigentlich gemacht? Ich weiß es nicht mehr. Aber vermutlich haben sich damals viele Leute über die Veröffentlichung des Internet Explorer 6 gefreut, da es gegenüber der 5.x Version einen gewaltiger Schritt nach vorn war. Die Bauchschmerzen kamen erst später und heute fühlt sich die Erinnerung an dieses Ereignis doch ziemlich unsexy an. Fakt ist, der Internet Explorer 6 will einfach nicht von der Bildfläche verschwinden und ist in den Augen vieler mittlerweile die Innovationsbremse Nr. 1, wenn es um den Einsatz moderner Webtechnologien geht. Denn aufgrund des heute noch weltweiten Marktanteils von aktuell 18,5 Prozent (Stand Januar 2009) ist das Ignorieren dieses Dinosauriers irgendwie auch nicht drin – das Dilemma ist perfekt.
In regelmäßigen Abständen rufen deshalb seit ein paar Jahren Webentwickler zur aktiven Sterbehilfe für den Internet Explorer 6 auf, aktuelles Beispiel: Skandinavien. Die norwegische Webseite Finn.no ging kürzlich in die Offensive und rät ihren Besuchern aktiv und unverblümt zum Umstieg. Ähnliches wünscht sich das Projekt IE Death March – in beiden Fällen gefeiert von einer Vielzahl an Webentwicklern.
Das Dilemma wird noch deutlicher, denn wie Ingo Chao im XING Blog zielsicher den Finger in die Wunde legt, waren es die Webentwickler selbst, die mit ihrer erfolgreichen Suche nach Workarounds und CSS-Hacks sowie deren Sammlung und Veröffentlichung erst dafür gesorgt haben, dass sich dieser Browser bis heute über Wasser halten konnte.
Isn’t it ironic that we, as web developers, have made this nonsense possible? It is our documentations and analyses of browser bugs. We, not the vendors, did that. We found workarounds for today’s complex pages in IE, or, if this failed, we reverse engineered its bugs for standards-compliant browsers so they act like IE. So we made this trap for ourselves, conscious of the consequences or not.
Ebenso Recht hat natürlich auch Jens Grochtdreis mit seinem Hinweis, dass die Webentwickler seinerzeit gar keine andere Wahl hatten, als sich mit dem IE6 zu arrangieren. Von Microsoft war aufgrund fehlender Konkurrenz keine Aktivität zu erwarten.
Fakt ist aber auch: Die Bugs des IE6 sind bereits seit einem halben Jahrzehnt im Netz bestens dokumentiert, einschließlich passender Fixes und Workarounds. Und der überwiegende Teil lässt sich auf relativ einfache Art und Weise fixen. Zu einem offensichtlichen Problem wurde diese Situation erst mit dem rasanten Aufstieg des Firefox und der Wiederaufnahme der Entwicklungsarbeit bei Microsoft, die Ende 2007 in der Veröffentlichung des IE7 mündete, ohne jedoch den IE6 zu ersetzen. Seither ist richtig Bewegung im Browsermarkt, genauso wie in der Entwicklung neuer Webstandards (CSS3, HTML 5 samt Canvas, WAI-ARIA, RDFa, SVG).
Was war zu erst da, die Henne oder das Ei?
Also, wie kommen wir raus aus diesem Dilemma? Meinungen dazu gibt es viele, Antworten aber leider nicht. Denn wenn sich das Problem Internet Explorer 6 mit Unterschriftenaktionen, in Webseiten eingeblendeten Textboxen mit Wechselempfehlungen oder gar der Verweigerung von CSS-Styles für den IE6 tatsächlich lösen ließe, dann hätte das schon 2007 funktionieren müssen. Dummerweise haben wir jetzt 2009 und sind keinen Schritt weiter. Zwar ist der Marktanteil des IE6 bereits stark gesunken und wird weiter fallen (vermutlich aber langsamer), doch es will niemand mehr so lange warten, bis er von selbst in der Bedeutungslosigkeit untergeht.
Die große Chance, die Herzen aller Webentwickler dieser Welt zu rühren, hatte Microsoft erstmals beim Release des Internet Explorer 7 - und ließ sie ungenutzt. Man unterstützte nur Windows XP, ließ ältere Betriebssysteme außen vor und machte die Installation nicht zur Pflicht – aus Angst vor massiven Problemen mit alten Webseiten sowie Unternehmenssoftware vieler großer Firmen, die speziell auf den IE6 abgestimmt waren (und es vermutlich vielerorts auch heute noch sind). Den zweiten Matchball hat Mircosoft mit dem IE8 gerade in der Hand. Doch auch jetzt sieht es nicht so aus, als bringe Microsoft den notwendigen Mut auf, einen klaren Schnitt zu machen.
So motivierend oder eindringlich öffentliche Kampagnen auch sein mögen – sie bleiben lokale Strohfeuer. Nur Microsoft erreicht weltweit die kritische Masse und könnte mit einem Zwangsupdate auf den Internet Explorer 8 in Verbindung mit einer konsequenten Ausrichtung auf Webstandards (ohne Kompatibitätsmodus und IE7 Emulation) für unmittelbare und nachhaltige Reduktion der IE6-Installationen sorgen, so dass wir das Problem nicht weiter aussitzen müssen. Doch das wird nicht geschehen und so werden die bestehenden IE6-Installationen nur gemächlich weniger werden.
Was also tun?
Der Internet Explorer 6 ist seit nunmehr 8 Jahren ein fester Bestandteil des Internets und hat die Weiterentwicklung der Standards nicht behindert. Genauso wenig darf seine Anwesenheit den Einsatz neuer Techniken behindern. Genau das tut er jedoch – vorrangig in den Köpfen vieler Webentwickler.
Aufklärung!
Jens Grochtdreis wird nicht müde, immer wieder auf die einzigartigen Stärken des Mediums Internet zu verweisen ...
Der Kernpunkt zur Lösung des Problems ist ein anderer. Wir müssen uns von der irrigen Annahme verabschieden, wir könnten Pixelperfektion in allen Browsern garantieren. Wir müssen uns von der Annahme verabschieden, Pixelperfektion sei ein sinnvoller Wert. Vor allem Kunden und Grafiker müssen in meinen Augen lernen, dass Pixelperfektion nur im Bildbearbeitungsprogramm sinnvoll ist, aber nicht in unterschiedlichen Browsern.
... und weiter ...
Alle, die professionell für das Internet arbeiten, sollten wirklich begreifen, dass das Geniale des Internet seine Flexibilität ist.
...
Wenn diese Flexibilität aber die große Stärke des Internet ist, warum versuchen dann so viele Beteiligte, sie einzuschränken?
Das Verständnis für die Einzigartigkeit des Mediums muss erst einmal in die Köpfe der Webentwickler und Grafiker und zur eigenen Überzeugung reifen. Ist es da angekommen, wird es auch einfacher, Kunden besser zu beraten. Es geht um das Grundverständnis, dass kein Webdesigner oder Grafiker die Kontrolle über die Darstellung seiner Webseite im Browser des Nutzers hat.
Doch halt: So wichtig Aufklärung über die Vorteile von Webstandards und die Nachteile eines veralteten Browsers für und unter Webentwicklern auch ist, so sehr kann sie bei Kunden und Usern aufdringlich und bevormundend herüberkommen. Ein erhobener Zeigefinger hat meiner Meinung nach wenig Überzeugungskraft, denn gleichzeitig wissen wir (und auch die User), das der IE6 auch mit aktuellen CSS-Layouts durchaus klarkommt. Zigtausende Seiten beweisen es. Wo liegt also für den User der Nutzen eines solchen Wechsels? Um uns Webdesigner zufrieden zu stellen? Wohl kaum.
Viel einfacher lassen sich User zu einem Browserwechsel bewegen, wenn der Einsatz neuer Webtechniken (ohne dass sie sich selbst dessen bewusst sein müssen) zu einem besseren Nutzererlebnis führt. Jüngstes Beispiel: Die Vorstellung von Bespin, Mozillas Texteditor auf Canvas Basis. Eine derartige Applikation verlangt für die Anwendung selbstverständlich einen aktuellen Browser. Und niemand erwartet ernsthaft, den aktuellen Stand der Technik auf einem technisch veralteten Browser zum Laufen zu bekommen. Die Applikation ist das Zugpferd, in dessen Windschatten sich Anwender gern einen neuen Browser installieren. Und genau dann ist die konsequente Anwendung aktueller und neuer Standards legitim und zugleich förderlich für die Weiterentwicklung des Webs. Genau solche Projekte brauchen wir – und sie werden kommen, ohne Zweifel.
Nutzt Frameworks!
Ob ihr es hören wollt oder nicht: Nutzt Layout-Frameworks! YAML, YUI grids, 960gs oder Blueprint CSS befreien vom permanenten Kampf mit Browserinkompatibilitäten und niemand muss heute das Rad ein zweites Mal erfinden. Natürlich geht auch dann nicht jedes Projekt völlig ohne Stress mit dem Internet Explorer über die Bühne. Doch die Probleme sind zumindest mit YAML so gering und überschaubar, dass das Aussitzen eines langsamen Aussterbens des IE6 kaum einen YAML-Anwender ernsthaft Sorgen bereitet. Die weiteren genannten Frameworks mögen geringere Fähigkeiten im Bereich der Bugprävention haben, für die jeweilige Kernfunktionalität ist die Sicherheit aber dennoch gegeben und führt somit in jedem Fall nachhaltig zu kürzeren Entwicklungszeiten.
Zweifelsohne notwendige Einarbeitungszeiten sind als Argument gegen CSS Frameworks eher schwach bis untauglich, denn diesem einmaligen Aufwand steht eine nachhaltige Zeiteinsparung bei korrekter Anwendung gegenüber. Und mal ehrlich: Weiterbildung und das ständige Erlernen neuer Techniken sind Grundlagen professioneller Arbeit, denn das Web erfindet sich alle paar Jahre neu.
Es zeugt jedoch nicht von Professionalität, öffentlich lautstark auf den verbuggten Internet Explorer 6 zu schimpfen und gleichzeitig zeitsparende Weiterentwicklungen im Bereich CSS zu ignorieren. Denn gleichermaßen gilt: Seit vielen Jahren bereits gibt es für fast ausnahmslos alle CSS-Probleme des Internet Explorer 6 sinnvolle CSS-Hacks oder Workarounds. Weiterhin existieren zahlreiche Methoden, diese Anpassungen so zu integrieren, dass sie die Pflege und Weiterentwicklung eines Layouts nicht behindern. Wer sich der rein manuellen Layoutentwicklung aus eigenem sportlichem Ehrgeiz stellt und Handkodierung bevorzugt, der kommt mit Ausdauer und fundiertem Fachwissen mit Sicherheit ebenso zum Ziel. Aber schon heute würde er das Ziel nicht mehr als erster überqueren. "Working in the now" ... wer mir nicht glauben mag, der lasse sich von Chris Heilmann überzeugen.
In jedem Fall kann ein Kunde erwarten, dass wir als professionelle Webentwickler mit dem Internet Explorer 6 umzugehen wissen und er darf ebenfalls erwarten, dass heute die Unterstützung des IE6 bei der Erstellung eines Screenlayouts nicht zu spürbaren Mehrkosten führt, denn was mit Framework-Einsatz machbar ist, sollte auch bei professioneller Handkodierung ohne Extrakosten realisierbar sein.
Anders sieht der Fall für Einsteiger und Hobbybastler aus. Hier kann ich die Flüche auf den IE6 durchaus verstehen, denn er macht das Erlernen von HTML & CSS unnötig schwer durch seinen zahlreichen Darstellungsfehler. Und es wahrlich nicht einfach, die Vorteile von Webstandards lieben zu lernen, wenn der lokale Testbrowser des Weltmarktführers sich nicht an diese hält.
Funktionale- anstatt visueller Anpassungen
Wenn es darum geht, sich die Arbeit mit dem Internet Explorer 6 zu erleichtern, ist es doch in den seltensten Fällen legitim, ihn ganz außen vor zu lassen. Auf privaten Webseiten ist es sicherlich vorstellbar, im öffentlichen und geschäftlichen Leben ist ein Ausschluss des Internet Explorers jedoch heute und in naher Zukunft ein absolutes Unding. Demzufolge kann es nur in kleinen Schritten vorwärts gehen. Auch hierzu finde ich Ingo Chaos Ansatz ausgesprochen sinnvolll ...
The web is about information, networking, and interaction. This means, a page simply has to work. As I see it, disgraceful degradation would abandon the attitude of everything-is-possible. Functional hacking should supersede the obsolete presentational hacking now, or we keep being trapped in a costly, mutual mistake of the web developers and the web consumers.
Eine Webseite muss in erster Linie benutzbar sein und ihre Aufgabe erfüllen. Die überwiegende Mehrheit der IE6-Nutzer surft eben nicht parallel mit Safari oder Firefox und wird sich deshalb auch an visuellen Abweichungen/Einschränkungen des Layouts nicht stören. Deshalb sollte man die Eingriffe auf notwendige funktionelle Anpassungen beschränken und nicht versuchen, per halbtransparenten Screenshot-Vergleich visuelle Deckungsgleichheit zwischen Browsern zu erzielen, zwischen denen gleich mehrere Evolutionsstufen liegen. Ob via Progressive Enhancement, Graceful Degradation oder doch ein härterer Schnitt, wird immer projektabhängig zu entscheiden sein. Es sollte jedoch jedem Kunden im Beratungsgespräch überzeugend klarzumachen sein, dass Pixelperfektion in dieser Situation nicht das erstrebenswerte Ziel sein kann. Genauso wie ein 8 Jahre alter Röhrenfernseher nicht mehr die visuelle Brillianz aktueller Plasma-TVs erreicht.
Umgang mit neuen Webtechnologien
Auch wenn es vermutlich noch Jahre dauern wird, bis alle Module von CSS3 Recommendation Status erhalten, so unterstützen dennoch bereits jetzt Firefox, Safari und Opera einige interessante neue Eigenschaften:
- erweiterte Gestaltungsmöglichkeiten für Rahmen (Border-Radius, Border-Image)
- Mehrfache Hintergrundgrafiken
- Nachladbare Schriften mit @font-face
- Schatteneffekte (Box- und Text-Shadow)
- Alphatransparente RGB-Kanäle (RGBa)
- Verläufe (Gradients)
- Animation und Übergänge (Transitions)
- usw.
Auch für die modernen Browser ist das momentan die Speerspitze, denn selbst Firefox 3 und Opera 9 unterstützen momentan noch nicht alle diese Features (beim Safari 4 bin ich mich mir nicht ganz sicher) und so wird einen Teil dieser Eigenschaften momentan noch sehr zurückhaltend einsetzen. Runde Ecken via border-radius können sie hingegen alle und es ist ein hervorragendes Beispiel, wie CSS3 die zahllosen, teils recht markupintensiven Rounded-Corner Lösungen obsolete macht.
Keine dieser Eigenschaften wird der IE6 jemals verstehen, der Internet Explorer 8 übrigens auch nicht – sollen wir deshalb sie deshalb einfach links liegen lassen? Ganz klar, Nein. Dennoch sollte klar sein, dass wir uns hier am anderen Ende des Entwicklungszweiges befinden, am vorderen. Demzufolge ist momentan nur die neueste Browsergeneration (z.T. sogar nur Betaversionen) überhaupt dazu in der Lage,fehlerfrei mit diesen neuen Möglichkeiten darzustellen. Der Einsatz muss daher immer mit Bedacht erfolgen.
Erst vor einem Monat veröffentlichte Peter Kröner eine ausführliche Zusammenstellung der aktuellen Browserunterstützung von HTML 5, verbunden mit einer Einschätzung für eine Nutzung schon heute. Wie bei CSS3 gilt: Wir befinden uns an der Spitze dessen, was gute aktuelle Browser leisten können. Aus meiner Sicht macht es deshalb heute noch keinen Sinn, HTML 5 als Grundlage für die Layoutentwicklung zu nutzen. Viel zu lückenhaft ist da noch die Browserunterstützung. Dennoch lassen sich, wie Peter Kröner zeigt, die neuen Formulartypen durchaus bereits verwenden und können Nutzern moderner Browser bereits heute das Leben erleichtern. Doch auch das ist momentan nur Profis zu empfehlen, denn ein Formularfeld vom Typ "date" liefert nur im Opera 9 gesichert auch einen validierenden Datumsstring, in anderen Browsern muss diese Validierung auch weiterhin beispielsweise per JavaScript erfolgen. Daher sind Fallback-Lösungen zwingend gefragt.
Fazit
Der Internet Explorer 6 wird nicht über Nacht verschwinden, das sollte jedem klar sein. Das ist auch gar nicht so wichtig, denn die Probleme sind nicht neu und die Lösungen seit Jahren bekannt. Die Ursache für die plötzliche Aufruhr muss ihren Ursprung also woanders haben. Nämlich in der Tatsache, dass wir mehr und mehr in Konflikte kommen mit aktuellen Technologien, die wir nicht einsetzen können, solange wir uns Pixelperfektion und identische Optik in allen Browsern (seien sie auch noch so alt) selbst verordnen. Solange wir dieses Dogma nicht aufgeben, befinden wir uns in einer Endlosschleife, passend zum Titel dieses Essays.
Gerade im Bezug auf den Einsatz neuer Technologien stellt sich letztlich nämlich die Frage, ob der Internet Explorer 6 hier wirklich die einzige Bremse ist? Auch die Versionen 7 und 8 des Internet Explorers hängen dem Stand der Technik um Jahre hinterher, werden uns aber noch weitaus länger begleiten als der IE6. Die eigentliche Frage müsste daher lauten: Wie gehen wir heute und in Zukunft mit einem Internet Explorer um, der in jeder Version dem aktuellen Stand der Technik um zwei bis drei Jahre hinterher hinkt? Denn machen wir uns nichts vor. Wenn wir diese Frage keine Antwort finden, reiben wir uns in zwei Jahren die Augen weil wir exakt an der gleichen Stelle stehen werden wie heute, nur dass aus der Zahl 6 eine 7 geworden ist. Auch Tomas Caspers, drüben bei Einfach für Alle sieht das übrigens so.
Informationen
Der Internet Explorer 6 wurde am 21. August 2001 von Microsoft veröffentlicht und hatte in bis zum Erscheinen des Internet Explorers 7 einen weltweiten Marktanteil zw. 80 und 90 Prozent.
Aktuell steht die Version 8 des Internet Explorers in den Startlöchern, welche von Microsoft mit dem Anspruch entwickelt wird, erstmals einen Browser mit fehlerfreier Unterstützung für CSS 2.1 auszuliefern.
Freitag, 06.03.09 (14:52 Uhr)
Bravo, bravo, bravo. Das neue Killerargument hast du selbst geliefert: „Genauso wie ein 8 Jahre alter Röhrenfernseher nicht mehr die visuelle Brillianz aktueller Plasma-TVs erreicht.“.
Freitag, 06.03.09 (15:00 Uhr)
Danke für diesen erstklassigen Artikel und dass ich ihn vorher schon lesen durfte ;-)
Mich hat diese regelmäßig aufgewärmte Diskussion um aktive Sterbehilfe für den IE6 schon immer irritiert. Erinnerte mich ein bisschen um die Diskussion von Zwangsverschrottung von Autos ohne Katalysatoren in den 1980er Jahren. Redet heute keiner mehr von. Und der langsame Tod des NN4? Auch Geschichte. Apropos Engagement für moderne Browser: Wo ist eigentlich die längst fällige Unterschriftenaktion mit internationaler Großdemo gegen den noch immer nicht gelösten Mist-Bugs des FF beim Druck von gefloateten Elementen?
Also Leute: Locker bleiben, Ärmel hochkrempeln, einen Ordner mit Patches und Bugfixes für den IE auf den Server schmeißen und dann um die wirklich relevanten Themen der Webentwicklung kümmern.
Freitag, 06.03.09 (15:25 Uhr)
“Schlauerweise” nutzt Microsoft ja in Zukunft die IE6-Engine fuer den neuen mobilen IE, also kommt er darueber leider nochmal ein bisschen zurueck. Gluecklicherweise ist auf Geraeten mit Windows Mobile eher Opera der Platzhirsch, sodass uns das nur nebensaechlich beruehren sollte. :)
Freitag, 06.03.09 (15:46 Uhr)
Sehr guter, ausführlicher und treffender Artikel.
Schön finde ich besonders den Abschnitt Aufklärung! Leider gibt es nur wenige, die das einigermaßen verstanden haben.
Was ich zum Thema IE Mobile 6 bloß gar nicht recht verstehe:
Schlauerweise hat es Microsoft aber hinbekommen, ein eine aktuelle JavaScript-Engine einzubauen.
Quelle
Irgendwie ist das so, als ob man bei einem Haus am Fundament spart…
Freitag, 06.03.09 (22:43 Uhr)
Ein Hochgenuss diesen Artikel zu lesen, wenn man bei der täglichen Arbeit selber ständig über dieses Fossil des Internets stolpert. Interessant wäre die Frage, wie hoch die weltweiten Extrakosten sind, die pro Zeiteinheit dadurch entstehen, dass Webdesigner Websites IE6-kompatibel machen müssen.
Samstag, 07.03.09 (18:05 Uhr)
Ganz großes Kino, dieser Artikel! Vielen herzlichen Dank dafür.
Was ich persönlich mehr als traurig finde, ist das der IE 8 ganz groß als standardkonform angekündigt wurde und es wieder einmal nicht ist. Lernt Microsoft denn nie dazu? Oder sind die Programmierer des IE einfach nicht kompetent genug.
Dieses ständige auf die Internet Explorer Problemchen Rücksicht nehmen zu müssen nervt schon etwas.
Sonntag, 08.03.09 (11:18 Uhr)
Sehr gelungener und lesenswerter Artikel!
Besonders gefallen hat mir die Differenzierung nach verschiedenen Gruppen von Webseitenerstellern sowie die Darlegung des Problems, dass Microsoft selbst nicht konsequent für Updates auf neuere IE-Versionen sorgt.
Auch wenn ich mich lediglich der Gruppe der Hobbybastler hinzurechne, möchte ich doch gerne noch folgende Anmerkungen machen:
Der Opera bis einschließlich zur aktuellen Version 9.64 unterstützt leider border-radius noch nicht. Das soll sich wohl mit der Version 10 ändern.
Im XHTML-Forum gibt es einen sehr umfänglichen und lesenswerten Beitrag mit grundsätzlichen Überlegungen, warum man generell sehr wohl Anti-IE-Kampagnen befürworten kann (siehe http://xhtmlforum.de/55895-finnische-webmaster-gegen-veraltete-browser-13.html#post424546).
Als Hobbybastler nehme ich mir das Recht heraus, Besucher meiner Website, die diese mit dem Internet Explorer bis einschließlich Version 7 betrachten, auf Folgendes hinzuweisen:
Anschließend nenne ich noch ein paar kostenlose Alternativen.
So etwas ist natürlich für Kundenaufträge nicht oder nur bei gelungener Kundenüberzeugung möglich.
Für die eigenen Webseiten halte ich das aber unabhängig davon, ob man Hobbybastler oder gewerblicher Webdesigner ist, für den richtigen Ansatz.
Sonntag, 08.03.09 (11:42 Uhr)
Sehr guter Artikel!
Allerdings halte ich es für gefährlich, pauschal den Einsatz von Frameworks zu empfehlen. Bei diesen bleibt die Semantik ab und an auf der Strecke, Frameworks sind eher visuell orientiert und gehen nicht vom Inhalt aus, Trennung von Inhalt und Struktur wird auch nicht konsequent verfolgt, wenn im HTML Klassennamen geändert werden müssen, um das Layout zu ändern. Grade als Profi ist es doch ein leichtes, auf Frameworks zu verzichten, für Amateure halte ich sie aber für sehr sinnvoll.
Sonntag, 08.03.09 (12:11 Uhr)
Nachtrag:
Für mich als Hobbybastler ist das CSS-Framework YAML ein Segen.
Ohne YAML und dessen hervorragende Dokumentation wäre ich wohl.an den IE-Bugs verzweifelt und würde heutzutage nicht versuchen auf Semantik und Validität meiner Webseiten zu achten, sondern würde einfach nur einen Webbaukasten oder WYSIWYG-Webeditor verwenden.
Sonntag, 08.03.09 (12:49 Uhr)
@Christoph
Das ist Unsinn. Zum einen haben Klassennamen keinen semantischen Kontext (bezogen auf den Inhalt einer Webseite). Die sollten lediglich einer logischen Ordnung folgen, um sich als Anwender im Quelltext zurecht zu finden. Zum zweiten geht diese Übersicht nicht durch die Verwendung von Frameworks verloren, sondern wenn der Anwender damit nicht umgehen kann bzw. den Kopf ausschaltet.
Das mag ein Nachteil von Grid-Layouts generell sein. Dieser Nachteil ist aber gewiss nicht exklusiv den Grid-Frameworks anzulasten. In Handarbeit würde Dein Code bei Erstellung eines Grid-Layouts vermutlich nicht viel anders aussehen.
Ist das wirklich so? Gerade die Arbeit von Profis besteht daraus, immer wieder neue Layouts zu entwickeln. Gerade dann zahlt sich die Frameworknutzung besonders aus, denn die Zeitersparnis multipliziert sich mit der Anzahl der Projekte.
@Dieter
Wie gesagt, ich halte von solchen Aktionen nicht viel. Denn solange eine Webseite keine aktuellen Technologien zur Funktion benötigt, die den IE6 aufgrund seines techischen Unvermögens, mit diesen Technologien umzugehen, von selbst ausschließen, sehe den User zu bevormunden.
Ein Vergleich: Stell Dir vor, einige Autowerkstätten würden öffentlich protestieren, dass in Zukunft nur noch Autos reparieren, die maximal 5 Jahre alt sind. Bei älteren Autos wäre immer soviel zu tun und sie wollen den Kunden nicht mehr so hohe Rechnungen ausstellen. Stattdessen empfehlen Sie, älteren Autobesitzern auf den ÖPNV umzusteigen. Der ist gut ausgebaut in den meisten Großstädten und kostet wenig. Die betroffenen Kunden wird das bestimmt nicht freuen. Wenn aber neue Fahrzeuge deutlich weniger Sprit verbrauchen, leiser und geräumiger sind und zudem steuerlich deutlich günstiger sind und der TÜV schrottreife Autos aussortiert, funktioniert der Übergang ohne Gezanke.
Vielleicht passt der Vergleich nicht ganz, aber ich hoffe Du verstehst worauf ich hinaus will. Er wird von ganz allein verschwinden, wenn wir behutsam beginnen, aktuelle Webtechnologien zur Verbesserung des Nutzererlebnisses unserer Webseiten einzusetzen.
Sonntag, 08.03.09 (15:44 Uhr)
@Dieter:
Ich halte den Hinweis darauf, möglichst einen anderen Browser als den Internet Explorer zu verwenden für Userbevormundung. Und es kann auch nicht der richtige Weg sein, einen solchen Hinweis auf private Webseiten zu schalten, da ich gerade diese als Aushängeschild eines Webdesigners betrachte. Diese Verantwortung obliegt Microsoft, konsequenter in ihrer Update Politik zu sein. Und vor allem neue Browserversionen so zu programmieren, dass auch sämtliche Firmenrelevanten Programme mit den neuen Versionen der Browser laufen. (Tun sie noch nicht.)
@Christoph:
Hier muß man genau differenzieren. YAML ist eindeutig eindeutig visuell, jedoch auch semantisch orientiert. Um mit YAML zu arbeiten müßen eigentlich keine Klassennamen geändert werden. YAML ist absolut und ganz eindeutig an den Webstandards und damit auch an strikter Trennung von Inhalt und Layout orientiert. Wenn das vom Anwender händisch geändert wird - nun, das ist dann das Problem des Anwenders;-)
Ob es unbedingt ein leichtes ist, auf ein dermaßen ausgereiftes Framework wie YAML bei der Entwicklung zu verzichten, wage ich zu bezweifeln. Selbstverständlich können Profis auch ohne auskommen, doch der Zeiteinsatz wird dafür immer ein höherer sein. Man müsste sämtliche Browserbugs händisch behandeln usw.. Und gerade die perfekte Behandlung der Bugs macht YAML ja so interessant. Ob allerdings ein Amateur, wie Du es nennst, so einfach mit YAML klar kommt, wage ich mal vorsichtig zu bezweifeln. Dafür ist es einfach zu anspruchsvoll.
Sonntag, 08.03.09 (16:05 Uhr)
@Dirk
Dagegen spricht der nicht ganz unberechtigte Einwand, dass der “normale” Benutzer nur mit einem Browser surft und damit gar keine Vergleichsmöglichkeiten hat. Schlimmer noch: Man(n) (Frau auch) kann mit immer weniger Wissen um Internet und Browser ins Netz. Wie soll sich da eine Webkompetenz aufbauen? Da sind auch, wenn nicht sogar gerade Webdesigner gefordert.
@Andreas
Benutzer, die in der Masse über eine immer geringere Webkompetenz verfügen - insoweit verweise ich noch einmal auf den Forumsbeitrag unter http://www.highresolution.info/?URL=http://xhtmlforum.de/55895-finnische-webmaster-gegen-veraltete-browser-13.html#post424546 -, auf ein Problem hinzuweisen, ist für mich Information und Aufklärung. Nicht mehr, aber auch nicht weniger.
Einfach auf Microsoft verweisen, die offensichtlich das Problem selbst nicht hinreichend angehen, hilft hier nicht weiter.
Sonntag, 08.03.09 (16:35 Uhr)
@ Dieter:
Ich hab mir jetzt tatsächlich den gesamten von Dir angesprochenen Beitrag durchgelesen. Und der war ja mal verd****t lang;-)
Also, ich kann mit etlichen dieser Äußerungen überhaupt nicht konform gehen, weil sie meiner Meinung nach einfach dem Grundgedanken des Internets widersprechen. Der Grundgedanke lautet, dass so viele Informationen wie möglich so vielen Menschen wie möglich zugänglich gemachte werden. Sollen jetzt alle Menschen ausgeschlossen werden, die ohne JavaScript surfen (so wie ich)? Oder alle, welche den IE6 benutzen (müssen, weil evtl. von der Arbeit aus)?
Mit Sicherheit ist es möglich, Webseiten so zu entwerfen, dass der volle Genuß nur den Anwendern mit einem standardkonformen Browser zukommt. Doch für alle anderen muß die Webseite trotzdem benutzbar sein.
Der normale User verwendet übrigens die standardmäßig aktivierte automatische Updatefunktion von Windows. Da kommt dann ganz automatisch eine zumindest “verbesserte” Version eines nicht den standards entsprechenden Browsers auf den Rechner. Auch auf dem kann man rumhacken, jedoch zeigt er die Webseiten schon mal bedeutend besser an als der IE6.
Übrigens habe ich auf Microsoft verwiesen, weil Windows XP Service Pack 3 (für Netbooks) immer noch mit dem IE6 ausgeliefert wird. Konsequent jedes Produkt auf zumindest IE7 upzudaten würde hier Abhilfe schaffen. Nicht jedoch die Ausgrenzung ganzer Usergruppen. Das kann einfach nicht unser Weg sein.
Sonntag, 08.03.09 (20:26 Uhr)
Hallo Dieter,
Dann hast Du mich nicht richtig verstanden. Warum sollte es einen User interessieren müssen, dass ein Webentwickler den IE6 nicht mag? Professionelle Webentwickler sollten bessere Argumente haben, nämlich bessere, attraktivere und zugänglichere Webseiten. Dann löst sich das Problem von ganz allein und ohne Belehrungen und sinnlose Warnmeldungen.
Andernfalls müssten wir auch vor dem Firefox waren, wie Nils richtig zu bedenken gibt. Auch der Firefox schleppt teils gravierende CSS-Bugs bereits über Jahre mit sich herum.
Dienstag, 10.03.09 (13:45 Uhr)
@ Dirk
Ich beziehe mich mit dem Begriff Semantik nicht auf die Klassennamen, sondern auf deren Verwendung. Bei Blueprint z.B. bestimmt der Klassenname mitunter die Erscheinung, ich muss ins HTML eingreifen, um das Layout zu ändern. Das kann man doch nicht wirklich befürworten.
@ Andreas
Grundsätzlich sind Frameworks nicht schlecht, sie sparen natürlich Arbeit. Es wird aber immer so getan, als würde jeder, der sie nicht nutzt, mit jedem neuen Projekt bei null anfangen. Wenn man aber zehn/zwanzig Projekte gemeisert hat, hat man doch auch eine Menge an Code-Schnipseln angesammelt zur Lösung diverser Probleme, man muss nicht bei null anfangen.
Bei Blueprint aber werden
Dienstag, 10.03.09 (19:39 Uhr)
Hallo Christoph
dann sag doch einfach Blueprint & Co. und nicht pauschal Frameworks. Bei YUI Grids ist dieser Anteil schon geringer, bei YAML ist es nochmal weniger. Und um fair zu bleiben, bei Handkodierung muss in bestimmten Situationen genauso ans Markup ran ... und bei welcher dieser Lösungen der Anteil am größten ist, lässt sich so pauschal gar nicht sagen. Insofern sollte man auch bei der Kritik an Blueprint erstmal schauen, ob man in jedem Fall von Hand effizienter arbeitet.
Dienstag, 10.03.09 (23:00 Uhr)
In pucto Pixelperfektion seh ich das so: einerseits ist pixelperfektes arbeiten ein Segen: der Kunde segnet ein PSD ab, und erwartet letztendlich genau das. Warum das für mich gut ist? Weil ich schon bei der Umsetzung eines Designs (pixelgenau) weiss was erwartet wird und mich auch pixelgenau auf etwas freigegebenes berufen kann.
Das funktioniert natürlich nur wenn das im Konsenz mit dem Designer passiert und der auch ganz genau weiss was unter der Haube draus wird/damit passiert und wie HTML und Browser funktionieren.
Persönlich find ich das zwar überflüssig, aber im Umgang mit Kunden vereinfacht dieser kleine Mehraufwand mein Leben ungemein. Es dürfte schwieriger sein gute Designer zu finden die auch im Photoshop dieselbe pixelgenauigkeit an den Tag legen… pixelgenaues CSS kann jeder.
@Christoph: ich seh das mit den Klassennamen bei Blueprint (z.B. span-2 span-3, usw.) extremst gelassen. Ich bemühe mich einfach mein Markup mit so wenig Klassennamen und IDs auskommen zu lassen wie möglich. Is doch super wenn man die alle aussagekräftig tituliert. Aber an ein paar span-irgendwas Klassen stört sich doch nicht wirklich jemand, oder? clearfloat-divs oder inner-outer wrapper werden auch verwendet. Wofür - genau, fürs aussehen der Webseite.
Ich krieg Ausschlag wenn ich irgendwelche Dropdownmenüs sehe, wo auf jeden Menüpunkt 10 Klassennamen kommen… und per JS dass nochmal soviele dynamisch reingeschrieben werden… dass man nur mit CSS jedes Design verwirklichen kann ist doch ein Armenmärchen von vor 4, 5 Jahren. Sonst gäbs die Frameworks mit ihren Markup-Eigenheiten nicht. Inhaltsebene ist imho das was in xml/DB steht. Gestaltungseben ist beides: (X)HTML und CSS.
Mittwoch, 11.03.09 (00:21 Uhr)
@Dirk
Ums kurz zu machen:
http://meiert.com/en/blog/20080805/html-css-frameworks/
so seh ich das auch.
@Erik
Dann sieh mal den Artikel “Grid Layout - das neue Tabellenlayout?” (http://grochtdreis.de/weblog/2008/05/30/grid-layouts-das-neue-tabellenlayout/), vielleicht weißt du dann was ich meine.
Die von dir beschriebene Pixelperfektion ist doch gerade das Problem.
Hier noch einmal das Zitat von Jens Grochtdreis aus dem Artikel oben:
So wie du es beschreibst, ist genau die falsche Denkweise. Man hat ein Photoshop Layout und daraus wird eine Website gemacht, die genauso aussieht wie in Photoshop, was dabei im HTML rauskommt ist egal, Hauptsache jeder Browser kann damit umgehen und das Layout sitzt. Warum dann nicht gleich ein PDF hochladen?
Websites sind aber keine Gemälde sondern Dokumente, die zunächst entsprechend ihres Inhalts ausgezeichnet und anschl. gestaltet werden sollten. Das ist aber eine Tatsache, die viele noch lernen müssen, vor allem im Umgang mit dem Kunden, ich schließe mich da selbst nicht aus.
Aufgrund der Unzulänglichkeiten in CSS kommt man nicht immer ohne zusätzliche div- oder span-Elemente aus, um eine bestimmte Gestaltung zu erzielen. Daraus kann man aber nicht umgekehrt die Schluss ziehen, dass es egal ist, wie der Quellcode aussieht.