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 uniformanti trattano le condizioni generali di errore, incluso il loro atteggiamento 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 consigliamo di seguire il seguente atteggiamento:
Consigliamo che gli interpreti provvedano a fornire un supporto agli utenti per notificare questi errori.
Visto che gli interpreti possono variare il modo di affrontare 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" i meccanismi SGML all'HTML (per esempio: estendere le DTD, aggiungere un nuovo gruppo di definizioni alle entità, etc.).
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 (per esempio, definiti con %URI; nella DTD). A proposito, il seguente valore href è illegale:
<A href="http://foo.org/Håkon">...</A>
In questi casi, consigliamo agli interpreti di adottare la seguente convenzione per trattare i caratteri non ASCII:
Questa procedura risulta in un URI sintatticamente legale (come definito in [RFC1738], paragrafo 2.2 o [RFC2141], paragrafo 2) che è indipendente dal codice 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 del codice 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 trattare 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 del codice 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">.
Consigliamo 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.
L'SGML (vedere [ISO8879], paragrafo 7.6.1) specifica che la riga di separazione immediatamente seguente un tag iniziale deve essere ignorata, così come una riga di separazione immediatamente dopo un tag di chiusura. Questo vale per tutti gli elementi HTML senza eccezione.
I due esempi seguenti di HTML devono essere resi 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 sapere 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 l'elemento del tag iniziale e finisce 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 delle virgolette singole o doppie 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 largamente supportate dagli interpreti. Consigliamo 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 rendono 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 nessuna ambiguità, tecnicamente, 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à scaricato. 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 scaricati. 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 dell'attributo del nome e del contenuto 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 tavola 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 spettro di tecniche d'impaginazione a tavola 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 HTML per tabelle si integri bene con questi strumenti di creazione. Questo riguarda il modo in cui le celle, che si estendono per colonne o file multiple, vengono rappresentate, e come l'allineamento altre presentazioni sono associate con gruppi di celle.
Una considerazione importante riguardante il modello HTML di tabelle è che l'autore non controlla il modo nel quale l'utente dimensionerà una tabella, quali caratteri utilizzerà, etc. Questo rende rischioso dipendere dalla larghezza delle colonne specificata in termini di unità di pixel assoluta. Invece, le tabelle devono essere capaci di cambiare misure dinamicamente per coincidere con la grandezza della finestra ed i suoi caratteri. Gli autori possono fornire una guida circa le relative larghezze delle colonne, ma gli interpreti dovrebbero assicurare che le colonne siano larghe abbastanza da rendere la larghezza del più ampio elemento contenuto nella cella. Se le direttive dell'autore devono essere tralasciate, le larghezze relative delle singole colonne non dovrebbero essere cambiate in modo troppo drastico.
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. La larghezza 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 della larghezza 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 larghezza. La larghezza predefinita della tabella è la grandezza attuale della finestra (width="100%"). Questo può essere modificato cambiando l'attributo relativo alla larghezza della tabella width dell'elemento relativo alla tabella TABLE. Come predefinito, tutte le colonne hanno la stessa larghezza, ma si possono specificare le larghezze 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 esplicitamente specificare 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 rimodellare la tabella in modo automatico per dimensionare i contenuti delle celle. Nei due passaggi di auto-ridimensionamento, 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 resa quali margini, caratteri, colori, etc. In che modo queste distinzioni toccano le tabelle? Dal punto di visata del purista, l'allineamento del testo all'interno delle celle di una tabella e i bordi tra le celle fanno parte delle problematiche di visualizzazione 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 HTML delle tabelle lascia la maggior parte dell'informazione relativa alla visualizzazione a fogli di stile associati. Il modello presentato in queste specifiche è destinato a prendere i vantaggi di tali fogli di stile senza esserne necessitati.
Gli attuali pacchetti di desktop publishing forniscono controlli molto potenti per la visualizzazione 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 visualizzazione. L'attributo style può essere utilizzato per specificare informazione di visualizzazione circa elementi individuali. Ulteriori informazioni di visualizzazione 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 visualizzazione 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 file, 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 file o colonne multiple.
Seguendo il modello di tabelle CALS (vedere [CALS]), queste specifiche permettono di raggruppare le righe delle colonne all'interno delle sezioni destinate al corpo ed alla parte finale. In questo modo si semplifica la rappresentazione delle informazioni di visualizzazione e può essere utilizzato per ripetere file del corpo e del finale di tabelle nell'interruzione di tabella 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 la possibilità di evitare i problemi causati dall'utilizzo di interfacce utente basate su sistema Windows. 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 dati da tabelle a base di dati o a fogli di calcolo.
Se gli attributi COL oppure COLGROUP sono presenti, essi specificano il numero di colonne e la tabella può essere visualizzata utilizzando un layout fisso. Altrimenti dovrebbe essere utilizzato l'algoritmo del layout automatico descritto di seguito.
Se l'attributo relativo alla larghezza width non è specificato, gli interpreti visivi HMTL dovrebbero assumere come valore predefinito il 100% per la formattazione.
E' raccomandato agli interpreti HTML di incrementare la larghezza delle tabelle oltre il valore specificato da width nei casi in cui i contenuti delle celle eccederebbero. Gli interpreti HTML che sovrascrivono la larghezza specificata dovrebbero farlo raggionevolmente. 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 l'utilizzo del layout, gli interpreti dovrebbero considerare che le didascalie delle tabelle (specificate dall'elemento CAPTION) si comportano come le celle. Ogni didascalia è costituita da una cella che se posizionata all'inizio o alla fine della tabella si estende a tutte le colonne della tabella mentre a tutte le righe se a destra o a sinistra della tabella.
Per questo algoritmo è assunto che si conosca il numero di colonne. Le larghezze delle colonne per definizione dovrebbero essere della stessa grandezza. Gli autori possono oltrepassare questo fattore specificando le larghezze relative o assolute delle colonne, utilizzando gli elementi COLGROUP o COL. La larghezza predefinita della tabella è lo spazio tra i margini attuali di sinistra e di destra, ma possono essere evitati utilizzando l'attributo width sull'elemento TABLE, o determinato dalla larghezza assoluta delle colonne. Per occuparsi delle mescolanze di larghezze assolute e relative delle colonne, il primo passo è di allocare spazio della larghezza della tabella alle colonne con larghezze assolute. Dopo di che, lo spazio rimanente verrà diviso tra le colonne con larghezze 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 delle celle. La larghezza della tabella come specificato dall'elemento TABLE oppure COL può risultare nell'eccedenza dei contenuti delle celle. È consigliato agli interpreti di cercare di recuperare queste situazioni, per esempio, con parole sillababili e con la risoluzione di dividere le 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 il ridimensionamento della larghezza delle colonne e visualizzare di nuovo la tabella. Nel peggiore dei casi, si può prendere in considerazione il taglio, se non è fattibile l'aggiustamento della larghezza 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 dovrebbe utilizzare l'algoritmo seguente di auto-strutturazione. Utilizza due passaggi attraverso i dati della tabella e scala linearmente con la grandezza della tabella.
Nel primo passo, l'interruzione di riga viene disabilitata e l'interprete tiene traccia della larghezza minima e massima di ogni cella. La larghezza massima è data dalla linea più larga. Visto che l'interruzione di riga è stata disabilitata, i paragrafi sono trattati come linee lunghe tranne se rotte da elementi
Questo processo va anche applicato a qualsiasi tabella annidata all'interno del contenuto di celle. Le larghezze massime e minime per le celle delle tabelle annidate sono utilizzate per determinare le larghezze massime e minime di quest'ultime e dunque per le celle della tabella che le contengono. L'algoritmo è lineare con il contenuto dell'insieme della cella e indipendente dalla profondità dell'annidamento.
Per l'allineamento dei caratteri del contenuto delle celle, 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). La larghezza minima per una colonna è dunque: max(min_left + min_right, min_non-aligned).
Le larghezze minime e massime delle celle sono dunque utilizzate per determinare le corrispondenti larghezze minime e massime delle colonne. Quest'ultime sono utilizzate per trovare le larghezze 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 larghezze delle colonne in base allo spazio disponibile (per esempio, 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 dividere equamente le larghezze minime e massime per ognuna delle costituenti colonne. Un approccio leggermente più complesso risulta dall'utilizzo delle larghezze minime e massime delle celle non espanse per calcolare quanta larghezza sia distribuita. Gli esperimenti ci suggeriscono che una miscela dei due approcci rende buoni risultati per un ampio ventaglio di tabelle.
I bordi delle tabelle e i margini tra le celle hanno bisogno di essere inclusi nelle larghezze assegnate alle colonne. Esistono tre casi:
Per ogni colonna, lasciamo che d sia la differenza tra la larghezza massima e quella minima di questa colonna. Ora bisogna calcolare la larghezza della colonna con la larghezza minima più d volte W diviso per D. Questo rende le colonne con grandi differenze tra le larghezze minime e massime più ampie di colonne con differenze minori.
Questo passo viene ripetuto per le tabelle annidate utilizzando le larghezze minime e massime derivate per ogni tabella simile all'interno del primo passaggio. In questo caso, la larghezza della cella della tabella "madre" detiene il ruolo della larghezza della finestra attuale descritta prima. Questo processo viene ripetuto ricorrentemente per ogni tabella annidata. La tabella più alta è dunque visualizzata con le larghezze assegnate. Le tabelle annidate vengono visualizzate in seguito come parte del contenuto della cella appartenente alla tabella "madre".
Se la larghezza della tabella viene specificata con l'attributo width , l'interprete cercherà di aggiustare la larghezza delle colonne. L'attributo width non viene preso in considerazione nel caso in cui le colonne risultassero avere meno della loro larghezza minima (per esempio, indivisibile).
Se le larghezze relative sono specificate con l'elemento COL, l'algoritmo viene modificato per aumentare le larghezze delle colonne oltre la larghezza 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 larghezza minima. Similarmente, le colonne non dovrebbero essere troppo larghe da espandersi oltre l'estensione della finestra. Se un'elemento COL specifica una larghezza relativa di zero, la colonna dovrebbe avere sempre la propria larghezza minima.
Quando si utilizza l'algoritmo di strutturazione con due passaggi, la posizione di allineamento predefinito in assenza di un esplicito o ereditato attributo charoff può essere determinato scegliendo la posizione che centrerebbe le linee per cui le larghezze 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 visualizzazione incrementale delle tabelle, il valore predefinito suggerito è charoff="50%". Se più celle in diverse file 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 riguardanti gli oggetti troppo larghi per le colonne vengono applicate quando l'allineamento implicito o esplicito risulta in una situazione nella quale i dati eccedono la larghezza assegnata della colonna.
Scelta dei nomi degli attributi. Sarebbe stato 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 furono 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 concentrarsi sul minore tabindex disponibile al momento.
Se i moduli sono associati con script sul lato client, esistono ulteriori potenziali problemi. Per esempio, uno script handler 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 quanto mappa d'immagine sul lato client 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 dipendenti dalle proprietà degli oggetti che appaiono all'inizio della 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 deve sempre seguire la parentesi destra, altrimenti il carattere della parentesi destra "}" viene trattato come facente parte del corpo della macro. E' anche utile notare che si devono sempre utilizzare le virgolette 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, etc.
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 di immagine sul lato client:
<MAP NAME=foo>
<AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
</MAP>
Quest'esempio dona la grandezza di un'immagine basata sulle proprietà di un documento:
<IMG src="bar.gif" width='&{document.banner.width/2};' height='50%' alt="banner">
Si può dare l'URI per un collegamento o un'immagine attraverso 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 SGML relativi a CDATA possono essere citati utilizzando virgolette singole o doppie. Se utilizzate singole virgolette intorno alla stringa dell'attributo allora potete includere quelle doppie in quanto parte della stringa dell'attributo. Un'altro approccio può essere quello di utilizzare " per le doppie virgolette:
<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 suo nome:
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 inserisce l'attributo alt per gli elementi IMG o APPLET, gli interpreti dovrebbero fornire il testo alternativo, calcolato nell'ordine seguente:
Quando l'autore non inserisce l'attributo alt per l'elemento INPUT, gli interpreti dovrebbero 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 che l'utente non abbia esplicitamente richiesto. Dunque, gli interpreti dovrebbero confermare qualsiasi nome di file predefinito che potrebbe essere suggerito dall'attributo
Queste specifiche non contengono un meccanismo per la criptazione dei dati; questo dovrebbe essere preso in carico da qualsiasi altro meccanismo adibito alla sicurezza di trasmissione dei dati.
Una volta caricato il file, l'agente adibito al trattamento dovrebbe trattarlo e archiviarlo appropriatamente.