JavaScript  »  Articoli  »  Effetti e controlli Javascript 

Creare attributi e DTD personalizzati

Se non volete inserire 'validate required email' nei nomi delle classi, potrete sempre aggiungere i vostri attributi personalizzati ai campi del form e usare una DTD personalizzata per validare comunque la pagina su cui li userete.

L'idea è stata divulgata da Peter Paul Koch su A List Apart e sul suo sito Quirksmode.

Il markup del nostro form sarebbe questo:

Questo è davvero un bel form. Niente campi nascosti, niente giochi con i nomi delle classi. Se un campo è obbligatorio aggiungiamo un required="true". Se bisogna fare un'ulteriore validazione aggiungiamo una cosa tipo validazione="tipo_di_validazione". L'attributo message, poi, ci dice dove sarà mostrato il messaggio di feedback. Molto semplice da usare, molto semplice da leggere.

Per validare il tutto secondo le specifiche, prendiamo la DTD del W3C e inseriamo queste righe:

Quindi colleghiamo la nostra DTD personalizzata alla nostra pagina, con questa dichiarazione del doctype:

Prima di prendere il codice e provarlo, cerchiamo di imparare qualcosa in più su quello stiamo facendo. Una DTD o Document Type Definition è quello che inseriamo all'inizio delle nostre pagine web per aiutare i browser a determinare la lista degli elementi che è legittimo usare nelle pagine stesse. In genere è così:

La DTD definita qui sopra, per esempio, ci dice che l'elemento (tag) <p> è valido mentre non lo è <newparagraph>. Quando validiamo una pagina, il codice viene verificato rispetto a quella DTD. Dal momento che required="true" è un attributo che noi usiamo per i nostri campi di testo, la DTD di sopra non considera valido il nostro markup. Creando una DTD personalizzata con nuovi attributi legittimi e validi, noi possiamo tranquillamente usare required="yes" oppure validate="zip".

Tecnicamente, però, non abbiamo bisogno di cambiare una DTD perché tutto funzioni. La pagina funzionerà bene aggiungendo attributi personalizzati e JavaScript può usare getAttribute() per accedere a quei valori. Cambiamo la DTD altrimenti la pagina non è valida, una cosa che è piuttosto disdicevole, come ho potuto notare. Per saperne di più sulla creazione di DTD personalizzate, c'è un buon articolo su A List Apart.

Ora, una DTD personalizzata può essere utile se vogliamo rintracciare un problema in fase di programmazione ed avviene un errore. Se la pagina è valida rispetto ad una DTD (anche la nostra) possiamo attribuire l'errore a JavaScript e non preoccuparci del fatto che possa essere un errore nel markup XHTML. Dal momento che il W3C raccomanda di usare le sue DTD per la validazione, le DTD personalizzate non saranno considerate corrette dal validatore del W3C perché il loro lavoro è quello di creare standard a cui tutti dovrebbero conformarsi. Si può vedere la lista delle DTD legali del W3C qui. Per verificare la validità di una pagina rispetto ad un doctype personalizzato, si può usare il validatore di YoYo Design.

Purtroppo, c'è un lato oscuro in tutto ciò. Anche se tecnicamente possiamo creare le nostre DTD, così facendo rendiamo il web un luogo piuttosoto confuso e rendiamo praticamente inutile la presenza di un W3C che crea standard per lo sviluppo web. Inoltre, una pagina così fatta non sarebbe a prova di futuro. Le cose potrebbero infatti andare per il peggio se un produttore di browser o il W3C decidessero un giorno che required="true" significa un'altra cosa. Se siete curiosi di approfondire l'argomento DTD e volete pensare con lo sguardo volto al futuro, leggete qualcosa sui namespaces.

Ora che si tratta di trarre le conclusioni, non è facile dire quale dei tre metodi visti nel corso dell'articolo sia il migliore. Personalmente, preferisco il metodo basato sulle classi per la validazione dei miei form. La soluzione è un buon bilanciamento rispetto alle funzionalità che cerco ed è piuttosto versatile. E penso che il sacrificio rispetto alla semantica sia roba di poco conto. Anche se gli attributi personalizzati e le DTD ad hoc hanno un certo appeal e sono roba da veri nerd, creare una DTD personalizzata non è cosa che digerisco molto, specialmente se penso che il W3C lavora sodo per fornirmi validi strumenti di cui ho bisogno per creare un sistema di validazione efficace e riusabile.

Approfondimenti

Questi articoli e qusti siti sono stati grandi risorse nella concezione e nella stesura di questa guida:

• Forms, usability, and the W3C DOM

• Separating behavior and presentation

• HTML & CSS : about class, id and style

• Behavioral extensions to CSS

• Using a custom DTD

• More About Custom DTDs

• Document Type Conformance

• W3C DoctypeDefinitions

• Namespace information

Altri articoli

Altre guide

Altre newsletter