Perché Internet Explorer ha bisogno il flag “hasLayout”?

Question

Come molti sviluppatori che lavorano su siti web per Internet Explorer, mi sembra di imbattersi in un sacco di bug che sono causati dal famigerato hasLayout bandiera .

capisco che cosa questo flag fa e come funziona (per la maggior parte). Una buona spiegazione che ho letto l'altro giorno (anche se non riesco a trovare la fonte) è che hasLayout in IE significa essenzialmente "Fate questo elemento di un rettangolo."

E 'ovviamente più complicato di così, ma è abbastanza ben riassunto con quella (a mio parere).

Quello che non capisco è il motivo per cui il browser utilizza questo flag. Quando alla ricerca di una risposta, ho trovato uno che sembrava logico:

  

Internet Explorer ha dovuto affrontare molto vecchio codice legacy da prima CSS è stato davvero in pieno svolgimento. Come una decisione di architettura per rendere il browser facile aggiungere CSS su di esso, la bandiera hasLayout è stato utilizzato per innescare alcune proprietà CSS in modo che la pagina sarebbe resa correttamente. Questo risale intorno al periodo della IE4.

Questo senso quasi fatta per me, fino a quando mi sono reso conto che Firefox (Netscape al momento) ha dovuto affrontare lo stesso problema. Netscape è stato intorno per quasi tutto il tempo di Internet Explorer, ma non ha bisogno di alcuna bandiera hasLayout interno, o qualcosa di simile, per quanto ne so.

Visto che la bandiera hasLayout è la fonte di tanti bug in Internet Explorer, qualcuno sa perché IE ha questo flag e altri browser non ne hai bisogno?

Questo è qualcosa che mi piacerebbe sapere per pura curiosità se qualcuno ha qualche teoria o capita di conoscere la risposta. Mi piacerebbe capire di più sul perché (o perché no) questo flag è utile.

Answer 1

Il renderer Netscape è stata completamente riscritta post-NS4. motore di rendering "Trident" di IE non ha ottenuto un tale amore. Questo rel="noreferrer"> - IE ha continuato a migliorare in modo incrementale mentre NS veniva riscritta, e in parte a causa di questo (e in parte a causa del suo accordo di distribuzione ...) è riuscito a catturare una quota enorme del mercato ...

Ma il risultato finale è un vecchio, codebase crufty che rende la vita un inferno per gli sviluppatori, che devono di conseguenza essere dolorosamente consapevoli di ciò che dovrebbe essere nascosti i dettagli di implementazione.

Ora, quest'ultimo punto è fondamentale: rendering di un browser è un'astrazione, che consente di creare in poche righe di markup qualcosa che richiederebbe centinaia o migliaia di righe di resa a basso livello e il codice di gestione degli eventi. E come tutte le astrazioni di programmazione, si perde un po '... Questo è vero per IE, Netscape, Firefox, Opera, Webkit ... E ogni browser ha sviluppatori che lavorano febbrilmente per tappare le perdite nelle astrazioni. Tranne che, per cinque anni, IE non ha fatto. Altro di perdite sono stati tappati, ma il motore di rendering è diventato sempre più setaccio-like.

Insieme, questi fattori cospirano per esporre le cose come hasLayout.

Answer 2

E 'molto difficile sapere senza essere in grado di guardare il loro codice sorgente.

I seguenti link sono il più informativo che ho trovato finora:

• On avere layout - il concetto di hasLayout in IE / Win
• / IE7 / note /

La prima cita un documento obsoleto che contiene una frase molto interessante:

  

Internamente, avere layout significa che un elemento è responsabile dell'elaborazione del suo contenuto.

E il secondo dice:

  

Il modello a oggetti all'interno Explorer sembra essere un ibrido di un modello di documento e il loro modello di applicazione tradizionale.

Mettere entrambi insieme, la mia ipotesi è che gli elementi con hasLayout sono finestre infatti nel senso API Win32 - cioè, le cose CreateWindow offerte con. Gli elementi senza hasLayout quindi non hanno una propria "finestra", ma sono attratti da loro antenato hasLayout-avere più vicino, utilizzando una sorta di codice del layout (un po 'come le classi di layout di Qt). Dal momento che solo i veri "finestre" hanno il codice del layout (che richiama le loro descentants di layout-less), sono quelli che "hanno layout", così hasLayout.

Se questo è il caso, ci sarebbero due diversi percorsi di codice Codice del layout (quello per hasLayout, che avrebbe dovuto posizionare le "finestre" in modo che possano essere disegnati in seguito utilizzando il normale sistema di disegno finestra, e quella che disegna i figli della "finestra" hasLayout a mano mentre si disegna la "finestra"). Dal momento che tutto il codice ha bug (e le prove anedoctal dice IE <= 6 ha più rispetto alla media), entrambi i percorsi di codice avrebbero diverso bug, spiegando il motivo per cui l'aggiunta o la rimozione di hasLayout (in modo efficace il passaggio verso l'altro percorso di codice ) cambia il set di bug che interessano l'elemento in questione. Non solo, ma dal momento che si dispone di due percorsi di codice che lavorano nello stesso documento, il iterazione di entrambi i percorsi di codice sarebbe un altro ricca fonte di bug sottili.

Altri browser probabilmente evitato il problema semplicemente utilizzando un'architettura che non ha un tale percorso a doppio layout.

Se la mia ipotesi è corretta, vorrei dire che se è stato utilizzato uno strumento per mostrare tutte le finestre figlio il browser utilizza, si potrebbe scoprire che ogni elemento hasLayout visibile ha uno, mentre gli elementi di layout-meno non hanno uno.