IE6: Besser als sein Ruf?

[Sheridan]

Hallo,

ihr werdet sicher gleich denken: der spinnt oder ist von MS wenn er den IE6 lobt.
Aber zur Beruhigung: Als Softwarentwickler habe ich so meine K(r)ampf mit den MS Bugs (aktuell: Excel als Datenbankquelle macht Probleme, wenn gemischte Datentypen vorkommen: Pseudointelligenz pur!)

Der letzte Beitrag ([pref:t=84316&m=493992]) bestärkt mich allerdings, dass der IE6 IMHO einen guten HTML/CSS Parser hat: Er ist fehlertoleranter als seine Kollegen Netscape, Mozilla und Opera.

Mein HTML und CSS war nicht validiert (Danke an nag und andere für die Links für die HTML und CSS Validierung) und IE6 hat die Seite wie gewünscht dargestellt.

Auch bei Tabellen ist der IE6 Parser sehr fehlertolerant: Wenn ich eine table Endtag vergesse, so stellt dieser die Tabelle korrekt dar.

In Bezug auf die Sicherheit mag er sehr schwach sein, aber der Parser ist IMHO sehr gut!

Wie gesagt, ich bin nicht unbedingt ein Freund von MS (obwohl ich damit arbeiten muss).

Aber ihr könnt mich gerne vom Gegenteil überzeugen.

Bitte um eure Meinungen.

Danke und

LG,
Georg!

[Christian Kruse]

Hallo Sheridan,

dieses Thema wurde bereits mehrfach ausdiskutiert. Schau doch mal im
Archiv (</archiv/>), da findest du sehr viele Diskussionen zu
diesem Thema. Finden kannst du sie leichter mit der Suche:
http://suche.de.selfhtml.org/.

Grüße,
 CK

[Sven Rautenberg]

Moin!

In Bezug auf die Sicherheit mag er sehr schwach sein, aber der Parser ist IMHO sehr gut!

"Gut" ist eine Frage der Betrachtungsweise. Wenn der IE zufällig korrekt raten kann, was im fehlerhaften Einzelfall vom Seitenautor gemeint ist, dann ist das für einen Anwender, der die Seite nur angucken will, sicher gut.

Für den Autoren der Seite hingegen ist das schlecht, weil er durch die Seitenanzeige in der Sicherheit gewogen wird, alles sei in Ordnung, was aber nicht stimmt.

Insofern mag der IE hinsichtlich seiner Fehlertoleranz für den normalen Anwender ganz gut sein (wenn man mal von den offenen Sicherheitslücken absieht, die den IE zu einer ernsthaften Gefahr machen) - für den Seitenentwickler ist sie des definitiv nicht.

- Sven Rautenberg

[Thomas J.S.]

Hallo,

dass der IE6 IMHO einen guten HTML/CSS Parser hat:

Hmm ... die Frage ist, welcher Grad der Fehlertoleranz "wir" als "gut" bezeichnen.

Aber eine gute Sache hat der IE (6) tatsächlich und das ist sein XML- und XSLT-Parser.

Grüße
Thomas

[Danny]

Hi,

also ich bin anderer Meinung.

Vom IE hätte es schon längst eine neue Version geben müssen, mal abgesehen von den ständigen Service-Packs und Fixes. IE6 hat schon Jahre auf dem Buckel, was angesichts der rasanten Entwicklungen der Webstandards schon eine Frechheit ist. Gerade Microsoft, denen die finanziellen Mittel und Zeit dafür nicht fehlen sollten...

Okay, der Parser mag fehlertolerant sein. Für Hobby-Bastler und Einsteiger ist das auch durchaus ein großer Vorteil. Aber eben durch diese Toleranz und Vermutungen, wie der Code bei Fehlern wahrscheinlich eigentlich gemeint war, schleichen sich unbemerkt Fehler ein, die man ohne strenge Prüfungen nicht als solche erkennt.

Mein Wunsch-Feature wäre es daher, abgesehen vom Doctype-Switching eine Möglichkeit zu implementieren (z.B. über meta-Tag oder condition comments), den Code auf Wunsch gemäß Webstandards zu validieren, bzw. den Render-Modus zu wählen. Daraufhin sollten natürlich auch aussagekräftige Warnungen, bzw. Fehler ausgepuckt werden.
Außerdem hat der aktuelle Parser hier und da Probleme mit Leerzeichen, wobei dadurch z.T. sichtbarer Leeraum gerendert wird. Das scheint aber eine Schwäche vieler Parser zu sein, warum auch immer. Es hängt wohl auch davon ab, ob eine Regex-basierte Engine oder klassische Tokenizer verwendet werden und wie genau der Hersteller sich an die Grammatik hält.

MfG
Danny

[Uwe]

Der letzte Beitrag ([pref:t=84316&m=493992]) bestärkt mich allerdings, dass der IE6 IMHO einen guten HTML/CSS Parser hat: Er ist fehlertoleranter als seine Kollegen Netscape, Mozilla und Opera.

Das nennst Du gut, wenn Seiten verfälscht werden? Ich will im Browser das angezeigt bekommen, was ich reinstecke. Nicht was es evt. sein könnte.

[MudGuard]

Hi,

Der letzte Beitrag ([pref:t=84316&m=493992]) bestärkt mich allerdings, dass der IE6 IMHO einen guten HTML/CSS Parser hat: Er ist fehlertoleranter als seine Kollegen Netscape, Mozilla und Opera.

In CSS ist genau festgelegt, was zu tun ist, wenn einer Eigenschaft ein ungültiger Wert (z.B. Länge ohne Längeneinheit) zugewiesen wird: die Regel muß ignoriert werden. (Siehe http://www.w3.org/TR/REC-CSS2/conform.html#conformance, wo es heißt: "This means that the user agent must accept all valid values and must ignore declarations with invalid values.")

Einen Browser, der in so einem Fall den ungültigen Wert in irgendeiner Weise zu interpretieren versucht, würde ich nicht als fehlertolerant, sondern als fehlerhaft bezeichnen.

cu,
Andreas

[Cheatah]

Hi,

(Siehe http://www.w3.org/TR/REC-CSS2/conform.html#conformance, wo es heißt: "This means that the user agent must accept all valid values and must ignore declarations with invalid values.")

ergänzend: Das gleiche Dokument definiert, wie der Begriff "must" zu verstehen ist.

Einen Browser, der in so einem Fall den ungültigen Wert in irgendeiner Weise zu interpretieren versucht, würde ich nicht als fehlertolerant, sondern als fehlerhaft bezeichnen.

Siehst Du dies ebenso für den Quirks-Mode, der ja dafür gedacht ist, mit (potenziell) fehlerhaften Seiten günstig(er) umzugehen?

Cheatah

[MudGuard]

Hi,

(Siehe http://www.w3.org/TR/REC-CSS2/conform.html#conformance, wo es heißt: "This means that the user agent must accept all valid values and must ignore declarations with invalid values.")
ergänzend: Das gleiche Dokument definiert, wie der Begriff "must" zu verstehen ist.

<korinthenkack mode="smile">
Nö, tut es nicht. Es steht nur da, wo diese Definitionen zu finden sind.
</korinthenkack>

Einen Browser, der in so einem Fall den ungültigen Wert in irgendeiner Weise zu interpretieren versucht, würde ich nicht als fehlertolerant, sondern als fehlerhaft bezeichnen.
Siehst Du dies ebenso für den Quirks-Mode, der ja dafür gedacht ist, mit (potenziell) fehlerhaften Seiten günstig(er) umzugehen?

Der Quirks Mode ist m.E. überflüssig. Es gibt keinen vernünftigen Grund, fehlerhafte Seiten zu erstellen, und damit auch keinen vernünftigen Grund, fehlerhafte Seiten darstellen lassen zu wollen.

cu,
Andreas

[Bubax]

Hi,

Der Quirks Mode ist m.E. überflüssig.

Nein.

Es gibt keinen vernünftigen Grund, fehlerhafte Seiten zu erstellen,

Ja.

und damit auch keinen vernünftigen Grund, fehlerhafte Seiten darstellen lassen zu wollen.

...und was ist mit alten Seiten, die niemand mehr überarbeiten wird? Eine gewisse Übergangsphase mit quirks mode ist sehr sinnvoll ( - wie lange diese aber dauern sollte, möchte ich jetzt nicht aus dem Stegreif entscheiden müssen ;)

Viele Grüße,
Bubax

[Henryk Plötz]

Moin,

...und was ist mit alten Seiten, die niemand mehr überarbeiten wird? Eine gewisse Übergangsphase mit quirks mode ist sehr sinnvoll

Dann sollte die aber so aussehen, dass beim Laden einer offensichtlich fehlerhaften Seite ein modales Dialogfenster erscheint mit der Frage ob die Seite im Quirks-Modus oder den Spezifikationen folgend zu rendern sei.

[Mathias Bigge]

Hi MudGuard,

dass der IE durch seine Sicherheitsprobleme desavouiert ist, ist klar und braucht nicht weiter ausgeführt zu werden. Das Gleiche gilt für seine unbestreitbaren Stärken wie Schnelligkeit, XML usw. Hatten wir alles schon tausend Mal...

..., dass der IE6 IMHO einen guten HTML/CSS Parser hat: Er ist fehlertoleranter als seine Kollegen Netscape, Mozilla und Opera.
Einen Browser, der in so einem Fall den ungültigen Wert in irgendeiner Weise zu interpretieren versucht, würde ich nicht als fehlertolerant, sondern als fehlerhaft bezeichnen.

Das Thema Fehlertoleranz finde ich allerdings interessant: Viele hier im Forum teilen Deine Position, die an Hypertext-Interpretation prinzipiell ähnliche Wertmaßstäbe anlegen wie an eine Programmiersprache, wo Fehlertoleranz wirklich fehl am Platz wäre.

Ich halte diesen Ansatz für ein Mißverständnis der Funktion von Hypertext. Ziel war und ist, ein einfaches Kommunikationsmedium zu schaffen, dass es Autoren, nicht nur Informatikern, ermöglicht, Inhalte durch Formatierungen besser zu strukturieren und um Bilder und andere Elemente zu ergänzen und zudem verschiedene Texte durch Links miteinander zu verbinden und in offenen und vielfältigen IT-Umgebungen zu kommunizieren. In Bezug auf diesen Aspekt ist Fehlertoleranz ein Feature.

Die Entwicklung, für die Du eintrittst, hat natürlich auch einen Hintergrund: Wenn das Internet zu einem Medium wird, komplexe und genau definierte Daten zu kommunizieren, etwa Unternehmensdaten, oder wie hier im Selfraum eine komplexe Programmlogik im Hintergrund steht, um Daten durchsuchbar, verwaltbar und durch Programme zugänglich zu machen, ist die Anforderung natürlich eine andere.

Insofern finde ich die Microsoft-Überlegung, zwei Modi der Dateninterpretation einzuführen, durchaus sinnvoll, ebenso wie ich es für sinnvoll halte, auf der DTD-Ebene zwei Schienen weiterzuentwickeln, also XHTML nicht als einzigen Standard zu betrachten, sondern nur als eine Schiene unter mehreren, die auf besonders strenge Strukturierung ausgerichtet ist. Hier fände ich durchaus sehr strenge Maßstäbe sinnvoll.

Wir bemühen uns im Selfraum um eine Standardisierung der Daten, es zeigt sicher aber, dass es gar nicht so einfach ist, verbindliche Normen für Dokumente sehr variablen Inhalts zu vereinbaren und konsequent durchzusetzen. Da Du die Dokeumente sehr gut kennst, kannst Du leicht erkennen, welche Klippen es da zu umschiffen gilt.

Meine Prognose: Es wird in Zukunft beide Schienen geben, eine fehlertolerante, etwa für eMails und die schnelle Kommunikation in einer Arbeitsgruppe, eventuell sogar reduziert auf zentrale Tags, und eine Schiene in Richtung XML mit sehr genauen Standards.

Was hältst Du davon?

Viele Grüße
Mathias Bigge

[zoidberg]

Hi,

..., dass der IE6 IMHO einen guten HTML/CSS Parser hat: Er ist fehlertoleranter als seine Kollegen Netscape, Mozilla und Opera.
Einen Browser, der in so einem Fall den ungültigen Wert in irgendeiner Weise zu interpretieren versucht, würde ich nicht als fehlertolerant, sondern als fehlerhaft bezeichnen.

Das sehe ich auch so. Sicher sind die Quirks-Modi gut, um ältere Seiten darzustellen, aber die webautoren sollten sich nicht darauf verlassen, dass die Parser "schon das richtige machen", also interpretieren, denn darin sind Computer generell schlecht.

Ein Webautor sollte wissen was er nach welchen Regeln macht, so wie ein "echter" Autor die Rechtschreibregeln kennen sollte. eine gewisst Fehlertoleranz ist sicher angesagt, um Programmabstürze bei nicht verstandenen "Befehlen" zu verhinden, aber nicht um zu versuchen, irgendwas sinvolles aus einem unsinvollem Dokument zu machen. Die Parser sollten sich generell an die "Rechtschreibregeln" halten und Fehler ignorieren. Wenn ein Webautor fehler macht, sind das nunmal seine Fehler.

Fehlertoleranz als Feature zu verkaufen kann auch nach hinten losgehen, denn ich kann nicht glauben, dass alle Browser und all deren Versionen irgendwelche Fehler gleichermaßen interpretieren. Als Webautor darauf zu spekulieren, dass "das schon irgendwie hinhaut" kann es doch nicht sein - grade bei kommerziell betriebenen Seiten (die Startseite von www.amazon.de hat beispielweise nach dem Valigatortest über 700 Fehler, ist also absoluter Bockmist).

Auch im Zusammenhang mit der Zugänglichkeit (für Behinderte) ist regelkonformes HTML, wichtig, denn die "Geräte", die diese Personen nutzen MÜSSEN, haben wohl kaum die "Fehlertoleranz" des IE.

noch schlimmer wird es allerdings, wenn ein Browser einem fehlerfreiem Dokument den Fehlerinterpretationsmodi auzwingt. Dies macht etwa der IE6, wenn man korrekterweise bei einem XHTML-Dokument den XML-Prolog <?xml version="1.0" encoding="UTF8"?> angibt.

mfg - zoidberg

[molily]

Hallo,

Als Webautor darauf zu spekulieren, dass "das schon irgendwie hinhaut" kann es doch nicht sein - grade bei kommerziell betriebenen Seiten (die Startseite von www.amazon.de hat beispielweise nach dem Valigatortest über 700 Fehler, ist also absoluter Bockmist).

Ds hatten wir doch schon öfters. Es wird eben nicht nur faktisch spekuliert, dass es schon irgendwie hinhaut, sondern es haut tatsächlich hin und die Seite erreicht nichtsdestoweniger eine hohe Kompatibilität. Das Argument, dass populäre kommerzielle Seiten wie Amazon und Ebay trotz Syntaxfehlern halbwegs interoperabel sind, was sich darin zeigt, dass sie Seiten faktisch erfolgreich sind, ist nicht so einfach vom Tisch zu fegen.

Auch im Zusammenhang mit der Zugänglichkeit (für Behinderte) ist regelkonformes HTML, wichtig, denn die "Geräte", die diese Personen nutzen MÜSSEN, haben wohl kaum die "Fehlertoleranz" des IE.

Die Ironie ist eben, dass die meiste assistive Software, wie etwa Screenreader, auf dem MSIE aufbaut.

Mathias

[molily]

Hallo,

(...) Meine Prognose: Es wird in Zukunft beide Schienen geben, eine fehlertolerante, etwa für eMails und die schnelle Kommunikation in einer Arbeitsgruppe, eventuell sogar reduziert auf zentrale Tags, und eine Schiene in Richtung XML mit sehr genauen Standards.

Hier finde ich die Entwicklung sehr interessant, dass es faktisch keinen wirklich standardkonformen XML-Parser in den Browsern gibt (wenn die kompromisslose Lesart MudGuards angelegt wird). Der XML-Standard ist ja, was bestimmte Fehler angeht, sehr deutlich und sieht Fehlertoleranz nicht vor. Bei Wohlgeformtheitsfehlern brechen die Parser zwar auch weiterhin ab. Wer als XHTML schreibt und es darauf anlegt, dass die Browser ihre XML-Parser einsetzen, muss formale einwandfrei Syntax abliefern, sonst streikt der Browser völlig. Über dieses Verhalten wurde in letzter Zeit kontrovers in der Szene diskutiert. Angesichts dessen, dass die Weiterentwicklung von HTML nur im Rahmen von XML und damit diesen strengen Regeln verläuft, spielt die von dir angesprochene Forderung nach einer einfachen und robusten Hypertextsprache als Alltagstechnik für Laien natürlich eine zentrale Rolle.

Davon ungeachtet sind die Browserprogrammierer faktisch dazu übergegangen, dass sich die XML-Parser nicht mehr sklavisch an die Regeln halten. So wird mittlerweile die Kodierung eines XHTML-Dokuments durch nicht-standardgerechte Browserheuristik festgestellt. Der Standard schreibt vor, dass die Kodierung UTF-8 angenommen werden muss, wenn keine anderslautende angegeben wurde. Das bedeutet gleichzeitig, dass der Parser die Verarbeitung abbrechen müsste, wenn er z.B. auf ISO-8859-1-kodierte Zeichen wie Umlaute trifft. Bei früheren Opera- und Mozilla-Versionen war das meines Wissens auch der Fall. Die jetzigen verarbeiten das Dokument trotzdem so gut es geht, obwohl es kein gültiges XML-Dokument ist. Aus technischer Sicht ist es natürlich nicht ratsam, solche Dokumente zu schreiben, da die besagte universelle Verarbeitbarkeit flöten geht.

Insofern sehe ich trotz aller (in sich zweifellos plausiblen) Forderungen nach Striktheit selbst diese harte Linie faktisch bröckeln bzw. sie wird von der Wirklichkeit überholt. Und diese Entwicklung könnte sogar demokratisch genannt werden.

Mathias

[Henryk Plötz]

Moin,

Ich halte diesen Ansatz für ein Mißverständnis der Funktion von Hypertext. Ziel war und ist, ein einfaches Kommunikationsmedium zu schaffen, dass es Autoren, nicht nur Informatikern, ermöglicht, Inhalte durch Formatierungen besser zu strukturieren und um Bilder und andere Elemente zu ergänzen und zudem verschiedene Texte durch Links miteinander zu verbinden und in offenen und vielfältigen IT-Umgebungen zu kommunizieren. In Bezug auf diesen Aspekt ist Fehlertoleranz ein Feature.

Aber grade bei der Kommunikation über mehrere verschiedene IT-Umgebungen hinweg, sind Dokumente die nicht einer gemeinsamen Spezifikation gehorchen eher suboptimal (um das mal vorsichtig auszudrücken). Wenn du es nur mit einer Umgebung zu tun hast von der du weist welchen Browser sie einsetzt und wie dieser gewisse Dinge interpretiert, dann ist das vielleicht ok. Wenn du aber ein Dokument hast welches im weiten Internet (IE-dominiert), im Universitätsumfeld (teilweise noch NN4-dominiert) und in der Grafikabteilung (lauter Macs) eingesetzt werden soll, wäre es äusserst unpraktisch wenn die Bedeutung des Dokuments nicht genau definiert ist.

Und wenn du mit "Autoren, nicht nur Informatikern" sagen willst, dass es nicht kompliziert sein sollte, dann ist 'fehlertoleranz' grade unnötig. Wer kein HTML kann soll einen WYSIWYG-Editor einsetzen (das war AFAIK auch ursprünglich als der primäre Weg, HTML-Dokumente zu erzeugen, geplant) und der hat verdammtnochmal korrekten HTML-Code auszuspucken.

Grade die HTML-Spezifikation ist doch extrem einfach zufriedenzustellen: man muß die meisten Tags nicht zumachen und einige nicht einmal öffnen. (Ok, es gibt derzeit nur einen verbreiteten Browser der HTML potentiell korrekt parsen kann, aber das ist eine andere Geschichte.)

Insofern finde ich die Microsoft-Überlegung, zwei Modi der Dateninterpretation einzuführen, durchaus sinnvoll

Das Gegenteil von "gut gemacht" ist leider immernoch "gut gemeint" und eine Implementation die vollständig definiertes Verhalten im Zuge der 'Fehlertoleranz' fehlerhaft interpretiert ist mindestens unbrauchbar, wenn nicht gar schlimmeres. Die Entscheidung, ob ein Dokument 'fehlertolerant' (also evt. auch 'fehlererzeugend') geparst werden soll, sollte meiner Meinung nach dem Benutzer überlassen werden. Oder meinetwegen auch dem Autor, dann aber bitte in deutlich (also ein HTTP-Header oder ein Meta-Tag) und nicht über irgendwelche Ratespiele (Doctype-Sniffing) die prinzipbedingt eher zufällig richtig raten.

[zoidberg]

Hi,

Aber grade bei der Kommunikation über mehrere verschiedene IT-Umgebungen hinweg, sind Dokumente die nicht einer gemeinsamen Spezifikation gehorchen eher suboptimal (um das mal vorsichtig auszudrücken).

So sehe ich das auch. Die grundlegende HTML-Spezifikation ist nicht extrem schwer zu erlernen und es gibt einen vernünftigen Grund, warum es eine (ja gut, mehrere) exakt definierte Spezifikation gibt, welche den Aufbau eines HTML-Dokuments beschreibt: Das Dokument soll bei jedem Ausgabegerät die gleiche Aussgae haben.
Informationen werden von jemanden als Daten abstrahiert (z.B. als HTML-Dokument) und sollen so dargestellt werden. unabhängig davon, welches Gerät zur darstellung verwendet wird. Deswegen heißt es ja auch Parser (to parse = analysieren) und nicht Interpreter. Aber genau das macht der IE mit seiner Fehlertoleranz. Er analysiert die Dokumente nicht (und macht folglich auch nicht dass, was er machen sollte), er interpretiert die HTML-Dokumente und ich habe es schon mal gepostet: Im Interpretieren sind Computer generell schlecht!

Wer kein HTML kann soll einen WYSIWYG-Editor einsetzen und der hat verdammtnochmal korrekten HTML-Code auszuspucken.
Grade die HTML-Spezifikation ist doch extrem einfach zufriedenzustellen: ...

Eben! HTML ist (im Vergleich) echt einfach (zu erlernen), weswegen es für WYSIWYG-Programme doch eigentlich nicht schwer sein sollte, validen Text zu generieren. Leider hat es sich etabliert, nicht mehr HTML, sondern ROTZ ins Netz zu stellen, weil die Browser "gebonnen haben", diesen Rotz zu interpretieren und nicht zu parsen. Folge: "Niemand" interessiert sich mehr dafür, denn warum sollte er auch. Bei Kommerziellen Projekten kann man sich viel zeit und Arbeit sparen, denn "das läuft ja".
Das es nur irgendwie läuft interessiert don niemanden. Aber das kann doch gar nicht gut gehen, auf lange sicht.
Es wird immer mehr Browser geben, immer mehr Versionen und immer mehr Betriebssysteme für verschiedene Systeme (PDA, Handy, ...) - wieder mit verschiedenen Programmen in verschiedenen Versionen. Dazu kommen immer mehr Techniken, die Clientseitig verarbeitet werden müssen - wieder in verschiedenen versionen. Wenn also jede Kombination aus Hardware, OS und Browser irgendwas bei irgendeiner technik irgendwie anders macht, wird es irgendwann völlig unmöglich sein, ein HTML-Dokument zu schreiben, das auf mehr als 25% aller möglichen Kombinationen einigermaßen einwandtfrei läuft.

Es wird ein GAU geben, wenn man nicht langsam anfängt, Spezifikationsgerecht zu arbeiten. So "schlau" köännen PC's gar nicht werden, dass sie selbstständig erarbeiten können, was sich der Verfasser eines Dokuments gedacht hat. Wenn ich jetzt plötzlich [html] [head] ... [-head][hyperbody] ... [-hyperbody]... [-html] schreibe weil ich das besser/schöner/toller finde - welcher Browser kann damit noch was anfangen?

Das kann auf Dauer doch nicht funktionieren. Zumal immer mehr Menschen online gehen und "unbedingt" ihre eigene Page brauchen und je mehr menschen online gehen, desto meh meinungen gibt es auch, wie "vernünftiges" HTML-auszusehen hat.

mfg - zoidberg

[Mathias Bigge]

Hi Henryk,

Kommunikation über mehrere verschiedene IT-Umgebungen hinweg

Ich denke, das war von Anfang an das Ziel, das dabei gewisse Unterschiede in der Darstellung entstehen, wurde hingenommen, sie sind vielleicht auch unvermeidbar. Dass es auch Bedürfnisse nach stärker standardisierten Dokumenten gibt, zeigt vielleicht der PDF-Boom, wobei hier die Vereinheitlichung anders hergestellt wird als durch die strenge Normierung des Codes, der Maßstab ist eine normierbare Ausgabe auf verschiedenen Print-Medien.

Wer kein HTML kann soll einen WYSIWYG-Editor einsetzen und der hat verdammtnochmal korrekten HTML-Code auszuspucken.

Wenn korrekt valide heißt, gibt es solche Editoren nicht, oder? Die Frage ist  die genaue Definition von Korrektheit, hier im Forum wird sie von vielen mit dem Validieren gleichgesetzt, was ich problematisch finde.

Grade die HTML-Spezifikation ist doch extrem einfach zufriedenzustellen: man muß die meisten Tags nicht zumachen und einige nicht einmal öffnen.

Wenn Du "transitional" als korrekt akzeptierst, ist die strenge Normierung aus meiner Sicht auch nicht gegeben. Der Standard ist da doch noch sehr offen.

Die Entscheidung, ob ein Dokument 'fehlertolerant' (also evt. auch 'fehlererzeugend') geparst werden soll, sollte meiner Meinung nach dem Benutzer überlassen werden. Oder meinetwegen auch dem Autor,

Das halte ich für einen entscheidenden Unterschied. Die Masse der User dürfte mit solchen Entscheidungen völlig überfordert sein oder doch den zugegebenermaßen schwer zu definierenden "fehlertoleranten" Weg wählen.

Viele Grüße
Mathias Bigge

[zoidberg]

Hi Mathias (Herr Bigge)

Wenn korrekt valide heißt, gibt es solche Editoren nicht, oder? Die Frage ist  die genaue Definition von Korrektheit, hier im Forum wird sie von vielen mit dem Validieren gleichgesetzt, was ich problematisch finde.

Was ist daran problematisch? Es gibt eine genaue Spezifikation. entweder entspricht ein Dokument dieser, oder nicht. Entweder es ist richtig/valode/korrekt, oder eben nicht. Und wenn es jemand nicht hinbekommt ein Dokument zu schreiben, dass richtig ist, soll er es eben lassen, so sehe ich das. Gut, es gibt verschiedene Spezifikationen, aber es gibt auch die Möglichkeit, diese zu kennzeichen, damit der Browser weiß, was er machen soll.

By the way. gibt es einen Browser, der den Doctype konsequent umsetzt und bei "strict" z.B. das align-Attribut ignoriert?

Die Entscheidung, ob ein Dokument 'fehlertolerant' (also evt. auch 'fehlererzeugend') geparst werden soll, sollte meiner Meinung nach dem Benutzer überlassen werden. Oder meinetwegen auch dem Autor,
Das halte ich für einen entscheidenden Unterschied. Die Masse der User dürfte mit solchen Entscheidungen völlig überfordert sein oder doch den zugegebenermaßen schwer zu definierenden "fehlertoleranten" Weg wählen.

Eben, deswegen ist es wichtig, dass die Dokumente vom Verfasser ordnungsgemäß geschrieben werden. Wo gibt es denn das sonst, dass im Computerbereich dermaßen auf Standarts geschiss** wird? Gut, nirgendwo werden Standarts immer und völlig eingehalten, aber dermaßen davon abzuweichen und dem Computer zu überlassen, wie er das Dokument "gerne verarbeiten möchte", wo gibt's dass?
Wie wärs mit einer random-Anweisung, an Stelle der Doctype-Bestimmung????

mfg - zoidberg

[Cyberfuzzy]

Moin,

ich kenne ein paar Problempunkte, wo ich den IE auf jeden Fall bevorzuge. Da wären Z. B. ein Dateiupload auf Webseiten. Die meißten funktionieren mit allen Browsern. Es gibt aber auch welche, die nur im IE funktionieren. Bei Netscape, Firefox, usw. erscheint dann nur:

ADODB.Stream- Fehler '800a0bbc'
Die Datei konnte nicht beschrieben werden.

Ja, und dann so Sachen wie JavaScript in XML, da hat der IE auch einen rießen Vorsprung.

Ansonsten finde ich, dass der Firefox auch keine schlechte Alternative ist.

Gruß
Cyberfuzzy
--
http://www.cyberfuzzy.com

[Michael]

Hallo Sheridan,

Der letzte Beitrag ([pref:t=84316&m=493992]) bestärkt mich allerdings, dass der IE6 IMHO einen guten HTML/CSS Parser hat: Er ist fehlertoleranter als seine Kollegen Netscape, Mozilla und Opera.

Ich für meine Teile glaube, dass die "Kollegen" des IE besser sind als er selbst.
Ich möchte dass kurz erklären, wenn ich eine Webseite erstellt habe, bin ich meistens stolz auf das, was ich gemacht habe und ich möchte auch, dass jeder Besucher meiner Webseiten das erhält, was ich wollte und nicht das, was der IE interpretiert.

In Bezug auf die Sicherheit mag er sehr schwach sein, aber der Parser ist IMHO sehr gut!

Was bringt dir der Parser, wenn man mit dem IE deine Daten manipulieren kann?

Wie gesagt, ich bin nicht unbedingt ein Freund von MS (obwohl ich damit arbeiten muss).

Wieso musst du mit dem IE arbeiten?

Aber ihr könnt mich gerne vom Gegenteil überzeugen.

Ich hoffe, dass ich dies getan habe.

Ich möchte noch anmerken, dass ich glaube, dass man keinen Quirks-Modus benötigt, auch nicht für alte Webseiten. Wenn jeder Teil einer Webseite eine Doctype-Angabe hätte würden die meisten Browser wissen, wie sie sich zu Verhalten haben!

Gruß,
Michael

[Arx]

Hallo,

ihr werdet sicher gleich denken: der spinnt oder ist von MS wenn er den IE6 lobt.

Genau. ;-)

Aber zur Beruhigung: Als Softwarentwickler habe ich so meine K(r)ampf mit den MS Bugs

Kenne ich.

Der letzte Beitrag ([pref:t=84316&m=493992]) bestärkt mich allerdings, dass der IE6 IMHO einen guten HTML/CSS Parser hat: Er ist fehlertoleranter als seine Kollegen Netscape, Mozilla und Opera.

Also ist der Parser schlechter. Wie soll es jemals _einheitliche_ Standards geben, wenn diese nicht von _allen_ Browsern eingehalten werden?

Mein HTML und CSS war nicht validiert (Danke an nag und andere für die Links für die HTML und CSS Validierung) und IE6 hat die Seite wie gewünscht dargestellt.

Der IE ist ja auch kaputt. http://forum.de.selfhtml.org/archiv/2004/5/80314/ hat mich zum Firefox bekehrt und seitdem ich vor ein paar Wochen einen Hijacker-Angriff hatte, der sogar meinen MediaPlayer lahmgelegt hat, ist Firefox auf meinem System Standardbrowser.

In Bezug auf die Sicherheit mag er sehr schwach sein,

...Genau!

Aber es gibt Hoffnung! Die Masse der Bekehrten wächst! Da stehts: http://www.zdnet.de/news/tkomm/0,39023151,39123969,00.htm

Gruß
Arx