Creare un popup con Dreamweaver Mx



Il passaggio dalla versione 4 a Mx, non ha cambiato di molto l’aspetto della scheda “Behaviors“. È un componente di Dreaweaver che permette, di utilizzare componenti già “confezionati” e personalizzabili, pronti all’uso anche senza conoscere Javascript.

È anche possibile scaricare direttamente dal sito Macromedia alcuni comportamenti aggiuntivi, che permettono di aggiungere nuove funzionalità interattive ai siti.

Prima fase: creazione del popup

Per iniziare realizzaremo una semplice pagina Html contente del testo e delle immagini, in particolare un popup contente il logo di Fucinaweb e un testo che riassume il contenuto di questo articolo.

Per comprendere al meglio la realizzazione della pagina è possibile scaricare il file compresso (25 KByte), contenente sia il file Photoshop (layout grafico) sia il file Html, oltre alle relative immagini.


Per prima cosa realizziamo il layout grafico del popup, dopodiché apriamo Dreamweaver Mx e selezioniamo File > Nuovo (File > New).

Proprietà della pagina

Dal menu Modifica (Modify) selezioniamo < Proprietà Pagina (Page Properties). In questa finestra definiamo il titolo, il colore di sfondo e le dimensioni del Margine sinistro (Left Margin) e della parte superiore (Top Margin) a 0 pixel. Così facendo, la tabella che creremo nel secondo passaggio si troverà perfettamente allineata al margine superiore e a quello sinistro.

Tabella con il contenuto della pagina web (popup)

Dal menu Inserisci (Insert) selezioniamo Tabella (Table). In questa finestra inseriamo il numero di colonne e righe desiderato, nel nostro caso 3 righe.

Andremo inoltre a specificare la larghezza della tabella, che di conseguenza determinerà la larghezza del popup. Una volta inserita la tabella andiamo a inserire il contenuto del popup.


Nel popup che abbiamo realizzato, la prima cella della tabella contiene il logo di Fucinaweb, la seconda cella contiene a sua volta un’altra tabella con il testo riferito all’articolo, ed infine la terza cella contiene il testo “Idee per forgiare i siti”.

Realizzata la pagina salviamo il lavoro: File > Salva come.. (File > Save as..).

Seconda fase: inserimento e richiamo del popup

Entriamo adesso nel vivo dell’articolo e inseriamo il codice che ci permetterà di richiamare il popup, in base a degli eventi. Principalmente i metodi di richiamo per un popup sono due.

Il primo metodo si basa sull’evento onclick del navigatore, che consente di richiamare un popup a seguito di un clic su una parola o immagine.

Il secondo esempio è attivato dall’evento onload, scatenato al termine del caricamento di una pagina.

Vediamo come realizzare i due esempi.

Evento onclick

Apriamo il documento Html e posizioniamoci nel punto di inserimento del link che aprirà il popup. Selezioniamo il testo (o l’immagine) e inseriamo un link di riferimento: <a href:”#”>Primo esempio</a>.

Selezionando il + nella scheda dei Behaviors compaiono tutti comportamenti possibili per questo contesto.


Per il nostro esempio selezioniamo Apri Finestra (Open Browser Window): si aprirà una finestra di dialogo in cui possiamo definire le caratteristiche del popup.

Procediamo come segue:

  • Con il tasto sfoglia (Browser), selezioniamo il documento contenente il popup (nel nostro caso pop.html)
  • Specifichiamo la larghezza e l’altezza del popup (Window Width e Window Height, nel nostro esempio 250 e 180)
  • Definiamo il nome della finestra (Window Name), operazione necessaria se si desidera associare la finestra a dei collegamenti o controllarla per mezzo di JavaScript

Le altre opzioni che è possibile attivare sono:

  • Barra degli strumentiNavigation Toolbar (è la barra del browser che contiene i pulsanti Indietro, Avanti, Inizio e ricerca)
  • Barra degli indirizziLocation Toolbar (è la barra di navigazione che contiene il campo dell’indirizzo)
  • Barra di statoStatus Bar (è l’aria grigia che occupa la parte inferiore della finestra del Browser in cui vengono visualizzati i messaggi)
  • Barra dei menuMenu Bar (è l’area della finestra del browser in cui appaiano i menu come File, Modifica, Visualizza ect.)
  • Barre di scorrimentoScrollbar as Needed (specifica la necessità di visualizzare delle barre di scorrimento se il contenuto della finestra si estende fuori dell’area visibile)
  • RidimensionamentoResize Handles (indica che l’utente può ridimensionare la finestra trascinandone l’angolo inferiore destro e facendo clic sul controllo di ridimensionamento visualizzato nell’angolo inferiore destro)

Una volta specificate le caratteristiche del popup e premuto il pulsante di Ok, Dreamweaver Mx inserirà all’interno del tag <head></head>, la seguente funzione:

function MM_openBrWindow(theURL,winName,features)
{ //v2.0 window.open(theURL,winName,features); }

Questa funzione è la stessa per tutti e due gli esempi che stiamo realizzando. Quello che cambia è il modo con cui viene richiamata.

Nel primo esempio, Dreamweaver Mx richiamerà all’interno del tag <a> creato la funzione “MM_openBrWindow”:

<a href=”#” onClick=”MM_openBrWindow(‘pop.html’,’pop1′,’width=250,height=180′)”>Primo esempio</a>

In questo modo, l’apertura della finestra è determinata dall’evento onclick.

Nel secondo esempio, l’unica differenza sta nel fatto che invece di creare un link di riferimento, ci posizioniamo all’interno del tag <body>

Questa volta il codice eseguito all’apertura della finestra sarà del tipo:

<body onLoad=”MM_openBrWindow(‘pop.html’,’pop2′,’width=250,height=180′)”>

L’evento creato comparirà all’interno della scheda Behaviors, così da consentirne una successiva modifica.


Un Web Accessibile a Tutti – Intervista a Joe Clark

  1. Ci parli di lei [Risposta 1]
  2. Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“? [Risposta 2]
  3. Che cosa è l’accessibilità Web e perché è così importante nella costruzione di un sito? Quali fasi del ciclo di vita di un sito hanno a che fare con l’accessibilità? [Risposta 3]
  4. L’accessibilità web è utile solo alle persone disabili? [Risposta 4]
  5. In cosa differisce l’accessibilità web dalla usabilità web? [Risposta 5]
  6. Le specifiche Wai sono a volte difficili da applicare. Le pagine di un sito devono “degradare gentilmente”, ma allo stesso tempo è meglio usare i Css anche per il layout. Le due tecniche sembrano agli antipodi. È davvero possibile costruire un sito seguendo queste specifiche così restrittive? [Risposta 6]
  7. Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità? [Risposta 7]
  8. A parte il sito Wai, ci sono altre risorse online che ci potrebbe consigliare? [Risposta 8]

Ci parli di lei

Sono un giornalista [nuova finestra] e consulente di accessibilità [nuova finestra] a Toronto. Svolgo questo lavoro praticamente da 20 anni. Ho pubblicato circa 400 articoli su riviste e giornali e sto per pubblicare un libro, Building Accessible Websites [nuova finestra]. Mi occupo di consulenza su temi di accessibilità per un piccolo numero di clienti (soprattutto per la televisione e il cinema).

Top

Quali sono gli argomenti trattati nel vostro libro “Building Accessible Websites“?

Piuttosto che il solito manuale di programmazione, il libro è una chiara spiegazione di cosa sia l’accessibilità Web e delle regole per progettare siti accessibili.

Alcuni degli argomenti riguardano:

  • L’accesso alle informazioni e le leggi
  • Una breve spiegazione di come le persone disabili usano i computer
  • Multimedia
  • La navigazione
  • Tabelle e frame
  • Il testo e i link
  • La struttura della pagina
  • Le immagini
  • Come creare pagine accessibili fin dall’inizio

Top

Che cosa è l’accessibilità Web e perché è così importante nella costruzione di un sito? Quali fasi del ciclo di vita di un sito hanno a che fare con l’accessibilità?

In generale l’accessibilità viene incontro alle situazioni e difficoltà invariabili di alcune persone. Una persona con problemi alla vista continua ad averli anche quando visita un sito, tanto per fare l’esempio più comune.

Il Web non è un mezzo universale. Non è come la stampa: economica e disponibile senza troppe difficoltà. C’è un certo grado di elitarismo nel Web: c’è bisogno di un computer e di una connessione ad Internet, elementi con un certo costo. Allora perché l’accessibilità Web è importante? Perché non si vuole essere elitari inutilmente. Non bisogna impedire l’accesso ai siti per cause che queste persone non possono cambiare.

Oltre a questo, l’accessibilità è sempre più richiesta dalle norme di legge [nuova finestra]. Non ci sono decreti nati appositamente per l’accessibilità Web, ma ci sono dimostrazioni di quanto le leggi attualmente in vigore siano state applicate all’accessibilità Web.

Una persona non vedente, Bruce Maguire, ha vinto un caso [nuova finestra] contro le Sydney Olympics del 2000; ha sostenuto che il loro sito Web era per lui inaccessibile (Bruce legge il testo Web con un visualizzatore Braille e un lettore vocale), e le autorità australiane gli diedero ragione, richiedendo al comitato olimpico l’adeguamento del sito e il pagamento di una multa. (Non hanno mai aggiornato il sito, che si sarebbe potuto progettare nel modo corretto fin da subito, ma pagarono la multa).

Il decreto “Americans with Disabilities Act [nuova finestra] si applica senza equivoci anche al Web. Lo stesso dicasi per il “Disability Discrimination Act [nuova finestra] nel Regno Unito, e anche per tutte le forme legislative che proibiscono un trattamento non equo, ma sfavorevole nei confronti delle persone disabili. Inoltre, i servizi e i siti realizzati da chi lavora per o nel governo federale degli Stati Uniti devono essere accessibili e rispettare i requisiti “Section 508 [nuova finestra].

Meglio includere le politiche di accessibilità fin dall’inizio. È generalmente semplice realizzare un sito accessibile partendo da zero e molto noioso e spiacevole ritornare indietro e correggere errori in un secondo momento. Il mio libro, a dire il vero, spiega anche come migliorare un sito esistente, se questa è l’unica possibilità. Ci sono delle procedure che rendono il compito gestibile.

Top

L’accessibilità web è utile solo alle persone disabili?

In quasi tutti i casi, si. Personalmente sono stanco di sentire quei difensori dell’accessibilità che dicono “Se rendi il tuo sito accessibile, le persone potranno visualizzarlo con i loro Palm Pilot!”. Non vedo perché si debbano cercare delle giustificazioni al fatto che rendere un sito accessibile è utile soprattutto per rispondere alle esigenze delle persone disabili (più qualche altra esigenza, come i problemi di lingua, anche se non ne parlo molto nel libro).

In ogni caso un sito che si definisce accessibile non funzionerà bene su un Palm Pilot. Ci sono ancora troppi link (come le barre di navigazione) e troppo testo non pertinente perché valga la pena usarlo. Si è verificato il contrario con il caso Amazon [nuova finestra]. Amazon ha adattato il sito per i Pda e ha sostenuto che era fruibile anche con i software di sintesi vocale. Ma le cose non funzionano così.

Top

In cosa differisce l’accessibilità web dalla usabilità web?

L’interazione tra le due discipline sta diventando sempre più chiara.

Il problema principale è il seguente: se il tuo sito è immediatamente ed efficacemente utilizzabile da una persona non disabile, ma una persona disabile deve faticare per completare i suoi compiti e impiega il triplo del tempo, quanto accessibile è il tuo sito? Quanto è usabile?

Questo è riconducibile a due aree principali: la navigazione e le form.

I siti web “tipici” hanno troppi link da saltare. Questo non è solo un problema per le persone non vedenti che usano i sintetizzatori vocali, come invece tutti pensano. Un abile utilizzatore di sintetizzatori vocali può infatti evitare molto agevolmente i link, per esempio saltando completamente la barra sinistra di navigazione. Ma una persona con problemi motori potrebbe essere costretta a tabulare tra 80 o più link solo per posizionare il cursore sulla casella di ricerca. (E usare la tabulazione per navigare i link è in realtà il caso migliore e quello più veloce – alcuni metodi usati da persone con gravi problemi motori muovendo le mani e le braccia sono molto lenti).

I siti dovrebbero riordinarsi automaticamente così che gli elementi cruciali, come le caselle di ricerca o i più importanti livelli di navigazione siano in cima, mentre tutto il resto dovrebbe essere presentato di seguito secondo un ordine logico. Forse il protocollo CC/PP [nuova finestra] renderà un giorno tutto questo possibile. A dire il vero, ogni sito realizzato come insieme di moduli da un sistema di gestione dei contenuti potrebbe automaticamente riordinarsi in questo modo, ma nessuno si sta prendendo il disturbo di farlo. Non si prendono neppure la briga di riordinare gli elementi della pagina premendo un bottone invece che farlo automaticamente. Si stanno ancora studiano delle tecniche che risolvano questo problema.

Riguardo alle form, i miglioramenti per l’accessibilità sono molto semplici in Html. Le form sono già di per sé complicate da mettere insieme, così gli sviluppatori non hanno nessuna scusa per non includere i tag che migliorino l’accessibilità. Il problema è in realtà che i sintetizzatori vocali non sono stati aggiornati per usare queste caratteristiche (come <label> intorno al tag <input>). Potrebbe allora succedere che gli autori di contenuti abbiano svolto correttamente il loro lavoro, ma che la tecnologia per l’accessibilità non riesca ad interpretarlo. E i sintetizzatori vocali non sono per niente bravi nel leggere il testo, i bottoni, i radio button, i check box e i textarea e chiarire come tutti questi elementi siano collegati gli uni agli altri. È molto facile perdersi quando si compila una form online. Allora, se le persone non disabili possono usare la vostra form ma le persone disabili no, la vostra form è realmente usabile? (Anche in questo caso, rendere accessibili le form per persone con difficoltà motorie è molto difficile. Nessuno ha sviluppato un buon metodo per svolgere questo compito fino ad oggi).

Top

Le specifiche Wai sono a volte difficili da applicare. Le pagine di un sito devono “degradare gentilmente”, ma allo stesso tempo è meglio usare i Css anche per il layout. Le due tecniche sembrano agli antipodi. È davvero possibile costruire un sito seguendo queste specifiche così restrittive?

Le specifiche del Wai sono pessime, ma sono in fase di attenta revisione. Finalmente abbiamo una
title=”Wcag 2 Restructuring Proposal” target=”_blank”>bozza della versione 2.0 [nuova finestra] delle Web Content Accessibility Guidelines che è quasi decente. Siamo ancora lontani dal traguardo, ma rappresenterà un forte miglioramento. Al momento siamo ancora bloccati alla versione 1.0.

La frase “degradare gentilmente” è stata ampiamente fraintesa. Significa semplicemente che “le cose devono funzionare anche in condizioni che lo sviluppatore non ha potuto o saputo anticipare”. È facile da ottenere, soprattutto in siti che non usano elementi multimediali. Se si scrive Html valido e si usano gli elementi dell’Html nel modo consono (cioè, non si usa <p> per codificare un titolo), si è già a buon punto.

Non è “sicuramente meglio” usare i Css per il layout. È troppo difficile far sì che i layout creati con i Css funzionino consistentemente in tutti i browser; è molto più semplice usare le tabelle. Questo nel mondo reale, dal momento che chiunque abbia messo insieme più di qualche pagina ha usato le tabelle per il layout. I costruttori di sintetizzatori vocali hanno inoltre aggiornato il loro software per gestire le tabelle (con rare eccezioni). I Css, quando riuscite a farli funzionare, vanno bene; anche le tabelle vanno bene. Lo so che sembra esserci un’eresia, ma questa è la realtà. (Io uso Css e tabelle, e qualche volta nessuno dei due, per le circa 500 pagine che ho online. Non pretendo di essere un purista, ma nessun altro dovrebbe pretenderlo).

Top

Cosa dire dei browser: Internet Explorer 6 e Netscape 6 interpretano correttamente i tag Html rivolti all’accessibilità?

I browser sono solo mediocri quando si tratta di supporto all’accessibilità nell’Html.

Le ultime versioni di Mozilla [nuova finestra] gestiscono molte funzionalità correttamente. Sottolineano gli acronimi e le abbreviazioni con linee tratteggiate; vi danno l’accesso alle descrizioni lunghe (longdesc) delle immagini (ma non dei frame – nessun browser lo fa); gestiscono l’alt text per le immagini meglio di qualsiasi altro browser (visualizzano semplicemente il testo dell’alternate senza cornici o altri riferimenti grafici che non siano stati progettati per la pagina).

iCab [nuova finestra] ha un supporto molto buono: è l’unico browser che può leggere l’attributo summary di una <table>.

Il supporto per l’accessibilità di Internet Explorer [nuova finestra] è solo discreto. Dal momento che non sono visualizzate alcune funzionalità molto utili come le descrizioni lunghe, gli sviluppatori spesso non sanno neppure che è possibile aggiungerle all’Html.

Top

A parte il sito Wai, ci sono altre risorse online che ci potrebbe consigliare?

Gestisco il Web AccessiBlog [nuova finestra], un Weblog di link ad altri siti che trattano di accessibilità. Dovrei aggiornarlo più spesso (ho davvero bisogno di un sistema basato su database), ma so di sicuro che ha link a praticamente tutte le risorse attualmente disponibili in inglese (a volte anche in tedesco). C’è meno materiale disponibile su questo argomento di quello che potreste pensare.

Chiunque avesse domande relative all’accessibilità web dovrebbe iscriversi a WebAIM [nuova finestra] e alla mailing list del WAI-IG [nuova finestra]. O semplicemente chiedere a me.

Xhtml e l’accessibilità web – Amici per la pelle

È vero: all’inizio non è facile capire perché valga la pena utilizzare lo standard Xhtml per la costruzione delle pagine.

Quello su cui molti si interrogano è la reale necessità di passare da un linguaggio (Html) ad un altro che gli somiglia e sembra aggiungere poche (forse nessuna) funzionalità di rilievo.

A questo si aggiungono i dubbi sui costi di aggiornamento e addestramento per un sito che possa definirsi accessibile: utilizzo dei tag e degli attributi corretti, interpretazione e applicazione delle linee guida.

I due concetti possono sembrare tra loro distanti, ma hanno invece diversi punti in comune.

Potremmo dirvi (anzi, l’abbiamo già fatto in un precedente articolo) che Xhtml è lo standard del futuro, che aiuta a separare lo strato di presentazione dal contenuto, che può essere esteso con la creazione di moduli, ecc.

Quello che però vogliamo presentare oggi è un esempio legato da un lato al tema dell’accessibilità web, dall’altro al costo dei contenuti.

In “Il vero costo dell’accessibilità web” abbiamo detto che i contenuti di un sito costano, e costano molto. Per questo motivo, è necessario costruirli efficacemente.

Di conseguenza, perchè il contenuto di un sito sia costruito in modo efficace, è necessario che si verifichino queste condizioni:

  • dev’essere scritto “correttamente”
  • deve rispondere alle domande degli utenti
  • dev’essere facilmente ricercabile
  • dev’essere facilmente indicizzabile
  • dev’essere trasformabile

Per i primi due punti, come sviluppatori e designer, c’è ben poco da fare: il contenuto va scritto da persone competenti.

Il nostro ruolo è quello di garantire (insieme a chi edita i testi) che il contenuto non rimanga sepolto nei meandri del sito, ma che possa essere trovato anche quando non è strillato ai quattro venti dalla Homepage.

Non solo, il contenuto va opportunamente categorizzato, perché chi usa il sito probabilmente ha un problema da risolvere, alla cui soluzione arriva procedendo dalla Homepage alle sezione e alle sottosezioni.

Ma il contenuto dev’essere anche trasformabile: quello che oggi è una pagina web domani potrebbe trasformarsi in un articolo cartaceo o in un documento Pdf. Per non parlare di visualizzazione su cellulari, Pda, ecc. Riscrivere una versione ad hoc per queste esigenze introdurrebbe degli altri costi.

Se lo standard Xhtml viene usato con “accortezza”, donerete al vostro contenuto il segreto dell’eterna giovinezza, perché potete passare da una versione all’altra senza riscrivere il contenuto. Ma non solo: lo fate con estrema semplicità, utilizzando lo standard Xsl.

Vediamolo con un esempio.

Convertire documenti Xhtml

Partiamo da una semplice (quasi banale) pagina che contiene un piccolo articolo. Ecco come è visualizzata:

Categoria: Sviluppo web

Come abbiamo già visto la scorsa puntata, con il solo Html non è possibile realizzare siti dinamici.

Per creare applicativi lato server è possibile ricorrere all’uso dei seguenti linguaggi di scripting (cfr. il manuale cartaceo a pag. 52):

Per costruire la pagina sono stati impiegati i tag e gli attributi che migliorano l’accessibilità e l’usabilità del documento: acronym, abbr, title, lang, ecc. Il sorgente è il seguente:

  1 <html lang="it" xmlns="http://www.w3.org/1999/xhtml">
  2   <head>
  3     <title>Xhtml e i tag accessibili</title>
  4   </head>
  5   <body>
  6     <p>Categoria: <span id="categoria"><strong>Sviluppo <span lang="en">web</span></strong></span></p>
  7     <p>Come abbiamo gi&agrave; visto la <a href="http://www.foo.com/percorso1" title="Puntata precedente: sviluppare per il web">scorsa puntata</a>, con il solo <acronym lang="en" title="HyperText Markup Language">Html</acronym> non &egrave; possibile realizzare siti dinamici.</p>
  8     <p>Per creare applicativi lato <span lang="en">server</span> &egrave; possibile ricorrere all’uso dei seguenti linguaggi di <span lang="en">scripting</span> (<abbr title="confronta">cfr.</abbr> il manuale cartaceo a <abbr title="pagina">pag.</abbr> 52):</p>
  9     <ul>
 10       <li>
 11         <acronym lang="en" title="Active Server Pages">Asp</acronym> di <a href="http://www.microsoft.com" title="Sito web di Microsoft Corporation"><span lang="en">Microsoft</span></a>, su <acronym lang="en" title="Internet Information Services">Iis</acronym>
 12       </li>
 13       <li>
 14         <acronym lang="en" title="Java Server Pages">Jsp</acronym> di <span lang="en"><a href="http://www.sun.com" title="Sito web si Sun Microsystem">Sun</a></span>
 15       </li>
 16       <li>
 17         <acronym lang="en" title="Hypertext Preprocessor">Php</acronym>
 18       </li>
 19     </ul>
 20   </body>
 21 </html>

Come vedete, il testo è arricchito da informazioni aggiuntive che ne migliorano l’accessibilità.

I vantaggi però non si fermano all’accessibilità: il fatto che il documento sia standard Xhtml consente la realizzazione, tramite Xsl, di opportuni fogli di trasformazione che consentono di tradurre il documento in un altro formato.

Un esempio di risultato (forse il più semplice tra gli infiniti disponibili) è il seguente:

Categoria: Sviluppo web

Come abbiamo già visto la scorsa puntata, con il solo Html non è possibile realizzare siti dinamici.

Per creare applicativi lato server
è possibile ricorrere all’uso dei seguenti linguaggi di scripting (cfr. il manuale cartaceo a pag. 52):


Link nella pagina
Acronimi
Abbreviazioni
  • cfr.: confronta
  • pag.: pagina
Termini stranieri
Categoria
  • Sviluppo web

Come potete vedere, l’articolo è stato stravolto: sono stati estratti e separati gli acronimi, le abbreviazioni, le parole in lingua straniera e i link.

Sono anche state aggiunte alcune funzionalità:

  • se selezionato un acronimo vi collegate a Google, dove troverete una definizione estesa del termine
  • se selezionate un termine straniero interrogare invece Babylon, che cercherà di trovare il corrispettivo italiano
  • compare un elenco dei link e il testo di accompagnamento è l’attributo title del link

Abbiamo ricavato molte informazioni precise da un testo davvero modesto.

Inoltre, il tempo necessario per la costruzione del foglio Xsl per la trasformazione ha richiesto non più di un’ora ed è applicabile a qualsiasi documento Xhtml.

Usare lo standard Xhtml insieme ai tag di solito ignorati (quelli che migliorano
l’accessibilità), vi apre quindi molti scenari:

  • possibilità di realizzare una copia per il mondo cartaceo
  • conversioni per telefoni e Pda
  • costruzione automatica di indici e tabelle con le abbreviazioni
  • elenco dei link presenti nella pagina
  • isolamento dei termini stranieri
  • categorizzazione dei contenuti della pagina (per parole d’ordine, tipologia, ecc.)

Possibili obiezioni

Come tutte le metologie, sono naturali alcune critiche al metodo sopra illustrato. Cerchiamo di prevederle insieme.

Non è meglio usare l’Xml come lingua franca per poi trasformare i documenti?

Senza dubbio l’Xml è il candidato principe alle trasformazioni Xml.

In questa sede stiamo però parlando di contenuti, che come tali saranno inseriti da un editor di competenze tecniche limitate.

È sicuramente possibile utilizzare l’Xml per categorizzare un documento la cui struttura è fissa (titolo, sommario, categorie, data, ecc.), più difficile se i dati sono “semistrutturati“.

Poiché ogni documento ha una struttura diversa dagli altri (per numero e posizione degli acronimi, dei collegamenti, delle parole straniere), l’editor ha più controllo con lo standard Xhtml, di cui riesce agevolmente ad avere un’anteprima su browser.

Ma un documento Xhtml è una specializzazione di documento Xml, per cui sarà possibile trasformarlo senza rinunciare ad alcuna caratteristica.

Non è eccessivo il costo per produrre contenuti così ricchi di informazioni?

Il costo c’è e non è esiguo. Non solo: mentre scrivere Html è ormai alla portata di tutti, diventa ora importante che i documenti siano sintatticamente e semanticamente corretti.

Ma tanto più il business dipende dai contenuti (siano questi articoli, documenti, listini), tanto maggiore sarà il risparmio futuro.

È possibile trasformare un documento anche partendo dall’Html. Perché devo usare Xhtml?

Perché è estremamente più semplice.

Il formato Xml di per sé non rappresenterebbe niente di eccezionale se lo sviluppo di procedure di interrogazione e trasformazione fosse complesso e costoso.

In realtà, i vincoli di cui bisogna tener conto nella scrittura di un documento Xml (è case sensitive, ha un solo nodo padre, tutti i tag devono essere chiusi), fa si che i parser per l’interrogazione e la trasformazione siano molto efficienti e semplici da utilizzare.

Conclusione

Il contenuto incide in larga misura sui costi di realizzazione di un sito accessibile. Vale perciò la pena di realizzarlo secondo lo standard Xhtml ed utilizzando tutti i tag che arricchiscono il testo di informazioni.

In questo modo è possibile facilitare la ricerca e la memorizzazione dei documenti, ma anche le conversioni per altri media e formati e per future versioni del sito.