Forum libero

Boh, la semantica dovrebbe competere a XML.

- Scritto da: alex.tg
> Mi spiegate come si imposta la "semantica"
> (qualunque cosa sia) di una pagina web con le
> tabelle?
>
>
> *va a mangiare*


<table>
<caption>Menu</caption>
<tr><th id="headermenu">Voce di menu</th></tr>
<tr><td headers="headermenu"><a...>Home page</a></td></tr>
<tr><td headers="headermenu"><a...>Chi siamo</a></td></tr>
<tr><td headers="headermenu"><a...>Dove andiamo</a></td></tr>
</table>

che verrà letto come:
Menu Voce di menu Link Home page Link Chi siamo Link Dove andiamo

Nel caso di link già cliccati dirà:
Menu Voce di menu Visitato Link Home page Visitato Link Chi siamo Link Dove andiamo

Per fare un lavoro esagerato puoi anche studiarti gli attributi css per browser vocali e fare un foglio di stile apposito, ma basta quanto ti ho detto per fare una cosa decente.
Come vedi una lista non ordinata produce codice più compatto, e non necessita di attributi speciali per ottenere una lettura decente, che senza attributi e senza caption leggerebbe Tabella Riga Cella etc. poiché proverebbe a descrivere senza aiuti quello che vede.

A quelli che ancora fanno i layout tabellari proverei a fargli ascoltare i loro siti letti da jaws o nvda.

- Scritto da: alex.tg
> Mi spiegate come si imposta la "semantica"
> (qualunque cosa sia) di una pagina web con le
> tabelle?
>
>
> *va a mangiare*

"Semantica" significa "significato".
Originalmente l'HTML è nato per rappresentare il signficato del contenuto di una pagina. Poi con le browser-wars fra IE e Netscape sono nate varie porcherie che mischiavano semantica (significato) con presentazione.
Poi si è notato che questo non solo rendeva i sorgenti estremamente difficili da capire (tutto era mischiato assieme) ma mischiando significato e presentazione era poi impossibile separarli lato client (con tutti i problemi che ne derivano).

Si è quindi deciso di *RIPULIRE* l'HTML, separando semantica da presentazione. Molti tag sono stati eliminati, altri sostituiti. Gli usatissimi tag I e tag B ad esempio vanno sostituiti (laddove la modifica non sia puramente estetica, nel qual caso si può mettere uno SPAN con attributi CSS appositi) con EM e STRONG, infatti "I" stava per "italic" e B stava per "bold" (chiaramente di "presentazione"), tag che NON rappresentano il SIGNIFICATO di ciò che contengono mentre EM (enfasi) e STRONG (forte) indicano proprio che il contenuto va inteso come qualcosa a cui si deve dare enfasi o "forza" perché trattasi di contenuto su cui l'utente deve soffermarsi o comunque di contenuto a cui l'utente deve dare particolare attenzione. Con i TAG I e B infatti non era possibile stabilire se si trattasse di un mero effetto estetico (puramente decorativo) oppure di una caratteristica importante del testo che racchiudevano mentre i tag EM e STRONG sono indubbiamente TAG che indicano che ciò che contengono è qualcosa di importante/particolare per l'utente.

Stessa cosa per tutti gli altri TAG. Le tabelle ad esempio si devono usare SOLO per i dati. Sono nate per questo. Hanno attributi appositi per rappresentare gruppi di dati, header, titoli, sommari dei dati, ecc. Se le usi a scopo di presentazione fai un macello che difficilmente si riesce a riparare lato client (l'esempio che portavo è quello di un browser testuale che non sa più in che ordine leggere le varie celle [per riga? per colonna?]).

In una pagina HTML ben fatta non solo si usano i tag in modo appropriato [le tabelle per i dati, strong e em lì dove servono, gli header per distinguere le sezioni, ecc] ma si cerca anche di rendere il sorgente più pulito eliminando tutto ciò che non serve al contenuto e separando il tutto in diversi file. Pertanto avrai il file HTML che contiene solo TAG HTML validi e correttamente utilizzati, il/i file CSS che viene usato dal browser per presentare all'utente il contenuto HTML, il/i file JS che contengono tutta la parte javascript per elaborare il contenuto/presentazione dinamico e così via.

In questo senso è anche sbagliato usare i tag "onClick" direttamente nell'HTML ma è preferibile usare gli addEvent dall'interno del file JS (per esempio con jQuery). Anche gli eventi devono tener conto dell'accessibilità.
Gli eventi (almeno quelli non puramente decorativi, ovvero gli eventi che avviano funzioni a solo scopo decorativo) infatti dovrebbero essere agnostici da un punto di vista dello strumento di input. Per esempio onMouseOver è chiaramente un evento legato al mouse, mentre onFocus no, e via dicendo.

In altre parole chi progetta la pagina non deve dare per scontato che esista un mouse, che esista un browser grafico, ecc. Purtroppo non tutti gli effetti si possono ottenere ancora in questo modo, ma è compito di chi sviluppa la pagina cercare di rendere la vita di chi la visita il più semplice possibile. Deve permettere all'utente di saltare ai menu, saltare al contenuto. Prova ad immaginare ad esempio come ti sentiresti se non ci vedessi e arrivassi su una pagina che conosci ma di cui non puoi, ogni volta, saltare il menu. Ovvero ogni volta il tuo browser vocale deve essere costretto a rileggersi il menu dalla prima all'ultima voce. Questo per ogni volta che ricarichi una pagina (immagina di essere su un forum).

Oppure immagina di essere un utente che usa un cellulare per navigare e che siccome tu hai usato delle tabelle per la presentazione non può fare a meno che continuare a scorrere in orizzontale oltre che in verticale le pagine perché non trova ciò che cerca e non si aggiusta nemmeno disabilitando il CSS (ovviamente non è il problema peggiore delle tabelle).

Oppure immagina di essere un tizio che non può muovere le mani e quindi non ha il mouse ma il bamba che ha progettato la pagina ha previsto che certo contenuto compaia solo con l'onMouseOver.

Oppure immagina di essere uno che per via di ciò che fa non può guardare il monitor ed è costretto ad ascoltare la pagina con delle cuffie e si ritrova continuamente con TAG I e B là dove non servono, usati solo a scopo decorativo, che però hanno l'effetto di modificare il tono e il volume della voce che ascolta, o ancora di avere il browser vocale che non sa in quale ordine scorrere le celle della tabella che hai usato per la presentazione e così deve farlo a caso, o ancora che deve ascoltarsi mezza pagina prima di arrivare a ciò che gli interessa quando se lo sviluppatore web avesse usato gli header (h1, h2, ecc) anziché i tab B per indicare i titoli ora lui potrebbe skippare da header in header in velocità e trovare velocemente la sezione che gli interessa.

Oppure ancora un utente esperto che usa un'applicazione WEB che però è senza access-key e lo costringono ad usare mouse, scorrimenti, ecc quando un semplice shortcut da tastiera gli permetterebbe di risparmiarsi un sacco di tempo.

Insomma, questi concetti hanno un perché, non sono un capriccio di web-developer con la puzza sotto il naso. Servono ad aiutare tutti. Anche i web-developer creando pagine più logiche, più pulite e più facili da mantenere.