Webstandard

Also allein die Positionierung im IE ist der Hammer. Es ist sowieso eine gute Idee, allgemein alle relevanten Tags mit einem reset zu versehen (margin, padding auf 0 und solche Sachen). Aber ohne müsste man für beim IE noch mehr schauen, dass die Seite zumindest in etwa gleich aussieht, wie in allen anderen Browsern auch. Jetzt mit der 8ten Version wird vieles besser, aber wird wohl noch ein paar Jährchen dauern, bis der sich durchgesetzt hat.

Ich frage mich immer und immer wieder wenn ich die Web-Stats der Seiten ansehe, die ich gestaltet habe, wieso noch immer 50% der Internet-User mit MS IE 6 surfen.
Jetzt wird meistens eh schon jeder User mit Updates zwangsbeglückt und trotzdem surft die Hälfte mit diesem alten klobigen Ding.
Jeder, dem ich nur kurz die Funktionalität eines Firefox oder Opera gezeigt habe, hat sich auf Nimmer-wiedersehen vom IE getrennt.
Ich glaube es Bedarf einer grundlegen Aufklärung von Usern...

Fehler wie das fehlende max-width oder min-width wurden ja schon genannt. Folgender Fehler ist ebenfalls bekannt, nervt mich aber besonders: Ein width: 100% bezieht sich im IE nicht auf den umgebenden Container, sondern auf die Fensterbreite. Wenn ich also z.B. mein Konterfei im Navigationscontainer skalieren möchte, dann möchte ich, dass es 100% der Breite des Navigationscontainers einnimmt. Im IE leider unmöglich.

Folgende zwei Fehler des IE sind kaum oder gar nicht bekannt, obwohl ich schon seit Jahren immer mal wieder darauf hin weise:

Folgendes Konstrukt: Ein Link (a) enthält ein button, der einen Text enthält. Ein völlig legales Konstrukt. Es geht dabei um Navigationsbuttons. Wenn ein Button wie ein Button aussieht, wie ein Button funktioniert, wie ein Button gedacht ist, letztendlich ein Button _ist_, dann sollte er auch button genannt werden. Ich meine hier nicht das Element input type="button", sondern das Element button (gibt's sein html 4). Der IE zeigt diesen zwar korrekt an, und bei Darüberfahren mit der Maus wird das Ziel, das durch den Link angegeben ist, auch korrekt in der Statuszeile angezeigt, aber ein Klick auf den Button führt zu gar Nix. Um den IE zufrieden zu stellen, muss man die Navigation in diesem Fall als Javascript Event Handler duplizieren. Und ohne Javascript funktioniert hier gar Nix.

Zweitens: Javascript, das nachtträglich per Javascript erzeugt und eingebunden wurde, funktioniert nicht im EI. Folgender Gedanke: Ich habe einen Javascript Styleswitcher. Der sol zwischen verschiedenen Stilen umschalten. Nun möchte ich aber, dass die Auswahlbox für die alternativen Stile nur angezeigt wird, wenn auch Javascript aktiviert ist. Wenn es nicht aktiviert ist, dann ist nämlich eine nicht funktionierende Auswahlbos eher irritierend. Also füge ich diese Auswahlbos einschließlich des Javascript Event Handlers erst per Javascript ein. Das funktioniert so weit, dass die Auswahlbos auch wirklich per Javascript eingefügt wird. Aber das dort angegebene Javascript zum Umschalten des Stils funktioniert einfach nicht. In anderen Browsern schon. Nur eben nicht im IE. Dabei benötigt nur der IE diesen Javascript Styleswitcher, die anderen Browser können zwischen den alternativen Stilen mit Bordmitteln umschalten. Also, der einzige Browser, der hier die Javascript Krücke braucht, kann dsa per Javascript eingebundene Javascript leider nicht ausführen.

Beide Bugs veröffentliche ich seit Jahren immer und immer wieder, aber es passiert Nichts. Es wird keine Notiz davon genommen.

Matthias, ich verstehe nicht ganz, was Du eigentlich willst. Du kennst die einschlägigen Seiten, welche die Mängel des IE an zahllosen Beispielen beschreiben, in erster Linie die Probleme die auch der IE 7 nicht abschaffen konnte: CSS und Sicherheit.

Warum sollte man die »Grundlagen« auf dem schwächsten Glied der Browserkette ausarbeiten? Das bedeutet doch eine Beschneidung der Möglichkeiten die das Web heute bietet, zu Gunsten eines nach wie vor schlechten Produktes von Microsoft. Kein Fortschritt, weil immer noch eine Mehrheit der User den IE benutzt? (In erster Linie stammen diese Zahlen von unbedarften Anwendern, die noch nie was von anderen Browsern gehört haben bzw. von armen Angestellten, die in der Firma keine alternativen Browser verwenden dürfen.). Das ist unlogisch.

Zum Glück entwickelt sich mittlerweile ein Trend dahin, dass für den IE (speziell 6) nur die notwendigen Elemente einer Seite optimiert werden und alle modernen Funktionen einfach weggelassen werden.

Darüber hinaus ist sich Microsoft selbst nicht sicher, wie es mit dem IE weitergehen soll. Vielleicht doch Webkit als Engine oder ganz einstampfen? Die Gerüchteküche brodelt und irgendwas ist immer dran.

Was Du im anderen Beitrag mit der Serverdarstellung/-nutzung meinst, ist mir nicht ganz klar. Aber was hat das Serverinterface mit dem allgemeinen Web zu tun?

Hallo Matthias,

die Grundlage sollte immer das schwächste Glied sein. Generell ist das so richtig. Für mich liegt der Haken an einer ganz anderen Stelle: Gewissenskonflikte.

Der Kunde/ich möchte eine Webseite, die von möglichst vielen Menschen betrachtet werden kann. Gleichzeitig sollen mittlerweile in fast jede Webseite aber auch neue Erkenntnisse zu Nutzerverhalten und optimierten Bedienungen einfließen (siehe z.B. AJAX und JavaScipt-Effekt-Bibliotheken). Selbst wenn der Kunde sagt: „Lass den IE 6 einfach weg.“, kann ich das doch nicht machen. Schließlich ist es auch meine Aufgabe den kunden zu beraten. IE 6 weglassen kann je nach Zielgruppe bedeuten, dass die Hälfte der Besucher die Seite nicht effektiv nutzen kann.

Um das auch mit dem schwächsten Glied zu vereinbaren ist ein teilweise ungeheurer Mehraufwand zu leisten. Wer bezahlt mir den? Der Kunde? Der zweifelt doch an meinen Fähigkeiten wenn ich ihm sage, dass der meistgenutze Browser ungenügend aus heutiger Sicht funktioniert. So wird doch eine Distanz aufgebaut, die nicht gut für das Klima zwischen mir und dem Kunden sein kann. Also muss ich geradezu „klammheimlich“ die Funktionen auch dem IE beibringen.

Das gibt es in vielen Bereichen: Automechaniker, die an vergammelten alten Karossen rumschrauben müssen, obwohl’s schon seit 10 Jahren ein Nachfolgemodell gibt, Netzwerkadmins, die uralt Modems integriegen müssen, usw.

Das ist einfach frustrierend.

Noch eine Ergänzung zu ein paar Kommentaren hier: Wenn der IE einige Einstellungen anders voreingestellt hat als andere Browser, dann ist das kein Fehler des IE. So weit ich weiss, gibt es dazu keine Vorgaben des w3c. Ein Fehler wäre es z.B., wenn der IE den Ramen um verlinkte Bilder auch mit border: none nicht weg bekäme. Tut er aber.

Solche Voreinstellungen sind möglicherweise von Microsoft etwas ungeschickt gewählt, aber ein fehler im eigentlichen Sinn sind diese Voreinstellungen nicht. Fehler hat der IE genug. Echte Fehler.

Neben Fehlern nervt auch immer wieder, dass bestimmte Standards gar nicht umgesetzt werden. So kann der IE z.B. immer noch kein echtes xhtml anzeigen. Er zeigt eine xhtml-Seite nur an, wenn man ihm diese als html (text/html) verkauft. Dann behandelt er diese einfach wie eine weitere fehlerhafte html Seite. Ein Umstieg auf moderne und zeitgemäße Technik wird damit massiv ausgebremst. Der IE kann's halt einfach nicht.

Auch in Punkto css patzt der IE, was die Implementierung von Standards angeht. Alternative Stylesheets? Im IE Fehlanzeige. Abgerundete Ecken? Fehlanzeige. Das wäre so die wichtigsten Punkte, die mir so einfallen, die auch der IE8 noch immer nicht beherrscht.

Was den sog. Page-Zoom angeht, hast Du Recht. Allerdings ist schon allein die Notwendigkeit dazu ein Versagen der Webdesigner.

Was Pixel als relative Einheit angeht, hast Du ebenfalls Recht. Nur, relativ zu was? Früher war ein Pixel eine Größe relativ zu einer physikalischen Gegebenheit. Ein Pixel auf einem Monitor hat nun mal eine gegebene Größe. Theoretisch auch heute noch. Pixel auf verschiedenen Monitoren können in der Tat verschieden groß sein. In der Regel ist ein Pixel auf einem älteren und/oder einem kleineren Monitor größer als auf einem neueren und/oder größeren Monitor. Heutzutage kommt dazu, dass ein logisches Pixel abhängig von der gewählten Bildschirmauflösung nicht mehr identisch sein muss mit einem physikalischen Pixel.

Ich kann, wie ich schon mehrmals geschrieben habe, schlecht sehen. Übermorgen habe ich dazu einen Termin in dre Augenklinik. Mal sehen, warum. Ich habe mir also wegen meiner schlechten Sehfähigkeit einen großen modernen Bildschirm geleistet. Was passiert nun mit Schriften, deren Größe in px festgelegt wurde? Nun, sie werden auf meinem großen und hochauflösenden Monitor noch kleiner dargestellt. Weil auf diesem Monitor ein Pixel eben noch kleiner ist als auf einem älteren Monitor.

Eine mögliche absolute Größe wäre eine Größe in cm. Doch warum überhaupt eine Größe festlegen? Gut, Größen relativ zu einer Basisgröße festlegen macht Sinn. Aber diese Basisgröße sollte nicht vom Webdesigner festgelegt werden, sondern vom Benutzer. Denn nur der weiss, welche Größe er zum lesen braucht.

Was diese Seite hier angeht: Nun, sie ist für mich nicht unbenutzbar. Ich habe die Firefox Extension "nosquint", mit der ich den Text hier auf 120% vergrößere. Das reicht, um sie für mich benutzbar zu machen. Insofern ist das hier ein wirklich marginales Problem. Dennoch, marinal oder nicht, es sind unnötige Probleme.

@John: Dem ist wohl so. Ganz sicher ist ein komplett medienunabhängiges Design (das geht weit über ein em-basiertes Layout hinaus) deutlich schwerer und aufwändiger. Und Kostendruck und Zeitdruck sind ganz sicher Faktoren. Insofern weiss ich, dass meine Vorstellung eine Idealvorstellung ist, und in der Realität eben Abstriche gemacht werden müssen.

Was mir allerdings ganz lieb wäre, wenn dies Notwendigkeit von Abstrichen nicht überall dazu führen würde, abstriche zur Norm zu machen.

@Siegfried

IE Buttons

Zu dem Thema Buttons in A Tags oder A Tags in Buttons, bisher habe ich BUTTON Tags immer im Formular Kontext verwendet und nicht im LINK Kontext weil dann würde ich nur einen A Tag verwenden. Laut W3C ist das auch korrekt, also der IE verhält sich zumindest diesbzgl. richtig weil es dafür ja nicht vorgesehen war. Vielleicht nimmst du "Button" zu wortwörtlich den eigentlich hast du ja vor einen LINK zu setzen. Semantisch ein A Tag. Wenn man ihn aber Visuell wie einen Button aussehen lassen möchte dann ist das doch eher eine Sache für dein CSS.