Contents
Le seguenti note sono informative, non normative. Nonostante la presenza di parole quali "deve" e "dovrebbe", tutti i requisiti citati in questa sezione appaiono in altro luogo delle specifiche.
Queste specifiche non definiscono come i programmi utente conformi gestiscono delle condizioni di errore generali, compreso il modo in cui i programmi utente si comportano quando incontrano elementi, attributi, valori di attributo o entità non specificati in questo documento.
Tuttavia, per facilitare la sperimentazione e l'interoperabilità tra implementazioni di differenti versioni di HTML, si raccomandano i seguenti comportamenti:
Si raccomanda anche che i programmi utente forniscano supporto per notificare all'utente simili errori.
Poiché i programmi utente possono variare nel modo in cui gestiscono le condizioni di errore, autori ed utenti non devono fare affidamento su uno specifico comportamento di recupero dell'errore.
Le specifiche HTML 2.0 ([RFC1866]) osservano che molti programmi utente assumono che un documento, che non cominci con una dichiarazione del tipo di documento, rinvii alle specifiche HTML 2.0. Dal momento che l'esperienza ha mostrato che si tratta di un'assunzione insoddisfacente, le specifiche correnti non raccomandano questo comportamento.
Per ragioni di interoperabilità, gli autori non devono "estendere" l'HTML attraverso i meccanismi SGML disponibili (ad es., estendendo la DTD, aggiungendo un nuovo insieme di definizioni di entità, ecc.).
Benché gli URI non contengano valori non-ASCII (si veda [URI], sezione 2.1), gli autori talvolta li specificano in valori di attributo che prevedono URI (definiti cioè con %URI; nella DTD). Ad esempio, il seguente valore di href è illegale:
<A href="http://tizio.org/Håkon">...</A>
Si raccomanda che i programmi utente adottino la seguente convenzione per gestire caratteri non-ASCII in casi simili:
Questa procedura dà come risultato un URI sintatticamente legale (come definito in [RFC1738], sezione 2.2 o [RFC2141], sezione 2) che è indipendente dalla codifica dei caratteri nella quale il documento HTML che contiene l'URI può essere stato transcodificato.
Nota. Alcuni programmi utente più datati elaborano grossolanamente gli URI in HTML, utilizzando i byte propri della codifica dei caratteri in cui il documento è stato ricevuto. Alcuni dei documenti HTML più vecchi fanno affidamento su questa pratica e risultano danneggiati da una transcodifica. I programmi utente che desiderano gestire questi documenti più vecchi dovrebbero, nel ricevere un URI contenente caratteri al di fuori dell'insieme legale, in primo luogo usare la conversione basata su UTF-8. Soltanto se l'URI risultante non viene risolto, dovrebbero cercare di costruire un URI basato sui byte della codifica dei caratteri in cui il documento era stato ricevuto.
Nota. La medesima conversione basata su UTF-8 dovrebbe essere applicata ai valori dell'attributo name per l'elemento A.
L'URI che è costruito quando un modulo viene inoltrato può essere usato come un collegamento stile-ancora (es., l'attributo href per l'elemento A). Purtroppo, l'uso del carattere "&" per separare i campi di un modulo interagisce con il suo uso nei valori di attributo SGML per delimitare i riferimenti ad entità carattere. Per esempio, l'uso dell'URI "http://nodo/?x=1&y=2" come un URI di collegamento, deve essere scritto <A href="http://nodo/?x=1&y=2"> o <A href="http://nodo/?x=1&y=2">.
Si raccomanda agli sviluppatori di server HTTP e, in particolare, agli sviluppatori di CGI di supportare l'uso di ";" al posto di "&", per liberare gli autori dal problema di evitare i caratteri "&" con tale sistema.
SGML (si veda [ISO8879], sezione 7.6.1) specifica che un'interruzione di riga immediatamente successiva ad un marcatore iniziale deve essere ignorata, così come un'interruzione di riga immediatamente precedente un marcatore finale. Ciò si applica a tutti gli elementi HTML senza eccezione.
I seguenti due esempi HTML devono essere riprodotti in modo identico:
<P>Tommaso sta guardando la TV.</P>
<P> Tommaso sta guardando la TV. </P>
E lo stesso vale per questi altri due esempi:
<A>Il mio sito Web preferito</A>
<A> Il mio sito Web preferito </A>
Dati di script e di style possono apparire come contenuto di un elemento o come valori di attributo. Le seguenti sezioni descrivono il confine tra il codice di marcatura HTML e i dati esterni.
Nota. La DTD definisce i dati di script e di stile come CDATA sia per il contenuto di elementi sia per i valori di attributo. Le regole SGML non consentono i riferimenti a caratteri nel contenuto CDATA di elementi ma lo permettono nei valori CDATA di attributo. Gli autori dovrebbero porre una particolare attenzione nel tagliare e incollare dati di script e di stile tra contenuto di elementi e valori di attributo.
Questa asimmetria implica anche che, durante la transcodifica da una codifica dei caratteri più ricca ad una più povera, il convertitore non può semplicemente sostituire nei dati di script o di stile i caratteri non convertibili con i corrispondenti riferimenti numerici a caratteri; esso deve analizzare il documento HTML e conoscere la sintassi di ciascun linguaggio di script e di stile, allo scopo di elaborare correttamente i dati.
Quando dati di script o di stile sono il contenuto di un elemento (SCRIPT e STYLE), i dati cominciano immediatamente dopo il marcatore iniziale dell'elemento e terminano in corrispondenza del primo delimitatore ETAGO ("</") seguito da un carattere iniziale di nome ([a-zA-Z]); si noti che questo può non essere il marcatore finale dell'elemento. Gli autori dovrebbero perciò evitare "</" all'interno del contenuto. I meccanismi di fuga sono specifici per ciascun linguaggio di script o di fogli di stile.
ESEMPIO ILLEGALE:
I seguenti dati di script contengono in modo non corretto una
sequenza "</" (come parte di "</EM>") prima del
marcatore di chiusura SCRIPT:
<SCRIPT type="text/javascript">
document.write ("<EM>Questo non funzionerà</EM>")
</SCRIPT>
In JavaScript, questo codice può essere espresso legalmente nascondendo il delimitatore ETAGO prima del carattere iniziale di un nome SGML:
<SCRIPT type="text/javascript">
document.write ("<EM>Questo funzionerà<\/EM>")
</SCRIPT>
In Tcl, si può ottenere lo stesso risultato in questo modo:
<SCRIPT type="text/tcl">
document write "<EM>Questo funzionerà<\/EM>"
</SCRIPT>
In VBScript, il problema può essere evitato grazie alla funzione Chr():
"<EM>Questo funzionerà<" & Chr(47) & "EM>"
Quando i dati di script o di stile sono i valori di un attributo (o style o gli attributi di eventi intrinseci), gli autori dovrebbero evitare le occorrenze delle virgolette singole o doppie di delimitazione all'interno del valore, seguendo la convenzione propria del linguaggio di script o di stile. Inoltre gli autori dovrebbero evitare le occorrenze di "&", se la "&" non rappresenta l'inizio di un riferimento a carattere.
Così, per esempio, si potrebbe scrivere:
<INPUT name="num" value="0"
onchange="if (compare(this.value, "aiuto")) {riceviaiuto()}">
È previsto che i sistemi SGML conformi a [ISO8879] riconoscano una serie di caratteristiche che non sono largamente supportate dai programmi utente HTML. Si raccomanda agli autori di evitare l'uso di tutte queste caratteristiche.
Gli autori dovrebbero essere informati che molti programmi utente riconoscono soltanto la forma minimizzata degli attributi booleani e non la forma completa.
Ad esempio, gli autori possono specificare:
<OPTION selected>
invece di
<OPTION selected="selected">
Le sezioni marcate giocano un ruolo simile a quello del costrutto #ifdef riconosciuto dai preprocessori C.
<![INCLUDE[ <!-- questo sarà incluso --> ]]> <![IGNORE[ <!-- questo sarà ignorato --> ]]>
SGML definisce anche l'uso di sezioni marcate per contenuti CDATA, all'interno delle quali "<" non è trattato come l'inizio di un marcatore, ad es.:
<![CDATA[ <un> esempio di marcatura <sgml> che non si <preoccupa> di scrivere usando < e simili. ]]>
Il segno rivelatore che un programma utente non riconosce una sezione marcata è l'apparizione di "]]>", che compare quando il programma utente usa erroneamente il primo carattere ">" come la fine del marcatore che comincia con "<![".
Le istruzioni di elaborazione sono un meccanismo per catturare idiomi specifici di una piattaforma. Un'istruzione di elaborazione comincia con <? e termina con >
<?istruzione >
Ad esempio:
<?> <?style tt = font courier> <?page break> <?experiment> ... <?/experiment>
Gli autori dovrebbero essere informati che molti programmi utente riproducono le istruzioni di elaborazione come parte del testo di un documento.
Alcuni costrutti SGML abbreviati [SHORTTAG] fanno risparmiare caratteri ma non aggiungono capacità espressive all'applicazione SGML. Benché questi costrutti non introducano tecnicamente delle ambiguità, riducono la robustezza dei documenti, specialmente quando il linguaggio viene accresciuto con l'inclusione di nuovi elementi. Perciò, mentre i costrutti abbreviati di SGML riferiti ad attributi sono largamente usati ed implementati, quelli riferiti ad elementi non lo sono altrettanto. I documenti che li adoperano sono documenti SGML conformi, ma è probabile che molti degli strumenti per HTML esistenti non siano in grado di gestirli.
I costrutti abbreviati in questione sono i seguenti:
<nome/.../
<nome1<nome2>
<>
</>
Questa sezione fornisce alcuni semplici suggerimenti che renderanno i vostri documenti più accessibili ai motori di ricerca.
<LINK rel="alternate"
type="text/html"
href="miodoc-fr.html" hreflang="fr"
lang="fr" title="La vie souterraine">
<LINK rel="alternate"
type="text/html"
href="miodoc-de.html" hreflang="de"
lang="de" title="Das Leben im Untergrund">
<META name="keywords" content="vacanze,Grecia,sole"> <META name="description" content="Vacanze europee idilliache">
<LINK rel="start"
type="text/html"
href="pagina1.html"
title="Teoria generale della relatività">
Ci si può sorprendere di trovare che il proprio sito sia stato indicizzato da un robot di indicizzazione e che non si sarebbe dovuto permettere al robot di visitare una parte del sito contenente dati sensibili. Molti webrobot offrono strumenti agli amministratori di siti web e ai fornitori di contenuti per limitare l'azione dei robot. Ciò si ottiene attraverso due meccanismi, descritti sotto: un file "robots.txt" e l'elemento META in documenti HTML.
Quando un robot visita un sito web, diciamo http://www.qualsiasi.com/, per prima cosa controlla se c'è http://www.qualsiasi.com/robots.txt. Se trova questo documento, analizzerà il suo contenuto per vedere se è consentito recuperare il documento. È possibile personalizzare il file robots.txt in modo che si applichi solo a specifici robot, e per disabilitare specifiche cartelle o file.
Ecco un file robots.txt esemplificativo, che proibisce a tutti i robot di visitare l'intero sito
User-agent: * # si applica a tutti i robot
Disallow: / # impedisce l'indicizzazione di tutte le pagine
Il robot cercherà semplicemente un URI "/robots.txt" sul vostro sito, dove un sito è definito come un server HTTP attivo su un particolare computer e numero di porta. Ecco alcune posizioni esemplificative per robots.txt:
| URI del sito | URI di robots.txt |
|---|---|
| http://www.w3.org/ | http://www.w3.org/robots.txt |
| http://www.w3.org:80/ | http://www.w3.org:80/robots.txt |
| http://www.w3.org:1234/ | http://www.w3.org:1234/robots.txt |
| http://w3.org/ | http://w3.org/robots.txt |
Può esserci soltanto un singolo "/robots.txt" su un sito. In particolare, non è possibile collocare file "robots.txt" nelle cartelle degli utenti, perché un robot non cercherà mai in esse. Se volete che i vostri utenti possano creare i propri "robots.txt", dovete fonderli tutti insieme in un singolo "/robots.txt". Se non vi sta bene questa soluzione, i vostri utenti potrebbero adoperare invece il Metatag Robot.
Alcune indicazioni: gli URI sono sensibili alla forma maiuscola-minuscola, e la stringa "/robots.txt" deve essere tutta in lettere minuscole. Non sono consentite righe vuote all'interno di un singolo record del file "robots.txt".
Deve esserci esattamente un campo "User-agent" per record. Il robot dovrebbe essere liberale nell'interpretare questo campo. Per il nome si raccomanda una corrispondenza di sottostringa indifferente a maiuscole/minuscole, senza informazioni sulla versione.
Se il valore è "*", il record descrive il comportamento di accesso predefinito di un robot che non abbia analizzato nessuno degli altri record. Non è consentito di avere più record di questo tipo nel file "/robots.txt".
Il campo "Disallow" specifica un URI parziale che non deve essere visitato. Può essere un percorso completo oppure un percorso parziale; ciascun URI che cominci con questo valore non sarà recuperato. Ad esempio:
Disallow: /help proibisce sia /help.html sia /help/index.html, laddove
Disallow: /help/ proibirebbe /help/index.html ma consentirebbe /help.html.
Un valore vuoto per "Disallow" indica che tutti gli URI possono essere recuperati. Almeno un campo "Disallow" deve essere presente nel file robots.txt.
L'elemento META consente agli autori HTML di dire ai robot che visitano il sito se un documento può essere indicizzato o usato per raccogliere più collegamenti. Non è richiesto alcun intervento di amministrazione del server.
Nell'esempio successivo, un robot non dovrebbe né indicizzare questo documento né analizzarlo in cerca di collegamenti.
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
L'elenco di termini nel contenuto è ALL, INDEX, NOFOLLOW, NOINDEX.
Nota. Ai primi del 1997 solo pochi robot implementano ciò, ma si attende che la situazione cambi non appena una maggiore attenzione pubblica sarà riversata sul controllo dei robot di indicizzazione.
Il modello di tabella HTML è evoluto da studi su esistenti modelli di tabella SGML, dal trattamento delle tabelle nei comuni pacchetti di videoscrittura e da un'ampia gamma di tecniche di impaginazione tabellare in riviste, libri ed altri documenti di tipo cartaceo. Il modello fu scelto per consentire che semplici tabelle fossero espresse in modo semplice, con una complessità aggiuntiva disponibile in caso di necessità. Ciò rende pratico creare la marcatura di tabelle HTML con comuni editori di testo e riduce la curva di apprendimento necessaria per cominciare. Questa caratteristica è stata molto importante per il successo dell'HTML fino ad oggi.
In misura crescente si creano ora tabelle convertendole da altri formati di documento o generandole direttamente per mezzo di editori visuali. È importante che il modello di tabella HTML si adatti bene a questi strumenti autoriali. Ciò influenza il modo in cui le celle che si estendono su righe o colonne multiple sono rappresentate, ed il modo in cui l'allineamento ed altre proprietà di presentazione sono associati con gruppi di celle.
Una delle principali considerazioni circa il modello di tabella HTML è che l'autore non controlla il modo in cui un utente dimensionerà una tabella, quali caratteri adopererà, ecc. Ciò rende rischioso affidarsi a larghezze di colonna specificate in termini di unità assolute espresse in pixel. Al contrario, le tabelle devono essere in grado di cambiare dimensione dinamicamente così da corrispondere alla dimensione della finestra corrente ed ai caratteri. Gli autori possono fornire un'indicazione per quanto riguarda le larghezze relative delle colonne, ma i programmi utente dovrebbero garantire che le colonne siano sufficientemente ampie da riprodurre la larghezza dell'elemento più largo tra i contenuti di cella. Se le dimensioni specificate dall'autore devono essere sovrascritte, le larghezze relative delle singole colonne non dovrebbero subire cambiamenti drastici.
In caso di tabelle grandi o connessioni di rete lente, è importante per la soddisfazione dell'utente la visualizzazione incrementale delle tabelle. I programmi utente dovrebbero essere in grado di cominiciare la visualizzazione di una tabella prima che tutti i suoi dati siano stati ricevuti. La larghezza predefinita della finestra per la maggior parte dei programmi utente mostra all'incirca 80 caratteri, e gli elementi grafici di molte pagine HTML sono progettati con queste misure in mente. Specificando il numero di colonne e includendo informazioni per il controllo della larghezza della tabella e delle larghezze delle differenti colonne, gli autori possono fornire ai programmi utente suggerimenti che consentono la visualizzazione incrementale dei contenuti di tabella.
Per la visualizzazione incrementale, ai borwser occorre il numero di colonne e la loro larghezza. La larghezza predefinita della tabella è la dimensione corrente della finestra (width="100%"). Ciò può essere alterato impostando l'attributo width dell'elemento TABLE. Per impostazione predefinita, tutte le colonne hanno la medesima larghezza, ma è possibile specificare le larghezze di colonna per mezzo di uno o più elementi COL prima che comincino i dati della tabella.
Il problema rimanente è il numero di colonne. Alcuni hanno suggerito di attendere finché la prima riga della tabella sia stata ricevuta, ma questo potrebbe richiedere molto tempo se nelle celle vi è una gran quantità di contenuti. In generale ha più senso, quando si desidera una visualizzazione incrementale, permettere che gli autori specifichino esplicitamente il numero delle colonne nell'elemento TABLE.
Gli autori necessitano inoltre di un modo per dire ai programmi utente se utilizzare la visualizzazione incrementale o dimensionare automaticamente la tabella in modo da adattarla ai contenuti di cella. Nella modalità di autodimensionamento in due passaggi, il numero di colonne è determinato dal primo passaggio. Nella modalità incrementale, il numero di colonne deve essere definito in anticipo (tramite gli elementi COL o COLGROUP).
In HTML si distingue tra codice di marcatura strutturale, come paragrafi e citazioni, e stili di riproduzione, quali margini, caratteri, colori, ecc. In che modo tale distinzione influenza le tabelle? Dal punto di vista del purista, l'allineamento del testo all'interno delle celle di una tabella ed i bordi tra le celle sono un problema di riproduzione, non di struttura. Nella pratica, tuttavia, è utile raggruppare questi dati con l'informazione strutturale, dal momento che tali caratteristiche sono altamente portabili da un'applicazione alla successiva. Il modello di tabella HTML lascia la maggior parte delle informazioni di riproduzione a fogli di stile associati. Il modello presentato in queste specifiche è progettato per trarre vantaggio da codesti fogli di stile, ma non li richiede necessariamente.
Gli attuali pacchetti di applicativi per l'editoria forniscono un controllo molto sofisticato sulla rappresentazione di tabelle, e non sarebbe pratico riprodurre questo in HTML, senza trasformare l'HTML in un ingombrante formato "rich text" come RTF o MIF. Queste specifiche, tuttavia, offrono agli autori la possibilità di scegliere tra un insieme di classi comunemente adoperate di stili per i bordi. L'attributo frame controlla l'aspetto della cornice intorno alla tabella mentre l'attributo rules determina la scelta di filetti all'interno della tabella. Un livello di controllo più fine sarà supportato tramite annotazioni di riproduzione. L'attributo style può essere usato per specificare le informazioni di riproduzione di elementi individuali. Ulteriori informazioni per la riproduzione possono essere fornite con l'elemento STYLE nell'intestazione del documento o attraverso fogli di stile collegati.
Durante lo sviluppo di queste specifiche, sono state investigate una quantità di strade per determinare i modelli per governare le tabelle. Uno dei problemi riguarda i tipi di enunciazioni che è possibile fare. Includere il supporto per la sottrazione o per l'addizione di bordi conduce ad algoritmi relativamente complessi. Per esempio, il lavoro per consentire che il completo insieme di elementi di una tabella includa gli attributi frame e rules ha portato ad un algoritmo comprendente qualcosa come 24 passaggi, necessari per determinare se un particolare bordo di una cella dovesse essere filettato oppure no. Ma neppure questa complessità aggiuntiva fornisce un controllo sulla riproduzione sufficiente a coprire l'intera gamma di bisogni per le tabelle. Le specifiche correnti si fermano deliberatamente ad un semplice modello intuitivo, sufficiente per la maggior parte degli scopi. Occorre un ulteriore lavoro sperimentale prima che un approccio più complesso sia standardizzato.
Queste specifiche forniscono un sovrainsieme del più semplice modello presentato nel precedente lavoro su HTML+. Le tabelle sono considerate come costituite da una didascalia facoltativa e da una sequenza di righe, che a sua volta consiste in una sequenza di celle di tabella. Il modello distingue ulteriormente tra celle d'intestazione e celle di dati, e consente alle celle di estendersi su molteplici righe e colonne.
Seguendo il modello di tabella CALS (si veda [CALS]), queste specifiche permettono che le righe di tabella siano raggruppate nelle sezioni intestazione corpo e piede. Ciò semplifica la rappresentazione delle informazioni di riproduzione e può essere usato per ripetere le righe d'intestazione e piede di tabella nel caso di tabelle interrotte dai margini di pagina, o per fornire titoli bloccati al di sopra del riquadro scorrevole del corpo. Nel codice, la sezione piede è posizionata prima delle sezioni corpo. Si tratta di un'ottimizzazione condivisa con CALS per la gestione di tabelle molto lunghe. Ciò permette che il piede sia riprodotto senza dover aspettare che l'intera tabella sia elaborata.
Per i disabili visivi, HTML offre la speranza di impostazioni atte a riparare il danno causato dall'adozione di interfacce utente grafiche basate su finestre. Il modello di tabella HTML include attributi per etichettare ciascuna cella, onde supportare una conversione di alto livello del testo a sintesi vocale. I medesimi attributi possono anche essere utilizzati per supportare l'importazione e l'esportazione automatiche di dati tabellari verso basi di dati e fogli di calcolo.
Se sono presenti gli elementi COL o COLGROUP, essi specificano il numero delle colonne e la tabella può essere riprodotta utilizzando un'impaginazione fissa. In caso contrario dovrebbe essere usato l'algoritmo di autoimpaginazione descritto di seguito.
Se l'attributo width non è specificato, i programmi utente visuali dovrebbero assumere un valore predefinito di 100% per la formattazione.
Si raccomanda che i programmi utente aumentino la larghezza della tabella oltre il limite specificato da width nei casi in cui i contenuti di cella oltrepasserebbero altrimenti i margini. I programmi utente che sovrascrivono la larghezza specificata dovrebbero fare ciò in modo ragionevole. I programmi utente possono scegliere di separare le parole su più righe per evitare la necessità di un eccessivo scorrimento orizzontale o quando tale scorrimento sarebbe non pratico o indesiderato.
Ai fini dell'impaginazione, i programmi utente dovrebbero considerare che le didascalie di tabella (specificate per mezzo dell'elemento CAPTION) si comportano come celle. Ciascuna didascalia è una cella che si estende per tutte le colonne della tabella se è posta sopra o sotto la tabella, e per tutte le righe se posta al lato sinistro o destro della tabella.
Per questo algoritmo, si assume che il numero delle colonne sia noto. La larghezza delle colonne dovrebbe essere impostata in modo predefinito alla stessa dimensione. Gli autori possono sovrascrivere ciò specificando larghezze di colonna relative o assolute, utilizzando gli elementi COLGROUP o COL. La larghezza di tabella predefinita è lo spazio tra i margini correnti sinistro e destro, ma può essere sovrascritta tramite l'attributo width dell'elemento TABLE, o determinata dalle larghezze assolute di colonna. Per gestire mescolanze di larghezze assolute e relative di colonna, il primo passo è di allocare spazio dalla larghezza della tabella per le colonne con larghezze assolute. Fatto ciò, lo spazio rimanente viene ripartito tra le colonne con larghezze relative.
La sintassi di tabella da sola non è sufficiente a garantire la consistenza dei valori di attributo. Per esempio, il numero degli elementi COL e COLGROUP può essere inconsistente con il numero di colonne determinato dalle celle della tabella. Un ulteriore problema si verifica quando le colonne sono troppo strette per evitare che i contenuti di cella ne oltrepassino i limiti. La larghezza della tabella come specificata dall'elemento TABLE o dagli elementi COL può sfociare nell'oltrepassamento dei limiti da parte dei contenuti di cella. Si raccomanda che i programmi utente tentino di rimediare gradevolmente a queste siatuazioni, per es. dividendo in sillabe le parole e spezzandole se i punti di sillabazione sono ignoti.
Nell'eventualità che un elemento indivisibile causi l'oltrepassamento dei limiti di cella, il programma utente può valutare di aggiustare le larghezze di colonna e rigenerare la tabella. Nel caso peggiore, può essere preso in considerazione il ritaglio, qualora gli aggiustamenti delle larghezze di colonna e/o lo scorrimento dei contenuti di cella non siano possibili. In ogni caso, se il contenuto di cella viene spezzato o ritagliato, ciò dovrebbe essere segnalato all'utente in maniera adeguata.
Se il numero delle colonne non è specificato tramite gli elementi COL e COLGROUP, allora il programma utente dovrebbe usare il seguente algoritmo di autoimpaginazione. Esso si serve di due passaggi attraverso i dati della tabella ed effettua un ridimensionamento lineare della tabella.
Nel primo passaggio, l'a capo automatico è disabilitato ed il programma utente tiene traccia della larghezza minima e massima di ciascuna cella. La larghezza massima è data dalla riga più lunga. Poiché la funzione di a capo è stata disabilitata, i paragrafi sono trattati come singole righe lunghe a meno che non siano interrotti da elementi BR. La larghezza minima è data dal più largo elemento di testo (parola, immagine, ecc.), tenendo in considerazione il rientro dei margini e i pallini degli elenchi, ecc. In altre parole, è necessario determinare la larghezza minima che una cella richiederebbe in una finestra sua propria prima che la cella cominci a traboccare. Consentire ai programmi utente di spezzare le parole ridurrà la necessità di ricorrere allo scorrimento orizzontale o, nel peggiore dei casi, al ritaglio dei contenuti di cella.
Tale processo si applica anche a ciascuna tabella annidata che sia presente nel contenuto di cella. Le larghezze minime e massime delle celle nelle tabelle annidate sono usate per determinare le larghezze minime e massime di queste tabelle e perciò della stessa cella di tabella genitrice. L'algoritmo è lineare rispetto al totale dei contenuti di cella e, in linea di massima, indipendente dalla profondità di annidamento.
Per far fronte all'allineamento dei caratteri dei contenuti di cella, l'algoritmo conserva tre totali correnti min/max per ciascuna colonna: a sinistra del carattere di allineamento, a destra del carattere di allineamento e non allineato. La larghezza minima di una colonna è allora: max(min_left + min_right, min_non-aligned).
Le larghezze minime e massime delle celle sono poi usate per determinare le corrispondenti larghezze minime e massime delle colonne. Queste, a loro volta, sono usate per trovare la larghezza minima e massima della tabella. Si noti che le celle possono contenere tabelle annidate, ma ciò non complica il codice in modo significativo. Il passo successivo consiste nell'assegnare le larghezze alle colonne in ragione dello spazio disponibile (cioè lo spazio tra i margini correnti sinistro e destro).
Per le celle che si estendono su più colonne, un approccio semplice consiste nel distribuire le larghezze min/max uniformemente tra ciascuna delle colonne costituenti. Un approccio leggermente più complesso consiste nell'usare le larghezze min/max delle celle non estese su più colonne per influenzare il modo in cui le larghezze estese sono distribuite. Esperimenti suggeriscono che una mescolanza dei due approcci dà buoni risultati per un'ampia gamma di tabelle.
I bordi della tabella e i margini tra le celle devono essere inclusi nell'assegnazione delle larghezze di colonna. Si danno tre casi:
Per ciascuna colonna, sia d la differenza tra la larghezza massima e la minima di quella colonna. Ora si imposti la larghezza della colonna alla larghezza minima più d volte W fratto D. Ciò fa sì che le colonne con grandi differenze tra la larghezza minima e la massima siano più ampie delle colonne con piccole differenze.
Questo passo di attribuzione è poi ripetuto per le tabelle annidate, usando le larghezze minime e massime derivate per tutte le tabelle nel primo passaggio. In questo caso, la larghezza della cella di tabella genitrice gioca il ruolo della grandezza della finestra corrente nella descrizione precedente. Questo processo è ripetuto ricorsivamente per tutte le tabelle annidate. La tabella di livello più alto è quindi riprodotta usando le larghezze assegnate. Le tabelle annidate sono susseguentemente riprodotte come parte dei contenuti di cella della tabella genitrice.
Se la larghezza della tabella è specificata tramite l'attributo width, il programma utente tenta di impostare le larghezze di colonna in modo corrispondente. L'attributo width non è vincolante, se il suo uso sfocia in colonne aventi larghezze minori della loro larghezza minima (cioè indivisibile).
Se le larghezze relative sono specificate per mezzo dell'elemento COL, l'algoritmo è modificato in modo da aumentare le ampiezze di colonna oltre la larghezza minima, così da corrispondere ai vincoli di larghezza relativa. Gli elementi COL dovrebbero essere presi come semplici indicazioni, poiché le colonne non dovrebbero essere impostate a meno della loro larghezza minima. Analogamente, le colonne non dovrebbero essere rese così ampie da stirare la tabella ben oltre l'ampiezza della finestra. Se un elemento COL specifica una larghezza relativa di zero, la colonna dovrebbe sempre essere impostata alla sua larghezza minima.
Quando si usa l'algoritmo d'impaginazione in due passaggi, la posizione predefinita di allineamento, nell'assenza di un esplicito o ereditato attributo charoff, può essere determinata scegliendo la posizione che allineerebbe al centro le righe per le quali le larghezze prima e dopo il carattere di allineamento sono ai massimi valori per ciascuna delle righe nella colonna per la quale align="char". Se una serie di celle in righe differenti della stessa colonna usa un allineamento in base a caratteri, allora per impostazione predefinita tutte queste celle dovrebbero essere allineate, indipendentemente da quale sia il carattere usato per l'allineamento. Le regole per gestire oggetti troppo larghi per una colonna si applicano quando un allineamento esplicito o implicito genera una situazione in cui i dati eccedono la larghezza assegnata per la colonna.
Scelta dei nomi di attributo. Sarebbe preferibile scegliere valori per l'attributo frame consistenti con l'attributo rules e con i valori usati per l'allineamento. Per esempio: none, top, bottom, topbot, left, right, leftright, all. Sfortunatamente, SGML richiede che i valori di attributo elencati siano unici per ciascun elemento, indipendenti dal nome di attributo. Ciò causa immediati problemi per "none", "left", "right" e "all". I valori per l'attributo frame sono stati scelti per evitare conflitti con gli attributi rules, align e valign. Questo fornisce una misura di future correzioni, dal momento che è stato anticipato che gli attributi frame e rules saranno aggiunti ad altri elementi di tabella in future revisioni di queste specifiche. Un'alternativa potrebbe essere il rendere frame un attributo CDATA. L'opinione prevalente del Gruppo di Lavoro su HTML del W3C era che i benefici di poter usare gli strumenti di validazione SGML per verificare gli attributi basati sui valori elencati superano per importanza la necessità di nomi consistenti.
La visualizzazione incrementale di documenti ricevuti via rete fa sorgere alcuni problemi relativamente ai moduli. I programmi utente dovrebbero evitare che i moduli siano inoltrati prima che tutti gli elementi del modulo siano stati ricevuti.
La visualizzazione incrementale genera alcune criticità per quanto riguarda la navigazione tramite selettori. L'euristica di dare il fuoco al tabindex con il valore più basso nel documento sembra sufficientemente ragionevole ad una prima impressione. Tuttavia ciò implica dover aspettare finché non sia stato ricevuto tutto il testo del documento, poiché fino ad allora il tabindex con il valore più basso può ancora cambiare. Se l'utente schiaccia il tasto tab prima di allora, è ragionevole per i programmi utente spostare il fuoco al tabindex più basso attualmente disponibile.
Se i moduli sono associati con degli script lato cliente, sorgono ulteriori problemi potenziali. Per esempio, un gestore di script per un dato campo può far riferimento ad un campo che ancora non esiste.
Queste specifiche definiscono un insieme di elementi ed attributi sufficientemente potente da soddisfare la necessità generale di produrre moduli. Tuttavia c'è ancora spazio per molti possibili miglioramenti. Per esempio in futuro potrebbero essere risolti i seguenti problemi:
Un'altra possibile estensione consisterebbe nell'aggiungere l'attributo usemap ad INPUT per l'uso come mappa immagine lato cliente quando "type=image". L'elemento AREA corrispondente alla posizione cliccata fornirebbe il valore da passare al server. Per evitare il bisogno di modificare gli script server, può essere appropriato estendere AREA in modo da fornire valori x e y per l'uso con l'elemento INPUT.
Queste specifiche riservano una sintassi per il futuro supporto di macro di script negli attributi HTML CDATA. L'intenzione è di consentire che degli attributi siano impostati in base alle proprietà di oggetti che appaiono precedentemente nella pagina. La sintassi è:
attributo = "... &{ corpo della macro }; ... "
Il corpo della macro è costituito da una o più righe di codice nel linguaggio di script predefinito (come per gli attributi relativi a eventi intrinseci). Il punto e virgola che segue la parentesi graffa destra è sempre obbligatorio, poiché altrimenti il carattere parentesi graffa destra "}" è trattato come facente parte del corpo della macro. È inoltre importante notare che gli apici sono sempre obbligatori per gli attributi che contengono macro di script.
L'elaborazione di attributi CDATA procede come segue:
L'elaborazione delle macro avviene quando il documento è caricato (o ricaricato), ma non si verifica nuovamente quando il documento è ridimensionato, ridisegnato, ecc.
ESEMPIO DISAPPROVATO:
Seguono alcuni esempi che fanno uso di JavaScript. Il primo crea
un colore di sfondo casuale:
<BODY bgcolor='&{randomrgb};'>
Forse vuoi attenuare lo sfondo per la visione serale:
<BODY bgcolor='&{if(Date.getHours > 18)...};'>
Il prossimo esempio usa JavaScript per impostare le coordinate di una mappa immagine lato cliente:
<MAP NAME=pippo>
<AREA shape="rect" coords="&{miorect(uriimmagine)};" href="&{miouri};" alt="">
</MAP>
Questo esempio imposta la dimensione di un'immagine in base alle proprietà del documento:
<IMG src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner">
È possibile impostare l'URI di un collegamento o di un'immagine per mezzo di uno script:
<SCRIPT type="text/javascript">
function produttore(oggetto) {
...
}
function luogo(produttore) {
...
}
function logo(produttore) {
...
}
</SCRIPT>
<A href='&{luogo(produttore("oggetto"))};'>oggetto</A>
<IMG src='&{logo(produttore("oggetto"))};' alt="logo">
Questo esempio mostra come gli attributi SGML CDATA possano essere virgolettati usando singoli o doppi apici. Se usate apici singoli per racchiudere la stringa attributo, allora potete includere i doppi apici come parte della stringa attributo. Un altro approccio consiste nell'usare " per i doppi apici:
<IMG src="&{logo(produttore("oggetto"))};" alt="logo">
Poiché non esiste garanzia che un nome di frame di destinazione sia unico, è appropriato descrivere la pratica corrente nel trovare un frame, dato un nome di destinazione:
La Web Accessibility Initiative ([WAI]) del W3C sta producendo una serie di linee guida per migliorare l'accessibilità del Web per le persone con disabilità. Esistono tre insiemi di linee guida:
Ancore, immagini incorporate e tutti gli altri elementi che contengono URI come parametri possono avere come conseguenza che l'URI sia intercettato in risposta all'immissione di dati da parte dell'utente. In questo caso, dovrebbero essere considerati i problemi di sicurezza di [RFC1738], sezione 6. I metodi largamente impiegati per inoltrare richieste di moduli -- HTTP e SMTP -- forniscono poche garanzie di riservatezza. I fornitori di servizi informativi che richiedono informazioni sensibili per mezzo di moduli -- specialmente tramite l'elemento INPUT, type="password" -- dovrebbero essere attenti e rendere i propri utenti attenti alla mancanza di riservatezza.
Un programma utente non dovrebbe inviare alcun file che l'utente non abbia richiesto esplicitamente di inviare. Pertanto è previsto che i programmi utente HTML confermino ciascun nome di file che possa essere suggerito tramite l'attributo value dell'elemento INPUT. I controlli nascosti non devono specificare file.
Queste specifiche non contengono un meccanismo per la crittografia dei dati; questo aspetto dovrebbe essere gestito da qualsiasi altro meccanismo sia idoneo alla trasmissione sicura dei dati.
Una volta che un file sia stato spedito, l'agente di elaborazione dovrebbe elaborarlo e conservarlo appropriatamente.