della Raccomandazione
XML 1.0 [XML <#ref-xml>]. Principalmente questa definizione indica
che gli elementi, delimitati dai loro tag iniziale e finale, sono
annidati in maniera corretta uno dentro l'altro.
3. Definizione Normativa di XHTML 1.0
3.1 Conformità del Documento
Questa versione di XHTML fornisce una definizione di conformità stretta
dei documenti XHTML, che viene ristretta ai tag e agli attributi dello
spazio dei nomi di XHTML. Vedi Sezione 3.1.2 <#well-formed> per
informazioni sull'uso di XHTML con altri spazi di nomi, per esempio,
l'inclusione di metadati espressi in RDF all'interno di documenti XHTML.
3.1.1 Documenti Strettamente Conformi
Un documento XHTML strettamente conforme è un documento che richiede
solo le strutture descritte come obbligatorie in queste specifiche.
Questi documenti devono rispettare tutti i seguenti punti:
1. Deve essere validato rispetto ad una delle tre DTD presenti in
Appendice A <#dtds>.
2. L'elemento radice del documento deve essere ||.
3. L'elemento radice del documento deve indicare lo spazio dei nomi di
XHTML usando l'attributo |xmlns| [XMLNAMES <#ref-xmlns>]. Lo spazio
dei nomi per XHTML è definito in |http://www.w3.org/1999/xhtml|.
4.
All'interno del documento ci deve essere una dichiarazione di
DOCTYPE prima dell'elemento radice. L'identificatore pubblico
incluso nella dichiarazione di DOCTYPE si deve riferire ad una delle
tre DTD presenti in Appendice A <#dtds> usando il corrispondente
Identificatore Formale Pubblico. L'identificatore di sistema può
essere cambiato per riflettere le convenzioni del sistema locale.
Qui viene riportato un piccolo esempio di un documento XHTML.
Virtual Library
Moved to vlib.org.
Nota che in questo esempio viene inclusa la dichiarazione di XML. Una
dichiarazione XML come quella sopra non viene richiesta da tutti i
documenti XML. Si raccomanda fermamente agli autori di documenti XHTML
di usare le dichiarazioni XML in tutti i loro documenti. Questo tipo di
dichiarazione viene richiesta quando la codifica dei caratteri del
documento è un'altra rispetto a quella usata per default UTF-8 o UTF-16.
3.1.2 Uso di XHTML con altri spazi di nomi
Lo spazio dei nomi XHTML può essere usato con altri spazi dei nomi XML
come viene indicato in [XMLNAMES] <#ref-xmlns>, sebbene questi documenti
non siano strettamente conformi ai documenti XHTML 1.0 come definito
sopra. Il lavoro futuro del W3C sarà nella direzione di specificare la
conformità per quei documenti che comprendono diversi spazi dei nomi.
L'esempio seguente mostra il modo in cui XHTML 1.0 può essere usato
insieme alle Raccomandazioni MathML:
A Math Example
The following is MathML markup:
L'esempio seguente mostra il modo in cui i marcatori di XHTML possono
essere incorporati in un altro spazio dei nomi XML:
Cheaper by the Dozen
1568491379
This is also available online.
3.2 Conformità degli User Agent
Uno user agent conforme deve rispettare tutti i seguenti punti:
1. Per essere consistente con le Raccomandazioni di XML 1.0 [XML]
<#ref-xml>, lo user agent deve analizzare e valutare un documento
XHTML come "ben formato". Se lo user agent si dice validante, allora
deve validare anche i documenti rispetto alla loro DTD in accordo
con [XML] <#ref-xml>.
2. Quando uno user agent afferma di supportare strutture <#facilities>
definite all'interno di queste specifiche o richieste da queste
specifiche attraverso le normative di riferimento, lo deve fare in
modo consistente rispetto alla definizione di stuttura.
3. Quando uno user agent processa un documento XHTML come un generico
XML, dovrà riconoscere solo gli attributi di tipo |ID| come
identificatori di frammento (per esempio l'attributo |id| nella
maggior parte degli elementi XHTML).
4. Se uno user agent incontra un elemento che non riconosce, deve
presentare il contenuto di tale elemento.
5. Se lo user agent incontra un attributo che non riconosce, deve
completamente ignorare le specifiche dell'attributo (per esempio,
l'attributo e i suoi valori).
6. Se lo user agent incontra un valore di attributo che non riconosce,
deve usare il valore di default dell'attributo.
7. Se lo user agent incontra un riferimento ad una entità (diversa da
quelle predefinite) per la quale lo user agent non ha processato
nessuna dichiarazione (può succedere se la dichiarazione si trova in
un sottoinsieme esterno che lo user agent non ha letto), l'entità
deve essere presentata come i caratteri (iniziando con un ampersand,
&, e finendo con un punto e virgola) che formano il riferimento alla
entità.
8. Quando viene presentato il contenuto, lo user agent che incontra
caratteri o entità di tipo carattere che riconosce ma che non sa
come presentare, dovrebbe visualizza il documento in modo tale che
l'utente si accorga chiaramente che non è stata possibile una
corretta presentazione.
9. I seguenti caratteri vengono definiti in [XML] come caratteri di
spazi bianchi:
* Spazio ( )
* Tabulazione ( )
* Ritorno carrello (
)
* Line feed (
)
Il processore XML normalizza diversi sistemi di codice di fine linea
in un singolo carattere di line-feed che viene passato
all'applicazione. In aggiunta lo user agent XHTML deve trattare come
spazi bianchi anche i seguenti caratteri:
* Form feed ()
* Zero-width space ()
Negli elementi dove l'attributo 'xml:space' ha il valore 'preserve',
lo user agent deve conservare intatti tutti i caratteri di spazi
bianchi (fatta eccezione per i caratteri di spazi bianchi iniziali e
finali che dovrebbero essere rimossi). In altri casi uno spazio
bianco viene considerato secondo le seguenti regole:
* Tutti gli spazi bianchi che circondano elementi in blocco
dovrebbero essere rimossi.
* I commenti vengono rimossi interamente e non hanno conseguenza
sulla manipolazione di spazi bianchi. Un carattere di spazio
bianco su entrambi i lati di un commento viene trattato come due
caratteri di spazio bianco.
* Gli spazi bianchi iniziale e finale dentro un elemento in blocco
devono essere rimossi.
* I caratteri di line feed all'interno di elementi in blocco
devono essere convertiti in uno spazio (tranne quando
l'attributo di 'xml:space' viene posto a 'preserve').
* Una sequenza di caratteri di spazi bianchi deve essere ridotta
ad un singolo carattere di spazio bianco (tranne quando
l'attributo di 'xml:space' viene posto a 'preserve').
* Rispetto alla presentazione, lo user agent dovrebbe visualizzare
il contenuto in maniera appropriata al linguaggio secondo cui è
scritto il contenuto stesso. Nelle lingue in cui la base di
scrittura è il carattere latino, il carattere di spazio ASCII
viene usato tipicamente sia come spazio grammaticale tra le
parole che come spazio tipografico bianco; nelle lingue la cui
scrittura è in relazione al Nagari (esempio Sanscrito, Thai,
ecc.) i limiti tra le parole possono essere codificati usando il
carattere 'space' ZW, ma non verranno visualizzati come
caratteri tipografici di spazi bianchi; lingue con scritture di
base araba possono codificare il carattere tipografico di spazio
bianco con un carattere di spazio, ma possono anche usare il
carattere spazio ZW per delimitare i limiti grammaticali
'interni' (quelle che sembrano parole arabe per un lettore
inglese normalmente comprendono più parole, per esempio
'kitAbuhum'= 'kitAbu-hum' = 'libri loro' == i loro libri); e
lingue di scrittura cinese normalmente non codificano questi
identificatori nè usano spazi bianchi in questo modo.
Gli spazi bianchi nel valore degli attributi vengono considerati in
accordo a [XML] <#ref-xml>.
4. Differenze con HTML 4
Poichè XHTML è un'applicazione XML, certi usi che erano perfettamente
legali in HTML 4.0 basato su SGML [HTML] <#ref-html4> devono essere
cambiati.
4.1 I documenti devono essere ben formati
Ben-formato <#wellformed> è un concetto introdotto da [XML] <#ref-xml>.
Sostanzialmente questo significa che tutti gli elementi devono avere il
tag di chiusura o devono essere scritti in una forma speciale (come
descritto sotto), e che tutti gli elementi devono essere annidati.
Sebbene la sovrapposizione sia illegale in SGML, è stata ampiamente
tollerata dai browser esistenti.
*/CORRETTO: elementi annidati./*
here is an emphasized paragraph.
*/SBAGLIATO: elementi sovrapposti/*
here is an emphasized paragraph.
4.2 Gli elementi e i nomi degli attributi devono essere in lettere
minuscole
I documenti XHTML devono usare lettere minuscole per tutti gli elementi
HTML e per i nomi degli attributi. Questa differenza è necessaria perchè
XML è sensibile alle minuscole e alle maiuscole, per esempio e
sono tag diversi.
4.3 Gli elementi non vuoti richiedono il tag di chiusura
In HTML 4.0 basato su SGML alcuni elementi potevano omettere il tag di
chiusura, in modo tale che gli elementi che seguivano implicavano tale
chiusura. Questa omissione non è permessa in XHTML basato su XML. Tutti
gli elementi, ad eccezione di quelli dichiarati come |EMPTY| nella DTD
devono avere un tag di chiusura.
*/CORRETTO: elementi chiusi/*
here is a paragraph.
here is another paragraph.
*/SBAGLIATO: elementi non chiusi/*
here is a paragraph.
here is another paragraph.
4.4 I valori degli attributi devono sempre essere compresi fra doppi
apici
Tutti i valori degli attributi devono essere compresi fra doppi apici,
inclusi i valori numerici.
*/CORRETTO: valori di attributo tra doppi apici/*
*/SBAGLIATO: valori di attributo senza doppi apici/*
4.5 Minimizzazione degli attributi
XML non supporta la minimizzazione degli attributi. I valori degli
attributi accoppiati devono essere scritti completamente. I nomi degli
attributi come |compact| e |checked| non possono essere presenti negli
elementi se non viene specificato il loro valore.
*/CORRETTO: attributi non minimizzati/*
*/SBAGLIATO: attributi minimizzati/*
4.6 Elementi vuoti
Gli elementi vuoti devono avere un tag di chiusura o il tag iniziale
deve terminare con |/>|. Per esempio |
| o |
|. Vedere HTML
Compatibility Guidelines <#guidelines> per informazioni sul modo con cui
poter assicurare la compatibilità retroattiva con gli user agent di HTML 4.
*/CORRETTO: tag vuoto chiuso/*
*/SBAGLIATO: tag vuoto non chiuso/*
4.7 La manipolazione di spazi bianchi nei valori degli attributi
Nei valori degli attributi, gli user agent elimineranno gli spazi
bianchi iniziali e finali dai valori degli attributi e sostituiranno la
sequenza di uno o più spazi bianchi (compreso il salto di linea) con un
singolo spazio tra le parole (un carattere di spazio ASCII per le
scritture di tipo occidentale). Vedere la Sezione 3.3.3
di [XML] <#ref-xml>.
4.8 Gli elementi Script e Style
In XHTML gli elementi script e style vengono dichiarati come se avessere
un contenuto di tipo |#PCDATA|. Come risultato|<| e |&| verranno
trattati come inizio del marcatore, e entità quali |<| e |&|
saranno riconosciute come entità di riferimento dal processore XML
rispettivamente come |<| e |&. |Racchiudere il contenuto dell'elemento
script o style dentro una sezione marcata |CDATA| evita il processamento
di queste entità.
Le sezioni |CDATA| vengono riconosciute dal processore XML e appaiono
come nodi nel Modello dell'Oggetto di Documento, vedi Section 1.3
delle Raccomandazioni DOM Livello 1 [DOM] <#ref-dom>.Una alternativa è
quella di usare documenti esterni per gli script e gli style.
4.9 Esclusioni dell'SGML
L'SGML dà allo scrittore di una DTD la possibilità di impedire che
specifici elementi siano annidati in altri elementi. Queste proibizioni
(chiamate "esclusioni") non sono possibili in XML.
Per esempio, la DTD Stretta di HTML 4 proibisce l'annidamento di un
elemento '|a|' dentro un altro elemento '|a|' a qualsiasi profondità.
Non è possibile dettagliare**tale proibizione in XML. Anche se queste
proibizioni non possono essere definite in una DTD, certi elementi non
dovrebbero essere annidati. Un elenco di questi elementi e degli
elementi che non dovrebbero essere annidati con loro si trova nella
normativa in Appendix B <#prohibitions>.
4.10 Gli elementi con attributi 'id' e 'name'
HTML 4 definisce l'attributo |name| per gli elementi |a|, |applet|,
|form|, |frame|, |iframe|, |img|, e |map|. HTML 4 introduce anche
l'attributo |id|. Entrambi questi attributi sono disegnati per essere
usati come identificatori di frammenti di informazioni.
In XML gli identificatori di frammenti sono di tipo |ID|, e ci può
essere un solo attributo di tipo |ID| per elemento. Quindi, in XHTML 1.0
l'attributo |id| viene definito di tipo |ID|. Con l'obiettivo di
assicurare che i documenti XHTML 1.0 siano documenti XML ben-formati, i
documenti XHTML 1.0 DEVONO usare l'attributo |id| quando definiscono gli
identificatori di frammento, compreso con elementi che storicamente
usavano anche un attributo |name|. Vedere HTML Compatibility Guidelines
<#guidelines> per informazioni su come assicurare la compatibilità
retroattiva delle ancore quando si servono di documenti XHTML come media
di tipo |text/html|.
Nota che in XHTML 1.0 l'attributo |name| di questi elementi è
formalmente proibito e verrà rimosso nella futura versione di XHTML.
5. Compatibilità: punti di attenzione
Sebbene non vi sia nessun obbligo per i documenti XHTML 1.0 per quanto
riguarda la compatibilità con gli user agent esistenti, in pratica
questo è facile da ottenere. Le linee guide per creare la compatibilità
dei documenti si trovano in Appendix C <#guidelines>.
5.1 Tipi di Media di Internet
Al momento della pubblicazione di questa raccomandazione, il MIME
generale raccomandato per le applicazioni basate su XML è stato già deciso.
Comunque, i documenti XHTML che seguono le linee guida indicate in
Appendix C <#guidelines>, "Linee guida sulla compatibilità di HTML"
possono essere etichettati con il tipo di Media per Internet
"text/html", in quanto sono compatibili con la maggior parte dei browser
HTML. Questo documento non presenta nessuna raccomandazione
sull'etichetta MIME di altri documenti XHTML.
6. Direzioni future
XHTML 1.0 fornisce le basi per una famiglia di tipi di documento che
estenderà e delimiterà XHTML per supportare un ampio insieme di nuovi
dispositivi e applicazioni, definendo moduli e specificando un
meccanismo per la combinazione di questi modelli. Questo meccanismo
permetterà l'estensione e la delimitazione di XHTML 1.0 in maniera
uniforme attraverso la definizione di nuovi moduli.
6.1 Modularizzare HTML
Nel momento in cui XHTML si sposterà dallo user agent del tradizionale
desktop ad altre piattaforme, è chiaro che non tutti gli elementi di
XHTML saranno necessari in tutte le piattaforme. Per esempio un
dispositivo manuale o un telefono cellulare possono supportare solo un
sottoinsieme di elementi XHTML.
Il processo di modularizzazione spezza XHTML in una serie di piccoli
insiemi di elementi. Questi elementi possono essere ricombinati per
raggiungere i bisogni delle diverse comunità.
Questi moduli saranno definiti in un futuro documento del W3C.
6.2 Sottoinsiemi e estensibilità
La modularizzazione si porta dietro molti vantaggi:
* Fornisce un meccanismo formale per il sottoinsieme di XHTML.
* Fornisce un meccanismo formale per l'estensione di XHTML
* . Semplifica la trasformazione tra i tipi di documenti.
* Promuove il riutilizzo di moduli in nuovi tipi di documenti.
6.3 Profili del documento
Il profilo di un documento specifica la sintassi e la semantica di un
insieme di documenti. La conformità ad un profilo di documento fornisce
la base per garantire l'interoperabilità. Il profilo del documento
specifica le caratteristiche richieste per processare i documenti di
questo tipo, per esempio quale formato di immagine può essere usato, i
livelli di scripting, il supporto degli style sheet, e così via.
Per i designer dei prodotti questo permette di definire il proprio
profilo standard dei vari gruppi.
Per gli autori, questo permette di evitare di scrivere versioni
differenti dei documenti per diversi clienti.
Per gruppi speciali come i chimici, i medici o i matematici, questo
permette di costruire un profilo speciale usando elementi standard di
HTML insieme ad un gruppo di elementi appositamente disegnati per le
specifiche necessità.
Appendice A. DTD
*Questa appendice è normativa.*
Queste DTD e gli insiemi di entità formano una parte normativa di questa
specifica. L'insieme completo dei file delle DTD insieme con la
dichiarazione XML e il Catalogo Aperto SGML è incluso nel file zip
di questa specifica.
A.1 Definizione del Tipo di Documento
Queste DTD si avvicinano alle DTD di HTML 4. Verosimilmente quando
queste DTD verranno modularizzate, verrà adottato un modo di costruzione
delle DTD che corrisponda più strettamente a HTML 4.0.
XHTML-1.0-Strict
XHTML-1.0-Transitional
XHTML-1.0-Frameset
A.2 Insieme delle entità
Gli insiemi di entità di XHTML sono gli stessi di HTML 4, ma sono stati
modificati in modo da essere dichiarazioni di entità valide in XML 1.0.
Nota che l'entità per il segno dell'Euro (|€| or |€| or
|€|) è stata definita come parte di caratteri speciali.
Latin-1 characters
Special characters
Symbols
Appendix B. Limitazioni degli elementi
*Questa appendice è normativa.*
I seguenti elementi hanno limitazioni sugli elementi che possono essere
annidati (vedere la Sezione 4.9 <#h-4.9>). Questa proibizione si applica
a tutte le profondità di annidamento, cioè riguarda tutti gli elementi
discendenti.
|a|
non può contenere altri elementi |a|.
|pre|
non può contenere gli elementi |img|, |object|, |big|, |small|,
|sub|, or |sup|
|button|
non può contenere gli elementi |input|, |select|, |textarea|,
|label|, |button|, |form|, |fieldset|, |iframe| or |isindex|
|label|
non può contenere altri elementi |label|
|form|
non può contenere altri elementi |form|
Appendix C. Linee guida per la compatibilità con HTML
*Questa appendice è normativa.*
Questa appendice riassume le linee guida per gli autori che desiderano
che i loro documenti XHTML sia visualizzabili con gli user agent HTML
esistenti.
C.1 Istruzioni per il processo
E' necessario sapere che le istruzioni di processo sono visualizzabili
con alcuni user agent. Nota comunque che quando la dichiarazione XML non
viene inclusa in un documento, il documento può usare solo il carattere
di default codificato da UTF-8 or UTF-16.
C.2 Elementi vuoti
Includere uno spazio bianco prima della barra e della parentesi angolare
chiusa |/| e |>| di elementi vuoti, per esempio, |
|, |
| e
|
|. Inoltre, usare la sintassi
minimizzata per i tag degli elementi vuoti, per esempio, |
|, dato
che la sintassi alternativa |
| permessa da XML dà risultati
imprevisti con molti user agent esistenti.
C.3 Minimizzazione degli elementi e contenuto degli elementi vuoti
Data una istanza vuota di un elemento il cui modello di contenuto non è
|EMPTY| (per esempio, un titolo vuoto o un paragrafo) non usare la forma
mimimizzata (per esempio usa |
| e non ||).
C.4 Style sheet e script incorporati
Usare style sheet esterni se questi usano i caratteri |<| or |&| or
|]]>| or |--|. Usare script esterni se questi usano i caratteri |<| or
|&| or |]]>| or |--|. Nota che i parser XML possono rimuovere il
contenuto dei commenti. Comunque, la pratica comune di "nascondere" gli
script e gli style sheet all'interno di commenti rende il documento
compatibile con le vecchie versioni di browser, ma non lo rende
funzionante con implementazioni basate su XML.
C.5 Salto di linea all'interno dei valori dell'attributo
Evitare i salti di linea e i caratteri di spazi multipli all'interno dei
valori dell'attributo. Questi sono manipolati in maniera inconsistente
dagli user agent.
C.6 Isindex
Non comprendere più di un elemento |isindex| nel documento |head|.
L'elemento |isindex| è sconsigliato in favore dell'elemento |input|.
C.7 Gli attributi lang e xml:lang
Usare entrambi gli attributi |lang| and |xml:lang| quando si vuole
specificare il linguaggio di un elemento. Il valore dell'attributo
|xml:lang| ha la precedenza.
C.8 Identificatori di frammenti
In XML gli URI [RFC2396 <#ref-rfc2396>] che terminano con gli
identificatori di frammenti della forma |"#foo"| non si riferiscono a
elementi con un attributo |name="foo"|; piuttosto si riferiscono a
elementi con un attributo definito del tipo |ID|, per esempio
l'attributo |id| in HTML 4. Molti client HTML esistenti non supportano
l'uso degli attributi di tipo |ID| in questo modo, quindi devono essere
sostituiti valori identici per entrambi questi attributi in modo da
assicurare una compatibilità futura e retroattiva (e.g., |...|).
Inoltre, poichè l'insieme dei valori permessi per gli attributi di tipo
|ID| è molto più piccolo di quelli per il tipo |CDATA|, il tipo
dell'attributo |name| è stato cambiato in |NMTOKEN|. Questo attributo è
limitato in modo tale che possa avere solo gli stessi valori del tipo
|ID|, o come la produzione |Name| in XML 1.0 Sezione 2.5, produzione 5.
Sfortunatamente questa limitazione non può essere espressa nella DTD di
XHTML 1.0. A causa di questo cambiamento, si deve avere molta attenzione
quando si convertono i documenti HTML esistenti. I valori di questi
attributi devono essere unici all'interno del documento, validi, ed ogni
riferimento a questi identificatori di frammenti (sia interni che
esterni) dovrebbe essere aggiornato in modo che i valori vengano
cambiati durante la conversione.
Notare, in fine, che XHTML 1.0 ha disapprovato l'uso dell'attributo
|name| degli elementi |a|, |applet|, |form|, |frame|, |iframe|, |img|, e
|map|, e sarà eliminato da XHTML nella versioni successive.
C.9 Codifica dei caratteri
Per specificare la codifica dei caratteri nel documento, usare sia la
specifica dell'attributo di codifica nella dichiarazione xml (per
esempio, ||) sia una frase meta
http-equiv (per esempio, ||). Ha la precedenza il valore
dell'attributo di codifica dell'istruzione di processo xml.
C.10 Attributi booleani
Alcuni user agent HTML sono capaci di interpretare gli attributi
booleani quando questi appaiono nella loro forma completa
(non-minimizzata), come richiesto da XML 1.0. Notare che questo problema
non ha effetto sugli user agent conformi a HTML 4.0. Sono coinvolti i
seguenti attributi:|compact|, |nowrap|, |ismap|, |declare|, |noshade|,
|checked|, |disabled|, |readonly|, |multiple|, |selected|, |noresize|,
|defer|.
C.11 Il Document Object Model e XHTML
La Raccomandazione del Livello 1 del Document Object Model [DOM
<#ref-dom>] definisce le interfacce del modello dell'oggetto documento
per XML e HTML 4. Il modello di oggetto del documento di HTML 4
specifica che gli elementi e i nomi degli attributi di HTML vengono
restituiti in lettere maiuscole. Il modello di oggetto del documento XML
specifica che gli elementi e i nomi degli attributi vengono restituiti
in maiuscolo o minuscolo a seconda del caso in cui erano specificati. In
XHTML 1.0, gli elementi e gli attributi sono specificarti in lettere
minuscole. Questa apparente differenza può spiegata in due modi:
1. Le applicazioni che permettono l'accesso a documenti XHTML come tipo
di media su Internet |text/html| via DOM possono usare il DOM di
HTML e possono così assicurarsi che gli elementi e i nomi degli
attributi vengano ritornati in lettere maiuscole da queste interfacce.
2. Le applicazioni che permettono l'accesso a documenti XHTML come tipo
di media su Internet |text/xml| o |application/xml|, possono usare
anche il DOM di XML. Gli elementi e gli attributi saranno ritornati
in lettere minuscole. Inoltre, alcuni elementi XHTML possono o no
apparire nell'albero degli oggetti in quanto sono opzionali nel
modello di contenuto (per esempio l'elemento |tbody| all'interno di
|table|). Questo accade perchè in HTML 4.0 alcuni elementi possono
essere minimizzati in modo tale che il tag di apertura e di chiusura
sia entrambi omessi (una caratteristica di SGML). Questo non è
possibile in XML. Piuttosto che richiedere agli autori di documenti
di inserire elementi estranei, XHTML ha posto tali elementi come
opzionali. Le applicazioni si devono adattare a questo.
C.12 L'uso del carattere ampersand (&) nei valori degli attributi
Quando un valore di attributo contiene un ampersand (&), questo può
essere espresso come un riferimento ad una entità di tipo carattere (per
esempio, "|&|"). Per esempio, quando l'attributo |href|
dell'elemento |a| si riferisce ad uno script CGI con dei parametri, deve
essere espresso come
|http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user|
invece che |http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user|.
C.13 Cascading Style Sheets (CSS) e XHTML
Le Raccomandazioni di livello 2 dei Cascading Style Sheet [CSS2
<#ref-css2>] definiscono le proprietà di stile che vengono applicate
all'albero di analisi di un documento HTML o XML. Le differenze
nell'analisi produrranno risultati visivi o auditivi diversi a seconda
del selector usato. La traccia seguente ridurrà questo effetto per i
documenti che sono serviti senza modifiche in entrambi i tipi di media:
1. Gli style sheet CSS per XHTML dovrebbero usare i nomi degli elementi
e degli attributi in lettere minuscole.
2. Nelle tabelle, l'elemento tbody verrà dedotto dall'analizzatore
dello user agent HTML, ma non dall'analizzatore dello user agent
XML. Quindi si dovrebbe sempre aggiungere esplicitamente l'elemento
tbody se si vuole riferirsi a un selector CSS.
3. Dentro lo spazio dei nomi XHTML gli user agent si aspettano di
riconoscere l'attributo "|id|" come un attributo di tipo |ID|.
Quindi gli style sheet dovrebbero essere capaci di continuare usando
la sintassi abbreviata del selector "#" anche se lo user agent non
legge la DTD.
4. Dentro lo spazio dei nomi XHTML, gli user agent si aspettano di
riconoscere l'attributo "class". Quindi gli style sheet dovrebbero
essere capaci di continuare usando la sintassi abbreviata del
selector ".".
5. I CSS definiscono diverse regole di conformità per i documenti HTML
e XML; tenere in considerazione che le regole HTML si applicano ai
documenti XHTML distribuiti come HTML e le regole XML si applicano
ai documenti XHTML distribuiti come XML.
Appendix D. Ringraziamenti
*Questa appendice è informativa.*
Queste specifiche sono state scritte con la partecipazione dei membri
del gruppo di lavoro HTML del W3C:
Steven Pemberton, CWI (HTML Working Group Chair)
Murray Altheim, Sun Microsystems
Daniel Austin, AskJeeves (CNET: The Computer Network through July 1999)
Frank Boumphrey, HTML Writers Guild
John Burger, Mitre
Andrew W. Donoho, IBM
Sam Dooley, IBM
Klaus Hofrichter, GMD
Philipp Hoschka, W3C
Masayasu Ishikawa, W3C
Warner ten Kate, Philips Electronics
Peter King, Phone.com
Paula Klante, JetForm
Shin'ichi Matsui, Panasonic (W3C visiting engineer through September
1999)
Shane McCarron, Applied Testing and Technology (The Open Group
through August 1999)
Ann Navarro, HTML Writers Guild
Zach Nies, Quark
Dave Raggett, W3C/HP (W3C lead for HTML)
Patrick Schmitz, Microsoft
Sebastian Schnitzenbaumer, Stack Overflow
Peter Stark, Phone.com
Chris Wilson, Microsoft
Ted Wugofski, Gateway 2000
Dan Zigmond, WebTV Networks
Appendix E. Riferimenti
*Questa appendice è informativa.*
*[CSS2]*
"Cascading Style Sheets, level 2 (CSS2) Specification"
, B. Bos, H. W. Lie, C.
Lilley, I. Jacobs, 12 May 1998.
Ultima versione disponibile a: http://www.w3.org/TR/REC-CSS2
*[DOM]*
"Document Object Model (DOM) Level 1 Specification"
, Lauren Wood
/et al./, 1 October 1998.
Ultima versione disponibile a: http://www.w3.org/TR/REC-DOM-Level-1
*[HTML]*
"HTML 4.01 Specification"
, D. Raggett, A. Le
Hors, I. Jacobs, 24 December 1999.
Ultima versione disponibile a: http://www.w3.org/TR/html401
*[POSIX.1]*
"ISO/IEC 9945-1:1990 Information Technology - Portable Operating
System Interface (POSIX) - Part 1: System Application Program
Interface (API) [C Language]", Institute of Electrical and
Electronics Engineers, Inc, 1990.
*[RFC2046]*
"RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two:
Media Types" , N. Freed and N.
Borenstein, November 1996.
Disponibile all'indirizzo: http://www.ietf.org/rfc/rfc2046.txt. Note
that this RFC obsoletes RFC1521, RFC1522, and RFC1590.
*[RFC2119]*
"RFC2119: Key words for use in RFCs to Indicate Requirement Levels"
, S. Bradner, March 1997.
Disponibile all'indirizzo: http://www.ietf.org/rfc/rfc2119.txt
*[RFC2376]*
"RFC2376: XML Media Types" , E.
Whitehead, M. Murata, July 1998.
Disponibile all'indirizzo: http://www.ietf.org/rfc/rfc2376.txt
*[RFC2396]*
"RFC2396: Uniform Resource Identifiers (URI): Generic Syntax"
, T. Berners-Lee, R. Fielding,
L. Masinter, August 1998.
Questo documento aggiorna gli RFC1738 e RFC1808.
Disponibile all'indirizzo: http://www.ietf.org/rfc/rfc2396.txt
*[XML]*
"Extensible Markup Language (XML) 1.0 Specification"
, T. Bray, J. Paoli, C.
M. Sperberg-McQueen, 10 February 1998.
Ultima versione disponibile a: http://www.w3.org/TR/REC-xml
*[XMLNAMES]*
"Namespaces in XML"
, T. Bray, D.
Hollander, A. Layman, 14 January 1999.
Lo spazio dei nomi XML fornisce un metodo semplice per qualificare i
nomi usati nei documenti XML associandoli con lo spazio dei nomi
identificati da una URI.
Ultima versione disponibile a: http://www.w3.org/TR/REC-xml-names
Level Triple-A conformance icon, W3C-WAI Web Content Accessibility
Guidelines 1.0
------------------------------------------------------------------------
indice <#toc>