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?

Firefox update e unità di misura mancanti

Attenzione! Dopo l’ultimo update di Firefox tutte le misure specificate nei css senza indicare l’unità di misura (ex.: px, cm) vengono ignorate. Preparatevi a correggere tonnellate di css (rimbombano ancora le imprecazioni di V.).

p.s.: questo post andrebbe riscritto, dato che la questione è un attimo più complessa e interessa ciò che prevede lo standard e l’uso del DOCTYPE.

Questione di millimetri

Supponiamo che il vostro compito sia quello di realizzare un documento in html di cui sia prevista la stampa in un foglio A4. Nel foglio di stile è possibile specificate le misure in millimetri così che quando ad esempio dobbiate specificare le dimensioni dell’area contenente il documento, possiate prendere in considerazione le misure standard del foglio A4, cioè 210×297 millimetri, e quindi ad esse togliere un margine previsto di circa 10 millimetri per ogni lato. Potete realizzare il vostro layout della pagina in html usando sia una tabella contenente una cella a cui sia stato applicato un padding di 10mm oppure usare un div a cui è applicato lo stile:

.test_cover {
position: relative; top: 10mm; left: 10mm;
width: 190mm; height: 277mm; background-color: #F0F0F0;
}

Ora supponiamo che nel documento ci sia un svg contenete del testo (avete deciso di mettere nel documento un testo in verticale e l’unico modo che avete per farlo è quello di metterlo dentro un text svg ruotato di 90 gradi). Mettete il codice svg nel codice html e grazie al fatto che avete realizzato una pagina xhtml riconosciuta come tale dal browser vi aspettate che il documento sia presentato correttamente con l’immagine svg renderizzata correttamente col testo in verticale.

Sicuri?

Si, se nell’immagine contiene solo cerchi, quadrati, figure geometriche più o meno complesse l’immagine viene presentata correttamente. Però se provate a mostrare del testo in una immagine svg collocata dentro un documento realizzato come sopra, cioè in cui la view che contiene l’immagine sia stata traslata di una misura espressa in millimetri, il testo magicamente scompare.

Strano, no?

Soluzioni? Si, ci sono: non usare alcuna traslazione o esprimerla in pixel.

Quindi, in attesa che esca FF3.0 e che (forse) il problema scompaia… chi mi dice a quanti pixel corrispondono 10mm?

p.s.: ho provat con Gran Paradiso Alpha 4 e il bug non si ripresenta. In compenso non mi funzionano più altre cose.