CSS Hack ed IE7

Sommario

Legenda

Di seguito sono riportate le spiegazioni di tutte le abbreviazioni e gli acronimi presenti nel testo.

[Torna al sommario]

Annuncio speciale - 21 dicembre 2005

Nuove informazioni sulla gestione di Microsoft dello star-html hack sono apparse sul loro blog, ed è cambiato l'aspetto di ciò che compare nel vecchio articolo. Così abbiamo scritto un nuovo articolo in cui viene discussa in dettaglio la situazione, con l'aggiunta di un sondaggio.

Recentemente il blog di Microsoft ha annunciato alcuni cambiamenti che possiamo aspettarci dalla versione 7 di Internet Explorer, forse per l'inizio del 2006. È davvero una cosa positiva avere questa notizia in anteprima, poichè sembra che Microsoft stia facendo buon viso a cattivo gioco, dando una sistemata a parecchi effetti dei selettori che gli sviluppatori usano per passare speciali regole ad IE.

Nello specifico un buon numero di CSS hack, che si riferiscono al mancato supporto di IE Win per alcuni selettori avanzati, falliranno, poichè IE7 introdurrà il supporto per questi selettori. A lungo andare questa si rivela un'ottima cosa per noi che usiamo i CSS, poichè ci darà molto più controllo su quello che fanno i CSS. Sfortunatamente significherà nell'immediato dover riscrivere i fogli di stile, e fornire regole alternative per l'hacking di IE Win.

[Torna al sommario]

Ci dovremmo preoccupare?

Qualcuno dirà che quelli che usano gli hack hanno quello che si meritano, e c'è del giusto in questa opinione. Gli hack sono qualcosa che il mondo farebbe meglio a non avere, ma si tenga presente che la maggior parte dei browser non è stata concepita per gestire design complessi con i CSS senza l'abilità di indurre layout. Venendo a mancare l' Holly hack saremmo fortemente limitati nella scelta dei design, e le tabelle rimarrebbero il termine di scelta.

Tuttavia, a parte l'Holly hack, è possibile lavorare interamente o quasi senza hack usando dei semplici workaround. Quando delineiamo il design dei nostri siti, cerchiamo di rendere il codice CSS il più pulito possibile, e usiamo gli hack solo per IE Win. A volte IE Mac avrà bisogno anche lui di un pò d'aiuto, ma un sano e pulito "comment hack" tramite CSS esiste anche per questa eventualità. Gli altri browser moderni seguono standard più alti, e se hanno dei problemi che non si possono aggirare, alziamo le spalle e presupponiamo che alla fine il problema sarà risolto. Solo quando il problema è di quelli che distrugge il layout giungeremo a ridisegnare la pagina.

Come abbiamo detto, questa è la nostra filosofia di design, e voi avete il diritto di farla vostra. Comunque sia, andiamo dritti al cuore del problema, e nello specifico ai cambiamenti che possiamo aspettarci da IE7 e ai nuovi modi di gestire vecchi problemi.

[Torna al sommario]

In e Out

Diamo un'occhiata a quelli che, come abbiamo detto, saranno i cambiamenti rilevanti in IE7. Ci sono due "combinatori" CSS che saranno supportati, ed un elemento strutturale che sarà eliminato. Vediamo prima i due combinatori CSS:

Il selettore figlio

Questo selettore usa un simbolo ">" come un "combinatore" che viene posto fra le due parti di un selettore CSS, ed indica che il target della regola è l'elemento alla destra del combinatore ">", ma solo quando questo elemento è il figlio diretto dell'elemento a sinistra del combinatore. Così il selettore table>td non può mai puntare ad alcun elemento, poichè gli elementi td non sono mai figli diretti delle tabelle, ma solo di quelli tr. D'altro canto, il selettore tr>td selezionerà ogni td sulla pagina, poichè tutti gli elementi td sono figli diretti degli elementi tr.

La principale differenza fra il combinatore figlio ed il comune combinatore spazio è che il combinatore spazio è un combinatore "discendente", il che vuol dire che l'elemento alla destra dello spazio ha bisogno solo di essere fra i tag dell'elemento a sinistra per essere selezionato. Così con il selettore table td tutti gli elementi td saranno selezionati, poichè td cade sempre fra la coppia di tag di una tabella o l'altra.

Il combinatore figlio è abbastanza utile per indirizzare regole ai diretti figli di un elemento, senza indirizzare anche i discendenti innestati più profondamente. Sfortunatamente, fino a IE7 non vi era motivo di usarlo per il suo scopo predefinito, poichè pochi layoutr avrebbero beneficiato di questa applicazione di stile.

Tuttavia aveva una funzione utile nella scrittura di regole che IE Win avrebbe sicuramente ignorato, come html>body .targetelement. Funziona perchè il body è sempre un diretto figlio di html, rendendo vera ogni volta questa parte del selettore. Poi il combinatore spazio davanti a .targetelement (o a qualunque altro elemento selezionato) permette agli stili di essere applicati ovunque all'interno dell'elemento body.

IE Win ignora semplicemente l'intera regola, perchè non può riconoscere questo combinatore figlio. Ora che questo supporto è in arrivo, IE7 sarà in grado di vedere questo CSS hack. Ma poichè questo browser avrà ancora delle lacune, fargli dare un'occhiata a questi hack potrebbe essere a dir poco meno che desiderabile.

[Torna al sommario]

Il selettore fratello adiacente

Questo selettore è un simbolo combinatore "+" posizionato fra le parti di un selettore, ed è molto simile al combinatore figlio. L'unica differenza fra i due è che mentre il combinatore figlio punta ai figli diretti di un elemento, il combinatore fratello adiacente punta ad un elemento che segue direttamente un altro elemento nel codice sorgente.

Così il selettore tr+td non può selezionare nulla, perchè nessun elemento td segue mai direttamente un elemento tr. Invece gli elementi td sono contenuti dentro quelli tr, e questo non è considerato come il "successivo" di tr. Tuttavia il selettore tr+tr selezionerà ogni elemento tr che viene seguito direttamente da un altro tr, il che vuol dire che ogni elemento tr all'interno di una tabella sarà selezionato tranne che per il primo tr in tale tabella.

Ci siete? Un elemento fratello adiacente non solo segue il suo fratello precedente, ma lo separa anche completamente da quest'ultimo. Inoltre se due div sono in sequenza e ciascuno contiene un paragrafo, questi due paragrafi non sono considerati fratelli, perchè risiedono in differenti elementi genitori. Il fatto che uno segua l'altro non significa nulla, a meno che il successivo fratello inizi nello stesso punto dove finisce il fratello precedente.

È possibile puntare ad un selettore fratello in ciascun punto di una sequenza di elementi adiacenti, semplicemente ripetendo l'uso del combinatore, cosicchè il selettore td+td+td selezionerà tutti gli elementi td che vengono direttamente dopo i due precedenti td. Ciò significa anche che il terzo, quarto, quinto ed ogni td rimanente in una riga di tabella riceverà gli stili allegati a tale selettore, poichè hanno tutti due td direttamente prima di loro in una riga di tabella.

I primi due td nella successiva riga di tabella non saranno selezionati, perchè sono racchiusi in un tr differente. Ma naturalmente dopo ogni td rimanente in quella riga sarà selezionato, proprio come nella precedente riga di tabella.

Ancora una volta il combinatore fratello adiacente sarà disponibile in futuro, ma ora ci sono in giro CSS hack che lo utilizzano parecchio, come il combinatore figlio. Non va bene.

Chiaramente dobbiamo cominciare ad eliminare questi hack dai nostri file CSS prima che i nostri clienti comincino a fare il diavolo a quattro, non dopo.

[Torna al sommario]

Ma... non erano tre?

Oh, volete sapere della cosa strutturale? Bè, l'hack che lo usa è chiamato star-html hack, e funziona sfruttando una stranezza di Explorer nel trattamento del Document Object Model (o DOM, in breve). Per farla semplice, tutte le pagine web iniziano con un elemento radice chiamato html, che contiene quindi due figli, gli elementi head e body. Questi a loro volta contengono altri elementi e così via.

La maggior parte dei browser obbedisce a questa disposizione, ma Explorer, sia per Win che per Mac, non lo fa. Sembrano entrambi pensare che vi sia un misterioso elemento che racchiude l'elemento html! È abbastanza strano, ma di fatto questo elemento "radice" extra non ha apparenti effetti negativi sulle pagine, ed è rimasto dimenticato per anni, finchè Edwardson Tan cominciò a fare esperimenti con i selettori CSS. Scoprì che un selettore scritto come * html .targetelement applicherà gli stili a .targetelement, ma solo per i browser Internet Explorer.

Pensateci: questa stella è il selettore "universale", così punta ad ogni elemento, ma viene prima di html. Perciò il selettore completo in effetti dice: "Seleziona .targetelement quando è contenuto dentro html, e quando html è contenuto dentro ogni altro elemento".

Ovviamente poichè html è l'elemento radice nella pagina, non può essere contenuto da ogni altro elemento, ma questo è esattamente ciò che pensa IE! Non conosciamo il nome di questo elemento, ma il selettore stella di questo hack non ha importanza, finchè c'è un tale elemento che circonda html.

Come potete immaginare, questo hack si è dimostrato abbastanza utile, in particolare quando è inserito in un hack differente che nasconde lo star-html hack da IE Mac. Facendo questo, voi create un hack combinatorio che fornisce regole direttamente a IE Win, e a nessun altro browser. Un tale combo-hack è perfetto per gestire i problemi del box model e tutto quello che solo IE Win ha bisogno di vedere, in particolare l'Holly hack.

Purtroppo Microsoft si è adoperato per risolvere questo strano elemento "radice" in IE7, lasciando html come corretto elemento radice. Questo è davvero aderente agli standard, ma presenta un problema. Supportando questi nuovi combinatori, ogni pagina che usa questo hack comincerà a disintegrarsi in IE7, ma stavolta perchè IE7 non sarà in grado di leggere queste speciali regole di cui si è servito così malamente.

[Torna al sommario]

Alla disperata ricerca di soluzioni

Fortunatamente per noi, Microsoft ha ritenuto opportuno sviluppare una caratteristica di IE chiamata commenti condizionali (anche per IE5 Win). I commenti condizionali permettono agli sviluppatori di scrivere un commento HTML in modo da "avvisare" IE Win, facendo in modo che vada a sbirciare il commento condizionale ed interpreti quello che vi trova. Gli altri browser non hanno questa caratteristica, e così vedono solo un normale commento, ignorando lui ed il suo contenuto.

Vedete dove vogliamo arrivare con questo? Questi CSS hack nei nostri fogli di stile (utili ma ora imbarazzanti) possono essere rimossi ed inseriti in un file CSS separato. Poi questo nuovo file CSS con gli hack per IE Win può essere richiamato nella pagina con link nell'head che è stato nascosto all'interno di un commento condizionale. Tutti gli altri browser (anche IE Mac) vedranno un normale commento e passeranno al codice successivo. IE Win invece leggerà il commento condizionale, vedrà link, richiamerà lo speciale file CSS con gli hack e aggiungerà queste regole alla cascata come qualunque altro foglio di stile. Bello! Ecco come si presenterebbe:

  <!--[if IE]>
  <link rel="stylesheet" type="text/css" href="iehacks.css" />
  <![endif]-->

Ok, non è comodo come il seducente star-html hack, ma a differenza di questo hack i commenti condizionali non scompariranno mai. Inoltre i commenti condizionali vantano la sicurezza e l'affidabilità della solida roccia. Neppure il validatore del W3C riconoscerà nei commenti condizionali ninet'altro che un normale commento, sicchè la pagina sarà correttamente validata, anche se il vostro file CSS è pieno zeppo di regole proprietarie Microsoft non valide.

Ovviamente ci rendiamo tutti conto che questo file CSS abilitato con i commenti condizionali è fatto per regole che faranno comportare IE Win il più possibile vicino alle specifiche, giusto? E allora? Volete davvero usare tutti quei fichissimi stili proprietari Microsoft per la barra di scorrimento, no? Bè, se dovete, almeno questo metodo separerà queste regole sgradevoli dal sano e pulito CSS del foglio di stile principale. In questo modo la validazione è assicurata.

Dalla lettura dei commenti del blog Mezzobue vediamo che se si usa XSLT, le parentesi quadre contenute all'interno dei commenti condizionali possono creare problemi. Fortunatamente anche Nick Fitzsimons ha visto questi commenti ed ha descritto un modo per generare i commenti condizionali attraverso XSLT. Grazie Nick!

Comunque sia, scendiamo nei dettagli su come ripulire una tipica pagina web infestata dagli hack. A proposito: ci sono un sacco di pagine così qui su Position Is Everything! Oh bè...

[Torna al sommario]

Legittimare

Piuttosto che imbarazzare qualcuno esponendo i suoi hack al pubblico ludibrio, abbiamo intenzione di lavorare su quelli delle nostre pagine, ma sembra che nessuna pagina contenga alcun hack eccetto lo star-html hack. Così mostreremo invece come eliminare gli hack che si possono trovare in altre pagine del mondo reale.

Tutta la discusssione a seguire presuppone che IE Win sia in modalità "standard", attraverso un corretto doctype. Se si permette ad IE Win di cadere in modalità "quirk" con un vecchio, scorretto o mancante doctype, i giochi sono chiusi, e i comportamenti osservati possono apparire radicalmente differenti. Microsoft afferma che lo sviluppo futuro di IE Win dipenderà dal suo essere in modalità standard, e la modalità quirk sarà lasciata per quei siti che devono gestire molto codice che altrimenti distruggerebbe il layout se impostato secondo gli standard.

[Torna al sommario]

L'hack di Tantek

  #wrapper {
   border: 10px solid black;
   width: 770px; /* questo vede IE5.x Win */
   voice-family: "\"}\"";
   voice-family: inherit;
   width: 750px; /* ma non questo valore standard di width */
  }
  
  html>body #wrapper {
   width: 750px; /* rinforzo per la width standard */
  }

Questo è il celebre Tantek hack e fornisce un'ampiezza speciale alle versioni di IE Win precedenti la 6 per combattere il problema del box model, e da anche ad Opera 5 una seconda regola usando il selettore figlio, perchè questo browser veniva ingannato anch'esso dal primo hack di Tantek come IE Win. Tutto questo caos è stato rimpiazzato dal più semplice star-html hack, ma molte pagine web hanno ancora l'hack di Tantek. L'obiettivo specifico dell'hack d'esempio è creare un box contenitore che sia largo 770px quando i 10px di bordo vengono aggiunti alla larghezza dichiarata di 750px.

Tecnicamente non c'è bisogno di eliminare questo hack, perchè l'hack funziona principalmente con l'uso di caratteri di escape per nascondere alcuni caratteri critici alle vecchie versioni di IE. IE6, IE7 e tutti gli altri moderni browser non sono ingannati da questi escape legali, così nulla può andare storto facendo vedere l'hack a IE7. Neanche l'ultima parte è pericolosa, perchè l'hack col selettore figlio da solo l'ampiezza standard, che IE6 e IE7 acquisiscono già dalla prima parte dell'hack. Se IE7 leggesse all'improvviso l'hack col selettore figlio, acquisirebbe comunque il valore corretto.

Ancora: finchè rimuoviamo hack pericolosi, rimuoviamo anche questo. Naturalmente le regole sui bordi e tutte le altre regole CSS ordinarie sono lasciate all'interno del file CSS primario, insieme con l'ampiezza standard di 750px. Ricordate che il nostro file hacks.css, abilitato con i commenti condizionali, verrà visto solo da IE5.x Win e superiori, sicchè non c'è bisogno di nascondere il file da IE Mac.

Una volta tolto, l'hack di sopra viene rimpiazzato nel file iehacks.css con questo codice:

 iehacks.css
 
 #wrapper {
   width: 770px;
   wid\th: 750px;
 }

Vedete questo escape in rosso all'interno del nome della seconda proprietà? È un carattere legale e dovrebbe essere ingorato, ma quando si trova all'interno del nome della proprietà non è ignorato da IE5 e IE5.5 per Windows. Invece fa in modo che questi browser ignorino il successivo carattere "t" in questo caso, rendendo così illeggibile per loro il nome della proprietà. Il risultato è che tutte le versioni di IE Win ricevono l'ampiezza più larga, e poi IE6 e IE7 vedranno la seconda regola con l'ampiezza standard e vi obbediranno. Ricordate solo che l'escape non deve venire direttamente prima di ciascuno dei primi sei caratteri alfabetici, perchè essi hanno significati speciali quando vengono preceduti da un escape. Se avessimo scritto "wi\dth", allora IE6 e IE7 avrebbero ignorato la "d" e avrebbero visto "with" come il nome della proprietà. Non va bene. Nello specifico, i caratteri proibiti sono a, b, c, d, e, f.

Per fortuna c'è sempre almeno un carattere all'interno di ogni proprietà che non è fra i primi sei, e così si può usare in questo modo un carattere di escape. Comunque non potete usare la "w" in "width", perchè IE5.5 in qualche modo è in grado di ignorare l'escape quando viene per primo. Mantenete l'escape all'interno del nome e funzionerà ogni volta. Poichè IE5 e IE5.5 sono i browser che vengono ingannati dall'escape e sono anche gli unici che hanno il problema con il box model, è una soluzione perfetta e non creerà problemi in futuro.

[Torna al sommario]

Un metodo alternativo

Accade così che i commenti condizionali si presentano in diverse varietà che le differenti versioni di IE leggeranno o ignoreranno, a seconda del codice posto all'interno del tag iniziale del commento condizionale. Si veda la pagina di Microsoft per le specifiche, e "Domare le vostre versioni multiple di IE standalone" qui su Position Is Everything per molti più dettagli e tips utili sui commenti condizionali.

Così potreste creare due differenti file, uno che può essere visto da tutte le versioni di IE Win con gli hack generali, e un altro solo per i problemi del box model e qualsiasi altro hack possa servire nello specifico per le versioni di IE Win precedenti alla 6:

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="iehacks.css" />
<![endif]-->

<!--[if IE 5]>
<link rel="stylesheet" type="text/css" href="iehacks-5.css" />
<![endif]-->

Aggiungendo questo "5" nel tag iniziale, dichiarate che solo le versioni di IE Win che iniziano con un 5 dovrebbero leggere il commento condizionale. La versione di IE5.5 inizia con un 5, così legge il commento condizionale insieme con IE5 Win.

Una volta che questi file esistono, è una faccenda semplice relegare le altezze e le larghezze del box model all'interno del file per la versione 5. Questo sistema evita di aver bisogno di ogni CSS hack, ma naturalmente c'è un file CSS in più con cui fare i conti, ed è possibile che aumenti la probabilità di errori e difficoltà in futuro.

Quando usate questo metodo, assicuratevi che i link per i commenti condizionali vengano dopo il link per il CSS principale nel sorgente, e che le regole all'interno dei commenti condizionali abbiano almeno la stessa (o più alta) specificità rispetto ad ogni regola simile nel foglio di stile principale. Se ciò non avviene, i vostri hack non sovrascriveranno queste regole primarie per IE Win, e falliranno nel loro compito. Assicuratevi anche che, se i due differenti commenti condizionali linkati hanno regole in conflitto, l'ordine e/o la specificità sia giusta, altrimenti potrebbero esserci dei problemi.

[Torna al sommario]

Gli hack con il selettore figlio ed il selettore fratello adiacente

Questi combinatori, quando vengono usati come hack, sono sempre tenuti a prevenire che IE Win veda una regola che gli farebbe in qualche modo distruggere il layout. Così quando uno di essi compare in un file CSS, non si può semplicemente rimuovere senza privare gli altri browser degli stili all'interno di quella regola. Si, la parte dell'hack-figlio del selettore può essere cancellata, lasciando una semplice regola per IE7, ma le versioni più vecchie di IE Win la vedrebbero e distruggerebbero il layout. Abbiamo bisogno di semplificare in qualche modo la regola senza far si che IE Win la veda.

Infatti questo non è effettivamente possibile, e allora lasceremo invece che IE Win veda la semplice regola senza hack, salvo poi "negarla" dall'interno di un commento condizionale generale, dove i browser diversi da IE Win non saranno influenzati.

Un uso comune per l'hack-figlio è quello di dare un'height mentre gli altri browser ottengono solo una min-height. Poichè IE Win allargherà sempre ogni dimensione quando è richiesto il contenimento del contenuto, una height è in effetti trattata come min-height da IE Win. La cosa importante è non far vedere l'altezza riservata solo a IE Win. Di solito si fa in questo modo:

#wrapper {
 min-height: 500px; /* IE Win non supporta min-height */
 height: 500px;
}

html>body #wrapper {
 height: auto;
}

Questo imposta sia min-height che height sullo stesso valore, e quindi, nella regola con l'hack-figlio che IE Win non considera, l'altezza è riportata sul valore di default auto. Purtroppo IE7 sarà in grado di leggere questa seconda regola, e così succede che IE7 espanderà ancora il box come le vecchie versioni di IE Win. Ciò significa che la precedente regola farà resettare anche ad IE7 l'altezza su auto, e così in questo browser si perderà il desiderato effetto min-height.

La risposta è cancellare l'hack-figlio e il suo valore auto completamente, e quindi spostare la dichiarazione di height fuori dalla prima regola, mettendola invece nel file iehacks.css. IE Win ottiene ancora il valore che gli serve per l'altezza, e nessun altro browser va incontro a problemi. Ora il problema è risolto, almeno finchè non uscirà una versione di IE Win che non espanda i box in modo improprio!

Non vi è un grande problema, perchè i commenti condizionali sono assai flessibili. Poniamo che sia arrivato IE8, e che sia stato ridefinito in modo tale da osservare correttamente le dimensioni del box come gli altri browser. Si spera che una versione di IE così radicalmente differente supporterà anche min-height. Ma, in ogni caso, non vogliamo che la regola per l'altezza concepita per IE7 e versioni inferiori venga vista dall'IE8 che abbiamo descritto. È anche probabile che molte altre cose saranno al contempo sviluppate, sicchè potrebbe esserci un nutrito gruppo di regole speciali per IE Win che IE8 non dovrebbe vedere. Così scriveremmo il nostro commento condizionale:

<!--[if lt IE 8]>
<link rel="stylesheet" type="text/css" href="iehacks.css" />
<![endif]-->

Vedete questo "lt" nel codice del tag? Significa "less than" (meno di. N. d. T.) IE8, sicchè IE8 verrebbe escluso dalla lettura di questo commento condizionale e non otterrebbe il foglio di stile linkato. A seconda delle realtà future per i browser della famiglia IE, si potrebbero creare varie combinazioni di commenti condizionali per gestire quasi tutto. Dai, speriamo che Microsoft non ci crei troppe complicazioni, eh?

Succede poi che vi sia quella cosa chiamata Owen hack che ha il selettore head:first-child+body {}. Questo hack era utile perchè non poteva essere letto da Opera 6, mentre Opera 7 non aveva problemi. Attualmente ci si preoccupa poco di Opera 6, ma l'hack è ancora in agguato in pochi fogli di stile, e Microsoft mette in guardia contro il suo uso continuato.

Sappiamo che il selettore fratello sarà rispettato da IE7, ma l'Owen hack contiene anche "head:first-child". Questa è un'avanzata pseudoclasse CSS che al momento IE Win non supporta, ma questo avvertimento di Microsoft sembra dire che :first-child ed altri selettori di questo tipo potrebbero essere candidati per essere supportati in IE7! Vero o no, Questa dovrebbe essere una chiara indicazione che usare selettori avanzati per escludere browser deboli (ma in evoluzione) può essere controproduttivo. Parola del saggio, eh?

[Torna al sommario]

Lo star-html hack

Non c'è rimasto molto da dire su quest'hack. Nasconde una regola ai browser non IE, ma permette ad IE Win e IE Mac di vedere la regola. IE7 sarà escluso dalla visione dell'hack, sicchè ogni regola con hack che pensate che IE7 debba vedere, ha bisogno di essere spostata in iehacks.css, o in un foglio di stile linkato tramite commento condizionale che abbia un target più specifico.

L'unico trucco è con IE Mac. Ci possono essere a volte regole con hack che volete che IE Mac veda con gli altri IE per Windows, ma una volta che la regola speciale è nascosta dentro il commento condizionale, il povero IE Mac non sarà in grado di accedere a questo file o alla regola che contiene. La risposta a questo problema è quello che a volte chiamiamo l'hack solo per Mac, escogitato da Tantek Çelik (che è stato un programmatore Microsoft, fra le molte altre cose). È il più vecchio Mac hiding hack con un nuovo sviluppo. È costruito con una speciale coppia di commenti CSS, fra cui si possono inserire le regole CSS che solo IE Mac leggerà. Presupponendo che IE Mac ha bisogno di qualcosa di unico, come una larghezza su un float di norma senza larghezza, si può scrivere questo nel foglio di stile principale:

 /*\*//*/
 #floatedbox {
  width: 200px;
 }
/* */

Trovate come funziona qui, ma essendo un hack indesiderato non preoccupatevene. L'hack si basa interamente su un errore di parsing nel motore di IE Mac, causato dall'escape all'interno del commento superiore. Nessun browser successivo a Netscape 4 ha alcun problema con questa sistemazione, e nessun browser futuro lo avrà. Inoltre IE Mac non è più sviluppato da Microsoft, così vi sono zero probabilità di futuri problemi come quelli che abbiamo visto con IE7. Usatelo in buona salute!

[Torna al sommario]

Conclusione

Ora dovreste esservi fatti un'idea di quello che ci aspetta fra non molto. Se il vostro codice si basa su CSS hack come i nostri, avete due opzioni: ripulitelo ora oppure prendete parte ad un disastro ferroviario al rallentatore. La scelta è vostra. Non c'è neppure motivo di sgridare Microsoft. Abbiamo urlato per anni che avrebbero dovuto fare quello che stanno per fare. Ok, sarebbe carino da parte loro risolvere tutti i bug in un colpo solo, ma ammettetelo: non succederà. Microsoft inizia a prendere sul serio i suoi problemi, e IE7 sarà solo il primo passo verso un Explorer più conforme agli standard. Se Microsoft ha intenzione di affrontare un sacco di grane per accostarsi alla piena conformità, preferiamo vederlo come un buon segno per il futuro.

Comunque sia, perchè non avere un atteggiamento positivo? Non fa male a nessuno, e come risultato avremo molti acidi di stomaco in meno. Questa è la nostra politica e vi restiamo fedeli!

( Holly e John )

[Torna al sommario]

Nota del traduttore

La presente traduzione è stata esplicitamente permessa dagli autori dell'articolo. Eventuali errori nella traduzione sono da imputarsi esclusivamente al traduttore.

[Torna al sommario]