mavimo

Come parlavamo negli articoli precedenti, ogni progetto ben organizzato deve fare uso di strumenti di analisi del codice per prevenire l'inserimento di bug, creazione di errori nell'interfaccia o più genricamente dei "problemi" all'utente finale. Abbiamo anche visto l'importanza di realizzare pagine valide, di conseguenza vediamo come automatizzare il test di validazione delle pagine del nostro sito per prevenire errori di questo tipo.

Chi di voi utilizza il validatore del codice (X)HTML del W3C per controllare che quello che generiamo sia codice pulito? Su le mani.

Troppe poche mani alzate, quindi come prima cosa abbituiamoci a controllare il codice. Alcuni buoni motivi? Bhè, innazitutto avere del codice validato ci permette di rendere il nostro contenuto più facilmente fruibile agli utenti che vi accedono con browser non convenzionali (per capirci screen-reader, browser per dispositivi mobili, ...); inoltre, nonostante alcuni SEO Expert dicano che il vantaggio è minimo, è comunque un vantaggio dal punto di vista S.E.O. e non per ultimo, essendo l'XHTML uno standard va rispettato.

Anche se nella fase iniziale stiamo particolarmente attenti a chiudere tag, a non inserire block element in inline element può capitare che, per riutilizzo del codice o per necessità impellenti, questo non venga controllato, proprio per aiutarci in questa fase di debug l'utizzo del validatore del W3C ci aiuta.

Quando si crea un sito spesso si cerca di renderlo valito secondo lo standard XHTML, se non altro perché questo migliora la visibilità dello stesso e aumenta il suo punteggio alla vista dei motori di ricerca. Per fare questo, il nostro sistema di pubbilcazione contenuti preferito non ha problemi, tuttavia ci sono alcune situazioni in cui può essere necessario andare a fare qualche piccola modifica per ottenere il risultato sperato.

Una di queste situazioni è la creazione di views in cui compare un field di tiipo fivestar, inquanto ciò va ad invalidare l'output generato, poichè si trovano dei div all'interno di span (block element in inline element) e il meccanismo di validazione immancabilmente ce lo segnala.

Vediamo come correggere questo problema.

Capita a volte di dover scriver documenti LaTeX che contengano stralci di codice dei più diversi linguaggi di programmazione, spesso risolta utile anche un evidenziazione della sintassi nel documento finale prodotto. Per fare questo esistono diverse vie:

1. inserire il pezzo di codice e formattarlo a mano in modo che rispetti esattamente le impostazioni che vogliamo noi.
2. appoggiarci a programmi esterni che facciano l'operazione appena descritta per noi.
3. usare una classe apposita per far fare l'operazione LaTeX

Presuppongo che se siamo qui vogliamo seguire la terza strada l'operazione è abbastanza semplice, si tratta solamente di scaricare il pacchetto listings, per esempio da ctan.org.

Sempre più spesso si sente parlare di accessibilità, degli enormi vantaggi che derivano dal suo utilizzo e sopratutto dalla necessità dei siti della PA di rispettare le regole che sono inserite nella famosa legge Stanca che obbligano a rispettare le direttive WAI (o per lo meno dovrebbe essere così, anche se vedendo alcuni siti.. ma lasciamo perdere, non voglio entrare in polemica).
Una tra le varie caratteristiche che devono essere presente nel sito è la necessità che i link (per lo meno i più importanti) abbiano l'attributo accesskey che permette ai diversamente abili di poter visitare il link senza doverlo selezionare con un mouse, ma semplicemente il tasto della tastiera corrispondente alla lettera che è stata assegnata.