Uno spunto di riflessione sulla realizzazione di progetti con codice HTML valido.
Perchè esistono gli standard HTML? La risposta è semplice: deve esserci una base comune su cui poter sviluppare, e questa base deve essere capita e condivisa da tutti, per evitare incomprensioni e incompatibilità.
I problemi
In questo scenario, esistono numerose società che sviluppano applicazioni e tecnologie basate su un linguaggio come l’HTML: il loro nemico più grande è il codice non valido. Basti pensare a come sarebbe molto più semplice lavorare sempre su pagine validate, prive di errori e warning, anche semplicemente durante lo sviluppo di un sito web. Se però iniziano ad essere presenti errori e codici non standard, ecco che una gran parte del tempo verrà impiegato per correggere questi problemi. Se si parla poi di progetti come la creazione di un nuovo motore di rendering o di un browser, il tempo perso in questa direzione sarà ancora maggiore.
A questo proposito è illuminante un post di Rebuilding the Web riguardo al linguaggio HTML ed all’importanza della sua validità. L’autore dell’articolo racconta la sua esperienza in una piccola azienda che progettava la realizzazione di un browser standard-compliant: era impossibile pensare di gestire tutte le eccezioni generate dal codice non valido con un piccolo team di lavoro. Per questo i motori di rendering sul mercato restano sempre gli stessi, a meno che qualche soggetto importante non decida di investire, potendoselo permettere. Anche Apple e Google hanno deciso di puntare su Webkit (open-source) per Safari e Chrome piuttosto che realizzare un proprio rendering engine: la spesa sarebbe stata troppo elevata.
Meno del 10% del web ha codice valido
La colpa di tutto questo è proprio da ricercare nella diffusione del codice HTML non valido: se l’intero web non avesse errori non ci sarebbero problemi, ma è chiaro che questa rimarrà un’utopia. In passato ci sono state anche delle discussioni sul comportamento dei browser: c’era chi proponeva di visualizzare solo le pagine con codice valido, ma questo significherebbe impedire l’accesso a più del 90% dei siti web.
I dati che si trovano sulla rete sono impressionanti:
- una ricerca del 2001 di Dagfinn Parnas, analizzando i siti indicizzati su dmoz.org, ha rivelato che solo lo 0.71% aveva codice HTML valido.
- nel 2006 Rene Saarsoo ha ripetuto lo studio, ed i siti validi erano diventati il 2.58%.
- un progetto di ricerca di Opera del 2008, chiamato MAMA, ha analizzato 3 milioni e mezzo di pagine e quelle valide erano il 4.13%.
Fortunatamente la tendenza è in aumento, ma i numeri restano ridicoli ed per ora ben poco influenti.
L’utopia di un web migliore
Con un quadro di questo genere, è facile comprendere come le conseguenze del codice HTML non valido riguardino tutti. Se utilizzate un qualsiasi browser, o a maggior ragione uno screen reader, un editor WYSIWYG o un motore di ricerca state pagando la presenza di milioni di pagine web errate. Enormi risorse continuano ad essere investite per gestire gli errori contenuti in queste pagine, ed in futuro lo scenario non sarà molto diverso.
Non esiste una soluzione immediata al problema, ma se una pagina web può essere validata senza grande sforzo, perchè non impegnarsi a raggiungere questo obiettivo? Anche questi sono costi di sviluppo da considerare, ma esistono anche dei vantaggi: una pagina valida non ha problemi ad essere visualizzata in tutti i browser e viene indicizzata senza problemi dai motori di ricerca.
Nel vostro prossimo progetto pensate seriamente alla validità del codice HTML, con un minimo di attenzione in più darete il vostro contributo per un web migliore.
[foto: Heberger Site]
Lo studio di Saarsoo me lo ricordo. Bella riflessione la tua, condivido l’90% dell’articolo. Il resto lo considero “non valido” (non piace nemmeno a me la battuta, ma ci sta!).
La forzatura credo che stia nel pensare che la validazione sia perfetta. Secondo me conviene pensarla ancora in questo senso: a meno di errori=orrori, certe segnalazioni possono essere ignorate.
@Kiko: capisco quello che intendi, ed in effetti se la homepage di Google non è valida qualcosa dovrà pur significare. Proprio per questo parlo di utopia, perchè resta un sogno :)
@Tom
credo pure che la complessità ormai dei siti web e delle applicazioni web sia tale che avere una certa congruenza tra codice prodotto e codice-valido desiderato sia impossibile. O quasi. Serve davvero tanto tanto tanto lavoro, spesso di rifinitura. Ma dopo 80 ore su codice e layout, spenderne altrettanto sulla ripulitura pare eccessivo. Oltre che tedioso e molto frustrante. L’esperienza mi ha insegnato questo. Da parte mia cerco di produrre plugin e codice quanto più valido possibile. Con gli strumenti di terze parti, poi, la cosa si complica ulteriormente.
nell’azienda dove lavoro facciamo tutti i siti con HTML valido e alcune volte si perde un po di tempo per renderlo valido.
Bell’articolo e interessante riflessione, grazie :)
Personalmente “lotto” ogni giorno per scrivere codice valido per i motivi che hai elencato e in genere ci riesco, oltretutto aprendo il validatore di tanto in tanto durante lo sviluppo non si perde così tanto tempo.
Ma come fare con i framework tipo ICEfaces che generano montagne di codice html inutile, obsoleto e spesso non valido?…
Il punto sollevato da Kiko e Marinella sugli strumenti di terze parti è uno dei maggiori ostacoli, verissimo. Tanto per fare un esempio pratico, con WordPress 2.9 e l’embed automatico dei video il codice generato non è valido, sul mio blog personale ne ho appena avuta la prova.
Penso che scrivere codice valido o meno riguarda l’etica professionale ma anche la morale.
Non credo che fare le cose per bene implichi maggiore lavoro e tempo. E’ come per tutte le cose della vita, non si può aspettare che qualcuno te lo imponga o nascondersi dietro le cattive abbitudini della massa. Anche il più piccolo e insignificante sviluppatore (come me) dovrebbe fare la sua parte.
Proprio pochi giorni fa ho scritto un post sulla questione che il codice generato tramite oEmbed per i video (non ho provato per altri servizi) non è valido: non è colpa di WordPress, lo sappiamo, ma del provider che restituisce la sezione “html” in modo non conforme alle specifiche (qui al paragrafo 5.1 trovate un esempio).
Se già una realtà come YouTube non si cura di questo, come può progredire il Web? Come dici giustamente tu, sembra (o è?) un’utopia. Ho provato a validare la pagina di un video qualunque di YouTube (quello SC-2VGBHFQI); ho ottenuto il seguente responso: “176 Errors, 67 warning(s)”. Decisamente troppi: forse neanche il sito comunale più sgangherato ha tutti questi errori.
Secondo me l’unica chiave di volta possibile per reggere un web orientato al rispetto degli standard di validità si trova negli algoritmi dei motori di ricerca. Se un sito valido avesse una significativa “ricompensa” in termini di posizionamento inevitabilmente tutti i principali siti, cms, sviluppatori tenderebbero sempre più al rispetto degli standard. Constatiamo invece, spesso, che tecniche di posizionamento “spinte” e spesso paganti vanno in direzione opposta.
Avere un codice valido al 100% è veramente difficile!
Poi ci sono anche situazioni in cui non è possibile avere un’ottima soluzione come quella che provoca errori o warning.
Detto questo, credo che la validazione del codice sia comunque una cosa importantissima e bisognerebbe fare i siti con una scheda del browser su “validator.w3c.org” e buttarci un’occhiata ogni tanto.
Secondo me non bisogna accanirsi per avere il “bollino verde” :) ma cercare di avere una pagina con pochi warning e pochissimi errori. E’ proprio durante la “ricerca del bollino verde” che i web designer si possono scoraggiare lasciando perdere definitivamente la validazione del codice.
La mia esperienza.
Dopo aver osservato il codice html di questo blog e avendo una forte stima di Tommaso ho deciso di seguire la stessa strada. In particolare sono rimasto impressionato dall’ordine e dalla pulizia del codice html, e dal fatto che ci sono pochissime righe di codice css per correggere gli errori di IE!
Così mi sono deciso a riscrivere html e css del mio template di wordpress, cercando appunto di mantenere un certo ordine e soffermandomi di più sui bug di IE invece di scrivere subito un css per IE.
Risultati?
– pochissimi errori di validazione del codice html
– pochissimi problemi con IE (6, 7 e 8)
Vi consiglio di fare così! ;)
Magari non sarà la strada più giusta, ma cercare di ridurre gli errori di validazione del codice html anziché mollare a priori sarebbe già un bel passo avanti!
Sono d’accordo col fatto che il codice HTML valido sia un’utopia.
mygod, quelle cifre mi hanno ammazzata da un lato, dall’altro sono contenta di far parte di quel 4%, perlomeno su buona parte dei miei siti.
ottima riflessione, la ripropongo su italianwebdesign, grazie :)
Dal basso della mia esperienza condivido la riflessione di chi dice che gli script di terze parti sono una delle cause maggiori di errori di validazione.
Essendo fermamente convinto che la posizione nei motori di ricerca (anzi.. in google) sia dettata principalmente dai contenuti che un sito ha e non solo dalla sua struttura, non sono per niente d’accordo con chi propone di mettere in risalto i siti validati in quanto all’utente finale potrebbero non essere utili.
Quello che secondo me bisognerebbe approfondire in Italia (perchè italiano sono, ma questo discorso si può allargare in tutto il mondo) è la professione del web designer, del web developer, delle web agency.
Chi non è del settore crede che mettere in piedi un sito sia una passeggiata! piazzare colori e immagini gradevoli ti fa accaparrare clienti, non avere un codice pulito. I clienti sono IGNORANTI (nel senso che ignorano :D).
Se avessero idea di cosa ci sta dietro, se sapessero che esistono siti validati secondo standard mondiali, sicuramente affiderebbero la loro immagine a gente capace, non a improvvisati freelance o web agency e quindi la percentuale di siti validati (e usabili) si alzerebbe…
Questo è il mio pensiero, dal basso della mia esperienza! Saluti!
Sono pienamente d’accordo con Dario, conta molto la professioalita’ e non le ore di lavoro.
Io provo sempre a correggere errori nei siti che faccio.
Come detto sopra spesso si usa roba di altri, e metterci mano è molto difficile.
Soprattutto quando il codice html te lo crea uno script magari in php, dove se metti certi simboli che in html sarebbero giusti, ti si sballa tutto.
Può scoraggiare si, nel limite del possibile si va verso il corretto.
Nella maggior parte dei miei siti ho errori, soprattutto su quelli con molto traffico.
Sono perfettamente visibili dalla maggior parte dei browser (i più usati), quindi anche una via di mezzo sarebbe da valutare.
Un po’ di flessibilità su certe cose, soprattutto dove l’errore non compromette la visualizzazione.
Se poi i motori di ricerca dessero spessore all’esattezza del codice allora si potrebbe insistere per l’ottenimento di un bollino verde.
Ma visto che spesso e volentieri sono le “furbate” a far da padrone la rete nelle serp, non c’è per ora la necessità di averlo pulito se il browser lo legge lo stesso.
Non sarebbe male un’avvertimento di pagina con errori al posto dell’oscuramento completo del sito in caso di errori.
Un bel messaggio di avviso di pericolosità in top al sito, cosa che dovrebbero sviluppare i broser stessi, e la voglia verrebbe per forza.
Saluti e grazie per le riflessioni
Forse neanche google ha il codice HTML valido, a mio avviso è una gran perdita di tempo, non c’è nessun oggettivo vantaggio nell’avere il codice validato.
@TucanoFilm: il codice valido è spesso un buon passo verso un sito più accessibile, ed una pagina senza errori viene indicizzata più facilmente dai motori di ricerca. Sono stati fatti diversi test a riguardo, come questo. Ovviamente non si può generalizzare, dipende dagli errori, dal progetto e dai costi.
Qualche tempo fa, ho avuto l’esperienza di lavorare fianco a fianco di un ragazzo non vedente.
Per interagire con il pc ovviamente utilizzava strumenti diversi da quelli a cui siamo abituati e certamente per quel che riguardava le applicazioni aziendali, era sufficientemente soddisfatto.
Il difficile era la navigazione su internet.
Poichè gli avevano messo a disposizione in ufficio una “barra braille” era tremendamente penalizzato nel navigare tra i vari siti web. Lo aiutai allora ad installare su firefox un plug-in che trasforma il browser in uno screen reader e di fatto, con l’aiuto di un paio di economici auricolari, fece di sicuro un grande passo avanti.
Purtroppo il plug-in che riuscimmo a trovare possedeva solo fonemi inglesi, quindi solo siti di natura anglofona, ma tutto sommato anche meglio così!
Ma un sito dopo l’altro ci rendemmo presto conto che la navigazione “letta” era paurosamente tediosa per due motivi principali:
1. Gli errori formali di validazione, a differenza di quanto succede nei comuni browser, negli screen reader, creano disastri imporanti: lo screen reader letteralmente “perde pezzi” di contenuto o si annida in loop infiniti (teniamo presente che un non vedente non può usare un mouse!!!)
2. Oltre alla validazione formale, nel 99% dei casi i siti web non erano progettati nella loro struttura per essere utilizzati banalmente da utenti sprovvisti di mouse rendendo talvolta impossibile la navigazione.
Per rendersi conto di cosa parlo è sufficiente scollegare il mouse per 10 minuti. Con molta probabilità nessuno di noi riuscirà a navigare in siti web che normalmente apprezziamo per tante caratteristiche.
Vissuta quell’esperienza, ed essendo io stesso uno sviluppatore, mi domandai se non fosse possibile realizzare uno strumento che potesse aiutare sia chi realizza siti web, sia chi voglia visitarli.
Lo strumento in questione altro non è che un Content Management System (CMS) e approfittai del fatto che nel 2008 erano in fase di “Candidate Recommendation” le Web Content Accessibility Guidelines (WCAG 2.0) da parte del W3C per parteciparvi come implementatore.
Ci riuscii. Il mio software CMS fu utilizzato da parte del W3C per dimostrare che era (ed è) possibile realizzare siti web (anche utilizzando strumenti semi-automatici) completamente conformi agli standard.
Grande soddisfazione senz’altro, ma principalmente ho imparato che è assolutamente possibile realizzare siti e applicazioni complesse conformi agli standard. Indubbiamente è più difficile, ma solo se di fatto si tende a farsi aiutare da strumenti che non tengono conto delle regole dell’accessibilità.
Costi/benefici? Tante persone che usano strumenti che li aiutano a vincere le loro disabilità possono ottenere l’accesso ad informazioni alla stessa maniera di chi invece è normalmente abile.
Non credo sia poco.
Bella testimonianza Alessandro: il problema principale è proprio la presa di coscienza. E’ importante rendersi conto delle conseguenze di certe scelte errate di programmazione: capito il problema diventa molto più facile seguire il metodo di lavoro corretto.
Nessuno si aspetta di vedere un web interamente accessibile dall’oggi al domani, ma sviluppare siti con un minimo di attenzione risolverebbe la maggior parte dei problemi.
Sono perfettamente d’accordo con te: nessuno di noi immagina che domattina si prema su un interruttore e tutto il web diventi accessibile, ma di sicuro mi incuriosisce tanto che, almeno nel nostro belPaese, i “professionisti” del web e le webAgency non badino affatto all’accessibilità…
Ho navigato un pò nel tuo sito con grande soddisfazione nel vedere quanto sia curato anche in dettagli veramente minimi e soprattutto quanto tu sia stato attento alle regole dell’accessibilità.
Sono convinto che nessuno ti abbia pagato per questo.
Sono convinto anche che come te (e me) siamo in molti che cercano di rendere il web (e non solo quello) più accesibile…
Ma allora com’è possibile che proprio i professionisti del web (e mi riferisco a chi trae profitto dal lavoro di webdesign) e le aziende non abbiano alcun interesse in questo?
Mistero… ho scritto un post sul mio sito proprio a proposito di tanti siti realizzati in occasione delle ultime regionali… ne ho valutati una trentina: nessuno era accessibile. Nessuno… boh…
Complimenti ancora per il tuo lavoro ma soprattutto per i contenuti! Che so perfettamente essere la parte più complessa di tutte!
Per sistemare il proprio sito con codice valido consiglio w3school, personalmente l’ho usato tantissimo ed è fatto strabene..
Salve Tom! Solo tu mi puoi aiutare! sono solo a 6 errori dal xhtml 1.0 transitional, però non riesco a risolvere un errore che mi impedisce la validazione (e che ho notato affligge recentemente anche il tuo sito), ovvero quello che i link contenenti & anzichè & amp . non possono essere validati… il problema è che io utilizzo dei link dinamici per la condivisione dei post, e non posso modificarli in tempo reale o a priori… la stessa cosa accade per alcune pubblicità che uso…
Sapresti propormi una soluzione per risolvere? Senza dover rimuovere questi elementi? Ad esempio un codice che consenta di bypassare il contenuto di un href almeno da parte del validatore, o comunque farlo interpretare in maniera valida… grazie in anticipo!
@Emanuele (#21): intanto grazie per la segnalazione, avevo fatto una modifica al template e non mi sono accorto dell’errore di validazione. Ho risolto sostituendo & agli & presenti.
Per quanto riguarda il tuo problema, dovresti usare URL Encode per trasformare i link nel formato corretto. Puoi provare ad usare la funzione urlencode in PHP.
Purtroppo utilizzo blogger e non dispone di php :( Comunque fortunatamente ora ho risolto quel tipo di errore, ma ne ho riscontrato un altro in diverse pagine. Ad esempio un post validato, quando viene a trovarsi in una pagina categorie insieme ad altri post mi crea problemi perchè il tag di chiusura delle immagini e dei non viene più mostrato e non riesco proprio a spiegarmi perchè o come risolvere…
Volevo poi chiederti: com’è che non metti XHMTL1 come doctype? Il tuo sito è pienamente conferme anche ai suoi standard :)
Scusami intendevo XHTML1.1
Scusami i post multipli, ma devo puntualizzare che ora ho indagato il template e praticamente tutte le immagini (intendo non div con sfondo etc) non presentano tag di chiusura (evintemente è perchè blogger è una piattaforma più html che xhtml). Tuttavia il validatore mi segnala l’errore nelle pagine di etichette, in presenza di post multipli… mi domando proprio perchè lì si ed altrove no…
Purtroppo su piattaforme esterne ci sono spesso dei limiti, e la validazione del codice non è una delle priorità. Non ti preoccupare troppo comunque di avere la validazione al 100%, un sito può essere accessibile anche senza il tag di chiusura delle immagini ;)
Per quanto riguarda la doctype preferisco utilizzare quella XHTML più diffusa, almeno finché HTML5 non diventerà uno standard di fatto.