1. A List Apart: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8, di Aaron Gustafson.
2. A List Apart: From Switches to Targets: A Standardista’s Journey, di Eric Meyer.
3. IEBlog: Compatibility and IE8, di Chris Wilson (IE Platform Architect).

Se fate siti, se scrivete CSS, se usate Internet Explorer, questi tre articoli dovete quantomeno leggerli. Premesso questo, vi delineo comunque la situazione.

IE7 è stato sviluppato a partire da IE6 con ben fisso il principio di “don’t break the web”. Vi sono stati dei miglioramenti, anche se non sensibili come ci si aspettava. E’ evidente che risolvere anche solo una piccola parte dei bug di IE7 avrebbe rotto qualcosa.
Mi chiedo come il team di IE7 abbia potuto ignorare questa ovvia nozione dello sviluppo software (non è una cosa da poco, voglio dire, è una problematica rilevante ed esiste enorme letteratura in merito con alcune soluzioni, quali ad esempio i principi dello Unit Testing).
Quindi: una grossa maggioranza dei siti si è rotta con l’uscita di IE7.
Qui nasce la mia critica iniziale: il principio di partenza ha senso, ma ragionare in quei termini è fallato in origine ed infatti ha portato ad un browser con pochi miglioramenti e siti comunque rotti.
Tanto valeva sistemare tutto, tanto i siti si sarebbero rotti comunque, no?

Veniamo a IE8, oggi in sviluppo. Guarda caso, il principio è ancora “don’t break the web”. Non l’hanno mica imparata la lezione.
Però questa volta si son rivolti al WaSP, e sono venuti a capo con una soluzione interessante.
La proposta che verrà implementata in IE8 è quella di utilizzare un meta tag, del tipo http-equiv:

<meta http-equiv="X-UA-Compatible"

    content="IE=8;FF=3;OtherUA=4" />

Come ogni HTTP Equivalent può anche essere specificato nell’intestazione HTTP (in modo analogo al Content-Type):

X-UA-Compatible: IE=8;FF=3;OtherUA=4

E’ sicuramente una proposta interessante, perché seppure simile ai vecchi e orrendi hack per tentare di assecondare il browser, questa dicitura fa un cosa un po’ differente: dichiara per quali browser la pagina è stata generata.

A me viene in mente la dicitura delle date sui libri: “Finito di stampare il xxxx”.

La proposta è interessante perché non si tratta più di cercare di predirre comportamenti dei browser, ma è una dichiarazione leggibile dal browser: “guarda che questa pagina è stata realizzata per IE7, Firefox2 e Safari3″.

Questo approccio è interessante perché dichiarativo/descrittivo: non modifica esplicitamente il comportamento della pagina, con alte probabilità di rottura nel caso di aggiornamento dei browser.

Al contrario, consente a chi sviluppa i browser di gestire i cambiamenti: se la pagina è dichiarata IE7 e IE8 rompe una funzionalità, allora il browser può gestire bene sia i nuovi standard, sia le vecchie pagine, adattando la modalità di rendering di conseguenza.

Certo, gli sviluppatori dovranno sempre gestire i problemi dei browser attuali, ma in questo modo c’è la speranza di un po’ più di solidità all’uscita dei nuovi browser. Per esempio: Firefox3 ha migliorato la gestione dei font, cosa che sul mio blog ha comportato un piccolo disallineamento di 2 pixel. Ora, io l’ho sistemato, ma pensiamo cosa succederebbe in caso di utilizzo effettivo di quella sintassi: Firefox 3 potrebbe leggere che il mio sito è compatibile con Firefox 2 e gli sviluppatori saprebbero che quella modifica ha sfasato di 2 pixel l’altezza, compensandolo. Appena io avrei avuto il tempo di aggiornare, sarei passato a Firefox 3 e avrei sistemato quel bug.

L’approccio è conservativo e abbastanza intuitivo.

La cosa negativa però è un’altra: edge. E’ infatti possibile dichiarare la pagina come “compatibile sempre e comunque con l’ultima versione”. Questo a mio avviso è un errore (concordo con l’articolo che ho linkato inizialmente) perché fa perdere la natura dichiarativo/descrittiva del tag.
O, in altri termini: se il tag non fosse specificato, automaticamente io mi aspetterei un comportamento “edge”. Mancando l’informazione a riguardo di quando la pagina è stata fatta, si assume che sia recente. Anche perché non è facile inferire altre alternative (o se è possibile, non è molto affidabile, vedi con i DOCTYPE).

Vedremo un po’ come si evolverà la situazione, per ora sembra una proposta piuttosto interessante, ma che richiede un po’ di discussione perché ne vengano evidenziati pienamente gli aspetti positivi e negativi.

[update|2008.01.23] Ho trovato un interessante articolo, che ritengo meglio argomentato e di posizione opposta. Seppure ritenga che dichiarare la versione dei browser per cui una pagina è stata sviluppata possa avere la sua utilità, trovo più forti e importanti le tesi di questo articolo: End of Line Internet Explorer, di Mike Davies. Soprattutto nelle conclusioni: mettere Internet Explorer in maintenance e non svilupparlo più.

Si, perché, mi son dimenticato di dirlo: uno dei più grossi problemi che vedo è ancora la fusione di Internet Explorer con il sistema operativo. Indipendentemente dalla concorrenza sleale del suo legame con Windows, questo è grave perché impedisce l’installazione di più versioni di Internet Explorer (esistono hack, ma son inapplicabili per un reale utilizzo). E’ poi evidente che lo sviluppo è limitato: se risolvi i problemi, rompi per forza con il passato, e quindi per forza dovrai tentare di capire come renderizzare la pagina.

Nota: Safari seppure in misura minore soffre dello stesso problema di integrazione nel sistema operativo, anche se è possibile scorporarlo…

[update|2008.03.04] Il team di Internet Explorer ha cambiato idea: di default ora IE8 funzionerà in modalità “full standard”, o edge, e utilizzerà versioni precedenti solamente se esplicitamente specificato.

In light of the Interoperability Principles, as well as feedback from the community, we’re choosing differently. Now, IE8 will show pages requesting “Standards” mode in IE8’s Standards mode. Developers who want their pages shown using IE8’s “IE7 Standards mode” will need to request that explicitly [...].

Questo trasforma il tag in qualcosa di ‘descrittivo’ invece di ‘prescrittivo’. La cosa credo mi piaccia.

Pensando un attimo all’evoluzione del web, abbiamo avuto agli esordi HTML 1.0 che era ingenuo e incompleto, ma possedeva una chiara struttura semantica. I tag esistenti erano strutturati.

An HTML instance is like a text file, except that some of the characters are interpreted as markup. The markup gives structure to the document.
– HTML 1.0 RFC, 1993

Poi ci si accorse che le pagine erano come quelle su carta, e si sono iniziati ad aggiungere elementi per arricchire la visualizzazione, rendendo il codice di fatto non un formato per strutturare dati, ma un formato per visualizzare contenuti.

Successivamente ci si accorse che in questo modo era impossibile leggere la pagina in modo automatico. Non c’era più alcun significato semantico: h1 usati per evidenziare testi, pagine senza struttura, farciture di colore, banner pubblicitari.

Idea: usiamo XML, facilmente elaborabile dalle macchine, e rendiamo disponibile un contenuto uniforme sul web (glisserò su XSLT, che considero un aborto tecnicista).
Nacque così RSS e i successivi figli RDF, Atom e simili. Ovvero dei contenitori per uniformare le fonti testuali in modo da renderle comparabili.

Al che, pensavo: ma lo scopo di RSS e simili non è alla fine lo stesso che aveva HTML 1.0, ovvero strutturare contenuto?

Rifinito, certo. Raffinato dalla comprensione di cosa sia realmente necessario e da anni di teoria (ontologia, fra le altre) e pratica (spider, validatori, reader).

E se alla fine di tutto questo, si tornasse ad (X)HTML, puro, con la giusta separazione di dati e presentazione fatta tramite CSS?

Non stupisce troppo che sia un bug identico a quello che si ha su Internet Explorer 6 (fixxato con lo star hack), ma che dopo una mia ricerca in rete pare non abbia ancora nome. Sarebbe interessante cercare di ridurre dal CSS completo quale sia il problema, che sembrerebbe una variante del Peekaboo Bug.

Il problema in questione è che spariscono i background.

La soluzione è dire a IE che l’altezza minima del frame è 1%.

Soluzione sintetica:

* html #body div { height: 1%; } /* [IEfix] Peekaboo bug (contained float misbehaves w/o this) */

*:first-child+html #body div { min-height: 1%; } /* [IE7fix] wonder! IE7 still bugged */

Notare che su IE6- usiamo “height”, perché per un altro suo bug “height” è uguale a “min-height”.

Note di costume. Cercando ho trovato delle curiosità.
Una di queste segnala un bug su IE6 che fa sfarfallare le immagini. Su IE7 semplicemente quando ci passi sopra “sega” il margine inferiore, togliendo lo spazio. Curioso.
Per non citare poi i CSS applicati sull’elemento seguente, novità di IE7.

Si riesce ancora a leggere, vero?

Insomma, che ho fatto? Il sito di Nielsen Media Research Italia.

Notice the red border and the accent…

CSS:
top: -19px;

This could be minimized with this code:
top: -17px;
line-height: 20px;

…but still it isn’t solved.