Questa è una traduzione in italiano dell'unica versione ufficiale del documento che è la versione originale in inglese "HTML and XHTML Frequently Answered Questions" http://www.w3.org/MarkUp/2004/xhtml-faq. I possibili errori dovuti alla traduzione, sono di esclusiva responsabilità del traduttore Pasquale Popolizio e non sono in alcun modo imputabili al W3C. Questa traduzione è stata realizzata nell'agosto del 2004. Per qualsiasi commento riguardo tale traduzione rivolgersi a Pasquale Popolizio.
Redattore: Steven Pemberton, W3C/CWI
Data della versione: 21 Luglio 2004
Altre FAQ correlate:
Per commentare questo documento, o per inviare suggerimenti per domande, inviare un'email a www-html-editor@w3.org, scrivendo la parola FAQ nel soggetto.
L'HTML è probabilmente il linguaggio di markup di documenti di maggior successo al mondo. Quando fu introdotto l'XML, fu organizzato un workshop di due giorni per discutere se era necessaria una nuova versione dell'HTML in XML. L'opinione al workshop fu un chiaro 'Si': con un HTML basato su XML altri linguaggi XML potrebbero includere parti di XHTML, e documenti XHTML potrebbero includere parti di altri linguaggio di markup. Si potrebbe anche ridisegnare al fine di pulire alcune delle parti più disordinate dell'HTML, e aggiungere alcune nuove funzionalità necessarie, come form migliori.
Se il tuo documento è di puro XHTML 1.0 (non includendo altro linguaggio di markup), non noterai molta differenza. Comunque, come diverranno disponibili altri strumenti XML, come l'XSLT per trasformare i documenti, comincerai a notare i vantaggi di usare l'XHTML. Per esempio XForms ti permetterà di editare documenti (o ogni altro tipo di documento XML) in modo semplice. Le applicazioni di web semantico potranno avvantaggiarsi dai documenti XHTML.
Se il tuo documento è più di XHTML 1.0, per esempio includendo MathML, SMIL, o SVG, invece i vantaggi sono immediati: ciò non è possibile con l'HTML.
No. L'HTML non è in formato XML. Devi fare i cambiamenti necessari per fare del documento un documento XML, prima che esso sia accettato come XML.
HTML Tidy da la possibilità di trasformare un documento HTML in uno XHTML. Amaya è un browser/editor che salverà i documenti HTML come XHTML.
Ciò è voluto. I browser HTML accettano ogni input, corretto o non corretto, e provano a fare qualcosa. Questa correzione di errore fa sì che i browser siano difficili da realizzare, specialmente se si aspetta che tutti i browser facciano la stessa cosa. Questo significa anche che un grosso numero di documenti HTML non sono corretti, poiché sebbene essi si mostrino bene nel browser, l'autore non è a conoscenza degli errori. Ciò comporta che è veramente difficile realizzare nuovi user agent web, poiché i documenti che si dichiarano HTML sono spesso scadenti.
Tutti i browser sanno interpretare l'HTML corretto. Comunque, se non è corretto, il browser deve riparare il documento, e poiché non tutti i browser riparano i documenti nello stesso modo, ciò introduce delle differenze, così che il documento può mostrarsi e lavorare in maniera diversa su browser differenti. Poiché ci sono centinaia di browser diversi, ed altri sono in arrivo (non solo per PC, ma anche per PDA, cellulari, televisioni, stampanti, ed anche i frigoriferi), è impossibile testare il documento su ogni browser. Se si usa un HTML non corretto ed il documento non lavora bene su un particolare browser, l'errore è tuo; se invece usi HTML corretto ed il tuo documento non lavora bene, vuol dire che c'è un bug nel browser.
Il W3C offre un servizio a http://validator.w3.org/. Il browser/editor Amaya ti assicurerà che il tuo markup è corretto.
Sebbene i browser siano veramente degli utilizzatori importanti di HTML e XHTML, esistono altri programmi e sistemi che leggono quei documenti. Per esempio i motori di ricerca leggono quei documenti, eppure non sono browser. Usando il termine "user agent" proviamo a ricordare alle persone questa differenza.
Per esempio, quando fai un ricerca su Google, spesso vedi sotto qualche risultato "Questa pagina web usa i frame, ma il tuo browser non li supporta", il che di sicuro non invoglia le persone a cliccare su quel link. Gli autori dei siti web in questione non sanno che non ci sono solo browser, e che si dovrebbe includere del testo migliore nella loro sezione <noframes>, così che essi non sembrino così stupidi quando le persone ricercano il loro sito.
Nei primi tempi dell'HTML, vari gruppi ed aziende aggiunsero nuovi elementi ed attributi all'HTML secondo la loro volontà. Questo minacciò di causare un caos causa delle differenti versioni di HTML non compatibili fra di loro. L'XML (la X sta per Estensibile) permette ad ognuno di utilizzare elementi da linguaggi differenti, ma per far conoscere ad un browser o ad un altro user agent, a quale linguaggio appartiene quell'elemento, devi dirglielo. La dichiarazione del namaspace fa proprio questo.
L'XHTML è un formato dell'XML; significa che in termini rigidi esso dovrebbe essere inviato con un tipo di media relativo all'XML (application/xhtml+xml,
application/xml, o text/xml). Comunque l'XHTML è stato realizzato con cura, così che con cura esso dovrebbe andare bene su user agent HTML non moderni. Se segui semplici linee guida, puoi far in modo che i browser non moderni leggano bene molti documenti XHTML 1.0. Comunque, i browser antichi riconoscono solo il tipo di media text/html, così devi usare quel tipo di media se gli invii documenti XHTML. Ma attenzione, inviando documenti XHTML ai browser come text/html significa che quei browser li riconosceranno come documenti HTML, non XHTML.
I browser che conosciamo sono tutti quelli basati su Mozilla, come Mozilla, Netscape 5 e maggiori, Galeon e Firefox, come pure Opera, Amaya, Camino, Chimera, DocZilla, iCab, Safari, e tutti i browser sui cellulari che accettano il WAP2. In pratica, tutti i browser moderni. La maggior parte accetta validi documenti XHTML come application/xml. Vedi il test di tipi di media XHTML per maggiori informazioni.
No. Comunque c'è un trucco che permette di inviare documenti XHTML 1.0 a Internet Explorer come application/xml.
Includi all'inizio del documento la linea in bold::
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="copy.xsl"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
Dove copy.xsl è un file che contiene:
<stylesheet version="1.0"
xmlns="http://www.w3.org/1999/XSL/Transform">
<template match="/">
<copy-of select="."/>
</template>
</stylesheet>
Attenzione che questo file deve essere sullo stesso sito dove risiede il documento che a lui fa riferimento.
Sebbene stia inviando il documento come XML, e esso venga reso come XML, il browser pensa di aver ricevuto un documento text/html, e così il documento XHTML 1.0 deve seguire molte delle linee guida per essere inviato ai browser antichi.
Il documento XHTML continuerà a lavorare bene su browser che accettano XHTML 1.0 come application/xml.
No. Le regole dei CSS che si applicano all'HTML, si applicano solo a documenti che sono inviati come text/html.
No. A causa della definizione dell'XML, non è possibile fare trucchi come quello di prima, dove il markup viene generato da uno script mentre il parser sta ancora facendo il parsing del markup.
Puoi ottenere gli stessi effetti, ma devi utilizzare il DOM e aggiungere e cancellare elementi.
L'XHTML 1.1 è puro XML, e può essere solo XML. Esso non può essere inviato efficacemente ai browser non moderni. In ogni caso i documenti XHTML devono essere inviati con un tipo di media relativo all'XML, come application/xhtml+xml
Non è vero. L'XHTML 1.0 può essere in tre versioni: strict, transitional e frameset. Tutti e tre furono deliberatamente lasciati il più vicino possibile all'HTML 4.01 come l'XML permetteva. L'XHTML 1.1 è una versione aggiornata dell'XHTML 1.0 strict, e mai nessuna versione dell'HTML ha mai incluso l'attributo target. Le altre due versioni, transitional e frameset, non furono aggiornate, perché non c'era nulla da aggiornare. Se vuoi usare l'attributo target, utilizza l'XHTML 1.0 transitional.
La Modularizzazione dell'XHTML non è rivolta ai normali utenti dell'XHTML, ma ai designer dei linguaggi basati sull'XHTML. E' stato notato che che le società ed organizzazioni avevano la tendenza a disegnare la loro propria versione di HTML e XHTML che era spesso non compatibile a livelli base. La Modularizzazione dell'XHTML suddivide l'XHTML in un numero di moduli che possono essere selezionati singolarmente allorquando si definisce un nuovo linguaggio; in questo modo ogni linguaggio basato sull'XHTML che usa tabelle è garantito che usi la stessa definizione di tabelle, e non alcune diverse versioni. La Modularizzazione permette anche di rendere esplicito dove è permesso aggiungere nuovi elementi e dove invece no.
L'HTML e l'XHTML hanno fatto un buon lavoro, ma ci sono molte cose che possono essere migliorate. Le aree che hanno ricevuto particolare attenzione sono le migliori possibilità di strutturazione, la rimozione di caratteristiche che sono duplicate in XML, l'usabilità, l'accessibilità, l'internazionalizzazione, l'indipendenza dal dispositivo, form migliori e la riduzione della necessità di scripting.
No. <img> è sostituito in XHTML2, ma da qualche altra cosa (sebbene si possa utilizzare anche <object>).
Il design di <img> ha molti problemi in HTML:
alt. Questo fatto ha ostacolato l'adozione di immagini PNG, che in molti casi sono migliori di GIF e JPG, poiché si è continuato ad utilizzare il formato minimo comun denominatore, per assicurarsi che tutti potessero vedere le immagini.
longdesc
alla descrizione dell'immagine, per aiutare le persone che non possono vedere, ma è raramente implementato.Quello che l'XHTML2 fa è indicare che tutte le immagini sono equivalenti ad alcune parti di contenuto; lo fa permettendoti di inserire un attributo src ad ogni elemento. In altre parole è come se dicesse: se l'immagine è disponibile, ed il browser può processarla, usala, altrimenti usa il contenuto dell'elemento. Per esempio:
<p src="map.png">Exit from the station, turn left, go straight on to <strong>High Street</strong>, and turn right</p>
Il vantaggio di ciò è che se l'immagine non è disponibile per varie ragioni (come per esempio una cattiva connessione) o il browser non può processare quel tipo di immagine, il tuo documento continua ad essere utilizzabile. Se vuoi fornire più di un tipo di immagine, puoi fare:
<p src="map.png"><span src="map.gif">Exit from station...</span></p>
Sebbene è meglio utilizzare la negoziazione del contenuto se il tuo server lo supporta (e la maggior parte lo fa):
<p src="map">Exit from station...</p>
Che negozierebbe con il browser il tipo di immagine che esso accetta e le darebbe quella. Se non c'è immagine disponibile, allora verrebbe utilizzato il contenuto dell'elemento. Questo è un valore aggiunto in quanto puoi aggiungere in seguito altri tipi di immagini sul tuo server senza dover cambiare la pagina per farla lavorare ancora bene.
Xlink e XHTML hanno differenti requisiti per i collegamenti che li rendono non compatibili.
Lo è, ma in un modo differente di come lo erano precedenti versioni di HTML.
Poiché le precedenti versioni di HTML erano linguaggi con un obiettivo speciale, era necessario assicurare un livello compatibilità all'indietro per le nuove versioni così che i nuovi documenti sarebbero stati ancora utilizzabili nei vecchi browser. Per esempio, è per questo che l'elemento <meta> ha il suo contenuto in un attributo piuttosto che nel contenuto dell'elemento, poiché esso sarebbe apparso nei vecchi browser.
Comunque, grazie all'XML e ai fogli di stile, tale compatibilità all'indietro non è più necessaria, poiché un browser che legge XML, circa il 95% dei browser ora in uso, può processare nuovi linguaggi di markup senza essere aggiornato. La maggior parte dell'XHTML2 lavora già bene nei browser esistenti, browser che non sono stati preprogrammati per accettare l'XHTML2. La maggiorparte, ma non tutto: quando le forms e le tabelle furono aggiunte all'HTML, si dovettero aspettare le nuove versioni dei browser; in maniera simile, alcune parti dell'XHTML2, come XForms e XML Events, richiedono degli user agent che capiscono quella funzionalità.
L'attributo xml:space si riferisce all'input: come dire che esso controlla se gli spazi saranno presenti nel DOM (per esempio, nella versione interna del documento dentro il browser); Ciò non specifica niente su cosa apparirà sullo schermo. Lo spazio bianco in output è controllato dalla proprità dei CSS 'whitespace'. Con il valore 'pre' gli spazi nel DOM saranno preservati in output; con il valore
'normal' gli spazi bianci si raggrupperanno in uno solo (i CSS3 avranno maggiori proprietà che permetteranno un più ampio controllo).
Questa è la ragione per la quale tutti gli elementi in XHTML2 hanno valore
xml:space="preserve"; in caso contrario la proprietà
'whitespace' dei CSS non avrebbe effetto, e non avresti controllo sugli spazi bianchi visibili.
Il foglio stile di default per l'elemento 'whitespace' avrà valore 'normal' per tutti gli elementi eccetto per <pre>, ma si possono cambiare.
Copyright ©2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.