Quando abbiamo deciso di rivolgere qualche domanda ad Eric Meyer, il sito della casa editrice New Riders già ospitava un’intervista, che vi consigliamo di leggere senza indugi.
Per questo motivo abbiamo pensato di rivolgere all’autore qualche domanda un po’ più provocatoria, soprattutto perché ci aiuti a capire quali sono i veri vantaggi dei Css e fino a dove possiamo spingerci nel loro utilizzo.
- Qual è l’approccio del tuo ultimo libro, Eric Meyer on Css, e come hai scelto i casi studio? [Risposta 1]
- Siamo davvero pronti per il tuo libro? Niente più tabelle per il layout o spacer gif? Cosa possiamo dire ai nostri clienti quando si lamenteranno che non riescono a vedere il sito con Netscape 4.x? [Risposta 2]
- Quanto è complessa la curva di apprendimento per uno sviluppatore che proviene dalla vecchia scuola “tabelle per layout”? [Risposta 3]
- Tra le cause che tengono gli sviluppatori lontani dall’adottare i Css nei loro layout, c’è la gestione non perfetta da parte dei browser. Ma perché si verifica questo? [Risposta 4]
- A volte è possibile vedere documenti dove l’autore usa trucchi o complicate soluzioni per interagire con i browser meno recenti (@import per nascondere i Css con Netscape 4.x e commenti per Internet Explorer 5 e Opera). Altri cercano invece di riconoscere il browser lato client o lato server, così da inviare un versione personalizzata del Css. Altri scelgono semplicemente di non fare niente. Qual è la tua opinione? [Risposta 5]
- Navigando in Internet è possibile incontrare molti siti personali o blog che sono realizzati ricorrendo pesantemente ai Css. Lo stesso non sembra ancora accadere per i siti commerciali e in generale per i siti che dispongono di molti contenuti. Wired è stato il primo esempio, anche se soffre di alcuni problemi con la validità del codice. È più impegnativo usare i Css con i siti complessi? Quali sono i compromessi? [Risposta 6]
- Pensi che lo standard Css sia completo o che gli manchi qualche importante caratteristica? [Risposta 7]
Qual è l’approccio del tuo ultimo libro, Eric Meyer on Css, e come hai scelto i casi studio?
Eric Meyer on Css è quasi interamente pratico in natura. È composto da 13 progetti, ognuno dei quali inizia con un semplice documento al quale vengono applicati stili sempre più complessi. Il testo è stato scritto in modo da consentire agli utenti di seguire il libro e vedere i progetti che evolvono man mano.
I file di base dei progetti, così come tutti quelli che sono stati utilizzati per realizzare le schermate del libro, sono disponibili sul sito dedicato.
Ho creato tutti i progetti partendo da zero, scegliendo ognuno con un occhio rivolto ad un aspetto ben preciso dei Css. Due progetti, ad esempio, trattano quasi esclusivamente del posizionamento, uno si concentra sugli stili per la stampa, un altro si preoccupa dei form e il primo esamina la conversione di un design realizzato con tabelle e font in uno che usa i Css.
Il sito web contiene i dettagli su tutti e 13 i progetti, oltre a del materiale aggiuntivo, ad esempio alcune appendici che sono state eliminate dal libro per preservare spazio.
Siamo davvero pronti per il tuo libro? Niente più tabelle per il layout o spacer gif? Cosa possiamo dire ai nostri clienti quando si lamenteranno che non riescono a vedere il sito con Netscape 4.x?
Non penso sia arrivata la fine per le tabelle di layout, e il libro non ha questa pretesa. Se usate delle semplici tabelle per le aree principali della pagina e poi impiegate i Css per i contenuti di queste tabelle, otterrete una pagina decente in Netscape 4.x e la pagina voluta nei browser più recenti.
Ammetto che il libro non prende molto in considerazione Netscape 4.x, ma diciamolo: è un browser vecchio di 5 anni, più di metà dell’era del “web popolare”, quello che è cominciato con il rilascio di Mosaic 1.0. Era un browser contemporaneo di Internet Explorer 3, e di quest’ultimo nessuno ormai si preoccupa più.
Detto questo, se un webmaster si occupa di un sito con un buon numero di utenti che usano Netscape 4.x, allora dovrà fare un po’ di più per andare incontro a questo browser, ovviamente.
La vera domanda è: la pagina deve apparire identica in Netscape 4.x e in Internet Explorer 6?
Per me no. Fintantoché la pagina è comprensibile nei vecchi browser, può apparire leggermente diversa. Un esempio in questo senso è il sito di Fox Searchlight.
Questo sito non è preciso al pixel in Netscape 4.x rispetto ai browser recenti, ma la resa è molto buona. Se non paragonate Netscape 4.x e Mozilla fianco a fianco, probabilmente non vi accorgereste neppure che sono diversi.
Quanto è complessa la curva di apprendimento per uno sviluppatore che proviene dalla vecchia scuola “tabelle per layout”?
Non troppo complessa. L’ostacolo principale è che dovete lasciar perdere tutto quello che avete imparato con il layout basato su tabelle. Quando abbracciate il layout basato sui Css, ci sono sicuramente dei cambiamenti. Se però mantenete delle tabelle di base e usate i Css per il contenuto, allora la curva di apprendimento è praticamente lineare. Ogni autore che ho incontrato e che è passato dalle tabelle ai Css mi ha detto che non può credere di aver pasticciato con tabelle annidate in tabelle e spacer gif quando i Css avrebbero reso le cose molto più facili.
Tra le cause che tengono gli sviluppatori lontani dall’adottare i Css nei loro layout, c’è la gestione non perfetta da parte dei browser. Ma perché si verifica questo? Ecco alcune possibili cause che vorremmo esplorare con te:
perché sono pochi gli sviluppatori che usano i Css per il layout e così i produttori di browser non sentono la necessità di migliorarli
Questo poteva essere vero nel 1998, ma non oggi. Praticamente ogni sito usa i Css in qualche modo. Sono d’accordo che molti li usano senza sfruttarne le potenzialità, ma la maggioranza li usa almeno ad un livello che potremmo definire moderato. È comunque vero che alcuni siti mischiano i Css con i tag font, il che è una sciocchezza. Gli autori dovrebbero usare uno o l’altro, ma non entrambi nei loro design.
perché le specifiche Css sono scritte in inglese, e ogni lingua è per definizione ambigua (molti non sono bug, ma diverse interpretazioni delle specifiche)
Questa è una parte del problema. Ci sono stati casi in cui le specifiche Css 2 erano contraddittorie, come ci si può aspettare da un documento di grosse dimensioni. Il Css Working Group sta cercando di risolvere questi limiti con le specifiche Css 2.1, che sono quasi complete. Comunque ogni documento scritto in un linguaggio per umani è aperto alle interpretazioni.
perchè i Css sono complessi e così è complessa la loro implementazione
Questo è esattamente il nocciolo della questione. I Css sembrano molto semplici quando gli date un’occhiata, ma in realtà sono così complicati che la maggior parte dei comportamenti inaspettati sono in realtà casi particolari. Alla fine degli anni 90 i produttori di browser non hanno prestato la giusta attenzione alle sottigliezze dei Css, o hanno scelto deliberatamente di ignorarle. Solo in tempi recenti hanno cominciato a correggere gli errori fatti.
perché il layout basato su Css è una materia nuova
Penso che il layout basato sui fogli di stile sembri nuovo perché solo recentemente i browser li gestiscono più o meno correttamente, così da farci prendere in considerazione la loro adozione.
A volte è possibile vedere documenti dove l’autore usa trucchi o complicate soluzioni per interagire con i browser meno recenti (@import per nascondere i Css con Netscape 4.x e commenti per Internet Explorer 5 e Opera). Altri cercano invece di riconoscere il browser lato client o lato server, così da inviare un versione personalizzata del Css. Altri scelgono semplicemente di non fare niente. Qual è la tua opinione?
Uso @import per nascondere i Css a Netscape 4.x, quindi penso che questi stratagemmi possano benissimo essere utilizzati: ho impiegato alcuni di questi trucchi almeno in uno dei progetti per il libro. Penso comunque che sia facile eccedere nel loro utilizzo. Se il vostro foglio di stile è composto per metà da trucchi e regole che si appoggiano ai bug dei browser, state probabilmente sbagliando l’approccio. A me è capitato di scartare alcune progettazioni perché troppo avanzare per i browser di oggi senza impiegare un gran numero di trucchi. Questo accade per tutti i media e non è una sorpresa che si verifichi anche nel web.
Personalmente non mi piace l’uso di codice lato server per riconoscere il browser, perchè è un procedimento che introduce un carico extra al server ed è utile in pochissime situazioni. L’unico caso in cui questo sforzo è necessario si verifica quando il contenuto deve variare a seconda dei browser. Se invece volete inviare Css diversi a browser diversi, probabilmente state scegliendo una soluzione inutilmente complessa: un solo foglio di stile dovrebbe essere sufficiente.
Navigando in Internet è possibile incontrare molti siti personali o blog che sono realizzati ricorrendo pesantemente ai Css. Lo stesso non sembra ancora accadere per i siti commerciali e in generale per i siti che dispongono di molti contenuti. Wired è stato il primo esempio, anche se soffre di alcuni problemi con la validità del codice. È più impegnativo usare i Css con i siti complessi? Quali sono i compromessi?
A dire il vero, quando Wired è stato convertito ad un layout basato sui Css, i loro problemi con il codice valido riguardavano esclusivamente la codifica degli Url, non il markup. Ci sono pagine vecchie di 3 anni che non sono valide, ma possono essere sistemate gradualmente. Comunque la pagina principale del sito è valida, o almeno lo era quando la ho scritta io.
Se usate i Css per il layout, è più semplice ottenere pagine valide perché il codice è più semplice e più logico. Invece di districarvi tra tabelle annidate e tag td avete la possibilità di concentrarvi sui paragrafi e sui div. Quando ho abbandonato le tabelle dal mio sito personale a Gennaio 2002 è stato molto più semplice convalidare le pagine e correggere gli errori di validità.
Pensi che lo standard Css sia completo o che gli manchi qualche importante caratteristica?
Lo standard Css non sarà mai realmente completo. La sua evoluzione potrebbe cessare un bel giorno, ma ci sarà sempre qualcuno che si lamenta perché non fa quello che lui vuole.
Così com’è oggi, lo standard non dispone di un modo per legare un elemento ad un altro in termini di layout: non potete dire “rendi questo elemento alto come quest’altro”. Sarebbe una caratteristica che aiuterebbe il posizionamento degli elementi, e forse sarà aggiunta in un prossimo futuro, ma dovremmo poi gestire qualcosa di complesso.
Penso che nessun linguaggio di presentazione, non importa quanto ricco e potente, potrà mai soddisfare tutte le richieste degli autori.
Il fatto che una caratteristica mancante sia importante oppure no dipende dalla persona a cui si pone la domanda. Quella che per me è una lacuna cruciale, potrebbe essere di importanza minima per qualcun altro, e viceversa.
Un esempio è dato dalle “variabili”, la possibilità di definire una parola chiave e assegnarle un significato, per poi utilizzarla da qualunque parte all’interno del foglio di stile. Conosco alcuni autori che pensano si tratti di un’enorme lacuna dello standard, ma personalmente la cosa non mi ha mai preoccupato.
Eric Meyer è uno “Standards Evangelist” per Netscape Communications, il che vuol dire che cerca di spargere la voce sul perché gli standard sono una “cosa buona”. Realizza soluzioni basate sugli standard ed è anche l’autore di 3 libri, nonché di un gran numero di articoli. Il suo principale ambito lavorativo è rappresentato dai Cascading Style Sheets, in parte perché è stato uno dei primi ad adottarli, ma soprattutto perché li trova infinitamente affascinanti e utili.
