Quando arriva IE 8?

Me lo chiedo perché vorrei non dovermi più preoccupare di certi problemi.

So bene che la perfezione è un’utopia, ma la situazione potrebbe essere decisamente migliore a quella attuale.

Perché mi lamento? Dunque… argomento: visual formatting model – attributo display.Il w3c dice a proposito dell’attributo display:

“inline-block

This value causes an element to generate a block box, which itself is flowed as a single inline box, similar to a replaced element. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an inline replaced element”.

Firefox 2 implementa in modo errato questa modalità. Stiamo calmi! Per fortuna, questo bug è stato corretto in Firefox 3. Opera e Safari… pardon, WebKit (io preferisco le nightly build) non danno problemi. IE 7 si mostra in teoria capace di implementare questa modalità; con display: inline e width e height specificati renderizza il blocco come previsto dallo standard nel per display: inline-block. Eppure display: inline-block sembra proprio non sappia cosa sia. E non mi pare neanche che un suo eventuale supporto avrebbe prodotto chissà quali problemi.

Siamo buoni: se ne sono dimenticati.

Altra dimenticanza: empty-cells: show. Ovvero, dobbiamo continuare a complicare il nostro codice inutilmente per produrre inutili. Ma era così difficile da realizzare?

L’utopia della compatibilità

Cercando della documentazione che spiegasse in modo chiaro il contenuto delle proprietà clientWidth e offsetWidth degli oggetti HTML mi sono imbattuto in una tabella riassuntiva messa a disposizione da quirksmode.

Come si può notare diversi browser su diversi tipi di elementi hanno comportamenti differenti. Questo stato di cose è solo un esempio della complessita di uno lavoro di sviluppo non banale che debba tenere conto della compatibilità con i più diffusi browser.

Un aiuto possibile potrebbe arrivare da HTML 5. Il nuovo standard prevede, attraverso il DOCTYPE, la possibilità di attivare comportamenti standard nel browser. Un documento HTML 5 è riconosciuto come tale solo se dotato del giusto DOCTYPE. Questo riconoscimento comporterà anche un rendering della pagina più aderente allo standard da parte di quei browser (Explorer) che storicamente hanno utilizzato un’interpretazione dello standard non corretta e che sono costretti in qualche modo a mantenerla per ragioni di compatibilità. Questo in teoria comporterebbe minor fatica da parte degli sviluppatori che vorrebbero perder meno tempo concentrandosi solo sulla realizzazione della pagina così come previsto dallo standard senza pensare al comportamento dei diversi browser. Putroppo questo rimarrà una teoria, almento nell’immediato futuro, per diverse ragioni. La prima è che HTML 5 è ancora uno standard in via di definizione. La seconda è che per dimenticarsi del passato si dovrà aspettare la diffusioni dei browser HTML 5 compatibili. La terza è che già oggi i browser più rispettosi degli standard hanno comunque delle incompatibilità, per presenza di bug o per parziale implementazione dello standard, per cui allo sviluppatore che volesse solo occuparsi dello standard rimane sempre e comunque il compito di verificare se il proprio codice funziona su tutti i browser che si intende supportare.

Esiste solo UTF8

Regola fondamentale: encoding pagine UTF8, altrimenti funzioni utilissime come encodeURIComponent, che ragionano solo in UTF8, producono dati non utilizzabili in altri charset.

Ora metto pure le tabelle mysql in UTF8 e vaff… agli altri charset!