Índice
As notas que seguen son informativas, non normativas. Apesar da aparición de palabras como "debe" e "deberia", todos os requisitos desta sección aparecen noutro sítio da especificación.
Esta especificación non define como manexan os axentes de usuário as condicións de error xerais, incluído como se comportan os axentes de usuário cando achan elementos, valores de atributos ou entidades non especificadas neste documento.
Porén, para facilitar a experimentación e a inteoperabilidade entre as implementacións das distintas versións da HTML, recomendamos o seguinte comportamento:
Asi mesmo recomendamos que os axentes de usuário fornezan meios de notificar ao usuário de tais erros.
Dado que os axentes de usuário poden variar na maneira na que tratan as condicións de erro, os autores e usuários non deben confiar nun comportamento de recuperación de erro determinado.
A especificación da HTML 2.0 ( [RFC1866] ) observa que moitos axentes de usuário de HTML 2.0 asumen que un documento que non comeza cunha declaración de tipo de documento refire-se à especificación HTML 2.0. Dado que a experiéncia mostra que esta non é unha boa asunción, a especificación actual non recomenda este comportamento.
Por razóns de interoperabilidade, os autores non deben "extender" a HTML através dos mecanismos da SGML disponíbeis (p.ex., mediante a extensión de DTD, a adición dun conxunto novo de definicións de entidades, etc.).
Ainda que os URI non conteñan valores non ASCII(ver [URI] , sección 2.1) os autores às veces especifican-nos en valores de atributos que esperan un URI (ou sexa, defiidos con %URI; no DTD ). Por exemplo, o seguinte valor href é ilegal:
<A href="http://foo.org/Håkon">...</A>
Recomendamos que os axentes de usuário adopten as convencións seguintes para tratar os valores non ASCII nestes casos:
Este procedimento resulta nun URI sintacticamente legal (como se definen en [RFC1738] , sección 2.2 ou [RFC2141] , sección 2) que é independente da codificación de caracteres à que pode ser transcodificado o documento HTML que porta o URI.
Nota. Alguns axentes de usuário antigos procesan sen problemas os URI en HTML usando os bytes da codificación de caracteres na que se recebeu o documento. Alguns documentos HTML máis antigos confian nesta práctica e rachan cando son transcodificados. Os axentes de usuário que pretendan tratar estes documentos máis antigos deberian, ao receberen un URI que conteña caracteres que estexan fora do conxunto legal, usar primeiro a conversión baseada en UTF-8. Só se o URI resultante non se resolve deberian tentar construir un URI baseado nos bytes da codificación de caracteres na que se recebeu o documento.
Nota. Deberia-se aplicar a mesma conversión baseada en UTF-8 aos valores do atributo name para o elemento A .
O URI que se construe ao enviar un formulário pode-se usar como como un vínculo con estilo de áncora (por exemplo, o atributo href para o elemento A ). Infortunadamente, o uso do carácter "&" para separar campos de formulário interaciona co seu uso nos valores de atributos SGML para delimitar referéncias a entidades-carácter . Por exemplo, para usar o URI "http://host/?x=1&y=2" como un URI de vínculo, hai-no que escreber <A href="http://host/?x=1&y=2"> ou<A href="http://host/?x=1&y=2">.
Recomendamos que os implementadores de servidores HTTP, e en particular, os implementadores de CGI recorran ao uso de ";" en lugar de "&" para aforrar-lles aos autores os problemas de ter que escapar os caracteres "&" deste xeito.
A SGML (ver [ISO8879] , sección 7.6.1) especifica que un salto de liña que sega imediatamente unha etiqueta inicial debe ser ignorado, ao igual que un salto de liña imediatamente antes dunha etiqueta final. Isto aplica-se a todos os elementos HTML sen exceición.
Os seguintes dous exemplos de HTML deben ser apresentados de maneira idéntica:
<P>Thomas está a ver a televisión.</P>
<P>
Thomas está a ver a televisión.
</P>
E igualmente os dous exemplos seguintes:
<A>O meu sítio web favorito</A>
<A>
O meu sítio web favorito
</A>
Os dados de script e style poden aparecer como conteúdo de elemento ou valores de atributo. As seccións que seguen descreben o limite entre código HTML e dados externos.
Nota. As DTD definen dados de script e de style como CDATA tanto para o conteúdo de elemento e os valores de atributo. As regras da SGML non permiten referéncias a caracteres en conteúdo de elemento CDATA mais permiten-nos en valores de atributo CDATA. Os autores deberian prestar especial atención ao cortar e colar dados de script e data entre conteúdo de elemento e valores de atributo.
Esta asimetria significa tamén que ao transcodificar desde unha codificación de caracteres máis rica a outra máis pobre, o transcodificador non pode simplesmente substituir caracteres non convertíbeis nos dados de script ou estilo polas referéncias numéricas a caracteres; debe procesar o documento HTML e saber da sintaxe de cada script e linguaxe de estilo co obxecto de processar os dados correctamente.
Cando dados de script ou de estilo son o conteúdo dun elemento ( SCRIPT e STYLE ), os dados comezan imediatamente depóis da etiqueta inicial do elemento e rematan no primeiro delimitador ETAGO ("</") seguido por un carácter de comezo de nome ([a-zA-Z]); observe-se que isto pode non ser a etiqueta final do elemento. Polo tanto, os autores deberian escapar "</" dentro do conteúdo. Os mecanismos de escape son específicos de cada linguaxe de script ou folla de estilo.
EXEMPLO ILEGAL:
Os seguintes dados de script conteñen, incorrectamente, unha
secuéncia "</" (como parte de "</EM>") antes da etiqueta
final do
SCRIPT
:
<SCRIPT type="text/javascript">
document.write ("<EM>Isto non vai funcionar</EM>")
</SCRIPT>
En JavaScript, este código pode-se expresar legalmente se se esconde o delimitador ETAGO antes dun carácter de início de nome SGML:
<SCRIPT type="text/javascript">
document.write ("<EM>Isto si funcionará<\/EM>")
</SCRIPT>
En Tcl, pode-se conseguir da seguinte maneira:
<SCRIPT type="text/tcl">
document write "<EM>Isto si funcionará<\/EM>"
</SCRIPT>
En VBScript, pode-se evitar o problema coa función Chr() :
"<EM>This will work<" & Chr(47) & "EM>"
Cando dados de script ou de estilo son o valor dun atributo (ora o atributo style ora intrinsic event ), os autores deberian escapar cada aparición das aspas, simples ou dobres, dentro do valor dacordo coa convención da linguaxe de script ou de estilo. Os autores deberian tamén escapar as aparicións de "&" se "&" non se pretende que sexa o comezo dunha referéncia a caracteres .
Asi, por exemplo, poderia-se escreber:
<INPUT name="num" value="0"
onchange="if (compare(this.value, "help")) {gethelp()}">
Dos sistemas SGML conformes con [ISO8879] espera-se que recoñezan moitos rasgos que non son aceitados por moitos axentes de usuário de HTML. Recomentados que os autores eviten usar todas estas características.
Os autores deberian ser conscientes de que moitos axentes de usuário só recoñecen a forma minimizada dos atributos booleanos e non a forma plena.
Por exemplo, os autores deberian especificar:
<OPTION selected>
en vez de
<OPTION selected="selected">
As seccións marcadas xogan un papel semellante ao do construto #ifdef recoñecido polos pré-processadores de C.
<![INCLUDE[
<!-- isto será incluído -->
]]>
<![IGNORE[
<!-- isto será ignorado -->
]]>
A SGML define tamén o uso de seccións marcadas para conteúdo CDATA, dentro do que "<" non se trata como o início dunha etiqueta, como por exemplo en:
<![CDATA[O signo revelador de que un axente de usuário non recoñece unha sección marcada é a aparición de "]]>", que se vé cando o axente de usuário toma por erro o primeiro carácter ">" polo final da etiqueta que comeza por "<![".
<an> exemplo de <sgml> código que non
é <doloroso> escreber con < etcétera.
]]>
As instrucións de procesamento son un mecanismo para capturar peculiaridades específicas da plataforma. Unha instrución de procesamento comeza con <? e remata por >.
<?instruction >
Por exemplo:
<?>
<?style tt = font courier>
<?page break>
<?experiment> ... <?/experiment>
Os autores deberian ser conscientes de que moitos axentes de usuário mostran as instrucións de procesamento como parte do texto do documento.
Alguns construtos SHORTTAG da SGML aforran tempo ao teclado mais non lle engaden capacidade expresiva à aplicación SGML. Ainda que estes construtos tecnicamente non introducen ambigüidade, reducen a robusteza dos documentos, en particular cando a linguaxe se mellora para incluir elementos novos. Asi, mentres que os construtos SHORTAG da SGML relacionados cos atributos usan-se e están amplamente implementados , os relacionados cos elementos non o están. Os documentos que os usan son documentos conformes coa SMGL mais é improbábel que funcionen con moitas ferramentas de HTML.
Os construtos SHORTTAG en questión son os seguintes:
<name/.../
<name1<name2>
<>
</>
Esta sección fornece algunhas suxestións simples que farán que os seus documentos sexan máis acesíbeis para os motores de pesquisa.
<LINK rel="alternate"
type="text/html"
href="omeudocumento-fr.html" hreflang="fr"
lang="fr" title="La vie souterraine">
<LINK rel="alternate"
type="text/html"
href="omeudocumento-de.html" hreflang="de"
lang="de" title="Das Leben im Untergrund">
<META name="keywords" content="vacacións, Grécia, sol">
<META name="description" content="Idílicas vacacións europeas">
<LINK rel="start"
type="text/html"
href="page1.html"
title="Teoria xeral da relatividade">
Cando un robot visita un sítio web, como por exemplo http://www.foobar.com/, busca primeiro http://www.foobar.com/robots.txt. Se acha este ficheiro, analisará os seus conteúdos para ver se lle é permitido recuperar o documento. Pode-se preparar o ficheiro robots.txt para que funcione só con robots específicos e para impedir o aceso a directórios e ficheiros específicos.
Velaí un exemplo dun ficheiro robots.txt file que impide que calquer robot visite todo o sítio
User-agent: * # aplica-se-lles a todos os robots
Disallow: / # impede o indexado de todas as páxinas
O robot simplesmente procurará un URI "/robots.txt" no seu sítio, onde un sítio define-se como un servidor HTTP a correr nunha máquina e cun número de porto determinados. Velaqui algunhas localizacións de exemplo para robots.txt :
| URI do sítio | URI de 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 |
Só pode haber un "/robots.txt" nun sítio. En concreto, non se deben colocar ficheiros "robots.txt" en directórios de usuário porque un robot nunca mirará neles. Se quixer que os seus usuários sexan capaces de crear os seus próprios "robots.txt", precisará xuntá-los todos nun único "/robots.txt". Se non quixer facer isto, os seus usuários talvez quererán usar a etiqueta META Robots no seu lugar.
Algunhas suxestións: os URI distinguen entre maiúsculas e minúsculas a secuéncia "/robots.txt" debe ir toda en minúsculas. Non se permiten liñas en branco dentro dun rexisto único no ficheiro "robots.txt".
Debe haber exactamente un campo "Axente de usuário" por rexisto. O robot deberia ser xeneroso ao interpretar este campo. Recomenda-se a equivaléncia dunha subsecuéncia do nome sen información da versión sen ter en conta maiúsculas e minúsculas.
Se o valor é "*", o rexisto descrebe o que se determina como aceso por omisión para calquer robot que non coincidise cos demáis rexistos. Non se permite que haxa vários rexistos asi no ficheiro "/robots.txt".
O campo "Disallow" (non pemitir) especifica un URI parcial que non é para visitar. Pode ser unha localización completa ou parcial; non se recuperará nengun URI que comeze por este valor. Por exemplo,
Disallow: /help impede tanto /help.html como /help/index.html, mentres que
Disallow: /help/ impediria /help/index.html mais permitiria /help.html.
Un valor vacio en "Disallow", indica que se poden recuperar todos os URI. Debe haber cando menos un campo "Disallow" no ficheiro robots.txt.
O elemento META permite-lles aos autores de HTML indicar-lles aos robots que visitan se un documento pode ser indexado ou usado para recoller máis vínculos. Non se requer a actuación do administrador.
No seguinte exemplo un robot non deberia nen indizar este documento nen analizá-lo na procura de vínculos.
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
A lista de termos no conteúdo é ALL, INDEX, NOFOLLOW, NOINDEX.
Nota. A comezos de 1997 só uns poucos robots implementan isto, mais espera-se que isto cámbie conforme o control de robots de indización recebe maior atención pública.
O modelo de tabelas de HTML evoluíu de estudos sobre modelos de tabelas SGML xa existentes, do tratamento das tabelas en pacotes de procesamento de texto coñecidos e dunha ampla gama de técnicas de disposición tabular en revistas, libros e outros documentos baseados en papel. Escolleu-se o modelo para permitir que se pudesen expresar tabelas simples simplesmente con complexidade adicional disponíbel se se precisar. Isto fai que sexa práctico crear o código das tabelas HTML con editores de texto comuns e reduce a dificuldade de aprendizaxe no comezo. Esta característica foi moi importante para o éxito da HTML até hoxe.
Cada vez máis, a xente está a crear tabelas convertindo-as desde outros formatos de documento ou creando-as directamente con editores WYSIWYG. É importante que o modelo de tabelas HTML encaixe ben con estas ferramentas de creción. Isto afecta a como se representan as celas que se extenden por várias filas ou colunas e a como se asócian con grupos de celas o aliñamento e outras propriedades de apresentación.
Unha consideración importante no modelo de tabelas HTML é que o autor non controla como un usuário vai dimensionar unha tabela, que tipos de letra vai usar, etc. Isto fai que sexa arriscado confiar nos anchos de coluna especificados en termos de unidades de pontos absolutas. Pola contra, as tabelas deben ser capaces de alterar o tamaño dinamicamente para que correspondan co tamaño e tipo de letra da xanela actual. Os autores poden axudar co ancho relativo das colunas, mais os axentes de usuário deben asegurar-se de que as colunas son anchas davondo para mostrar o ancho do elemento máis grande do conteúdo da cela. Se hai que pasar por riba da especificación do autor, os anchos relativos das colunas individuais non deberian alterar-se drasticamente.
Nas tabelas grandes ou en conexións lentas à rede, a representación incremental das tabelas é importante para a satisfacción do usuário. Os axentes de usuário deberian ser capaces de comezar a mostrar unha tabela antes de teren recibido todos os dados. O ancho da xanela por omisión para a maioria dos axentes de usuário mostra uns 80 caracteres e os gráficos de moitas páxinas HTML están deseñados tendo estas pré-definicións en conta. Se expresan o número de colunas e incluen instrucións para o control do ancho da tabela e o ancho das diferentes colunas, os autores poden-lle suxerir aos axentes de usuário que permitan a representación incremental dos conteúdos das tabelas.
Para a representación incremental, o navegador precisa do número de colunas e o seu ancho. O ancho por omisión da tabela é o tamaño actual da xanela (width="100%" ). Pode-se mudar isto indicando o atributo width do elemento TABLE . Por omisión, todas as colunas teñen o mesmo ancho, mais poden-se especificar os anchos de coluna con un ou máis elementos COL antes de que comecen os dados da tabela.
Fica a questión do número de colunas. Algunhas persoas teñen suxerido que se aguarde até que se teña recebida a primeira fila da tabela, mais isto poderia levar moito tempo se as celas teñen moito conteúdo. En xeral ten máis sentido, se se desexa a representación incremental, que os autores especifiquen explicitamente o número de colunas do elemento TABLE .
Os autores ainda teñen un modo de indicar-lles aos axentes de usuário se usar a representación incremental se redimensional a tabela automaticamente para que se acomode ao conteúdo das celas. No modo de auto-dimensionamento de duas pasadas, o número de colunas determina-se na primeira pasada. No modo incremental, o número de colunas hai-no que indicar desde o princípio (cos elementos COL ou COLGROUP ).
A HTML distingue código estrutural tal como parágrafos e aspas para mostrar peculiaridades tais como marxes, tipos de letra, cores, etc. Como lles afecta esta distinción às tabelas? Do ponto de vista do purista, o aliñamento de texto dentro das celas das tabelas e os bordes entre as celas e asunto de como se mostran, non da estrutura. Na prática, porén, é útil agrupa-los coa información estrutural xa que estas características portan-se moi ben dunha aplicación à seguinte. O modelo de tabelas da HTML deixa-lles às follas de estilo a maior parte da información da apresentación. O modelo que se apresenta nesta especificación está deseñado para aproveitar-se destas follas de estilo mais non para que as requira.
Os pacotes de auto-edición actuais fornecen un control moi rico da apresentación das tabelas, e non seria moi práctico reproducir isto en HTML sen converter a HTML nun formato de texto rico como RTF ou MIF. Esta especificación, porén, oferece-lles aos autores a posibilidade de escoller dun xogo de clases de estilos de borde frecuentes. O atributo frame controla a aparéncia da moldura de borde arredor da tablea mentres que o atributo rules determina a escolla de das pautas dentro da tabela. Posibilitar-ase un nível control máis fino mediante as anotacións de apresentación. O atributo style pode-se usar para mostrar información de apresentación para elementos individuais. Pode-se fornecer máis información para a apresentación usando o elemento STYLE no cabezallo do documento ou através de follas de estilo vinculadas.
Durante o desenvolvimento desta especificación, investigaron-se moitos camiños para especificar os padróns para as liñas divisórias entre celas. Unha das cuestións é a relativa aos tipos de declaracións que poden facer-se. Incluir resposta para a substracción de bordes asi como para a adición de bordes conduce a algoritmos bastante complexos. Por exemplo, o traballo para permitir que o xogo completo de elementos de tabela incluíse os atributos frame e rules levaba a un algoritmo que implicaba uns 24 pasos para determinar se un borde determinado dunha cela deberia levar liña divisória ou non. Mesmo esta complexidade adicional non fornece control de apresentación davondo como para respostar a toda a gama de necesidades das tabelas. A especificación actual limita-se adrede a un modelo intuitivo simples, suficiente para a maioria das necesidades. Precisa-se de máis traballo experimental antes de facer padrón unha focaxe máis complexa.
Esta especificación proporciona un super-conxunto do traballo prévio sobre HTML+. Considera-se que as tabelas están formadas dun título opcional xunto cunha secuéncia de filas que, à sua vez, consisten nunha secuéncia de celas de tabela. O modelo distingue asi mesmo entre cabezallo e celas de dados e permite que as celas se extendan por várias filas e colunas.
Seguindo o modelo de tabelas de CALS (ver [CALS] ), esta especificación permite que as filas de tabelas se agrupen nas seccións cabeza e corpo e pé. Isto simplifica a representación da información de apresentación e pode-se usar para repetir filas de cabeza e pé cando as tabelas se rachan nos limites das páxinas ou para proporcionar cabezallos fixos sobre un painel desprazábel para o corpo. No código, a sección do pé situa-se antes das seccións do corpo. Isto é unha optimización compartillada con CALS para tratar tabelas moi longas. Permite que o pé se poda mostrar sen ter que agardar a que se procese toda a tabela.
Para quen teña unha discapacidade visual, a HTML oferece a esperanza de amañar o dano causado pola adopción de interfaces gráficas de usuário baseadas en xanelas. O modelo de tabela HTML inclui atributos para etiquetar cada cela, para permitir conversión de texto a voz de alta calidade. Poden-se usar os mesmos atributos para permitir a importación e exportación automatizadas de dados de tabelas para bases de dados ou follas de cálculo.
Se están presentes os elementos COL ou COLGROUP , estes especifican o número de colunas e a tabela pode-se representar usando unha composición fixa. De ser doutro modo, haberia que usar a auto-composición descrita abaixo.
Se non se especificar o atributo width, os axentes de usuário visuais deberian asumir un valor por omisión do 100% para o formatado.
Recomenda-se que os axentes de usuário incrementen a anchura das tabelas a máis do valor especificado por width nos casos en que, doutro modo, os conteúdos das celas rebosarian. Os axentes de usuário que substituan o ancho especificado deberian-no facer de maneira razoábel. Os axentes de uxuário poden escoller dividir as palabras entre as liñas para evitar a necesidade dun desprazamento vertical excesivo ou cando ese desprazamento non é práctico ou non se quere.
No que fai à composición, os axentes de usuário deberian considerar que os títulos das tabelas (que se especifican mediante o elemento CAPTION ) se comporten como celas. Cada título é unha cela que se extende todo ao longo das colunas da tabela que están no topo ou no fundo da tabela e das filas que están no lado esquerdo ou direito da tabela.
Para este algoritmo asume-se que se coñece o número de colunas. Os anchos de coluna por omisión deberian ter todos o mesmo tamaño. Os autores poden prescindir disto se especifican anchos de coluna relativos ou absolutos usando os elementos COLGROUP ou COL . O ancho da tabela por omisión é o espazo entre os marxes esquerdo e direito actuais, mais pode modificar-se co atributo width do elemento TABLE , ou determinar-se a partir dos anchos de coluna absolutos. Para tratar cunha mescla de anchos de coluna absolutos e relativos, o primeiro paso é destinar espazo do ancho de coluna às colunas que teñen anchos absolutos. Depóis disto, o espazo remanente divide-se entre as colunas con anchos relativos.
A sintaxe de tabelas por si só non chega para garantir que os valores dos atributos sexan consistentes. Por exemplo, o número de elementos COL e COLGROUP pode non ser consistente co número de colunas que as celas da tabela implican. Aparece outro problema cando as colunas son demasiado estreitas para evitar que os conteúdos das celas as rebasen. O ancho da tabela tal e como se especifica co elemento TABLE ou cos elementos COL pode resultar nun rebasamento dos conteúdos das celas. Recomenda-se que os axentes de usuário tenten recuperar-se con elegáncia destas situacións, por exemplo dividindo as palabras e recorrendo a partir as palabras se non se sabe onde colocar os trazos de separación.
No caso de que un elemento que non se poida dividir provoque o rebosamento dunha cela, o axente de usuário poderia considerar axustar os anchos de coluna e mostrar a tabela outra vez. No pior dos casos, pode considerar recortar se non é posíbel a coluna con axustamentos e/ou conteúdos de cela desprazábeis. En calquer caso, se os conteúdos da cela se dividen ou recortan, haberia que indicar-llo ao usuário de maneira adecuada.
Se non se especificar o número de colunas cos elementos COL e COLGROUP , entón o axente de usuário deberia usar o seguinte algoritmo de auto-composición. Usa duas pasaxes através dos dados da tabela e aumenta linearmente co ancho da tabela.
Na primeira pasaxe non se habilita o axustamento automático de liñas e o axente de usuário leva a conta do ancho mínimo e máximo de cada cela. O ancho máximo ven dado pola liña máis longa. Dado que o axustamento automático de liñas está desactivado, os parágrafos tratan-se como liñas longas a non ser que os rompan elementos BR . O ancho mínimo ven dado polo elemento de texto máis ancho (palabra, imaxe, etc.), tendo en conta as sangrias, os pontos das listas, etc. Por outras palabras, é necesário determinar o ancho mínimo que requeririra unha cela nunha xanela por si só antes de que a cela comece a desbordar. Permitindo-lles aos axentes de usuário que partan as palabras minimizará a necesidade de desprazamento vertical ou, no pior dos casos, de recortar os conteúdos da cela.
Este proceso tamén se aplica nas tabelas aniñadas que aparezan no conteúdo das celas. Os anchos mínimo e máximo para as celas nas tabelas aniñadas usan-se para determinar os anchos mínimo e máximo desas tabelas e a partir daí da cela da tabela pai mesma. O algoritmo é linear con conteúdo de cela agregado e, en termos xerais, independente da profundidade do aniñamento.
Para enfrontar o aliñamento de caracteres dos conteúdos das celas, o algoritmo mantén tres totais min/max activos para cada coluna: aliñamento à esquerda, aliñamento à direita e sen aliñamento. O ancho mínimo para unha coluna, entón, é: max(min_left + min_right, min_non-aligned) .
Os anchos mínimo e máximo das celas usan-se entón para determinar os anchos mínimo e máximo das colunas. Estas, pola sua vez, usan-se para achar o ancho mínimo e máximo da tabela. Observe-se que as celas poden contar tabelas aniñadas, mais isto non complica o código de maneira significativa. O seguinte paso é asignar os anchos de coluna dacordo co espazo disponíbel (isto é, o espazo entre as marxes esquerda e direita actuais).
Coas celas que se extenden por várias colunas, unha aproximación simples consiste en distribuir anchos min/max equitativamente a cada unha das colunas que as compoñen. Unha aproximación un pouco máis complexa consiste en usar os anchos min/max das celas que non abarcan máis que unha coluna para sopesar como se distribuen os anchos que si se extenden. Os experimentos suxiren que unha mescla das duas aproximacións proporciona bons resultados para unha grande variedade de tabelas.
Hai que incluir os bordes das tabelas e as marxes entre as celas ao asignar os anchos das colunas. Hai tres casos:
Para cada coluna, sexa d a diferenza entre o ancho máximo e mínimo desa coluna. Entón faga-se o ancho da coluna o ancho mínimo máis d por W dividido por D. Isto fai que as colunas con diferenzas grandes entre os anchos mínimo e máximo sexan máis anchas que as colunas con diferenzas máis pequenas.
Este paso de asignación repite-se entón para as tabelas aniñadas usando os anchos mínimo e máximo derivados de todas estas tabelas na primeira pasaxe. Neste caso, o ancho da tabela pai xogará o papel do tamaño de xanela actual na descrición anterior. Este proceso repite-se recursivamente para todas as tabelas aniñadas. Mostra-se a tabela superior usando os anchos asignados. As tabelas aniñadas mostran-se a continuación como parte dos conteúdos da cela da tabela pai.
Se o ancho da tabela está especificado mediante o atributo width o axente de usuário tenta que os anchos das colunas coincidan. O atributo width non é obrigatório se resulta que hai colunas con menos do seu ancho mínimo (ou sexa, indivisíbeis).
Se os anchos relativos se especifican co elemento COL modifica-se o algoritmo para aumentar os anchos das colunas sobre o ancho mínimo para cumprir as restricións de anchos relativos. Os elementos COL deberian seren tomados como suxestións só, de xeito que as colunas non se deberian facer menores do que o seu ancho mínimo. Da mesma maneira, as colunas non se deberian facer tan anchas que a tabela se extenda moito máis alá da extensión da xanela. Se un elemento COL especifica un acho relativo de cero, a coluna deberia facer-se sempre do seu ancho mínimo.
Ao usar o algoritmo de disposición de duas pasaxes, a posición de aliñamento por omisión na auséncia dun atributo charoff explícito ou herdado pode-se determinar escollendo a posición que centraria as liñas para a que os anchos antes e depóis do carácter de aliñamento tivesen os valores máximos para calqueira das liñas das colunas nas que align="char" . Para a disposición da tabela incremental os valores por omisión suxeridos son charoff="50%". Se várias celas en distintas filas da mesma coluna usan aliñamento en carácter, entón por omisión todas as celas deben-se aliñar, sen importar que carácter se usa para o aliñamento. Aplican-se as regras para tratar obxectos demasiado grandes para unha coluna cando o aliñamento explícito ou implicado resulta nunha situación na que os dados exceden os anchos asignados da coluna.
Escolla de nomes de atributos. Seria preferíbel escoller valores para o atributo frame consistentes co atributo rules e os valores usados para o aliñamento. Por exemplo: none, top, bottom, topbot, left, right, leftright, all. Infortunadamente, a SGML require que os valores de atributo enumerados sexan únicos para cada elemento, independentemente do nome do atributo. Isto ocasiona problemas imediatos para "none", "left", "right" e "all". Os valores do atributo frame foron escollidos para evitar conflitos cos atributos rules , align , e valign . Isto proprociona unha medida de comprobación para o futuro, xa que se anticipa que os atributos frame e rules se adicionen a outros elementos de tabela en revisións futuras desta especificación. Como alternativa, poderia-se facer de frame un atributo CDATA. O consenso do Grupo de Traballo sobre o HTML do W3C era que os benefícios de usar ferramentas de validación SGML para comprobar atributos baseados en valores enumerados sobrepasan a necesidade de nomes consistentes.
A representación incremental de documentos que se están a receber da rede fai xurdir certos problemas a respeito dos formulários. Os axentes de usuário deberian impedir que se envien formulários até que se reciban todos os elementos do formulário.
A representación incremental de documentos fai xurdir algunhas questións a respeito da navegación co tabulador. A heurística de dar-lle o foco ao tabindex co valor máis baixo do documento parece razoábel a primeira vista. Porén, isto implica ter que esperar até que se receba todo o documento do texto xa que, até entón, o valor de tabindex máis baixo pode ainda mudar. Se o usuário pulsa a tecla do tabulador antes, é razoábel que os axentes de usuário movan o foco ao valor tabindex máis baixo actualmente disponíbel.
Se os formulários van asociados a scripts do lado do cliente, hai o potencial de máis problemas. Por exemplo, un manexador de scripts para un campo determinado pode-se referir a un campo que ainda non exista.
Esta especificación define un conxunto de elementos e atributos potentes davondo como para cumprir a necesidade xeral de producir formulários. Porén, ainda hai espazo para moitas melloras posíbeis. Por exemplo os seguintes problemas poderian ser tratados no futuro:
Outra extensión posíbel consistiria en adicionar o atributo usemap a INPUT para que se usase como mapa de imaxes do lado do cliente cando" type =image". O elemento AREA que corresponda à localización na que se fai click aportaria o valor que se lle pasaria ao servidor. Para evitar a necesidade de modificar os scripts de servidor, poderia ser adecuado extender AREA para que fornecese valores X e Y para que se usen co elemento INPUT .
Esta especificción reserva sintaxe para poder aceitar no futuro macros de script en atributos CDATA de HTML. A intención é permitir que os atributos se poidan asignar dependendo das propriedades dos obxectos que aparecesen antes na páxina. A sintaxe é:
attribute = "... &{ corpo da macro }; ... "
O corpo da macro consiste de unha ou máis senténcias na linguaxe de script por omisión (como os atributos de eventos intrínsecos). O ponto e vírgula que segue a chave direita é necesário sempre porque por outro lado o carácter de chave direita "}" trata-se como se for parte do corpo da macro. Hai que facer notar que as aspas son sempre necesárias para os atributos que conteñan macros de script.
Os procesamento de atributos CDATA é como segue:
O procesamento de macros ten lugar ao carregar (ou recarregar) o documento mais non ten lugar de novo cando o documento se redimensiona ou se volve a pintar, etc.
EXEMPLO DESAPROBADO:
Velaqui vários exemplos que utiliza JavaScript. O primeiro
escolle ao chou unha cor para o fondo do documento:
<BODY bgcolor='&{randomrgb};'>
Talvez se queira atenuar o fondo para cando se vexa à noite:
<BODY bgcolor='&{if(Date.getHours > 18)...};'>
O seguinte exemplo utiliza JavaScript para determinar as coordenadas dun mapa de imaxes do lado do cliente:
<MAP NAME=nome>
<AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
</MAP>
Este exemplo determina o tamaño dunha imaxe baseando-se nas propriedades do documento:
<IMG src="barra.gif" width='&{document.banner.width/2};' height='50%' alt="banner">
Pode-se determinar o URI dun vínculo ou imaxe un script:
<SCRIPT type="text/javascript">
function fabricante(widget) {
...
}
function location(fabricante) {
...
}
function logo(fabricante) {
...
}
</SCRIPT>
<A href='&{location(fabricante("widget"))};'>widget</A>
<IMG src='&{logo(fabricante("widget"))};' alt="logo">
Este último exemplo mostra como se poden citar os atributos CDATA da SGML usando aspas simples ou dobres. Se usa aspas simples arredor da cadea do atributo, pode incluir aspas dobres como parte da cadea do atributo. Outra maneira é usar " para as aspas dobres:
<IMG src="&{logo(fabricante("widget"))};" alt="logo">
Dado que non se pode garantir que o nome dunha moldura destino sexa único, é adecuado descreber a práctica actual de como se atopa un nome dunha moldura de destino determinada:
A Iniciativa de Acesibilidade Web do W3C ( [WAI] ) está a producir unha série de directrices para mellorar a acesibilidade à Rede para as persoas con discapacidades. Hai tres grupos de directrices:
As áncoras, imaxes incrustada e todos os demáis elementos que conteñen URI como parámetros poden ocasionar que o URI perda a referéncia a causa da entrada de dados polo usuário. Neste caso, haberia que considerar as cuestións de seguranza de [RFC1738] , sección 6. Os métodos de envio de peticións de formulários amplamente usados -- HTTP and SMTP -- proporcionan pouca garantia de confidencialidade. Os fornecedores de información que soliciten información sensíbel por meio de formulários -- en particular co elemento INPUT , type ="password" -- deberian ser conscientes e facer que os seus usuários coñezan esa auséncia de confidencialidade.
Un axente de usuário non deberia enviar nengun ficheiro que o usuário non pedise expresamente que fose enviado. Asi, espera-se que os axentes de usuário de HTML confirmen caisquer nomes de ficheiro por omisión que puderan ser suxeridos polo atributo value do elemento INPUT . Os controis escondidos non deben indicar ficheiros.
Esta especificación non contén un mecanismo para o cifrado dos dados; isto deberia ser tratado por caisquer outros mecanismos presentes para a transmisión segura de dados.
Unha vez que un ficheiro é enviado, o axente que o procese deberia procesa-lo e armacena-lo apropriadamente.