[Precedente] - [Successivo] - [Pagina principale] - [Sommario rapido] - [Sommario completo] - [Proprietà]
Questo documento è la traduzione italiana di On Having Layout, che trovate su http://www.satzansatz.de/cssd/onhavinglayout.html.
Molte delle insufficienze di rendering di Internet Explorer possono essere risolte fornendo ad un elemento "layout". John Gallant ed Holly Bergevin hanno classificato queste insufficienze come "bug dimensionali", ossia che si possono risolvere applicando una width o height. Questo ci porta alla domanda sul perchè "layout" può cambiare il rendering e la relazione fra e degli elementi. Alla domanda, seppur buona, è difficile dare una risposta. In questo articolo gli autori si concentreranno su alcuni aspetti di questa complicata materia. Per ulteriori discussioni ed esempi, si faccia riferimento ai link forniti.
"Layout" è un concetto proprietario di IE per Windows che determina come gli elementi, in analogia ad una finestra, delineino e delimitino il loro contenuto, interagiscano e si rapportino con gli altri elementi, e reagiscano e trasmettano eventi utente-applicazione.
Gli sviluppatori della Microsoft hanno stabilito che gli elementi di tipo box debbano essere
in grado di acquisire una "proprietà (nel senso della programmazione orientata agli
oggetti) che essi indicano come layout, o in alternativa hasLayout.
hasLayout non è probabilmente nè una proprietà e neppure un
comportamento, ma piuttosto un concetto di rendering insito nel motore che da una qualità
ad un elemento.
Di fatto questa qualità di rendering può essere irreversibilmente inizializzata a
true da alcune proprietà dei CSS, ed alcuni elementi HTML hanno "layout"
di default.
Diciamo di un elemento che "ha layout" o che "ottiene layout", quando per quell'elemento
la proprietà proprietaria di Microsoft
hasLayout è settata a true.
Un "elemento layout" può essere qualunque elemento che ha layout di default o che ha ottenuto layout
con un'appropriata impostazione di una proprietà CSS.
Negli elementi "non-layout", hasLayout non è settato (o meglio è false),
per esempio un semplice div senza alcuna dimensione può essere un "contenitore non-layout".
Dare o applicare "layout" ad un elemento che non lo ha di default vuol dire impostare una proprietà
CSS che inizializzi hasLayout=true per l'elemento in questione.
Si veda Elementi aventi layout di default e Proprietà per
questa elencazione. Non c'è modo si settare hasLayout=false tranne che rimuovere la proprietà
CSS che ha causato hasLayout=true.
Il problema di hasLayout riguarda designers (e scrittori di codice) di ogni livello di esperienza.
Layout ha sia effetti insoliti e difficili da prevedere sul comportamento della visualizzazione di box che hanno
layout, sia implicazioni per gli elementi figli all'interno dei box.
Le conseguenze di un elemento che ha o non ha "layout" possono includere:
La lista di sopra è breve ed incompleta. Questo articolo cercherà di descrivere più nel dettaglio i problemi incontrati nell'applicazione di "layout" o dalla mancanza di questo.
Diversamente dalle proprietà standard, o anche dalla proprietà CSS disponibili nei vari browser, layout non è assegnato direttamente tramite dichiarazioni CSS. In altre parole, non vi è una "proprietà CSS layout". Alcuni elementi "hanno layout" automaticamente e per altri esso è semplicemente aggiunto quando si fanno varie dichiarazioni CSS.
I seguenti elementi hanno layout di default.
<html>, <body><table>, <tr>, <th>, <td><img><hr><input>, <select>, <textarea>, <button><iframe>, <embed>, <object>, <applet><marquee>Le seguenti coppie CSS valore-proprietà permetteranno ad un elemento, se applicate, di ottenere layout.
position: absolutefloat: left|rightdisplay: inline-blockwidth: qualunque valoreheight: qualunque valorezoom: qualunque valore
( MSDN)zoom: 1 può essere usato per il debugging.writing-mode: tb-rl
(
MSDN)In Internet Explorer 7, overflow è diventato un inizializzatore di layout.
overflow: hidden|scroll|autooverflow-x|y: hidden|scroll|autoE nuovi attori di hasLayout sono apparsi sullo schermo di Internet Explorer 7. Per quanto riguarda hasLayout, le proprietà min/max agiscono similmente a width ed height e gli effetti del posizionamento fisso ed assoluto sembrano identici.
position: fixedmin-width: qualunque valoremax-width: qualunque valore oltre a nonemin-height: qualunque valorehasLayout=true.max-height: qualunque valore oltre a noneBasato su query con la Developer Toolbar di Internet Explorer e su test preliminari.
Per gli elementi inline (sia inline di default come span, o che hanno display: inline)
width e height inizializzano hasLayout in IE5.x e IE6 solo in modalità
quirk. A partire da IE6, quando il browser è in modalità "standards-compliance" gli elementi
inline ignorano le proprietà width e height, e settare width e height non fa avere layout all'elemento.zoom inizializza sempre hasLayout, ma non è supportato in IE5.0.
Gli elementi che hanno sia "layout" che display: inline si comportano in modo simile
a quanto detto dagli standard sugli elementi inline-block: fluiscono orizzontalmente come parole in un paragrafo,
sono sensibili al vertical-align, e "si stringono" attorno al loro contenuto.
Non appena gli elementi inline hanno layout, si comportano come elementi inline-block, e questo spiega perchè,
in IE/Win, gli elementi inline possono contenere e controllare elementi block-level con meno problemi che negli altri
browser, dove display: inline rimane inline.
Abbiamo scelto di riferirici a hasLayout come ad una "proprietà di script" per
distinguerla dalle proprietà CSS a noi familiari.
Si noti che quando un elemento ha layout, non v'è modo di settare hasLayout=False.
La proprietà
hasLayout può essere usata per verificare se un elemento ha layout:
se ad esempio esso ha "eid" come id, allora semplicemente scrivere nella barra degli indirizzi di
IE5.5+ javascript:alert(eid.currentStyle.hasLayout) testa il suo stato.
La
IE Developer Toolbar consente di fare un'ispezione in tempo reale dello stile corrente di un elemento;
quando hasLayout è true il suo valore è riportato come "-1".
Editando in tempo reale gli attributi di un nodo, si può settare "zoom (css)" a "1"
per dare hasLayout a scopo di debugging.
Altra cosa da considerare è come "layout" condizioni lo scripting.
Le proprietà clientWidth/clientHeight restituiscono sempre zero per gli elementi senza "layout".
Questo può confondere i neofiti dello scripting ed è diverso da come si comportano i browser basati su Mozilla.
Possiamo usare questo fatto per determinare "layout" per IE5.0:
se clientWidth è zero allora l'elemento non ha layout.
I seguenti hack per inizializzare hasLayout sono stati testati con successo in IE6 ed inferiori.
Future versioni di IE potrebbero reagire differentemente.
Li riesamineremo quando saranno pubblicate nuove versioni di questo browser.
John Gallant e Holly Bergevin hanno pubblicato l'Holly Hack nel 2003.
/* \*/* html .gainlayout {height: 1%;}/* */overflow: hidden, tranne in IE6 in modalità standard
(dove height: 1% diventa height: auto, a meno che il genitore abbia un'altezza
specificata).Oppure possiamo usare l'underscore hack:
.gainlayout {_height: 0;}In alternativa, e forse più validi per il futuro, ci sono i commenti condizionali:
<!--[if lte IE 6]><style>.gainlayout {height: 1px;}</style><![endif]-->L'uso di un foglio di stile esterno per tutto ciò che soddisfa i bisogni di IE-Win, linkato all'interno di un commento condizionale, è una soluzione altrettanto sicura ed elegante:
<link rel="stylesheet" href="allbrowsers.css" type="text/css" />...<!--[if lte IE6]><link rel="stylesheet" href="iefix.css" type="text/css" /><![endif]-->
Preferiamo height: 0 e 1px - height dovrebbe "sempre" essere usata a meno che non vada
in conflitto con qualcos'altro (overflow: hidden). Per quel che riguarda il valore, preferiamo evitare 1%,
poichè può (seppur molto raramente)
causare problemi.
Un caso notevole, quando non possiamo usare height, è quando, in modalità standard, abbiamo un
elemento inline. Questo è un caso in cui useremmo display: inline-block, o zoom: 1.
Abbiamo visto disperati tentativi di "holy" hacks (sic!) applicati ad elementi flottanti, o ad elementi
che hanno già una larghezza. Si ricordi che l'obiettivo di questo hack non è quello di applicare
un'altezza ad un elemento, ma di inizializzare hasLayout = True.
Non date layout a tutti: * {height: 1px;}. Questa concentrazione è veleno, ed avere layout non è
una panacea, poichè cambia il rendering alla base.
I browser cambiano, e dobbiamo affrontare il problema che deriva dai bug che saranno risolti in IE7 e superiori:
inevitabilmente alcuni hack per IE6 potrebbero diventare dannosi nelle nuove versioni del browser, oppure
nuove versioni del browser con simili bug nel layout potrebbero non accettare più filtri come
* html. Sotto questo aspetto, l'uso del proprietario zoom può essere tenuto in
considerazione.
<!--[if lt IE 7]><style>/* style for IE 6 + IE5.5 + IE5.0 */.gainlayout {height: 0;}</style><![endif]-->...<!--[if IE 7]><style>.gainlayout {zoom: 1;}/* or whatever we might need tomorrow */</style><![endif]-->zoom: 1; dà layout ad ogni elemento in IE5.5+ (inclusi gli elementi inline), ma non ha effetti
in IE5.zoom deve essere nascosto con i commenti condizionali.Anche se pensiamo che "pronto per il futuro" sia una contraddizione in termini, raccomandiamo caldamente al web designer di "andare sul sicuro" e di rivedere le sue pagine per gli hack impliciti ed espliciti, usando i commenti condizionali per servire questi hack alla versione del browser appropriata.
IE Mac e IE Win sono due animali diversi, che vivono in parti separate dello zoo.
Ciascuno ha il suo proprio motore di rendering, e IE Mac non conosce affatto il comportamento di
"hasLayout" (o di contenteditable).
Il motore di rendering di IE Mac tende ad essere piuttosto conforme agli standard, ad esempio con
height trattata come height, come dovrebbe essere.
Gli hack e i workaround per i problemi di "hasLayout" (specie quando si usano le proprietà
height e width) avranno spesso effetti nocivi su IE Mac, e dovrebbero essere
nascosti a questo browser. Più informazioni sui problemi di IE Mac si possono trovare nella
pagina sulle stranezze e sui bug di IE Mac.
In MSDN vi sono davvero poche pagine legate alla proprietà Microsoft hasLayout, ed ancor meno è spiegato come tale proprietà sia correlata con il modello di formattazione visuale di IE.
Andando indietro fino ad IE4, quasi ogni elemento aveva una specie di layout, tranne semplici elementi
inline non posizionati assolutamente e senza alcuna dimensione
( MSDN ).
Ed in questa antica concezione di layout vi erano "proprietà di layout" come
border, margin, padding, che non potevano essere applicate ad un semplice
elemento inline. In altre parole, "avere layout" era solo un altro termine per esprimere rozzamente:
"possono avere queste proprietà".
MSDN parla ancora di "proprietà di layout", ma il significato è cambiato, non essendo più associate con elementi che hanno layout. In IE5.5, la proprietà Microsoft hasLayout fu introdotta più o meno come un flag interno.
In IE5.5, la documentazione della Editing Platform MSHTML (che consente l'editing in tempo reale, il ridimensionamento
ed il trascinamento di elementi di layout tramite <body contenteditable=true>) rivela tre importanti aspetti
legati all'avere layout:
Se un elemento con layout ha contenuti, il layout dei suoi contenuti è determinato dal rettangolo che lo delimita.
Avere layout significa essenzialmente che un elemento è rettangolare.
Internamente, avere layout significa che un elemento è responsabile della rappresentazione del suo contenuto.
Il funzionamento interno di IE correlato al layout stesso non era stato documentato fino all'agosto 2005 quando, come risultato della task force del Web Standards Project e di Microsoft, Markus Mielke [MSFT] aprì la porta ad una esauriente discussione:
In generale, gli elementi nel motore Dynamic HTML di Internet Explorer non sono responsabili della loro stessa sistemazione. Un elemento div o p possono avere una posizione all'interno dell'ordine del codice sorgente e del flusso del documento, ma i loro contenuti sono sistemati dal loro antenato più prossimo con layout (di frequente body). Questi elementi si relazionano al layout dell'antenato per determinare le informazioni di dimensione e di misurazione per loro.
La nostra interpretazione è un tentativo di spiegare ciò che accade nei casi conosciuti, e dovrebbe servire da guida per i casi non ben conosciuti. Il tentativo di decifrare una scatola nera inserendoci solo dei casi-test ed ascoltando se fa rumore è destinato al fallimento. Alla domanda "perchè" non si può rispondere. Dobbiamo cercare di comprendere la struttura in cui l'intero modello "hasLayout" opera, e come esso influenzi il rendering dei documenti web. Perciò si possono sviluppare delle linee guida (e queste possono essere solo delle linee guida, non soluzioni definitive).
Pensiamo che un elemento con layout sia come una piccola finestra. Il suo contenuto sarebbe completamente indipendente da ogni cosa al di fuori del confine dell'elemento, e il contenuto allo stesso modo non potrebbe influenzare nulla al di fuori.
La proprietà Microsoft hasLayout è una sorta di flag: quando è settata, l'elemento ha questa speciale "qualità" layout, la quale include capacità speciali sul floating, sul clearing, sullo stacking, sul counting e così via, sia per l'elemento stesso che per gli elementi figli che non hanno tale "qualità" layout.
Questa maggiore indipendenza degli elementi con layout è probabilmente la ragione per cui essi sono di solito più stabili, e quindi sono utili per risolvere alcuni bug. Il prezzo che si deve pagare può essere sia una minore aderenza agli standard, che ulteriori bug e problemi ai loro confini.
Estrapolando un pò, il modello di pagina web della Microsoft può essere visto come un'insieme di piccoli blocchi di storie scollegate tra di loro, mentre il modello W3C è piuttosto una narrazione continua, un insieme di blocchi collegati tra di loro.
I float sono auto-contenuti dagli elementi con layout. Questo è il motivo per cui molti principianti hanno difficoltà con le loro pagine costruite per Internet Explorer in un browser compliant, dove i float sporgono dal contenitore quando non viene applicato il clear.
Il comportamento opposto: cosa succede se un float deve sporgere dal suo contenitore, cioè quando l'auto-contenimento non è l'effetto desiderato? Per una dimostrazione dei problemi frustranti che si possono incontrare, controllate le nostre discussioni approfondite:
In IE, un float "apparterrà" sempre al suo contenitore con layout. Gli elementi successivi potrebbero rispettare il contenitore con layout, ma non il float stesso.
Questo, e l'espansione in IE6 di un contenitore per includere ogni contenuto più ampio (l' "estensione-per-includere"), possono essere visti come un aspetto della regola "determinato dal rettangolo che lo racchiude".
Anche peggio: clear non può influenzare un float al di fuori del contenitore
con layout che include il clear. I layout di pagina che utilizzano i float e si basano su questo bug
di IE non si possono trasferire per farli funzionare su un browser standard-compliant senza un generale
rifacimento.
Si veda la sezione "Similarità con le specifiche CSS" per ulteriori informazioni.
Quando un blocco segue un elemento che flotta a sinistra, il contenuto di testo dovrebbe scorrere a destra
del float e poi scivolare sotto il float.
Ma se il blocco ha layout, ad esempio perchè è impostata una larghezza per qualche motivo,
l'elemento con layout si comporta come un rettangolo ed il testo non scivola sotto il float.
La larghezza è erroneamente calcolata partendo dalla destra del float, sicchè
width: 100% si va ad aggiungere alla larghezza del float, ed il risultato è una barra
di scorrimento orizzontale. Questo è ben lontano dalle specifiche.
Similmente gli elementi posizionati relativamente vicini ai float dovrebbero scostarsi rispetto al limite
del padding del genitore (ad esempio left: 0 in un elemento posizionato relativamente lo
posizionerebbe sopra un box flottato che lo precede).
In IE lo scostamento left: valore inizia dal limite del margine destro del float, causando un
disallineamento orizzontale della complessiva ampiezza esterna del float (una soluzione è usare
margin-left, ma bisogna stare attenti ai problemi nel calcolo delle percentuali).
Secondo le specifiche, i float si intrecciano con i box che seguono. Ciò non si adatta con rettangoli bidimensionali che non si intersecano.
(Ri)visitando questa pagina sul bug:
vedremo che il box con layout che segue il float non mostrerà il 3px jog del testo, perchè i 3px che circondano il float non possono più influenzare il contenuto dentro l'elemento con layout, ma spostano l'intero documento di 3px. Come un guscio, layout impedisce al contenuto di essere influenzato, ma l'energia della spinta del float sposta il box stesso racchiuso nel guscio.
Si veda la sezione "Similarità con le specifiche CSS" per ulteriori informazioni.
Le liste sono influenzate da layout applicato sia alla lista (ol, ul) che agli
elementi di lista (li). Differenti versioni di IE reagiscono in modo diverso.
Gli effetti più evidenti sono sui marcatori di lista (liste completamente personalizzate dove i marcatori
non sono richiesti non avranno questi problemi).
I marcatori sono creati probabilmente dall'interno aggiungendo alcuni elementi che sono in qualche modo
"agganciati" agli elementi di lista (solitamente sporgono al di fuori di essi)
e sembrano piuttosto instabili.
Sfortunatamente, essendo solo oggetti "interni", non possono essere raggiunti per cercare di correggere
i comportamenti errati.
Gli effetti più evidenti sono:
A volte essi possono essere ripristinati cambiando i margini sugli elementi di lista. Ciò appare come una conseguenza del fatto che un elemento con layout tende a tagliare gli elementi interni sporgenti al suo esterno.
Un ulteriore problema è che (nelle liste ordinate) ogni elemento di lista con layout sembra avere un suo proprio contatore. Poniamo di avere una lista ordinata con cinque elementi dove solo il terzo ha layout. Vedremo questo:
1... 2... 1... 4... 5...
Inoltre quando un elemento di lista con layout si dispone su linee multiple, il marcatore è allineato verticalmente alla parte inferiore (non a quella superiore, come ci si aspetterebbe).
Alcuni di questi problemi non possono essere risolti, sicchè quando si vogliono avere i marcatori è megli evitare layout sulle liste e sugli elementi di lista. Se è necessario applicare delle dimensioni, è meglio applicarle ad altri elementi: per esempio l'ampiezza può essere applicata ad un contenitore esterno, e l'altezza al contenuto di ogni voce di lista.
Un altro problema comune con le liste in IE accade quando il contenuto di ogni li è
un'ancora con display: block. In queste condizioni lo spazio bianco fra le voci di lista
non è ignorato, e di solito è mostrato come una linea extra per ogni li.
Uno dei metodi per evitare questo spazio verticale extra è dare layout alle ancore di tipo blocco.
Questo sistema ha anche il beneficio di rendere cliccabile l'intera area rettangolare delle ancore.
Una table ha sempre layout, e si comporta sempre come un oggetto di larghezza definita.
In IE6,
table-layout: fixed di solito equivale ad una tabella di ampiezza pari al 100%,
con tutti i problemi che ciò comporta (computazioni erronee).
Come nota aggiuntiva, solo poche cose sulla
situazione in IE5.5 e il "quirks mode" in IE6.
Si noti che position: relative non inizializza hasLayout, che porta ad alcuni errori di rendering,
per lo più facendo scomparire o posizionando male il contenuto.
Queste insufficienze si possono incontrare ricaricando la pagina, ridimensionando la finestra,
facendo scrolling o selezionando.
Con questa proprietà, IE scosta l'elemento, ma sembra dimenticarsi di inviare un segnale di
"ridisegnamento" agli elementi suoi figli aventi layout
(un elemento con layout l'avrebbe inviato correttamente nella successione di segnali di ridisegnamento).
sono descrizioni correlate. Come regola pratica, non posizionate mai un elemento relativamente senza settare layout.
In aggiunta, si deve controllare se il genitore di un tale costrutto necessita di layout e/o anche di
position: relative. Questo diventa essenziale quando vengono coinvolti i float.
È essenziale comprendere il concetto CSS di blocco contenitore, che risponde alla domanda su dove si debba relazionare un elemento posizionato in modo assoluto, sia per definire l'origine dello scostamento che per stabilire rispetto a cosa si calcolino le percentuali delle misure.
Per gli elementi posizionati in modo assoluto, il blocco contenitore è stabilito dall'antenato
posizionato più vicino.
Se non vi è tale antenato, viene usato il blocco contenitore iniziale html.
Normalmente imposteremmo tale blocco contenitore tramite position: relative.
Il che vuol dire che possiamo far relazionare gli elementi posizionati in modo assoluto
a misure e origini indipendenti dal flusso degli elementi, sia per soddisfare i bisogni
del concetto di accessibilità che recita "prima il contenuto",
che per semplificarci la vita nei layout complessi basati sui float.
Questo concetto di design è messo in discussione da IE, a causa del concomitante
concetto di layout: l'elemento posizionato in modo assoluto è scostato rispetto
al suo più vicino antenato posizionato e con layout, ma una dimensione
in percentuale si relaziona al più vicino antenato.
Si noti la netta differenza, e come detto poc'anzi position: relative non
inizializza hasLayout.
Posto che un genitore non-layout sia posizionato relativamente, siamo costretti ad impostare layout per questo genitore per far funzionare lo scostamento:
Posto che un genitore non posizionato debba avere una dimensione, e che il design faccia affidamento sul calcolo di una larghezza espressa in percentuale, possiamo abbandonare tale idea, per una carenza di supporto nel browser:
La Microsoft-proprietaria filter è applicabile solo ad elementi di layout. Alcuni ampliano i confini di un oggetto. Mostrano i loro errori specifici: http://www.satzansatz.de/cssd/tmp/alphatransparency.html.
Una volta che tutti gli elementi di una pagina sono renderizzati, se avviene una transizione
a:hover (per esempio un cambio di background di un link)
IE risistema l'intero blocco contenitore avente layout.
A volte gli elementi vengono posizionati in una nuova posizione, poichè al momento in cui
si incorre nell'hover IE conosce tutte le ampiezze e gli scostamenti degli elementi correlati.
Di solito questo non accade al primo caricamento della pagina, quando l'ampiezza non è ancora
determinata a causa della caratteristica estensione-per-includere.
Ne può conseguire un salto sull'hover:
Questi bug relazionali, basati sul problema della risistemazione, creano problemi nei layout liquidi, dove è più comune l'uso di percentuali per margini e padding.
La proprietà Microsoft hasLayout influenza l'estensione ed il posizionamento del background.
Ad esempio, secondo le
specifiche CSS,
background-position: 0 0 dovrebbe riferirsi all' "estremità del padding"
dell'elemento. In IE/Win si riferisce all' "estremità del bordo" quando
hasLayout = false, e all' "estremità del padding" quando
hasLayout= true:
La proprietà Microsoft hasLayout influenza il collassamento dei margini fra un box ed i
suoi discendenti. Secondo le specifiche, il margine superiore di un box senza padding superiore e senza
bordo superiore collassa con il margine superiore del suo primo figlio di tipo blocco nel flusso:
In IE/Win questo non accade mai quando il box ha layout: sembra che layout impedisca ai margini del figlio di
sporgere fuori dal box contenitore. Inoltre quando hasLayout è true, sia sul contenitore
che sul figlio, si evidenziano altre computazioni errate dei margini:
hasLayout influenza l'area cliccabile e di hover di un'ancora di tipo blocco.
Di solito con hasLayout = false solo la parte coperta dal testo è sensibile.
Con hasLayout = true l'intera area del blocco è sensibile.
La stessa condizione è vera per ogni elemento di tipo blocco con annesso handler di un evento
onclick/onmouseover.
Quando si usa il tasto TAB in una pagina e si seleziona un link nella pagina, la successiva pressione del tasto TAB non riprenderà sul link successivo:
Il tasto TAB porterà (spesso in modo errato) l'utente al primo target del più vicino antenato
con layout (se l'antenato con layout è uno tra table, div, span e
certi altri elementi).
Alcune proprietà applicate ad elementi con width: auto li spinge a computare la loro
ampiezza con un algoritmo che rimpicciolisce l'elemento stesso fino a stringersi attorno al suo contenuto.
Esempi di tali proprietà sono:
float: left|rightposition: absolute|fixeddisplay: table|table-cell|inline-block|inline-tableQuesto funziona in IE/Win, naturalmente limitato alla proprietà supportate. Ma quando l'elemento che dovrebbe restringersi contiene un blocco con "layout", allora nella maggior parte dei casi tale figlio si espande per l'intera ampiezza disponibile, indipendentemente dal suo conteuto, e previene l'effetto di rimpicciolimento del genitore.
a {display: block; zoom: 1;} si è reso necessario per risolvere il bug dello spazio
bianco nella lista e per espandere l'area cliccabile.Il rimpicciolimento del contenitore resta attivo solo se il figlio con layout ha una larghezza assegnata, o ha una proprietà di restringimento esso stesso, come ad esempio float.
In generale, quando un box contiene più strutture complesse come contenuto sporgente, "hasLayout" su questo contenitore è spesso necessario per evitare problemi di rendering. Questo quasi-requisito causa un dilemma nelle zone di confine, poichè un elemento che ottiene "layout" diviene una sorta di box chiuso in sè stesso.
Box interni che vengono mossi al di fuori di tale elemento (usando ad esempio margini negativi) vengono "ritagliati".
Le porzioni ritagliate possono essere ripristinate inizializzando "hasLayout" sui box interni
e si richiede anche position: relative in IE6.
Il comportamento di IE7 sembra lievemente migliorato, in quanto position: relative non è
più necessaria.
Sembrano esservi due ordini di layering e di stacking all'interno di IE/Win:
Entrambi i modelli di stacking, sebbene incompatibili, sono residenti nel motore di IE. Regola pratica: quando si fa il debug, non dimenticarsi di vagliare entrambi i sospetti. Vediamo di frequente problemi correlati nei menu drop-down o in altri di simile complessità, dove lo stacking, il posizionamento ed il float possono portare a svariati disastri, e le soluzioni ai bug possono includere il dare layout ad elementi posizionati con z-index (ma variano, così siete avvisati).
L'attributo contenteditable=true, impostato su un tag HTML come body consente l'editazione
in tempo reale, il trascinamento ed il ridimensionamento dell'elemento e dei suoi figli con layout.
Ora si provi ciò con i float o l'elemento di layout li in una lista ordinata.
Al fine di manipolare gli elementi (editarli) "contenteditable" e "hasLayout" introducono un ordine di stacking separato per gli elementi con layout.
La Editing Platform eredita il concetto di layout, a riprova del fatto che la contenteditable è la causa dell'errata interpretazione del layout (con l'implicazione che le applicazioni che in qualche modo integrano il motore di editing di IE forzano una compatibilità a ritroso verso questo concetto di layout).
Le vostre pagine concepite per IE falliscono negli altri browser? Non c'è alcun motivo di farlo accadere, sappiatelo. Qualunque buon browser può gestire bene i design per IE, se lo chiedete gentilmente - e gli fornite dei validi CSS.
Utilizzare le deboli similarità che si trovano fra hasLayout e la creazione di un
nuovo contesto di formattazione dei blocchi ci da
degli strumenti per riprodurre gli effetti di hasLayout per il
contenimento dei float e per il comportamento degli
elementi vicini ad un elemento flottante nei browser
standard compliant.
Si faccia riferimento al nostro capitolo sulla modalità quirk per le informazioni su questa modalità di rendering.
Il concetto di layout nella sua interezza non è compatibile con un numero di concetti base dei CSS sul modello di formattazione visuale, ovvero il contenimento, il flusso, il floating, il posizionamento ed il layering.
Questo porta a specifiche violazioni da parte di IE/Win delle specifiche CSS a causa della presenza o dell'assenza di layout negli elementi della pagina.
Il modello ad oggetti all'interno di Explorer appare come un ibrido di un modello di documento e del loro modello di applicazione tradizionale. Cito questo perchè è un importante aspetto per capire come Explorer rende a video le pagine. Il procedimento per passare da un modello di documento ad un modello di applicazione consiste nel dare ad un elemento "layout".
A volte non è possibile dare un'intepretazione ad un comportamento: dipende semplicemente da quale motore fra i due venga usato, in funzione dello stato di hasLayout, ciascuno con i suoi bug e le sue modalità quirk.
I bug nel software sono il risultato di errori umani e della mancanza di completezza e di logica durante il processo di creazione. È una basilare manchevolezza umana, per la quale una cura definitiva deve essere ancora trovata. Ogni tentativo di correggere software con bug senza ricrearli da zero, porterà inevitabilmente a scoprire bug sempre più complessi nel software, a causa delle stesse manchevolezze umane. Ogni software che si relaziona ad un altro software, fra cui naturalmente i sistemi operativi, si relazionerà con i suoi bug. Così otteniamo una cascata di bug da ogni singolo bit coinvolto del software, che rende anche il solo pensiero di trovare del software senza bug completamente assurdo.
[Precedente] - [Successivo] - [Pagina principale] - [Sommario rapido] - [Sommario completo] - [Proprietà]