Argomenti
Le seguenti note sono da ritenersi informative e non normative. Nonostante l'esistenza di termini quali "deve" o "dovrebbe", tutte le richieste di questa sezione appaiono anche altrove all'interno delle specifiche.
Queste specifiche non definiscono in che modo gli interpreti conformi gestiscono le condizioni generali di errore, incluso il loro comportamento di fronte ad elementi, attributi, valori di attributi o entità non specificati in questo documento.
Comunque, per facilitare la sperimentazione e l'interoperabilità tra le implementazioni delle varie versioni di HTML, vi raccomandiamo di seguire il seguente comportamento:
Raccommandiamo inoltre che gli interpreti provvedano a fornire un supporto agli utenti notificando questi errori.
Dal momento che gli interpreti possono variare il modo di gestire le condizioni di errore, gli autori e gli utenti non devono fidarsi del comportamento specifico di recupero degli errori.
Le specifiche HTML 2.0 ([RFC1866]) osservano che molti interpreti HTML 2.0 presumono che un documento che non abbia inizio con una dichiarazione del tipo di documento sia riferito alle specifiche dell'HTML 2.0. Come ci dimostra l'esperienza, questo è un assunto inesatto, le specifiche attuali non consigliano questo comportamento.
Per ragioni di interoperabilità, gli autori non devono "estendere" l'HTML mattraverso i meccanismi SGML (ad es., estendere le DTD, aggiungere un nuovo gruppo di definizioni alle entità, ecc.).
Anche se gli URI non contengono valori non ASCII (vedere [URI], paragrafo 2.1) a volte gli autori li specificano nei valori degli attributi che prevedono URI (ad es., definiti con %URI; nella DTD). Per esempio, il seguente valore href è illegale:
<A href="http://foo.org/Håkon">...</A>
In questi casi, raccomandiamo agli interpreti di adottare la seguente convenzione per gestire i caratteri non ASCII in alcuni casi:
Questa procedura risulta in un URI sintatticamente legale (come definito in [RFC1738], paragrafo 2.2 o [RFC2141], paragrafo 2) che è indipendente dalla codifica dei caratteri al quale il documento HTML portante l'URI possa essere stato transcodificato.
Nota. Alcuni vecchi interpreti trattano banalmente gli URI all'interno dell'HTML utilizzando i bytes della codifica dei caratteri del quale è stato ricevuto il documento. Alcuni vecchi documenti HTML riposano su questa pratica e si rompono nel momento della transcodifica. Gli interpreti che vogliono gestire questi vecchi documenti dovrebbero, nel momento in cui ricevono un URI contenente caratteri fuori dal gruppo legale, prima utilizzare la conversione basata su UTF-8. Solo se l'URI risultante non si risolve dovrebbero cercare di costruire un URI basato su byte della codifica dei caratteri nel quale il documento è stato ricevuto.
Nota. La stessa conversione basata su UTF-8 dovrebbe essere applicata ai valori dell'attributo name per l'elemento A.
L'URI che viene costruito quando un modulo è inviato può essere utilizzato come un collegamento simile ad un ancora (ad es., l'attributo href per l'elemento A). Sfortunatamente, l'utilizzo del carattere "&" per separare i campi del modulo interagisce con il suo utilizzo nei valori degli attributi SGML per delimitare i riferimenti dell'entità dei caratteri. Per esempio, per utilizzare l'URI "http://host/?x=1&y=2" in quanto Uri collegante, deve essere scritto <A href="http://host/?x=1&y=2"> oppure <A href="http://host/?x=1&y=2">.
Raccomandiamo che gli implementatori dei server HTTP, e in particolare, che gli implementatori CGI supportino l'utilizzo di ";" al posto di "&" per evitare agli autori il problema di dovere evitare i caratteri "&" in questo modo.
Il SGML (vedere [ISO8879], paragrafo 7.6.1) specifica che la riga di separazione immediatamente seguente un tag iniziale deve essere ignorata, essa deve interrompere la riga immediatamente prima di un tag di chiusura. Questo vale per tutti gli elementi HTML senza eccezione.
I due esempi seguenti di HTML devono essere presentati in modo indentico:
<P>Thomas guarda la TV.</P>
<P> Thomas guarda la TV. </P>
Lo stesso vale per questi altri due esempi:
<A>Il mio sito Web preferito</A>
<A> Il mio sito Web preferito </A>
Dati riguardanti gli script e lo stile possono apparire come contenuti di elementi o come valori degli attributi. I paragrafi seguenti descrivono i legami tra le marcature HTML e i dati estranei.
Nota. La DTD definisce i dati degli script e dello stile in quanto CDATA per entrambi i contenuti degli elementi e i valori degli attributi. Le regole SGML non permettono riferimenti ai caratteri in contenuti degli elementi in CDATA ma le permettono nei valori degli attributi CDATA. Gli autori dovrebbero essere particolarmente cauti nel tagliare e incollare i dati degli script e degli stili tra i contenuti degli elementi e i valori degli attributi.
Questa asimmetria significa anche che mentre avviene la transcodifica da un codice povero di caratteri ad uno più ricco;, il transcodificatore non può semplicemente rimpiazzare i caratteri inconvertibili in dati di script o di stile con i riferimenti numerici dei caratteri corrispondenti; deve analizzare il documento HTML e conoscere la sintassi del linguaggio relativo ad ogni script e stile in modo da trattare i dati correttamente.
Quando i dati dello script o dello stile sono il contenuto di un elemento (SCRIPT e STYLE), i dati iniziano immediatamente dopo il tag iniziale dell'elemento e finiscono al primo TAG ("</") che delimita seguito da un carattere di nome ([a-zA-Z]); notare che questo non può essere il tag finale dell'elemento. Gli autori dovrebbero dunque evitare "</" all'interno del contenuto. I meccanismi di escape sono specifici di ogni linguaggio di scripting o di foglio di stile.
ESEMPIO ILLEGALE:
I dati del seguente script contengono incorrettamente un'espressione "</"
(come parte di "</EM>") prima del tag finale dello SCRIPT:
<SCRIPT type="text/javascript">
document.write ("<EM>Questo non funzionerà</EM>")
</SCRIPT>
In JavaScript, questo codice può essere espresso legalmente nascondendo il delimitante TAG prima di un carattere di nome d'inizio SGML:
<SCRIPT type="text/javascript">
document.write ("<EM>Questo funzionerà<\/EM>")
</SCRIPT>
In Tcl, si può compiere come segue:
<SCRIPT type="text/tcl">
document write "<EM>Questo funzionerà<\/EM>"
</SCRIPT>
In VBScript, il problema può essere evitato con la funzione Chr():
"<EM>Questo funzionerà<" & Chr(47) & "EM>"
Quando i dati dello script o dello stile sono i valori di un attributo (sia style sia eventi intrinseci di attributi), gli autori dovrebbero evitare la presenza degli apici singoli o doppi di demarcazione all'interno del valore accordato dalla convenzione del linguaggio dello script o dello stile. Gli autori dovrebbero sempre evitare la presenza di "&" se "&" non è pensato in quanto inizio dei riferimenti ai caratteri.
Dunque, per esempio, si potrebbe scrivere:
<INPUT name="num" value="0"
onchange="if (compare(this.value, "help")) {gethelp()}">
I sistemi SGML conformi a [ISO8879] dovrebbero riconoscere un certo numero di caratteristiche che non vengono ampiamente supportate dagli interpreti. Raccomandiamo a tutti gli autori di evitare l'utilizzo della totalità di queste caratteristiche.
Gli autori dovrebbero fare attenzione che molti interpreti riconoscono solo la forma minimizzata degli attributi booleani e non la loro forma completa.
Per esempio, gli autori potrebbero specificare:
<OPTION selected>
invece di
<OPTION selected="selected">
Le sezioni marcate hanno un ruolo simile al costrutto #ifdef riconosciuto dai preprocessori C.
<![INCLUDE[ <!-- questo verrà incluso --> ]]> <![IGNORE[ <!-- questo sarà ignorato --> ]]>
SGML definisce anche l'utilizzo delle sezioni marcate per i contenuti di CDATA, all'interno del quale "<" non è trattato in quanto inizio di un tag. Per esempio:
<![CDATA[ <un> esempio di <sgml> una marcatura con la quale non è <difficile> scrivere con < e così via. ]]>
Il segno rivelatore sul fatto che un interprete non riconosce una sezione marcata sta nell'apparenza di "]]>", il quale viene visto quando un interprete utilizza in modo sbagliato il primo carattere ">" in quanto finale di tag iniziato con "<![".
Le istruzioni di elaborazione sono un meccanismo per catturare idiomi specifici di piattaforma. Un'istruzione di elaborazione inizia con <? e finisce con >
<?istruzione >
Per esempio:
<?> <?style tt = font courier> <?page break> <?experiment> ... <?/experiment>
Gli autori dovrebbero tenere conto che molti interpreti presentano le istruzioni di elaborazione come parte del testo dello stesso documento.
Alcune costruzioni SGML di tag brevi permettono di scrivere di meno ma non aggiungono nessuna capacità espressiva all'aplicazione SGML. Anche se queste costruzioni non introducono tecnicamente nessuna ambiguità, riducono la robustezza dei documenti, specialmente quando il linguaggio è potenziato in modo da includere nuovi elementi. Dunque, mentre costruzioni SGML di tag brevi relativi ad attributi vengono largamente utilizzate ed implementate, quelle relative agli elementi non lo sono. I documenti che ne fanno uso sono documenti SGML conformi, ma non funzioneranno con molti strumenti HTML.
Le costruzioni di tag brevi in questione sono le seguenti:
<name/.../
<name1<name2>
<>
</>
Questo paragrafo fornisce alcuni semplici suggerimenti che renderanno il vostro documento più accessibile ai motori di ricerca.
<LINK rel="alternate"
type="text/html"
href="mydoc-fr.html" hreflang="fr"
lang="fr" title="La vie souterraine">
<LINK rel="alternate"
type="text/html"
href="mydoc-de.html" hreflang="de"
lang="de" title="Das Leben im Untergrund">
<META name="keywords" content="vacanze,Grecia,sole">
<META name="description" content="vacanza europea idillica">
<LINK rel="begin"
type="text/html"
href="page1.html"
title="General Theory of Relativity">
Quando un robot visita un sito web, per esempio http://www.foobar.com/, innanzitutto controlla http://www.foobar.com/robots.txt. Se riesce a trovare questo documento, analizzerà i suoi contenuti per vedere se gli è permesso scaricare il documento. Potete personalizzare il file robots.txt per applicarlo solo a robot specifici, e per vietare l'accesso a directory o file specifici.
Ecco una serie di esempi di file robots.txt che impediscono a tutti i robot di visitare l'intero sito.
User-agent: * # vale per tutti i robot
Disallow: / # impedisce l'indicizzazione di tutte le pagine
Il robot cercherà un URI "/robots.txt" sul vostro sito, nel quale un sito viene definito in quanto server HTTP funzionante con un particolare numero di host e di porta. Ecco alcuni luoghi dove trovare file robots.txt:
| Siti URI | URI per file 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ò esistere solo un "/robots.txt" all'interno di un sito. Specificatamente, non si deve mettere il file "robots.txt" nelle directory degli utenti, perché un robot non li vedrà mai. Se si desidera che i propri utenti siano in grado di creare i loro propri "robots.txt", bisogna raggrupparli tutti all'interno di un singolo "/robots.txt". Se non si desidera arrivare a questa soluzione, i propri utenti potrebbero utilizzare i META tag robot.
Alcuni consigli: gli URI sono maiuscolo significativi, e la stringa "/robots.txt" deve essere scritta solo con le minuscole. Righe di spazio non sono permesse.
Deve esserci esattamente un campo per "interprete" per ogni record. Il robot dovrebbe essere libero di interpretare questo campo. è raccomandata una corrispondenza della sotto stringa maiuscolo indifferente del nome senza informazione di versione.
Se il valore è "*", il record descrive la norma di accesso predefinita per qualsiasi robot che non abbia corrisposto nessun record. Non è permesso avere tali record multipli nel file "/robots.txt".
Il campo "Disallow" (impedire) specifica un URI parziale da non visitare. Questo può essere un percorso intero o parziale; qualsiasi URI che inizia con questo valore non verrà recuperato. Per esempio,
Disallow: /help impedisce entrambi /help.html e /help/index.html, mentre
Disallow: /help/ impedisce /help/index.html ma permette /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 permette agli autori HTML di avvertire i robot visitanti se un documento può essere indicizzato o utilizzato per raccogliere più collegamenti. Non si necessita di nessuna azione dell'amministratore del server.
Nell'esempio seguente un robot non dovrebbe né indicizzare questo documento né analizzarlo per eventuali collegamenti.
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
La lista dei termini nel contenuto è ALL, INDEX, NOFOLLOW, NOINDEX. I valori del nome e del contenuto dell'attributo sono maiuscolo indifferenti.
Nota. All'inizio del 1997 solo pochi robot implementavano questo fattore, ma questo dovrebbe cambiare appena si avrà una maggiore attenzione dedicata al controllo dei robot indicizzatori.
Il modello di tabella HTML si è evoluto dagli studi sugli esistenti modelli di tabelle presenti in SGML, dal trattamento delle tabelle nei comuni pacchetti di word processing, e da un ampio gamma di tecniche d'impaginazione tabellare delle riviste, dei libri e di altri documenti cartacei. Il modello fu scelto per permettere di esprimere semplicemente tabelle semplici con una complessità disponibile appena necessaria. Questo rende pratica la creazione della marcatura delle tabella in HTML con gli editor di testi quotidiani e riduce la curva dell'apprendimento iniziale. Questa caratteristica è stata molto importante per il successo di HTML.
Le persone creano sempre più tabelle convertendo documenti da altri formati o creandoli direttamente con gli editori WYSIWYG. Rimane importante che il modello di tabelle HTML si integri bene con questi strumenti di creazione. Questo riguarda il modo in cui le celle, che si estendono per colonne o righe multiple, vengono rappresentate, e come l'allineamento e altre presentazioni sono associate con gruppi di celle.
Una considerazione importante riguardante il modello di tabelle HTML è che l'autore non deve controllare il modo nel quale l'utente dimensionerà una tabella, quali caratteri utilizzerà, ecc. E' rischioso affidarsi all'ampiezza delle colonne specificate in unità di pixel assolute. Invece, le tabelle devono essere capaci di cambiare dinamicamente la propria dimensione per coincidere con quella della finestra e la dimensione dei caratteri. Gli autori possono fornire una guida circa le ampiezze relative delle colonne, ma gli interpreti dovrebbero assicurare che le colonne siano abbastanza ampie da presentare la larghezza del più ampio elemento contenuto nella cella. Se le direttive dell'autore devono essere sovrascritte, le ampiezze relative delle singole colonne non dovrebbero drasticamente cambiare.
Per tabelle voluminose o per connessioni lente, l'utilizzo della visualizzazione incrementale delle tabelle risulta importante per soddisfare l'utente. Gli interpreti dovrebbero essere in grado di iniziare la visualizzazione della tabella prima di avere ricevuto tutti i dati. L'ampiezza predefita della finestra della maggior parte degli interpreti mostra circa 80 caratteri, e la grafica di molte pagine HTML viene pensata tenendo a mente questi requisiti predefiniti. Specificando il numero di colonne e includendo i provvedimenti di controllo dell'ampiezza della tabella e delle sue colonne, gli autori aiutano gli interpreti che permettono la visualizzazione incrementale dei contenuti della tabella.
Per la visualizzazione incrementale, i browser hanno bisogno di conoscere il numero di colonne e la loro ampiezza. L'ampiezza predefinita della tabella è la grandezza attuale della finestra (width="100%"). Questo può essere alterato impostando l'attributo width dell'elemento TABLE. Come predefinito, tutte le colonne hanno la stessa ampiezza, ma si possono specificare le ampiezze delle colonne con uno o più elementi COL prima dell'inizio dei dati relativi alla tabella.
Rimane la questione relativa al numero di colonne. Alcuni suggeriscono di aspettare il ricevimento della prima riga della tabella, ma questo potrebbe prendere troppo tempo se le celle contengono molto materiale. In generale, sembra più sensato, quando la visualizzazione incrementale è desiderata, chiedere agli autori di specificare esplicitamente il numero di colonne all'interno dell'elemento TABLE.
Gli autori hanno ancora bisogno di avvertire gli interpreti se utilizzare la visualizzazione incrementale o se dimensionare la tabella in modo automatico per adattare i contenuti delle celle. Nei due passaggi del modo di auto dimensionamento, il numero di colonne viene determinato dal primo passaggio. Nel metodo incrementale, il numero di colonne deve essere dichiarato all'inizio (con gli elementi COL oppure COLGROUP).
L'HTML distingue le marcature strutturali quali paragrafi, citazioni da idiomi di presentazione quali margini, caratteri, colori, ecc. In che modo queste distinzioni toccano le tabelle? Dal punto di vista del puritano, l'allineamento del testo all'interno delle celle di una tabella e i bordi tra le celle fanno parte delle problematiche di presentazione e non di struttura. In pratica, comunque, è utile raggruppare queste questioni all'interno dell'informazione strutturale, visto che queste caratteristiche sono altamente veicolabili da un'applicazione all'altra. Il modello di tabella HTML lascia la maggior parte dell'informazione relativa alla presentazione a fogli di stile associati. Il modello presentato in queste specifiche è destinato a prendere i vantaggi da tali fogli di stile senza che essi siano richiesti.
Gli attuali pacchetti di desktop publishing forniscono controlli molto
potenti per la presentazione delle tabelle, risulterebbe poco pratico
riprodurre ciò in HTML, senza fare diventare l'HTML un voluminoso formato di
testo arricchito come RTF o MIF. Queste specifiche offrono, comunque, agli
autori l'abilità di scegliere tra un'insieme di classi comunemente utilizzate
di stili per bordi. L'attributo relativo alle cornici frame controlla l'apparenza della cornice di
bordo intorno alla tabella mentre l'attributo relativo alle regole generali rules determina le scelte da seguire per
l'interno della tabella. Un livello più alto di controllo sarà supportato
attraverso annotazioni di presentazione. L'attributo style può essere utilizzato per specificare
informazione di presentazione per elementi individuali. Ulteriori informazioni
di presentazione possono essere fornite con l'elemento
Durante lo sviluppo di queste specifiche, varie possibilità furono ricercate per delineare le regole da seguire per le tabelle. Una questione riguarda i tipi di istruzioni possibili. Includere un supporto per la sottrazione dei bordi, così come per l'addizione, porta ad algoritmi relativamente complessi. Per esempio, il lavoro che permette di includere gli attributi frame e rules ad un insieme completo di elementi per tabelle portava ad un algoritmo che impiegava 24 passaggi per determinare se un bordo particolare di una cella dovesse essere tracciato oppure no. Perfino questa aggiunta complessità non fornisce abbastanza controllo di presentazione per permettere il ventaglio completo delle esigenze riguardanti le tabelle. Le specifiche correnti si attengono deliberatamente ad un modello semplice, intuitivo e sufficiente per la maggior parte degli utilizzi. Vi è la necessità di una maggiore sperimentazione prima di standardizzare un approccio più complesso.
Queste specifiche forniscono un gruppo ampliato del più semplice modello presentato nel lavoro passato, relativo all'HTML+. Le tabelle sono considerate come costituite da una didascalia opzionale e da una sequenza di righe, che poi consistono in una sequenza di celle di tabelle. Il modello seguente differenzia tra celle d'intestazione e di dati, e permette alle celle di espandersi in righe o colonne multiple.
Seguendo il modello di tabelle CALS (vedere [CALS]), queste specifiche permettono di raggruppare le righe delle tabelle all'interno delle sezioni destinate al corpo ed alla parte finale. In questo modo si semplifica la rappresentazione delle informazioni di presentazione e può essere utilizzato per ripetere testate di tabella e righe finali nell'interruzione per limiti di pagina, o per fornire intestazioni fisse sopra un pannello di corpo scorrevole. Nella marcatura, la sezione finale viene prima delle sezioni relative al corpo. Questa è un'ottimizzazione condivisa con CALS quando si lavora con tabelle molto lunghe. Permette di visualizzare la parte finale senza dovere attendere il trattamento dell'intera tabella.
Per i non vedenti, l'HTML offre un aiuto per rimediare al danno creato dall'adozione di presentazione a finestre degli interpreti grafici. Il modello di tabelle HTML include attributi per etichettare ogni cella, per supportare la conversione vocale di testi qualitativamente alti. Gli stessi attributi possono anche essere utilizzati per supportare importazioni ed esportazioni automatizzate di tabelle di dati da basi di dati o da fogli di calcolo.
Se gli attributi COL oppure COLGROUP sono presenti, essi specificano il numero di colonne e la tabella può essere presentata utilizzando una configurazione fissa. Altrimenti l'algoritmo di auto configurazione descrive di seguito cosa dovrebbe essere usato.
Se l'attributo width non è specificato, gli interpreti visuali HMTL devono assumere un valore predefinito a 100% per la formattazione.
E' raccomandato agli interpreti HTML di incrementare l'ampiezza delle tabelle oltre il valore specificato da width nei casi in cui i contenuti delle celle eccederebbero. Gli interpreti HTML che sovrascrivono l'ampiezza specificata devono farlo ragionevolmente. Gli interpreti possono scegliere di dividere parole in più righe per evitare l'eccessivo scorrimento orizzontale o quando tale scorrimento diventa poco pratico o indesiderato.
Per gli scopi di configurazione, gli interpreti dovrebbero considerare che le didascalie delle tabelle (specificate dall'elemento CAPTION) si comportano come le celle. Ogni didascalia è costituita da una cella si estende su tutte le colonne della tabella, se posizionata all'inizio o alla fine della stessa, e a tutte le righe se posizionata a destra o a sinistra della tabella.
Per questo algoritmo è assunto che si conosca il numero di colonne. Le ampiezze delle colonne per definizione dovrebbero essere della stessa dimensione. Gli autori possono sovrascrivere questo fattore specificando le ampiezze relative o assolute delle colonne, utilizzando gli elementi COLGROUP o COL. L'ampiezza predefinita della tabella è lo spazio tra i margini attuali di sinistra e di destra, ma possono essere sovrascritti utilizzando l'attributo width dell'elemento TABLE, o determinato dall'ampiezza assoluta delle colonne. Per occuparsi delle mescolanze di ampiezze assolute e relative delle colonne, il primo passo è di allocare spazio dall'ampiezza della tabella alle colonne con ampiezze assolute. Dopo di che, lo spazio rimanente verrà diviso tra le colonne con ampiezze relative.
La sintassi per tabelle da sola è insufficiente per garantire la coerenza dei valori degli attributi. Per esempio, il numero di elementi COL e COLGROUP possono essere incoerenti con il numero di colonne utilizzate dalle celle. Un ulteriore problema si verifica quando le colonne sono troppo vicine da impedire l'eccedenza del contenuto delle celle. L'ampiezza della tabella come specificato dall'elemento TABLE o COL può risultare nell'eccedenza dei contenuti delle celle. è raccomandato che gli interpreti tentino di rimediare garbatamente a queste situazioni, ad es., con parole sillababili e ricorrendo alla divisione delle parole se i punti di sillabazione sono sconosciuti.
Nel caso in cui un elemento indivisibile causi lo straripamento di una cella, l'interprete può considerare l'aggiustamento dell'ampiezza delle colonne e ripresentare la tabella. Nel peggiore dei casi, si può prendere in considerazione il taglio, se non è fattibile l'aggiustamento dell'ampiezza delle colonne e/o del contenuto delle celle scorrevoli. In ogni caso, se il contenuto della cella è diviso o tagliato dovrebbe essere indicato all'utente in modo appropriato.
Se il numero di colonne non é specificato con gli elementi COL e COLGROUP, allora l'interprete deve utilizzare l'algoritmo seguente di auto configurazione. Utilizza due passaggi attraverso i dati della tabella e scala linearmente con la dimensione della tabella.
Nel primo passo, l'interruzione di riga viene disabilitata e l'interprete
tiene traccia della minima e massima ampiezza di ogni cella. L'ampiezza
massima è data dalla linea più ampia. Visto che l'interruzione di riga è stata
disabilitata, i paragrafi sono trattati come linee lunghe tranne se interrotte
da elementi
Questo processo va anche applicato a qualsiasi tabella annidata occorrente nel contenuto di celle. Le ampiezze minime e massime per le celle, nelle tabelle annidate, sono utilizzate per determinare le ampiezze minime e massime per queste tabelle e dunque per le celle della tabella genitrice. L'algoritmo è lineare con l'aggregato contenuto cella e indipendente dalla profondità dell'annidamento.
Per l'allineamento dei caratteri del contenuto della cella, l'algoritmo continua a fare girare tre totali min/max per ogni colonna: Left of align char (sinistra dei caratteri allineati), Right of align char (destra dei caratteri allineati) e unalign (non allineati). L'ampiezza minima per una colonna è dunque: max(min_left + min_right, min_non-aligned).
Le ampiezze minime e massime delle celle sono dunque utilizzate per determinare le minime e massime ampiezze corrispondenti per le colonne. Quest'ultime sono utilizzate per trovare le ampiezze minime e massime della tabella. Notare che le celle possono contenere tabelle annidate ma questo non complica il codice in modo significativo. Il passo successivo consiste nell'assegnare le ampiezze alle colonne in base allo spazio disponibile (cioè, lo spazio tra i margini attuali di sinistra e di destra).
Per le celle che si espandono in colonne multiple, un approccio semplice consiste nel porzionare equamente le ampiezze minime e massime per ognuna delle costituenti colonne. Un approccio leggermente più complesso risulta dall'utilizzo delle ampiezze minime e massime delle celle non espanse per calcolare quanta ampiezza sia distribuita. Gli esperimenti ci suggeriscono che una miscela dei due approcci dia buoni risultati per un'ampia gamma di tabelle.
I bordi delle tabelle e i margini interni delle celle hanno bisogno di essere inclusi nelle ampiezze assegnate alle colonne. Esistono tre casi:
Per ogni colonna, lasciamo che d sia la differenza tra l'ampiezza massima e quella minima di questa colonna. Ora bisogna impostare l'ampiezza della colonna con l'ampiezza minima più d volte W diviso per D. Questo crea colonne con grosse differenze tra le ampiezze minime e massime, più ampie di colonne con differenze minori.
Questo passo di assegnazione viene ripetuto per le tabelle annidate usando le ampiezze minime e massime derivate per ogni tabella simile all'interno del primo passaggio. In questo caso, l'ampiezza della cella della tabella "madre" gioca un ruolo fondamentale nel dimensionamento della finestra attuale descritta prima. Questo processo viene ripetuto ricorrentemente per ogni tabella annidata. La tabella più alta è dunque presentata con ampiezze assegnate. Le tabelle annidate sono sotto-sequenzialmente presentate come parte del contenuto della cella della tabella genitrice.
Se l'ampiezza della tabella viene specificata con l'attributo width , l'interprete tenterà di abbinare l'impostazione dell'ampiezza delle colonne. L'attributo width non è legato a questo risultato nelle colonne che abbiano meno della loro minima ampiezza (cioé, indivisibili).
Se le ampiezze relative sono specificate con l'elemento COL, l'algoritmo viene modificato per aumentare l'ampiezza delle colonne oltre l'ampiezza minima per incontrare le costrizioni relative. Gli elementi COL dovrebbero solamente essere presi in quanto suggerimenti, per cui le colonne non dovrebbero avere meno della loro ampiezza minima. Similarmente, le colonne non dovrebbero essere troppo larghe da espandersi oltre l'estensione della finestra. Se un'elemento COL specifica un'ampiezza relativa di zero, la colonna dovrebbe avere sempre la propria ampiezza minima.
Quando si utilizza l'algoritmo di configurazione a due passaggi, la posizione di allineamento predefinito in assenza di un esplicito o ereditato attributo charoff può essere determinata scegliendo la posizione che centrerebbe le linee per cui le ampiezze, prima e dopo il carattere di allineamento, sono nei loro valori massimi per qualsiasi linea all'interno della colonna, per cui align="char". Per la configurazione incrementale delle tabelle, il valore predefinito suggerito è charoff="50%". Se più celle in differenti righe per la stessa colonna utilizzano l'allineamento dei caratteri, allora, come predefinito, tutte queste celle dovrebbero allinearsi, senza riguardo per il carattere utilizzato per l'allineamento. Le regole per la gestione degli oggetti troppo larghi per le colonne vengono applicate quando l'allineamento implicito o esplicito risulta in una situazione nella quale i dati eccedono l'ampiezza assegnata della colonna.
Scelta dei nomi degli attributi. Sarebbe preferibile scegliere i valori per l'attributo frame in modo coerente con l'attributo rules e i valori utilizzati per l'allineamento. Per esempio: none, top, bottom, topbot, left, right, leftright, all. Sfortunatamente l'SGML richiede che i valori degli attributi enumerati siano unici per ogni elemento, independentemente dal nome dell'attributo. Questo causa problemi immediati per "none" (nessuno), "left" (sinistra), "right" (destra) e "all" (tutti). I valori per l'attributo frame vennero scelti per evitare conflitti con gli attributi rules, align, e valign. Questo fornisce ulteriori capacità per prove future, come anticipato dagli attributi frame e rules che saranno aggiunti ad altri elementi di tabelle nelle revisioni future di queste specifiche. Un'alternativa sarebbe di rendere frame un attributo di CDATA. Il consenso del Gruppo di Lavoro HTML del W3C era basato sul fatto che i benefici apportati dall'utilizzo degli strumenti di convalida di SGML per controllare gli attributi basati sui valori enumerati era più importante rispetto alla necessità di nomi coerenti.
La visualizzazione incrementale dei documenti ricevuti dalla rete porta ad alcuni problemi relativi ai moduli. Gli interpreti dovrebbero aspettare che tutti gli elementi del modulo siano arrivati prima di rinviare il modulo compilato.
La visualizzazione incrementale dei documenti porta delle problematiche relative alla navigazione assistita dai tasti di tabulazione. L'euristica che da più peso al meno valutato tabindex all'interno del documento sembra abbastanza ragionevole a prima vista. In ogni caso, questo significa attendere che tutto il documento sia ricevuto, perché fino a quel momento, il meno valutato tabindex può ancora variare. Se l'utente schiaccia il tasto TAB prima, per gli interpreti è ragionevole spostare il fuoco sul minore tabindex disponibile al momento.
Se i moduli sono associati con script sul lato client, esistono ulteriori potenziali problemi. Per esempio, un gestore di script per un dato campo può riferirsi ad un campo che non esiste ancora.
Queste specifiche definiscono un gruppo di elementi e di attributi abbastanza potenti da soddisfare il bisogno generale nelle creazioni di moduli. In ogni caso, c'è ancora molto spazio per eventuali migliorie. Per esempio i seguenti problemi potrebbero essere posti nel futuro:
Una ulteriore possibile estensione potrebbe essere consistere
nell'aggiungere l'attributo usemap all'INPUT per utilizzarlo in come mappa sensibile sul
lato cliente quando "type=image". L'elemento
Queste specifiche prevedono una sintassi per un futuro supporto delle macro di script negli attributi CDATA in HTML. L'intenzione è di permettere agli attributi di essere impostati in maniera dipendente dalle proprietà degli oggetti che appaiono precedentemente nella pagina. La sintassi è :
attribute = "... &{ macro body }; ... "
Il corpo della macro è formato da uno o più dichiarazioni nel linguaggio predefinito dello scripting (come per gli attributi di eventi intriseci). Il punto e virgola che segue la parentesi graffa chiusa è sempre necessario, altrimenti il carattere della parentesi graffa chiusa "}" viene trattato come facente parte del corpo della macro. E' anche utile notare che si devono sempre utilizzare i doppi apici per gli attributi contenenti macro di script.
Il trattamento degli attributi CDATA procede come di seguito:
Il trattamento delle macro avviene quando il documento viene caricato (o ricaricato) ma non avviene quando il documento viene ridimensionato, ridipinto, ecc.
ESEMPIO DISAPPROVATO:
Ecco alcuni esempi che utilizzano JavaScript. Il primo rende casuale il colore
di sfondo del documento:
<BODY bgcolor='&{randomrbg};'>
Forse si desidera abbassare l'intensità luminosa dello sfondo per una visita serale:
<BODY bgcolor='&{if(Date.getHours > 18)...};'>
Il prossimo esempio utilizza JavaScript per dare delle coordinate per una mappa sensibile sul lato cliente:
<MAP NAME=foo>
<AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
</MAP>
Quest'esempio imposta la dimensione di un'immagine basata sulle proprietà del documento:
<IMG src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner">
Si può impostare l'URI per un collegamento o un'immagine mediante uno script:
<SCRIPT type="text/javascript">
function manufacturer(widget) {
...
}
function location(manufacturer) {
...
}
function logo(manufacturer) {
...
}
</SCRIPT>
<A href='&{location(manufacturer("widget"))};'>widget</A>
<IMG src='&{logo(manufacturer("widget"))};' alt="logo">
Quest'ultimo esempio mostra come gli attributi CDATA di SGML possono essere citati usando apici singoli o doppi. Se utilizzate apici singoli intorno alla stringa dell'attributo allora potete includere quelli doppi in quanto parte della stringa dell'attributo. Un'altro approccio può essere quello di utilizzare " per i doppi apici:
<IMG src="&{logo(manufacturer("widget"))};" alt="logo">
Visto che non esiste una garanzia riguardo all'unicità del nome adoperato da un frame, è appropriato descrivere la pratica corrente per trovare un frame dato il nome di destinazione:
Nota. Il seguente algoritmo per generare testo alternativo può essere sostiuito dalle direttive del gruppo d'iniziativa per l'accessibilità al Web del W3C. Consultare [WAIGUIDE] per maggiori informazioni.
Quando un autore non imposta l'attributo alt per gli elementi IMG o APPLET, gli interpreti dovrebbero fornire il testo alternativo, calcolato nell'ordine seguente:
Quando l'autore non imposta l'attributo alt per l'elemento INPUT, gli interpreti devono fornire il testo alternativo, calcolato in questo ordine:
Ancore, immagini incorporate, e tutti gli altri elementi che contengono gli URI come parametri possono causare all'URI di essere dereferenziato in risposta all'input dell'utente. In questo caso, il problema della sicurezza del [RFC1738], paragrafo 6, dovrebbe essere considerato. I metodi largamente sviluppati per inviare le richieste dei moduli -- HTTP e SMTP -- non forniscono quasi nessuna sicurezza di riservatezza. I fornitori d'informazione che richiedono informazione sensibile attraverso moduli -- specialmente con l'elemento INPUT, type="password" -- dovrebbero essere attenti e rendere consapevoli i loro utenti della mancanza di riservatezza.
Un interprete non dovrebbe inviare nessun file di cui l'utente non abbia
esplicitamente richiesto l'invio. Così, gli interpreti dovrebbero prevedere la
conferma di ogni nome di file predefinito che potrebbe essere suggerito
dall'attributo
Queste specifiche non contengono un meccanismo per la criptazione dei dati; questo dovrebbe essere gestito da qualsiasi altro meccanismo adibito alla sicurezza di trasmissione dei dati.
Una volta caricato il file, l'agente adibito all'elaborazione dovrebbe elaborarlo e archiviarlo appropriatamente.