Зачем Internet Explorer нужен флаг «Haslayout»?

Question

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

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

Это, очевидно, сложнее, чем это, но это довольно хорошо суммировано с этим (на мой взгляд).

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

Internet Explorer пришлось иметь дело с очень старым устаревшим кодом из -за того, что 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 ... и каждый браузер имеет Разработчики работают лихорадочно Чтобы подключить утечки в абстракциях. За исключением пяти лет, т.е. нет. Другой Утечки были подключены, но двигатель рендеринга становился все более и более похожим на сито.

Вместе это к факторам сговорится, чтобы разоблачить такие вещи, как hasLayout.

Answer 2

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

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

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

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

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

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

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

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

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

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

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