Validare il codice è davvero necessario?
Validare il codice. É la mania di chi tende al perfezionismo e scrive il codice con un’accuratezza quasi maniacale quello di vedere il segno di spunta verde che sta ad indicare che il codice della pagina web appena sviluppata ha superato il controllo di validazione. Ma che cosa significa validare il codice? E perché conviene farlo? E ancora, è sempre necessario superare la validazione o ci possono essere delle eccezioni?
Andiamo con ordine, in quest’articolo cercheremo di rispondere a tutti gli interrogativi che ci siamo appena posti e con cui molti sviluppatori si trovano quotidianamente a combattere.
Che cosa significa scrivere codice valido o standard?
Iniziamo con il dire che cosa s’intende con l’affermazione “scrivere codice valido o standard“.
Un po’ di storia
Esiste un organismo internazionale senza scopo di lucro, composto da un gruppo di esperti che lavora da anni per standardizzare i linguaggi e le tecnologie per il Web. Tale organismo prende il nome di World Wide Web Consortium (o W3C).
Gli standard web
Il W3C nel corso degli anni ha definito degli standard che hanno il compito di definire la sintassi e i marcatori (tag) da impiegare nella costruzione di qualsiasi documento web. Di conseguenza seguendo questi standard si rendono i contenuti web più facilmente fruibili da tutti gli utenti a prescindere dal particolare browser utilizzato e in certi casi (se si sono rispettate anche le linee guida definite per l’accessibilità) anche dall’interprete in uso (ad es., browser normali, browser basati su dispositivi di sintesi vocale, telefoni cellulari, personal computer per automobili, ecc.)
Come scrivere codice valido?
Abbiamo appena detto che scrivere codice valido significa rispettare i relativi standard definiti dal W3C. Ma come scrivere codice valido?
Quando si sviluppa una pagina web, la prima cosa che si indica nel documento è il Doctype (Document Type Definition, Definizione del Tipo di Documento) che serve appunto a comunicare al browser con quale linguaggio di markup è redatto il documento.
Per scrivere codice valido bisogna accertarsi che i marcatori (tag) e gli attributi adoperati rispettino alla lettera la sintassi definita nel Doctype dichiarato all’inizio del documento.
Una volta realizzato il nostro documento web, come possiamo verificare di aver scritto codice standard?
Validare il codice: Come accertarsi di aver scritto codice valido?
Per controllare la validità del proprio codice si possono utilizzare dei software – come il Markup Validation Service offerto dal W3C – che controllano in modo automatico la correttezza e il rispetto degli standard del documento che si desidera sottoporre a verifica.
Il validatore messo a disposizione dal W3C, oltre ad indicare l’eventuale numero di errori commessi nella redazione del documento web, fornisce un valido aiuto per la correzione degli stessi segnalando la riga di codice dove è presente l’errore e descrivendone anche la tipologia. Ovviamente per capire e correggere i possibili errori segnalati bisogna comprendere il codice in modo da poter modificare all’occorrenza il codice sorgente del documento.
Una estensione per Firefox per validare il codice in tempo reale
Validare il codice del proprio documento web sul sito del validatore offerto dal W3C comporta qualche complicazione, per esempio non è possibile monitorare la validazione durante lo sviluppo del codice, a meno che non si carichi il documento web sul validatore del W3C ad ogni nuova riga di codice redatto, con conseguente enorme perdita di tempo.
Volendo è possibile risolvere questo inconveniente installando HTML Validator, un’estensione per il browser Open Source Firefox che mette a disposizione tutti gli strumenti necessari per la validazione delle pagine web direttamente sulla finestra del browser. Il plugin è basato su due algoritmi sviluppati dal W3C, Tidy e OpenSP.
Utilizzando questa estensione ogni volta che si naviga su qualsiasi documento web viene mostrato il risultato della validazione del documento direttamente nella finestra del browser, in fondo a destra, come mostrato nella foto sopra. In questo modo diventa molto più semplice validare il codice dei propri lavori.
Che cosa comporta scrivere codice valido?
Ovviamente scrivere codice standard comporta dei vantaggi, tra le altre cose il documento web sarà più facilmente fruibile da tutti gli utenti a prescindere dal particolare browser utilizzato e non è da trascurare anche il fattore “indicizzazione”, poiché gli spider dei motori di ricerca potrebbero trovare grosse difficoltà nell’indicizzare correttamente documenti web contenenti determinati errori di markup.
Un codice validato è sempre sinonimo di buon codice?
Attenzione però a non farsi ingannare dalle parole “validato” e dal risultato positivo restituito dal validatore del W3C.
Il codice di un documento web può anche essere validato ma ciò non presuppone che comunque questo debba considerarsi a priori un buon codice perché ci sono diversi fattori che un validatore, trattandosi di un software, non può valutare correttamente.
Per esempio i documenti web che soffrono di “classite” o “divite” possono anche essere validati dato che se i marcatori utilizzati per la realizzazione del documento web sono stati impiegati correttamente il validatore restituirà comunque come risultato un codice validato. Questo però non significa che è stato scritto un buon codice.
Facciamo subito un esempio pratico per cercare di comprendere meglio quello che stiamo dicendo:
<div id="titolo-grande">
<h2>Titolo argomento</h2>
</div>
<div id="navigazione">
<ul>
<li>item 1</li>
</ul>
</div>
<div class="paragrafo-rosso">
<p>questo è un paragrafo di colore rosso</p>
</div>
Il codice scritto sopra se fosse sottoposto al controllo del validatore sarebbe valido poiché tutti i marcatori (tag) definiti dalle linee guida del W3C sono stati utilizzati in modo corretto. Ma come dicevamo, questo codice non può essere considerato un codice ottimizzato perché utilizza diversi elementi di cui si potrebbe benissimo fare a meno.
Ecco un esempio di codice ottimizzato che produce il medesimo risultato del precedente:
<h2 id="titolo-grande">Titolo argomento</h2>
<ul id="navigazione">
<li>item 1</li>
</ul>
<p class="paragrafo-rosso">
questo è un paragrafo di colore rosso
</p>
Come puoi vedere in questo banalissimo esempio per scrivere solo tre elementi (titolo, lista e un paragrafo) di un ipotetico documento web il primo listato utilizza undici righe di codice mentre il secondo solo sette. Questo è l’errore tipico commesso dagli editor visuali, i quali riempiono il codice di un documento web di molti elementi assolutamente inutili.
Con questo esempio abbiamo dimostrato che non sempre quindi scrivere codice valido è sinonimo di scrivere buon codice.
É sempre necessario superare la validazione?
Partendo dal presupposto che per uno sviluppatore riuscire a validare il codice che realizza è di solito una soddisfazione personale oltre che una sfida con se stesso, è sempre necessario superare la validazione?
Quel segno di spunta verde che indica un codice validato è generato da un software in conformità al risultato fornito da un algoritmo sviluppato per verificare la correttezza del codice da esaminare. Considerando che un software ha delle regole piuttosto ferree può capitare che il codice di un documento web, seppur sviluppato in modo impeccabile, per una qualsiasi banalità non prevista dall’algoritmo di validazione possa essere non validato.
Facciamo subito un esempio pratico: di default le API di Twitter si basano su di un semplice div – da aggiungere al tuo codice HTML – contenente una lista non ordinata (<ul></ul>) in cui successivamente verranno inseriti i vari tweet caricati tramite una funzione javascript.
<div>
<ul id="twitter_update_list"></ul>
</div>
Se tentiamo di integrare il nostro account Twitter all’interno di un documento web utilizzando queste API, quando sarà il momento di validare il codice riceveremo un messaggio di errore poiché la lista non ordinata non contiene nessun elemento (<li>…</li>). Anche nel caso in cui avessimo sviluppato l’intero codice del documento web in modo perfetto, questo non sarebbe validato.
Può un errore del genere compromettere la validità dell’intero lavoro che abbiamo realizzato?
Paradossalmente potremmo trovarci in una situazione del genere:
- un documento web è validato nonostante sia stato sviluppato con grossi problemi di “divite” e “classite” o addirittura impaginato con tabelle;
- un documento web che – anche se sviluppato in modo impeccabile – con l’integrazione di un elemento di terze parti (come potrebbe essere la Google Maps o il fan box di Facebook, per fare un esempio) si ritrova ad avere un codice non validato.
Quale dei due documenti riterresti più valido?
I casi estremi di validare il codice
Concludo questo articolo con un’ultima riflessione: mi è capitato di vedere qualcuno che nonostante avesse scelto un doctype di tipo Strict per lo sviluppo del proprio documento web poi perdeva ore nel trovare dei metodi alternativi nel tentativo di validare il proprio codice che utilizzava attributi non più consentiti, come per esempio l’attributo target.
Se abbiamo la necessità di utilizzare l’attributo target, perché scegliere un doctype di tipo strict?
Adesso a te la parola: mi piacerebbe sentire il tuo parere sui vari quesiti sollevati nell’ultima parte di questo articolo.
P.s. Il problema dell’API di Twitter è stato riportato solo per fini didattici, in realtà per validare il codice, il problema può essere risolto semplicemente aggiungendo un elemento della lista contenente uno spazio vuoto: <li> </li>.
L'autore
Articoli correlati
Potresti essere interessato anche ai seguenti articoli:
42 commenti
Trackback e pingback
Non ci sono trackback e pingback disponibili per questo articolo
Complimenti x l’articolo chiaro e sicuramente utile ai più inesperti.L’unico punto su cui sono in disaccordo e’ quello in cui nell’esempio isolate l’ fuori dal div. L’ho già visto fare ma oltre che scomodo lo trovo concettualmente poco sensato per i menù tant’è che in html5 hanno introdotto il tag navigabili che sara’ pure un tag semantico ma certamente utilizzabile a fini stilistici. No?
ciao gleenk, grazie intanto per i complimenti.
nel tuo commento credo che wordprewss abbia “inghiottito” un tag utilizzato nell’esempio di cui volevi discutere e su cui non ti trovi d’accordo.
prova a riscriverlo all’interno del tag
...che in questo modo non dovrebbero esserci problemi e se capisco meglio a cosa ti riferisci provo a dirti il mio pensiero in merito.il tag era “ul” :)
credo di aver capito allora cosa intendi, se posso chiederti, perchè lo trovi scomodo?
riguardo il punto di vista concettuale i valori che attribuiamo a id e classi non hanno nessun valore semantico, uno screen-reader leggerà il contenuto nello stesso identico modo sia nel primo caso (citato dall’esempio in questione) che nel secondo. allora perchè appesantire la dimensione del documento scrivendo righe di codice in più ed inutili? zeldman suggeriva questo già dieci anni fa.
html5 ha introdotto nuovi tag proprio per dare un valore semantico ad elementi che con il tempo sono diventati quasi degli standard dei documento web, come la testata, il footer, la navigazione, la sidebar, ecc…
Lo trovo scomodo perchè spesso mi sono ritrovato ad avere la necessità di un livello superiore da modificare e mi è venuto a mancare. Parlo di menù ovviamente (nel contenuto non ha senso concordo :)). Per quanto riguarda il valore semantico infatti è quello che ho detto anche io, ma è sempre un tag e può di conseguenza essere stilizzabile. imho ^^
Ciao Nando, complimenti per l’articolo, offre buoni spunti di riflessione.
Sono perfettamente daccordo sul fatto di validare il codice e di scriverlo “pulito” (sai come la penso a riguardo)…Mi fa un po’ rabbia quando trovo qualcuno che viene a dirmi che la validazione è solo un vezzo personale e non è necessaria perché (cito testualmente) “anche i grandi siti come google o facebook hanno errori di validazione”…..non mi sembra un’argomentazione valida da parte di uno che si (auto)definisce un web designer di successo…..
ciao tizi, grazie intanto per i complimenti.
per chi si trova a sviluppare il codice quotidianamente credo che imparare a scrivere “codice standard” è il primissimo passo da compiere perchè offre notevoli benefici. in molto casi a giovarne sono proprio l’accessibilità del sito e la compatibilità con i diversi browser.
ma quello su cui volevo far riflettere è che non sempre avere un codice validato e sinonimo di aver scritto un buon codice standard e, viceversa, non sempre un codice non validato è sinonimo di “cattivo codice” e a tal proposito ho fatto due esempi piuttosto banali per far capire meglio cosa intendo.
tu su questo punto cosa ne pensi?
quando si tratta di errori banali che non influiscono sulla qualità del codice e soprattutto che non dipendono dallo sviluppatore ma più che altro da script forniti da terze parti, è corretto intestardirsi nella validazione del codice? c’è un vero e proprio vantaggio effettivo o si tratta di pura soddisfazione personale?
Sono perfettamente daccordo con te sul fatto che un codice valido non sia per forza un buon codice e viceversa.
Ovvio che le conoscenze di un web designer vanno oltre lo scrivere codice valido, il soggetto in questione deve saper anche scrivere buon codice, che rispetti il più possibile i criteri di usabilità, accessibiltà, e che sia anche performante (perché creare un sito che si carica in ‘n’ minuti a mio parere è non è professionale).
Se si parla di snippet di terze parti che impediscono la validazione del codice ci sono due strade: lasciare il codice non validato (o meglio: sorvolare sugli errori di validazione SOLO per quanto riguarda il codice “esterno”), oppure, se si è testardi e sprezzanti del pericolo, incaponirsi per ottenere una soddisfazione personale che (come scrive Maurizio più in basso nei commenti) non è mica roba da poco; la scelta in questo caso è soggettiva.
Io in ogni caso punterei sulla seconda soluzione :) (anche se ancora non ho trovato il tempo per correggere gli errori del like-box di facebook sul sito del mio gruppo)
mi trovi perfettamente d’accordo!
per i perfezionisti questo vale più di ogni altra cosa =)
Usare il doctype di tipo strict o di tipo target è un esigenza del sito. Molte volte mi tocca o giocare con javascript per evitare errori di validazione ( solitamente per i plugin sociali ) oppure cercare qualche escamotagè con i css.
Evito spesso e volentieri di cambiare il formato in base a widget o componenti extra, oltre se non ci ritroviamo davanti a qualche grosso errore.
Per il resto la validazione è uno dei componenti fondamentali per l’indicizzazione non tanto per il fatto che rendono la pagina più pulita… ma per il fatto che la rendono più veloce.
Infatti google ha deciso dall’anno scorso di mettere tra i tanti fattori che influenzano l’indicizzazione anche la Velocità di caricamento.
Matt Cutts che lavora nel gruppo Search Quality Google ha detto queste parole:
che se un sito ha buoni contenuti verrà lo stesso indicizzato anche se non ha una sintassi corretta. Questo in virtù che per google sono di fondamentale importanza i contenuti e poi tutto il resto.
Quindi fatto questo ragionamento potremmo pure utilizzare una sintassi confermata di doctype ( come quella ridotta di html5 ) che ci rende il tutto più veloce ( pensate che esistono al mondo più di 150 doctype differenti ) rispettando lo stesso tutte le notifiche di validazione di W3C.
Scusate se mi sono dilungato volevo dire la mia :D
ciao rocco, grazie per essere passato.
tu dici:
credo tu intendessi dire: utilizzare il doctype di tipo “strict” o “transitional” perchè non esiste nessun doctype di tipo target.
e io ti chiedo, quali sarebbero queste esigenze del sito che ti portano all’utilizzo di un doctype di tipo “strict” piuttosto che “transitional”? in cosa ne beneficia il sito?
come ho fatto vedere in un esempio non sempre codice validato vuol dire codice ottimizzato. potrei avere un documento web pieno zeppo di tag inutili (come spesso accade con il codice generato in modo automatico dagli editor visuali) e ritrovarmi con un codice si validato, ma con una dimensione del documento magari doppia a quella dello stesso documento sviluppato con codice ottimizzato. quindi “codice validato” non significa sempre pagina più veloce, non sei d’accordo?
per quanto riguarda lo sviluppo di documenti web i doctype più utilizzati sono questi, e nel caso di un sito web classico i tipi di doctype sono otto (tre per l’html 4.01, tre per l’xhtml 1.0 e due per l’xhtml 1.1).
perchè utilizzare un doctype non ancora standard di un linguaggio che è ancora in fase di bozza? sono d’accordo sul fatto di iniziare a sperimentare ma credo che al momento sia più corretto farlo nell’ambito di progetti personali piuttosto che su lavori commerciali. potrebbero cambiare ancora molte cose da qui a quando html 5 sarà reso ufficiale. poi che si fa, eventualmente si vanno a cambiare i cento siti che abbiamo già realizzato in html 5?
@nando ovviamente qua parliamo tra persone che fanno questo lavoro e non profani del web ^_^
1) Scusa se ho sbagliato a scrivere target :oops:
2) parlando tra web designer sotto intendevo il significato di codice pulito e snello
3) usare un doctype non quel doctype non ancora standard , dopo tanti esperimenti fa la differenza a livello di velocità, e siccome google desidera contenuti “content is king” e velocità preferisco mettere questo doc e non gli altri.
fidati ormai quegli standard rimangono così ;) , non ti vanno a cambiare di certo il doctype :D
Ciao Nando, grazie per l’articolo molto interessante!
Io faccio sempre il controllo del codice, ma nell’articolo hai parlato solo della validazione del contenuto, non dei css..
Di questi cosa ne dici? Ci sono dei vantaggi anche in questo caso? o è solo una fissazione? :)
Vorrei precisare che il famoso HTML Validator è disponibile solo per Windows :( usando un mac quindi è tutto un po’ più macchinoso, ma si fa lo stesso
Al momento attuale validare i CSS secondo me non ha molto senso, soprattutto se si fa un uso massiccio di CSS3, spesso siamo costretti ad usare prefissi che in futuro sparirarnno quindi credo che questo aspetto al momento venga totalmente trascurato. Secondo me ovvio :)
ciao eli, in parte ti ha già risposto gleenk.
un altro fattore secondo me che rende la validazione del codice css un po’ meno importante è che molti errori di sintassi commessi nel foglio di stile (come per esempio la banale dimenticanza di un “;”) rendono lo stesso inutilizzabile e quindi vengono corretti dallo sviluppatore già in fase di sviluppo senza nemmeno la necessità di verificare con un validatore.
un po’ meno importante però non significa che è del tutto inutile, anzi, soprattutto per chi è alle prime armi validare il CSS e verificarne gli errori commessi può essere un ottimo modo per migliorarsi e comprendere ancora meglio l’uso dei fogli di stile.
Per lo sviluppo potresti valutare l’installazione di Firefox sul tuo mac.
Grazie delle risposte! :)
cmq uso già firefox con i relativi plugin, dicevo solo che HTML Validator funziona solo su FF per Windows e non FF x mac. :)
oh cavolo, non pensavo.
chiediamo aiuto allora ai nostri lettori che sviluppano codice su piattaforma mac: utilizzate qualche strumento particolare per la validazione del codice di un documento web in tempo reale?
eli, abbiamo posto la domanda sul nostro gruppo facebook e stanno già arrivando le prime risposte. vedi se trovi qualcosa d’interessante che può fare a caso tuo.
giacinto e domenico, sulla pagine facebook dicono che non c’è nessun problema ad installare il plugin su firefox nella versione per mac.
prova a scaricare e installare la versione che fa per te e facci sapere se risolvi.
Fantastico!
Grazie 1000 a tutti! :)
provo subito :)
Spesso il problema nella validazione è dato da codici “esterni” al sito.
Sopra Rocco parla dei plugin sociali (sarebbe interessante approfondire come bypassa il problema ;) ) , ma non scordatevi delle affiliazioni…
Un saluto dal DON
@DonClaudissimo spero non sia considerato spam ^^
E’ il mio articolo più letto del mese http://www.ebug.it/validare-plugin-sociali-di-facebook-w3c/ e parla di come validare i plugin sociali di facebook :D
ciao DON, benvenuto su yiw.
sono assolutamente d’accordo, se s’impara a scrivere codice standard gli unici problemi che si possono riscontrare sono solo quando si cerca di integrare sulle proprie pagine codici fonirti da terze parti.
sulle affiliazioni invece non ho capito bene a cosa ti riferisci, intendi gli url forniti da questi siti che spesso hanno dei problemi di validazione con le “&”?
@Nando
Si , mi riferisco alle “&”.
Personalmente sono per il codice pulito e validato e quando , anche in fase di test di caricamento tramite tool ad esempio, trovi errori di validazione su codici di terze parti mi casca il mouse :D
Un saluto dal DON
Questo é il motivo per validare il codice:
La visione di questa cosa nell’angolo in basso a destra dello schermo mi provoca un senso di appagamento indescrivibile. Un po come quando scrivi un centinaio di righe di codice php di getto, lo provi, e funziona al primo colpo. Ecco, una sensazione del genere.
ecco, un perfezionista come te non poteva rispondere diversamente… quando il codice diventa poesia =)
Io in generale non sono un “fanatico” del w3c anche se ci provo sempre a validare i miei documenti.
La cosa che tuttavia ritengo errata è accostare gli aspetti legati alla validazione al SEO.
Tale opinione l’ho maturata per esperienza personale: quando realizzai il mio primo sito (da neofita totale) questo aveva una struttura tabellare, formattava i testi con , i senza chiusura, un paio di iframe nella sidebar, etc. etc. Oggettivamente una schifezza di markup (un centinaio di errori secondo il validatore!!).
Inoltre non conoscevo regole SEO particolari (eccetto title, description, keywords, segnalazione a google del sito).
Ebbene: nel periodo in cui curai questo sito questo raggiunse tra i 20000-30000 accessi unici mensili di cui il 75% (circa) da google.
Oggi a seguito di nuove esperienze gli aspetti del markup che curo maggiormente ai fini dell’indicizzazione sono gestione dei tag , , primo paragrafo , cercando di posizionare i contenuti il più in sù possibile nel codice.
Inoltre sono in attesa di verificare html5 cosa porterà di nuovo in ambito SEO (ho letto qualcosina ma desidero verificare con mano).
Ad oggi, sulla base di esperienze dirette, alla domanda “che importanza ha la validazione rispetto al SEO?” tenderei a rispondere “poca”.
ciao oly, direi che yeswebcan ti ha già risposto in modo esaustivo e che mi trova perfettamente d’accordo.
PS: ops non sapevo che vi è era lo strip_tags (caspita… in un sito che parla di questi argomenti strip_tags non ci vuole però… Dai Maurizio mettici mano te con un htmlspecialchars()…)
EDIT COMMENTO PRECEDENTE:
… formattava i testi con font, i br senza chiusura…
…gli aspetti del markup che curo maggiormente ai fini dell’indicizzazione sono gestione dei tag h1, h2, primo paragrafo p,…
@Oly
mi permetto di rispondere io anche se non sono dello staff di yiw, ma la tua domanda affronta un argomento a me molto a cuore.
Partiamo dal presupposto che negli ultimi anni e sopratutto nell’ultimo periodo gli algoritmi di Google sono cambiati tantissimo, c’è maggior coscienza lato Seo da parte dei webmaster e maggiore concorrenza. Ecco perchè prendere come esempio i risultati ottenuti qualche anno fa nonostante la schifezza di markup (come l’hai definito tu :) ) con i risultati attuali credo sia sbagliato, anche perchè visto che avevi conoscenze Seo limitate con un paragone del genere potremmo mettere in discussione oltre alla validazione l’importanza di tanti altri parametri.
Riguardo alla domanda:
Tenderei a darti ragione, sopratutto perchè Google è certamente un cattivo esempio… Infatti se hai mai provato ad effettuare la validazione di Google è lui stesso il primo a non rispettare la validazione e a non chiudere i tag, questo perchè non chiudere certi TAG e non usare identazione gli permettono di ottenere pagine con il minor numero di caratteri possibile. In questo modo si dovrebbe velocizzare la visualizzazione e diminuire la banda Internet utilizzata.
Tuttavia ritengo che indirettamente avere codice validato “può” portare vantaggi per il posizionamento. Validare il codice è un aspetto fondamentale per l’ACCESSIBILITA’ …. I nostri browser spesso passano sopra gli erori di validazione e tendono a visualizzare bene i nostri layout nonostante gli errori, ma possono fare lo stesso altri tipi di supporti, tipo gli screen reader rendendo così difficile o impossibile la navigazione da parte degli utenti disabiili.
Quando ho iniziato ad affacciarmi al mondo Seo non esisteva “visualizza come Googlebot” negli strumenti per webmaster e per vedere grosso modo cosa vedeva Google nei miei siti usavo il browser Lynx. Questo mi ha aiutato molto per capire l’importanza di accessibilità e validazione e a considerare Google ahimè come un utente che va aiutato nel modo più preciso possibile ad accedere ai nostri contenuti senza farlo incappare in errori.
Ecco perchè ritengo sia importante per l’accessibilità e anche per il posizionamento la validazione del codice.
Scusami se mi sono dilungato ;)
ciao sà, grazie per il prezioso intervento.
mi trovi perfettamente d’accordo su tutto quello che hai detto!
Complimenti x post..
grazie mille e alla prossima!
Ho letto da poco “Sviluppare con gli Standard Web” di Jeffrey Zeldman e anche se ho imparato a conoscere quest’argomento devo dire che una ripassata non fa mai male, grazie mille :P
Quel libro è stupendo….da consigliare caldamente a tutti, professionisti e non
ciao stefano, grazie a te.
mi trovi perfettamente d’accordo sul libro di jeffrey zeldman, direi che qualsiasi persona si avvicini a questo campo debba assolutamente leggere questo libro, sono le basi indispensabili per lavorare in modo serio e professionale. come mi sentirei di consigliare la lettura anche di quest’altro testo: web usability 2.0. l’usabilità che conta di jacob nielsen.
sui libri che un web designer dovrebbe leggere assolutamente presto ho intenzione di scriverci un articolo, è un argomento molto sentito.
Dopo aver letto l’articolo ho provato a installare HTML Validator su Firefox Mac e non ho avuto alcun problema
grazie domenico per la tua tempestiva risposta e conferma che il plugin funziona correttamente anche su Firefox Mac!
Mi spiego meglio su ciò che ho detto in precedenza.
Se mi si chiede se la validazione è importante… la mia risposta è nettamente sì… soprattutto per gli aspetti legati al cross-browser e all’accessibilità in genere.
Ma, io avevo concentrato l’attenzione sull’importanza che la validazione aveva per quel che concerne l’indicizzazione seo: faccio un esempio che mi capita di vedere in molti siti. Pensiamo ad una pagina perfettamente validata con:
- header
- slideshow (strutturata con ad esempio div/ul-li)
- sidebar a sinistra
- contenuti
- footer
con un markup disposto come in questo elenco.
Questo markup validato si presta ad essere indicizzato bene? Bhè io ci andrei cauto… o quantomeno farei dei correttivi come ad esempio:
- la slideshow la caricherei con ajax (dato che spesso non ha contenuti di cui voglio l’indicizzazione ma ha scopi più che altro “estetici” e/o si ripete in tutte le pagine);
- la sidebar nel markup la posizionerei dopo i contenuti.
Quindi quel “poco” a stava a dire che non sempre markup validato coincide con markup ottimizzato per google.
Io per farmi un’idea di come google “vede” le mie pagine uso questo tool:
http://cgi.w3.org/cgi-bin/html2txt
Una dei paragrafi dell’articolo di Nando era: “Un codice validato è sempre sinonimo di buon codice?”
Il mio (umilissimo) intento era di declinare la domanda in: “Un codice validato è sempre sinonimo di buon codice ai fini della validazione?”. E avevo dato la mia opinione, tutto qui.
E’ la prima volta che intervengo in vostre discussioni, generalmente evito probabilmente per un motivo stupido ma stavolta desidero dire anche io la mia.
Sono abituata a lavorare con xhtml 1.1 e i css 2.1. Grazie all’utilizzo della validazione di entrambi ho potuto imparare di più e questo mi ha portato col tempo ad averne una buona padronanza, non dico ottima perchè sono dell’idea che non si è mai finito di imparare nella vita, anche quando si crede di essere arrivati.
Condivido le idee di Nando sul fatto che non sempre codice validato è sinonimo di buon codice e contrario e poi…html5 e css3, finalmente qualcuno che la pensa come me, e di Maurizio che prova un piacere enorme nella positività della validazione. Sarà che sono fissata e abituata sin dagli inizi a certi canoni.
Senza scordare che in più occasioni la validazione mi ha permesso di correggere il codice di terze parti, vedi plugin ad esempio per cms.
Quindi alla fine per me è sempre stato un bene e non una perdita di tempo.
Ciao a tutti
la validazione è importantissima, non dimentichiamo che google e come un bambino dobbiamo darli il codice chiaro pulito e senza errori in modo che lui possa interpretarlo correttamente.
Grazie
hey there and thank you for your information – I’ve definitely picked up anything new from right here. I did however expertise several technical points using this site, since I experienced to reload the site many times previous to I could get it to load properly. I had been wondering if your web host is OK? Not that I’m complaining, but sluggish loading instances times will often
affect your placement in google and can damage your high-quality score if ads and marketing with Adwords.
Anyway I’m adding this RSS to my email and can look out for a lot more of your respective exciting content. Make sure you update this again soon.