Почему Internet Explorer нужен флаг hasLayout?

Question

Как и многие разработчики, работающие над веб-сайтами для Internet Explorer, мне кажется, что я сталкиваюсь с множеством ошибок, вызванных пресловутым hasLayout флагом .

Я понимаю, что делает этот флаг и как он работает (по большей части). Хорошее объяснение, которое я прочитал на днях (хотя я не могу найти источник), состоит в том, что hasLayout в IE по сути означает «Сделать этот элемент прямоугольником».

Это, очевидно, более сложно, чем это, но это довольно хорошо суммируется с этим (по моему мнению).

Я не понимаю, почему браузер использует этот флаг. Когда я искал ответ, я нашел тот, который звучал логично:

Internet Explorer должен был иметь дело с очень старым унаследованным кодом еще до того, как CSS был в самом разгаре. В качестве архитектурного решения сделать браузер простым для добавления в него CSS, флаг hasLayout использовался для запуска определенных свойств CSS, чтобы страница отображалась правильно. Это относится ко времени IE4.

Это почти имело смысл для меня, пока я не понял, что Firefox (Netscape в то время) имел дело с той же проблемой. Netscape существует уже почти столько же, сколько Internet Explorer, однако, насколько мне известно, ему не нужен ни внутренний флаг hasLayout, ни что-либо подобное.

Видя, как флаг hasLayout является источником многих ошибок в Internet Explorer, кто-нибудь знает, почему IE имеет этот флаг, а другим браузерам он не нужен?

Это то, что я хотел бы знать чисто из любопытства, если у кого-то есть какие-либо теории или случается, что он знает ответ. Я хотел бы больше понять, почему (или почему нет) этот флаг полезен.

Answer 1

Рендерер Netscape был полностью переписан после NS4. В движке IE Trident такой любви не было. Это имело хороший деловой смысл - IE продолжал постепенно улучшаться, пока NS переписывался, и частично из-за этого (и частично из-за его механизма распределения ...) удалось захватить огромную долю рынок ...

Но конечным результатом является старая, жесткая кодовая база, которая превращает жизнь в ад для разработчиков, которые, следовательно, должны с ужасом осознавать, что должно быть скрытыми деталями реализации.

Теперь, последний пункт является ключевым: браузерный рендерер - это абстракция, позволяющая создавать в несколько строк разметки нечто, что займет сотни или тысячи строк низкоуровневого кода рендеринга и обработки событий. И, как и все программные абстракции, он немного просачивается ... Это верно для IE, Netscape, Firefox, Opera, Webkit ... И в каждом браузере есть разработчиков, лихорадочно работающих для устранения утечек в абстракциях. За исключением пяти лет, IE не сделал. Другие утечки были закрыты, но механизм рендеринга становился все более и более похожим на сито.

Вместе эти факторы способствуют разоблачению таких вещей, как hasLayout.

Answer 2

Очень трудно понять, не имея возможности взглянуть на их исходный код.

Следующие ссылки являются наиболее информативными, которые я нашел до сих пор:

• Наличие макета - концепция hasLayout в IE / Win
• / IE7 / примечание /

Первый цитирует устаревший документ, который содержит очень интересное предложение:

Внутренне наличие макета означает, что элемент отвечает за отрисовку своего собственного содержимого.

А второй говорит:

Объектная модель внутри Explorer выглядит как гибрид модели документа и их традиционной модели приложения.

Соединяя оба, я предполагаю, что элементы с hasLayout на самом деле являются окнами в смысле Win32 API & mdash; то есть вещи, с которыми имеет дело CreateWindow. Элементы без hasLayout тогда не имеют своего собственного «окна», но отрисовываются их ближайшим hasLayout -представителем, используя некоторый код компоновки (что-то вроде классов компоновки Qt). Поскольку только истинные «окна» имеют код макета (который рисует их потомков без макета), именно они «имеют макет», поэтому hasLayout.

Если это так, то будет два разных кода расположения путей кода (один для hasLayout, который должен был бы позиционировать «окна», чтобы их можно было рисовать позже, используя обычную систему рисования окон, и тот, который рисует дочерние элементы hasLayout «окна» вручную при рисовании «окна»). Поскольку во всем коде есть ошибки (а в анекдотических данных говорится, что IE <= 6 имеет больше среднего), оба пути кода будут содержать <em>разных ошибок, объясняя, почему добавление или удаление hasLayout (фактически переключение на другой код путь) изменяет набор ошибок, влияющих на рассматриваемый элемент. Более того, поскольку в одном и том же документе работают два пути кода, итерация обоих путей кода станет еще одним богатым источником незаметных ошибок.

Другие браузеры, вероятно, избежали этой проблемы, просто используя архитектуру, которая не имеет такой двойной путь компоновки.

Если мои предположения верны, я бы сказал, что если бы вы использовали инструмент, чтобы показать все дочерние окна, которые использует браузер, вы бы обнаружили, что каждый видимый элемент hasLayout имеет его, в то время как элементы без компоновки делают не один.