Extensible HyperText Markup Language

XHTML.com recommends: PSD to HTML Slicing Service and PSD to HTML by W3 Markup. see your link here

X/HTML 5 contro XHTML 2

La competizione per diventare il prossimo linguaggio di markup del Web si infiamma. Questo articolo intende dare un'occhiata a cosa è cool, e cosa invece non lo è, delle diverse tecnologie.

Generalità

Nonostante HTML 4 e XHTML 1 abbiano svolto bene il loro compito da tempo, queste specifiche contengono alcuni errori. Per venire incontro alla domanda dell'utente che richiede applicazioni rich Web-based, per generare migliori risultati di ricerca, e per creare un Web più accessibile a tutte le persone con qualunque abilità e che usi qualsiasi tipo di dispositivo, tali specifiche hanno bisogno di essere aggiornate o sostituite.

Vi sono due specifiche che aspirano a diventare il successore di HTML 4 e XHTML 1. Queste sono l'XHTML 2.0 e le Web Applications 1.0, denominate più genericamente X/HTML 5.
Queste specifiche derivano da differenti approcci e porteranno conseguenze diverse in termini di sviluppo futuro di linguaggio di markup.

XHTML 2 è un grosso passo avanti rivolto alla creazione di un'architettura che diventerà il linguaggio di riferimento per molte altre tecnologie del W3C già in uso o che sono in progress. XHTML 2 è basato esclusivamente su XML, una tecnologia che in molti reputano in grado di portare il Web al suo pieno potenziale. XHTML 2 si concentra su come il markup dovrebbe essere usato, piuttosto che come il markup viene attualmente usato.

X/HTML 5 è un'estensione di HTML 4 e XHTML 1. E' un passo avanti successivo ed incrementale, piuttosto che un grosso passo avanti, sullo stile dell'XHTML 2. Lavorando entro i confini di HTML 4 e XHTML 1, X/HTML 5 presenta soluzioni più intelligenti per riparare ad alcuni errori presenti in HTML 4 e XHTML 1. X/HTML 5 può essere servito sia come HTML che come XML. Così, diversamente dall'XHTML 2, X/HTML 5 è molto influenzato dall'attuale stato dell'arte (tecnologie dei browser Web, etc.) e dall'uso che si fa ora del markup.

Sia X/HTML 5 che XHTML 2 sono ancora in una fase di bozza di lavoro. Sono attesi ancora cambiamenti in entrambe le specifiche, e passeranno ancora alcuni anni prima che esse possano diventare raccomandazioni. Questo articolo prende in considerazione le bozze di lavoro alla data di Febbraio 2007.

XHTML 2

Le cose di XHTML 2 che sono cool

Liste di Navigazione

Le liste di navigazione sono state ideate per creare menù di navigazione. Le liste di navigazione sono definite utilizzando un elemento nl e devono contenere un elemento label che contiene il titolo della lista. Per esempio:

  1. <nl>
  2. <label>You are here:</label>
  3. <li href="/">Home</li>
  4. <li href="/products/">Products</li>
  5. <li href="/products/widget/">Widgit</li>
  6. <li>Features</li>
  7. </nl>

Le liste di navigazione sono cool!

Miglioramenti alle Liste di Definizione

Le liste di definizione (elemento dl) definiscono un termine (elemento dt) ed una definizione (elemento dd). Un termine può avere multiple definizioni, mentre termini multipli possono avere la stessa definizione. XHTML 2 introduce la possibilità di raggruppare termini e definizioni utilizzando l'elemento di. Questo aiuterà a rendere chara la relazione fra un termine e la sua definizione o le sue definizioni e a generare un markup che è più facile da leggere. Per esempio:

  1. <dl>
  2. <di>
  3. <dt>center</dt>
  4. <dt>centre</dt>
  5. <dd>a building dedicated to a particular activity</dd>
  6. <dd>a point equidistant from its ends</dt>
  7. </di>
  8. <di>
  9. <dt>key</dt>
  10. <dd>metal device used to open a lock</dd>
  11. <dd>pitch of the voice</dd>
  12. </di>
  13. </dl>

I miglioramenti alle liste di definizione sono cool!

Un attributo href può essere aggiunto ad ogni elemento per trasformarlo in un collegamento. Per esempio:

  1. <q href="http://en.wikipedia.org/wiki/Neil_Armstrong">That's one small step for man, one giant leap for mankind</q>

E questo è molto cool!

acronym non c'è più

Molti autori si confondono su come dovrebbe essere utilizzato l'elemento acronym. XHTML 2 utilizzerà l'elemento abbr per rappresentare qualsiasi tipo di abbreviazione, compresi quindi anche gli acronimi.

E questo è cool!

b, i, small, big, tt, font e basefont non ci sono più

L'XHTML 2 dice addio a questi elementi, utilizzati a scopo di formattazione. L'elemento font, in particolare, non è stato ben utilizzato in passato e ha scoraggiato gli autori all'utilizzo di markup appropriato.

E questo è molto cool!

iframe non c'è più

L'elemento iframe, che ha sempre portato problemi agli utenti di tecnologie assistive, non è più previsto.

E questo è cool!

Nuovo modo di applicare gli heading

Gli heading rappresentano le costruzioni più importanti quando si realizzano pagine Web accessibili. Ancora nessuno utilizza gli heading correttamente, poiché la costruzione con numeri degli heading (elementi da h1 a h6) è difficile da visualizzare per la maggioranza delle persone, e sono quasi impossibili da gestire correttamente con editori WYSIWYG. Fisicamente, gli heading numerati rappresentano delle costruzioni lineari (elementi fratelli) che sono utilizzati per organizzare logicamente i dati in una gerarchia. Così, come si evince dall'esempio seguente, è necessario fare uno grosso sforzo per visualizzare la struttura gerarchica del contenuto.

  1. <h1>...</h1>
  2. <p>...</p>
  3. <h2>...</h2>
  4. <p>...</p>
  5. <h2>...</h2>
  6. <p>...</p>
  7. <h3>...</h3>
  8. <p>...</p>
  9. <h4>...</h4>
  10. <p>...</p>
  11. <h3>...</h3>
  12. <p>...</p>
  13. <h2>...</h2>
  14. <p>...</p>

Il nuovo modo di applicare gli heading, invece, utilizzando l'elemento h con l'elemento di raggruppamento section, rende molto più semplice recuperare le relazioni gerarchiche.

  1. <h>...</h>
  2. <p>...</p>
  3. <section>
  4. <h>...</h>
  5. <p>...</p>
  6. <h>...</h>
  7. <p>...</p>
  8. <section>
  9. <h>...</h>
  10. <p>...</p>
  11. <section>
  12. <h>...</h>
  13. <p>...</p>
  14. </section>
  15. <h>...</h>
  16. <p>...</p>
  17. </section>
  18. <h>...</h>
  19. <p>...</p>
  20. </section>

L'elemento h è molto cool!

Miglioramenti nella scrittura di esempi in codice

L'elemento blockcode può essere usato al posto di pre e code per scrivere blocchi di codice. Per esempio:

  1. <blockcode>
  2. function get_random_name() {
  3. $rand_name = "";
  4. for ($i = 1; $i &lt;= 8; $i++) {
  5. $rand_name .= chr(rand(97, 122));
  6. }
  7. return $rand_name;
  8. }
  9. </blockcode>

E questo è cool!

hr è sostituito da separator

Il nome dell'elemento hr, "riga orizzontale", ha portato sempre problemi agli autori di contenuto e ai costruttori di tool di sviluppo. Il nome implica l'esistenza di una linea orizzontale, quando nei fatti l'elemento fu ideato per separare una parte di un documento dall'altra. Con l'utilizzo di separator, si ripara a tale equivoco.

E questo è cool!

del e ins sono sostituiti dall'attributo edit

L'attributo edit funziona meglio degli elementi del e ins, nell'indicare parti del contenuto che sono state modificate. Può essere applicato come nell'esempio seguente:

  1. <p>This is <span edit="deleted">cool</span><span edit="inserted">way cool</span>!</p>
Possibilità di aggiungere semantica addizionale agli elementi già esistenti

L'attributo role può aggiungere semantica e metadati ad elementi già presenti, aiutando così i motori di ricerca e le tecnologie assistive a rendere al meglio le pagine Web. L'esempio seguente mostra come sarebbe possibile indicare che il contenuto
di una specifica lista di navigazione dovrebbe essere utilizzata come "briciole di pane":

  1. <nl role="breadcrumbs">
  2. <label>You are here:</label>
  3. <li href="/">Home</li>
  4. <li href="/products/">Products</li>
  5. <li href="/products/widget/">Widgit</li>
  6. <li>Features</li>
  7. </nl>

Tale utilizzo dell'attributo role viene denominato tecnicamente "incorporare l'RDF in XHTML". Questo rende l'XHTML 2 molto estensibile e può diventare lo strumento più importante per portare il Web al suo pieno potenziale.

L'attributo role è tremendamente cool!

Le cose di XHTML 2 che non sono cool

E' ancora presente l'elemento a

Poiché è possibile utilizzare l'attributo href su ogni elemento, l'elemento a, di fatto, non risulta più necessario. Lasciare questo elemento nella specifica, porta ancora più confusione negli autori di contenuti. Per esempio, nell'HTML 4 e XHTML 1, l'attributo id può essere usato per fare di ogni elemento un'ancora. Per esempio:

  1. <h2 id="introduction">Introduction</h2>

Vi sono molti autori di contenuto che utilizzano ancora l'elemento a per realizzare ancore. Per esempio:

  1. <h2><a name="introduction">Introduction</a></h2>

Mantenere l'elemento a non è cool!

E' ancora presente l'elemento img

Nell'XHTML 2, l'elemento object può fare le stesse cose che fa l'elemento img. In accordo con la specifica l'elemento img viene mantenuto per permettere una più facile transizione verso l'XHTML 2, ma questo porta confusione fra gli autori di contenuto. L'elemento img non è più un elemento vuoto, ma può contenere contenuto alternativo. Per esempio:

  1. <img src="W3C.png">W3C</img>

Se un elemento in XHTML 2 ha lo stesso nome di un elemento in uso già in HTML 4 o XHTML 1, ma si comporta differentemente, può portare confusione e dubbi.

Mantenere l'elemento img non è cool!

Supporto per heading numerati

Poiché l'elemento h rappresenta un miglior approccio per la creazione di heading, gli heading numerati non sono più necessari. Il supporto ad entrambi gli elementi h e heading numerati porterà solo confusione negli autori di contenuto.

Gli heading numerati non sono cool!

La natura chiusa del gruppo che sviluppa XHTML 2

Molto poco è stato reso pubblico dal gruppo XHTML 2 su cosa stia sviluppando, che potrebbe diventare il prossimo linguaggio di markup del Web. Ragazzi, non si tratta di una task force che deve realizzare un'arma segreta. Apritevi al mondo!

X/HTML 5

Le cose di X/HTML 5 che sono cool

L'idea degli elementi di sezione

X/HTML 5 introduce nuovi elementi che suddividono il contenuto della pagina Web in sezioni. Queste sezioni dovrebbero aiutare i motori di ricerca e le tecnologie assistive a processare al meglio il contenuto. L'utilizzo di questi nuovi elementi potrebbe rendere più leggibile il markup.

L'idea di suddividere il contenuto è cool! Ma vedi anche perchè le tecniche per l'implementazione degli elementi di sezione non sono cool!

L'elemento dialog

L'elemento dialog rappresenta una conversazione. Contiene elemnti dt che identificano chi parla, e elementi dd che rappresenato ciò che questi dice. Per esempio:

  1. <dialog>
  2. <dt>Costello</dt>
  3. <dd>Look, you gotta first baseman?</dd>
  4. <dt>Abbott</dt>
  5. <dd>Certainly.</dd>
  6. <dt>Costello</dt>
  7. <dd>Who's playing first?</dd>
  8. <dt>Abbott</dt>
  9. <dd>That's right.</dd>
  10. <dt>Costello</dt>
  11. <dd>When you pay off the first baseman every month, who gets the money?</dd>
  12. <dt>Abbott</dt>
  13. <dd>Every dollar of it.</dd>
  14. </dialog>

E questo è cool!

L'elemento figure

Nelle pubblicazioni stampate (libri, quotidiani, rivieste, etc.) gli oggetti media (foto, illustrazioni, grafici, etc.) vengono di solito accompagnati da didascalie. Il linguaggio di markup Web non se ne è mai occupato finora. L'elemento figure con un elemento figlio legend può essere usato per rendere le didascalie delle immagini. Per esempio:

  1. <figure>
  2. <legend>Credit: Media Inc., 2007</legend>
  3. <img src="smith.jpg" alt="Photo: J. Smith" />
  4. </figure>

E questo è molto cool!

L'elemento m

L'elemento m rappresenta un testo marcato o evidenziato. E' una funzione molto interessante quando vi sono pagine Web che sono create dinamicamente in risposta ad una parola chiave di ricerca, e la parola può essere identificata nella pagina, utilizzando l'elemento m. Per esempio, in risposta ad una ricerca per parola "snow", potrà essere generata una pagina Web con il contenuto così modificato:

  1. <p>A <m>snow</m>man is a man-like sculpture constructed out of <m>snow</m>.</p>

E questo è cool!

Miglioramenti all'elemento input

L'elemento input è migliorato per supportare email, url, e tipi di dati relativi a date, tempo ed anche numerici. Ciò significa che può avvenire una maggiore validazione sul client rispetto al server.

E questo è cool!

Processo aperto

Il processo di sviluppo dell'X/HTML 5 è più aperto di quello dell'XHTML 2. Chiunque può partecipare alla mailing list dell'X/HTML 5.

Il processo aperto è cool!

Le cose di X/HTML 5 che non sono cool

Implementazione degli elementi di sezione

L'idea alla base della elementi di suddivisione è grande, ma risulta complicato il modo in cui l'X/HTML 5 l'implementa. Alcune delle spiegazioni ti lasciano ancora più confuso. Per esempio:

L'elemento aside rappresenta una sezione di pagina che di contenuto che è tangenzialmente correlato al contenuto intorno all'elemnto aside, e che potrebbe essere considerato separato dal contenuto. Tali sezioni vengono spesso rappresentate nella stampa tipografica come barre laterali.

Non sarebbe più estensibile e più facile da implementare un elemento div con un attributo role?

Un altro elemento di sezione proposto è nav, che rappresenta una sezione di una pagina che si collega ad altre pagine. Abbiamo davvero bisogno di un elemento nav? La costruzione di nl dell'XHTML 2 può farlo molto meglio.

Implementazione degli elementi di sezione non è cool e dovrebbe essere migliorata.

Gli errori di HTML 4 e XHTML 1 sono presenti anche in una specifica futura

Poiché X/HTML 5 cerca di essere retrocompatibile, molti degli errori presenti in HTML 4 e XHTML 1 saranno presenti anche in X/HTML 5. Le specifiche non devono necessariamente essere retrcompatibili. Invece, sarebbe meglio se fossero retrocompatibili gli user-agent, in grado così di supportare diverse specifiche.

Il mantenimento del supporto agli errori di HTML 4 e XHTML 1, come gli heading numerati, gli elementi i, b, small, iframe e font non è proprio cool!

X/HTML 5 non è conforme al charter di X/HTML 5

L'X/HTML 5 mira ad essere retrocompatibile con HTML 4 e XHTML 1. Elementi come big, acronym, u e tt, non sembrano essere parte della specifica, mentre altri elementi come i e small hanno visto ridefinita la loro semantica. Per esempio, la specifica HTML 4.01 definisce i e small così:

i: mostra un testo in stile italic

small: mostra il testo in un font "small"

In X/HTML 5, i e small hanno nuovi significati:

L'elemento i rappresenta un pezzo di testo in una voce o con uno spirito alternativo, o anche fuori della prosa normale, come una definizione tassonomica, un termine tecnico, una frase idiomatica da un'altra lingua, un pensiero, un nome di nave, o altra prosa la cui presentazione tipografica viene resa in italic.

L'elemento small rappresenta piccoli pezzi di stampa (parte di un documento che descrive restrizioni legali, come copyright), o altri commenti a margine.

Ridefinendo il sigificato di i e small, si perde la retrocompatibilità con HTML e XHTML 1. Ciò perché la retrocompatimpilità comporta che un user agent HTML 5 deve interpretare un documento HTML 4 nello stesso modo di un user agent HTML 4. Così, se HTML 5 dichiara la retrocompatibilità, un costrutto che era senza senso in HTML 4 dovrebbe essere senza senso anche in HTML 5.

Gli obiettivi del charter non sono proprio cool!

Cosa? L'elemento font è supportato?

Si, l'X/HTML 5 supporta l'elemento font se il contenuto viene realizzato usando un editor WYSIWYG. Qual'è il motivo? Perchè gli editor WYSIWYG devono essere esentati?

Questo non è proprio cool!

La firma WYSIWYG

I documenti creati da editor WYSIWYG devono includere la seguente firma nell'elemento head:

  1. <meta name="generator" content="(WYSIWYG editor)" />

oppure

  1. <meta name="generator" content="Sample Editor 1.0 (WYSIWYG editor)" />

Qual'è il motivo? Una specie di marchio vergognoso? E' un segnale per gli user agent che si devono aspettare un cattivo markup poichè questo è stato generato da un editor WYSIWYG? E cosa succede se solo una parte del documento viene creata da un editor WYSIWYG?

Tutto ciò rende perplessi ed non è proprio cool!

Supporto per nomi predefiniti di classi

I nomi predefiniti di classi sono nomi di classi CSS che sono riservati e che possono avere un significato semantico rivolto agli user agent X/HTML 5. Il nome di classe "copyright" è un nome predefinito di classe nell'esempio seguente:

  1. <p class="copyright>...</p>

Altri nomi di classi sono "error", "issue", "note", "search" e "warning". A complicare la faccenda, alcuni nomi predefiniti di classi possono essere utilizzati solo con alcuni elementi e non con altri. Per esempio, il none di classe "copyright" può essere utilizzato solo con p e span. Il nome di classe "error" può essere utilizzato solo con p, section, span e strong.

Con i nomi predefiniti di classi vi è il problema che l'esempio seguente non significa nulla:

  1. <p class="important">

...mentre il successivo esempio vuole significare qualcosa:

  1. <p class="copyright">

La grossa quantità di attributi di classe rende molto difficile interpretare il significato della costruzione. Per esempio, cosa significa:

  1. <p class="important copyright issue">

I nomi predefiniti di classi limitano anche la possibilità degli autori di utilizzare liberamente nomi di classi. Inoltre, cosa accade se un autore utilizza un nome di classe che al momento non è predefinito, mentre potrà esserlo in seguito? Ciò cambierà il significato del contenuto che l'autore aveva precedentemente realizzato?

Poichè l'XHTML 2 provvede soluzioni migliori con l'utilizzo del suo attributo role, i nomi predefiniti di classi in X/HTML 5 non sono proprio cool!

HTML 5 contro XHTML 5

In un tentativo di risolvere finalmente la disputa fra HTML e XHTML, la specifica X/HTML rende però la cosa ancora più difficile da comprendere. Infatti, la specifica X/HTML 5 recita "in generale gli autori non devono essere incoraggiati ad usare XML sul Web", anche se il W3C continua a nominare l'XML come il futuro del Web. Questo è tutto molto confusionario e davvero non è cool!

Un processo troppo precipitoso

L'X/HTML 5 è una reazione al lento progresso realizzato dal W3C nello sviluppare un sostituto all'HTML 4 e XHTML 1. Come risultato, il processo di sviluppo dell'X/HTML 5 sembra affrettato ed in molti pensano che la specifica provenga dal nulla e che sia precipitosa. Anche molti degli stakeholder interessati direttamente nello sviluppo si stanno accorgendo che la timeline e gli obiettivi delle fasi di sviluppo della specifica non sono realistiche.

La competizione per essere il prossimo linguaggio di markup

Sia l'X/HTML 5 che l'XHTML 2 sono in corsa per sostituire l'HTML 4 e l'XHTML 1. Anche in questo primo stadio di sviluppo, alcuni realizzatori di browser hanno già dichiarato le loro preferenze per una specifica o per l'altra. Il risultato della rapidità e della natura chiusa delle discussioni è la forte polarizzazione delle due comunità sugli standard Web. Con il progresso nello sviluppo delle due specifiche, vi saranno maggiori investimenti in sviluppo e marketing e quindi le due specifiche saranno pronte per una vera e propria guerra degli standard.

Poichè ognuno di noi è uno stakeholder in quanto il Web è di tutti, solo un dibattito onesto e aperto può assicurare che la migliore specifica possa emergere come vincitrice.

Note

  • Per una maggiore leggibilità, "HTML 4.x/XHTML 1.x" è stato sostituito con "l'HTML 4 e l'XHTML 1".
  • Questa è la traduzione in Italiano di Pasquale Popolizio (IWA Italy) dall'originale Inglese.

Ulteriori letture