Warum braucht Internet Explorer die Flagge "Haslayout"?

Question

Wie viele Entwickler, die auf Websites für Internet Explorer arbeiten hasLayout Flagge.

Ich verstehe, was diese Flagge tut und wie es funktioniert (größtenteils). Eine gute Erklärung, die ich neulich gelesen habe (obwohl ich die Quelle nicht finden kann), ist das hasLayout In IE bedeutet im Wesentlichen "Machen Sie dieses Element zu einem Rechteck".

Es ist offensichtlich komplizierter als das, aber damit ist es ziemlich gut zusammengefasst (meiner Meinung nach).

Was ich nicht verstehe ist, warum der Browser diese Flagge verwendet. Bei der Suche nach einer Antwort fand ich eine, die logisch klang:

Der Internet Explorer musste sich mit sehr alten Legacy -Code aus dem CSS auseinandersetzen. Als architektonische Entscheidung, den Browser leicht zu machen, um CSS hinzuzufügen, die hasLayout Flag wurde verwendet, um bestimmte CSS -Eigenschaften auszulösen, damit die Seite korrekt gerendert wird. Dies geht bis zur Zeit von IE4 zurück.

Dies machte für mich fast Sinn, bis ich merkte, dass Firefox (zu der Zeit Netscape) mit dem gleichen Problem zu tun hatte. Netscape gibt es schon so lange wie Internet Explorer, es braucht jedoch keine interne hasLayout Flagge oder ähnliches, soweit ich weiß.

Sehen wie das hasLayout Flag ist die Quelle für so viele Fehler im Internet Explorer. Weiß jemand, warum dh diese Flagge und andere Browser sie nicht brauchen?

Dies ist etwas, das ich gerne aus Neugier wissen würde, wenn jemand Theorien hat oder die Antwort weiß. Ich würde gerne mehr darüber verstehen, warum (oder warum nicht) diese Flagge nützlich ist.

Answer 1

Der Netscape-Renderer wurde nach dem NS4 vollständig neu geschrieben. IEs "Trident" -Rending -Motor hat keine solche Liebe bekommen. Dies machte guten geschäftlichen Sinn - Der IE verbesserte sich weiterhin schrittweise, während NS neu geschrieben wurde, und teilweise aufgrund dieser (und teilweise wegen seiner Vertriebsregelung ...) gelang es, einen großen Anteil am Markt zu erfassen ...

Aber das Endergebnis ist eine alte, friedliche Codebasis, die das Leben für Entwickler zur Hölle macht, die sich folglich schmerzhaft bewusst sein müssen, was sollte Implementierungsdetails versteckt sein.

Nun ist dieser letzte Punkt der Schlüssel: Der Renderer eines Browsers ist eine Abstraktion, die es Ihnen ermöglicht, in einigen Zeilen von Markup etwas zu erstellen, das Hunderte oder Tausende von Zeilen von Code mit niedrigem Level-Rendering und Ereignishandling benötigen. Und wie alle Programmierabstraktionen läuft es ein wenig aus ... Dies gilt für IE, Netscape, Firefox, Opera, Webkit ... und jeder Browser hat Entwickler arbeiten fieberhaft Um die Lecks in die Abstraktionen zu schließen. Außer fünf Jahren, dh nicht. Sonstiges Lecks wurden angeschlossen, aber der Rendering-Motor wurde immer mehr Sieb.

Gemeinsam verschwören sich diese zu Faktoren, um Dinge wie zu entlarven wie hasLayout.

Answer 2

Es ist sehr schwer zu wissen, ohne ihren Quellcode betrachten zu können.

Die folgenden Links sind die informativsten, die ich bisher gefunden habe:

• Zum Layout - das Konzept von Haslayout in IE/Win
• /IE7/Notizen/

Der erste zitiert ein veraltetes Dokument, das einen sehr interessanten Satz enthält:

Innen bedeutet Layout, dass ein Element für das Zeichnen seiner eigenen Inhalte verantwortlich ist.

Und der zweite sagt:

Das Objektmodell im Explorer scheint ein Mischung eines Dokumentmodells und seines herkömmlichen Anwendungsmodells zu sein.

Beide zusammenstellen, ist meine Vermutung, dass Elemente mit hasLayout sind in der Tat Windows im Win32 -API -Sinn - das heißt, Dinge CreateWindow befasst sich mit. Die Elemente ohne hasLayout Dann haben Sie kein eigenes "Fenster", sondern werden von ihren nächsten gezeichnet hasLayout-Heißen Sie den Vorfahren mit einer Art Layout -Code (etwas wie QT -Layoutklassen). Da nur die wahren "Windows" den Layoutcode haben (der ihre Layout-freien Abstammung zeichnet), sind sie diejenigen, die "Layout" haben, also hasLayout.

Wenn dies der Fall ist, würde es zwei verschiedene Codepfade -Layoutcode geben (den für hasLayout, was die "Fenster" positionieren müsste, damit sie später mit dem normalen Fensterzeichnungssystem gezeichnet werden können, und das, das die Kinder der Kinder zeichnet hasLayout "Fenster" von Hand beim Zeichnen des "Fensters"). Da alle Code Fehler aufweisen (und Anidoctal -Beweise sagen, dass der IE <= 6 mehr als den Durchschnitt hat), hätten beide Codepfade anders Fehler, erklären, warum Hinzufügen oder Entfernen hasLayout (Wechsel zum anderen Codepfad effektiv) ändert den Satz von Fehler, die das betreffende Element beeinflussen. Nicht nur das, sondern da Sie zwei Codepfade haben, die im selben Dokument arbeiten, ist die Iteraktion Von beiden Codepfaden wäre eine weitere reichhaltige Quelle subtiler Fehler.

Andere Browser haben das Problem wahrscheinlich einfach durch die Verwendung einer Architektur mit einem solchen Doppel -Layout -Pfad vermieden.

Wenn meine Vermutung korrekt ist, würde ich sagen, dass Sie, wenn Sie ein Tool verwenden würden, um alle untergeordneten Fenster anzuzeigen, die der Browser verwendet hasLayout Element hat eins, während die layoutlosen Elemente keine haben.