Por que o Internet Explorer precisa do sinalizador “hasLayout”?

Question

Como muitos desenvolvedores que trabalham em sites para o Internet Explorer, parece que me deparo com muitos bugs causados ​​pelo notório hasLayout bandeira.

Eu entendo o que esse sinalizador faz e como funciona (na maior parte).Uma boa explicação que li outro dia (embora não consiga encontrar a fonte) é que hasLayout no IE significa essencialmente "Tornar este elemento um retângulo".

Obviamente é mais complicado que isso, mas se resume muito bem a isso (na minha opinião).

O que não entendo é por que o navegador usa esse sinalizador.Ao procurar uma resposta, encontrei uma que parecia lógica:

O Internet Explorer teve que lidar com códigos legados muito antigos, anteriores ao CSS estar realmente em pleno andamento.Como uma decisão arquitetônica para facilitar a adição de CSS ao navegador, o hasLayout flag foi usado para acionar certas propriedades CSS para que a página fosse renderizada corretamente.Isso remonta à época do IE4.

Isso quase fez sentido para mim, até que percebi que o Firefox (na época Netscape) tinha que lidar com o mesmo problema.O Netscape existe há quase tanto tempo quanto o Internet Explorer, mas não precisa de nenhum software interno hasLayout flag, ou algo semelhante, até onde eu sei.

Vendo como o hasLayout flag é a fonte de tantos bugs no Internet Explorer, alguém sabe por que o IE tem esse sinalizador e outros navegadores não precisam dele?

Isso é algo que eu gostaria de saber por pura curiosidade, se alguém tiver alguma teoria ou souber a resposta.Gostaria de entender mais sobre por que (ou não) esse sinalizador é útil.

Answer 1

O renderizador Netscape foi completamente reescrito após o NS4.O mecanismo de renderização "Trident" do IE não recebeu esse amor.Esse fazia sentido nos negócios - O IE continuou a melhorar gradativamente enquanto o NS estava sendo reescrito, e em parte por causa disso (e em parte por causa de seu acordo de distribuição...) conseguiu capturar uma enorme fatia do mercado...

Mas o resultado final é uma base de código antiga e desajeitada que torna a vida dos desenvolvedores um inferno, que devem, conseqüentemente, estar dolorosamente cientes do que deve detalhes de implementação ocultos.

Agora, esse último ponto é fundamental:o renderizador de um navegador é uma abstração, permitindo criar em poucas linhas de marcação algo que levaria centenas ou milhares de linhas de renderização de baixo nível e código de manipulação de eventos.E como todas as abstrações de programação, vaza um pouco...Isto é verdade para IE, Netscape, Firefox, Opera, Webkit...E cada navegador tem desenvolvedores trabalhando febrilmente para tapar os vazamentos nas abstrações.Exceto que, durante cinco anos, o IE não o fez. Outro os vazamentos foram tapados, mas o mecanismo de renderização tornou-se cada vez mais semelhante a uma peneira.

Juntos, esses fatores conspiram para expor coisas como hasLayout.

Answer 2

É muito difícil saber sem poder olhar o código-fonte.

Os links a seguir são os mais informativos que encontrei até agora:

• Sobre ter layout - o conceito de hasLayout no IE/Win
• /IE7/notas/

O primeiro cita um documento desatualizado que contém uma frase muito interessante:

Internamente, ter layout significa que um elemento é responsável por desenhar seu próprio conteúdo.

E o segundo diz:

O modelo de objeto dentro do Explorer parece ser um híbrido de modelo de documento e modelo de aplicativo tradicional.

Juntando os dois, meu palpite é que os elementos com hasLayout são na verdade janelas no sentido da API Win32 - ou seja, coisas CreateWindow lida com.Os elementos sem hasLayout então não têm sua própria "janela", mas são atraídos pelo mais próximo hasLayout-tendo ancestral, usando algum tipo de código de layout (algo como as classes de layout do Qt).Como apenas as verdadeiras "janelas" possuem o código de layout (que desenha seus descendentes sem layout), são elas que "possuem layout", então hasLayout.

Se for esse o caso, haveria dois caminhos de código diferentes para o código de layout (aquele para hasLayout, que teria que posicionar as "janelas" para que pudessem ser desenhadas posteriormente usando o sistema normal de desenho de janelas, e aquele que desenha os filhos do hasLayout "janela" à mão enquanto desenha a "janela").Como todo código tem bugs (e evidências anedóticas dizem que IE<=6 tem mais que a média), ambos os caminhos de código teriam diferente bugs, explicando por que adicionar ou remover hasLayout (mudar efetivamente para outro caminho de código) altera o conjunto de bugs que afetam o elemento em questão.Não só isso, mas como você tem dois caminhos de código trabalhando no mesmo documento, o iteração de ambos os caminhos de código seria outra fonte rica de bugs sutis.

Outros navegadores provavelmente evitaram o problema simplesmente usando uma arquitetura que não possui um caminho de layout duplo.

Se meu palpite estiver correto, eu diria que se você usasse uma ferramenta para mostrar todas as janelas secundárias que o navegador está usando, descobriria que todas as janelas visíveis hasLayout elemento tem um, enquanto os elementos sem layout não têm um.