Почему Internet Explorer нужен флаг "hasLayout"?
Как и многие разработчики, работающие на веб-сайтах для Internet Explorer, я, кажется, сталкиваюсь с множеством ошибок, вызванных пресловутым hasLayout flag.
Я понимаю, что делает этот флаг и как он работает (по большей части). Хорошее объяснение, которое я прочитал на днях (хотя я не могу найти источник), заключается в том, что hasLayout в IE по существу означает "Сделать этот элемент прямоугольником".
Это, очевидно, более сложное, чем это, но это довольно хорошо подведено (на мой взгляд).
Я не понимаю, почему браузер использует этот флаг. Когда я искал ответ, я нашел тот, который звучал логично:
Internet Explorer должен был иметь дело с очень старым устаревшим кодом, прежде чем CSS действительно был в самом разгаре. В качестве архитектурного решения, позволяющего браузеру легко добавлять CSS к нему, флаг hasLayout использовался для запуска определенных свойств CSS, чтобы страница отображалась правильно. Это относится ко времени IE4.
Это почти имело смысл для меня, пока я не понял, что Firefox (Netscape в то время) имел дело с той же проблемой. Netscape существует примерно столько же, сколько Internet Explorer, однако для него не требуется никакого внутреннего флага hasLayout или чего-либо подобного, насколько я знаю.
Как показано, как флаг hasLayout является источником стольких ошибок в Internet Explorer, знает ли кто-нибудь, почему IE имеет этот флаг, а другие браузеры ему не нужны?
Это то, что я хотел бы знать исключительно из любопытства, если у кого-то есть какие-то теории или он знает ответ. Я хотел бы узнать больше о том, почему (или почему нет) этот флаг полезен.
Ответы
Ответ 1
Средство рендеринга Netscape было полностью переписано после NS4. Двигатель IE "Trident" не получал такой любви. Этот сделал хороший бизнес-смысл - IE продолжал улучшаться постепенно, в то время как NS переписывалась и частично из-за этого (и частично из-за его распространения расположение...) удалось захватить огромную долю рынка...
Но конечным результатом является старая, жестокая кодовая база, которая делает жизнь ад для разработчиков, и поэтому они должны быть мучительно осведомлены о том, что должно быть скрытой информацией о реализации.
Теперь эта последняя точка является ключевой: рендеринг браузера - это абстракция, позволяющая создавать в нескольких строках разметки что-то, что потребует сотни или тысячи строк низкоуровневого рендеринга и кода обработки событий. И, как и все абстракции программирования, он немного течет... Это верно для IE, Netscape, Firefox, Opera, Webkit... И каждый браузер имеет разработчиков, работающих лихорадочно, чтобы подключить утечки в абстракциях. Кроме того, в течение пяти лет IE этого не делал. Другие утечки были подключены, но механизм рендеринга стал все более ситообразным.
Вместе эти факторы сговариваются, чтобы разоблачить такие вещи, как hasLayout.
Ответ 2
Очень трудно узнать, не имея возможности посмотреть исходный код.
Следующие ссылки являются наиболее информативными, которые я нашел до сих пор:
Первый цитирует устаревший документ, содержащий очень интересное предложение:
Внутренне, наличие макета означает, что элемент отвечает за рисование собственного содержимого.
И второй говорит:
Объектная модель внутри Explorer, по-видимому, представляет собой гибрид модели документа и их традиционной модели приложения.
Полагая оба вместе, я предполагаю, что элементы с hasLayout на самом деле являются окнами в интерфейсе Win32 API — то есть дело CreateWindow. Элементы без hasLayout затем не имеют своего собственного "окна", но нарисованы их ближайшим предком hasLayout -having, используя какой-то код макета (несколько похожий на классы макета Qt). Поскольку только истинные "окна" имеют код макета (который рисует их макроблоки), это те, которые имеют "макет", поэтому hasLayout.
Если это так, то будет два кода макета кода кода (один для hasLayout, который должен был бы позиционировать "окна", чтобы их можно было нарисовать позже, используя обычную систему рисования окон, и который рисует дочерние элементы окна hasLayout "вручную" при рисовании "окна" ). Так как у всего кода есть ошибки (а анодальные данные говорят, что IE <= 6 имеет больше, чем среднее), оба пути кода будут иметь разные ошибки, объясняя, почему добавление или удаление hasLayout (эффективное переключение на другой путь кода) изменяет набор ошибок, затрагивающих данный элемент. Не только это, но поскольку у вас есть два пути кода, работающие в одном документе, итерация обоих путей кода будет еще одним богатым источником тонких ошибок.
Другие браузеры, вероятно, избегали проблемы, просто используя архитектуру, которая не имеет такого двойного пути макета.
Если моя догадка верна, я бы сказал, что если вы использовали инструмент для отображения всех дочерних окон, которые использует браузер, вы обнаружите, что каждый видимый элемент hasLayout имеет один, в то время как элементы без макета не имеет.
