Pourquoi Internet Explorer besoin le drapeau « hasLayout »?

Question

Comme beaucoup de développeurs travaillant sur des sites Web pour Internet Explorer, il me semble venir à travers un grand nombre de bugs qui sont causés par le fameux hasLayout drapeau .

Je comprends ce que ce drapeau et comment il fonctionne (pour la plupart). Une bonne explication que j'ai lu l'autre jour (bien que je ne peux pas trouver la source) est que hasLayout dans IE signifie essentiellement « faire de cet élément un rectangle. »

Il est évidemment plus compliqué que cela, mais il est assez bien résumé avec cette (à mon avis).

Ce que je ne comprends pas pourquoi le navigateur utilise cet indicateur. Lorsque vous cherchez une réponse, j'ai trouvé un qui semblait logique:

  

Internet Explorer a dû traiter très ancien code existant avant de CSS était vraiment en plein essor. En tant que décision architecturale de rendre le navigateur facile d'ajouter CSS sur elle, le drapeau hasLayout a été utilisé pour déclencher certaines propriétés CSS pour que la page soit correctement rendue. Cela remonte à au moment de IE4.

Ce sens presque fait pour moi, jusqu'à ce que je compris que Firefox (Netscape à l'époque) a dû faire face au même problème. Netscape a été autour pour à peu près aussi longtemps que Internet Explorer, mais il n'a pas besoin de drapeau hasLayout interne, ou quelque chose de semblable, pour autant que je sais.

Voyant que la façon dont le drapeau hasLayout est la source de tant de bugs dans Internet Explorer, personne ne sait pourquoi IE a ce drapeau et les autres navigateurs ne ont pas besoin?

Ceci est quelque chose que je voudrais savoir pure curiosité si quelqu'un a des théories ou arrive à connaître la réponse. Je voudrais mieux comprendre pourquoi (ou pourquoi pas) ce drapeau est utile.

Answer 1

Le Netscape a été complètement rendu réécrite post-NS4. Le moteur de rendu « Trident » IE a pas un tel amour. Cette fait bonne sens des affaires - IE a continué d'améliorer progressivement alors que NS était récrite, et en partie à cause de cela (et en partie à cause de son accord de distribution ...) a réussi à capturer une grande part du marché ...

Mais le résultat final est un vieux, ce qui rend crufty codebase l'enfer de la vie pour les développeurs, qui doivent par conséquent être douloureusement conscients de ce que devrait être les détails de mise en œuvre cachées.

Maintenant, ce dernier point est essentiel: le moteur de rendu d'un navigateur est une abstraction, ce qui vous permet de créer en quelques lignes de quelque chose de balisage qui prendrait des centaines ou des milliers de lignes de rendu de bas niveau et le code de gestion des événements. Et comme toutes les abstractions de programmation, il fuit un peu ... Cela est vrai pour IE, Netscape, Firefox, Opera, Webkit ... Et chaque navigateur a développeurs travaillant fébrilement pour boucher les fuites dans les abstractions. Sauf, pendant cinq ans, IE n'a pas. Autre fuites étaient obstrués, mais le moteur de rendu est devenu de plus en plus en forme de tamis.

Ensemble, ces facteurs conspirent pour exposer des choses comme hasLayout.

Answer 2

Il est très difficile de savoir sans pouvoir regarder leur code source.

Les liens suivants sont, je l'ai trouvé plus d'information à ce jour:

• En ayant la mise en page - le concept de hasLayout dans IE / Win
• / IE7 / notes /

Le premier cite un document obsolète qui contient une phrase très intéressante:

  

En interne, ayant la disposition signifie qu'un élément est responsable de l'élaboration de son propre contenu.

Et le second dit:

  

Le modèle d'objet dans l'Explorateur semble être un hybride d'un modèle de document et leur modèle d'application traditionnelle.

Mettre les deux ensemble, je suppose que les éléments avec hasLayout sont dans les fenêtres de fait dans le sens de l'API Win32 - à savoir, les choses CreateWindow traite. Les éléments sans hasLayout alors ne disposent pas de leur propre « fenêtre », mais sont attirés par leur ancêtre le plus proche de hasLayout ayant, en utilisant une sorte de code de mise en page (un peu comme les classes de mise en page de Qt). Étant donné que seuls les vrais « fenêtres » ont le code de mise en page (qui dessine leurs descentants de schémas de moins), ils sont ceux qui « ont la mise en page », donc hasLayout.

Si tel est le cas, il y aurait deux codes de mise en page des chemins de code différents (l'un pour hasLayout, qui devrait placer les « fenêtres » afin qu'ils puissent tirer plus tard en utilisant le système normal de dessin de la fenêtre, et celle qui attire les enfants de la hasLayout « fenêtre » à la main tout en tirant la « fenêtre »). Étant donné que tout le code a des bugs (et les preuves anedoctal dit IE <= 6 a plus que la moyenne), les deux chemins de code auraient différents bugs, expliquant pourquoi l'ajout ou la suppression hasLayout (commutation efficacement à l'autre chemin de code ) modifie l'ensemble des bogues affectant l'élément en question. Non seulement cela, mais puisque vous avez deux chemins de code de travail dans le même document, le iteraction des deux chemins de code serait une autre source riche de bugs subtils.

D'autres navigateurs probablement évité le problème simplement en utilisant une architecture qui ne dispose pas d'un tel chemin double de mise en page.

Si ma conjecture est correcte, je dirais que si vous avez utilisé un outil pour afficher toutes les fenêtres de l'enfant le navigateur utilise, vous découvririez que chaque élément hasLayout visible a un, alors que les éléments de mise en page, moins ne sont pas une.