Nota: Este documento es parte de una traducción al castellano de la Recomendación del W3C "HTML 4.01 Specification" (más información). Puede consultar la versión original del mismo. Para cualquier comentario o corrección acerca de la traducción póngase en contacto con el traductor en jrpozo arroba conclase punto net. Gracias por su colaboración.
Véase el Aviso de copyright de la traducción.
Contenidos
Las siguientes notas son informativas, no normativas. A pesar de la aparición de palabras tales como "debe" y "debería", todos las exigencias de esta sección aparecen en otros lugares de la especificación.
Esta especificación no define el modo en que los agentes de usuario conformes tratan las condiciones generales de error, incluyendo el comportamiento de los agentes de usuario cuando encuentran elementos, atributos, valores de atributos, o entidades no especificadas en este documento.
Sin embargo, para facilitar la experimentación y la interoperabilidad entre las implementaciones de las diferentes versiones de HTML, recomendamos el comportamiento siguiente:
También recomendamos que los agentes de usuario proporcionen soporte para notificar tales errores al usuario.
Como los agentes de usuario pueden tratar las condiciones de error de maneras diferentes, los autores y los usuarios no deberían tomar como norma ningún comportamiento de recuperación de errores en particular.
La especificación HTML 2.0 ([RFC1866]) observa que muchos agentes de usuario HTML 2.0 suponen que un documento que no comience con una declaración del tipo de documento se refiere a la especificación HTML 2.0. Como la experiencia ha demostrado que esta es una mala suposición, la especificación actual no recomienda este comportamiento.
Por razones de interoperabilidad, los autores no deben "extender" el HTML por medio de mecanismos SGML disponibles (p.ej., extendiendo los DTDs, añadiendo un nuevo conjunto de definiciones de entidades, etc.).
Aunque los URIs no contienen valores no ASCII (ver [URI], sección 2.1) a veces los autores los especifican en valores de atributos que esperan URIs (es decir, definidos con %URI; en el DTD). Por ejemplo, el siguiente valor de href es ilegal:
<A href="http://blabla.org/Håkon">...</A>
Recomendamos que los agentes de usuario adopten la siguiente convención para el tratamiento de caracteres no ASCII en estos casos:
Este procedimiento resulta en un URI sintácticamente legal (según se define en [RFC1738], sección 2.2 o [RFC2141], sección 2) que es independiente de la codificación de caracteres a la que pudiera haber sido transcodificado el documento HTML que llevaba el URI.
Nota. Algunos agentes de usuario antiguos procesan trivialmente los URIs de HTML usando los bytes de la codificación de caracteres en que fue recibido el documento. Algunos documentos HTML antiguos dependen de esta práctica y no funcionen cuando son transcodificados. Los agentes de usuario que deseen manipular estos documentos antiguos deberían, al recibir un URI que contenga caracteres fuera del conjunto legal, usar en primer lugar la convención basada en UTF-8. Únicamente en el caso de que el URI resultante no funcione deberían intentar construir el URI basándose en los bytes de la codificación de caracteres en que fue recibido el documento.
Nota. La misma conversión basada en UTF-8 debería aplicarse a los valores del atributo name del elemento A.
El URI que se construye cuando se envía un formulario puede utilizarse como un vínculo "estilo ancla" (p.ej., en el atributo href del elemento A). Desafortunadamente, la utilización del carácter "&" para separar los campos del formulario interfiere con su uso en los valores de los atributos SGML para delimitar referencias a entidades de caracteres. Por ejemplo, para usar el URI "http://host/?x=1&y=2" como URI de un destino de vínculo, debe escribirse <A href="http://host/?x=1&y=2"> o <A href="http://host/?x=1&y=2">.
Recomendamos a los implementadores de servidores HTTP, y en particular a los implementadores de CGI, que soporten el uso de ";" en lugar de "&" para ahorrar a los autores las molestias de convertir los caracteres "&" de este modo.
SGML (ver [ISO8879], sección 7.6.1) especifica que un salto de línea que siga inmediatamente a una etiqueta inicial debe ser ignorado, así como también debe serlo un salto de línea inmediatamente antes de una etiqueta final. Esto se aplica a todos los elementos HTML sin excepción.
Los siguientes dos ejemplos de HTML deben ser representados de manera idéntica:
<P>Tomás está viendo la tele.</P>
<P> Tomás está viendo la tele. </P>
También deben serlo los siguientes dos ejemplos:
<A>Mi página web favorita</A>
<A> Mi página web favorita </A>
Los datos de scripts y estilos pueden aparecer como contenidos de elementos o como valores de atributos. Las siguientes secciones describen los límites entre el código HTML y los datos extraños a él.
Nota. El DTD define los datos de scripts y estilo como CDATA para los contenidos de ambos elementos y para los valores de los atributos. Las reglas de SGML no permiten referencias de caracteres en contenidos CDATA de elementos, pero sí las permiten en valores CDATA de atributos. Los autores deberían prestar atención especial cuando copien datos de scripts y estilos entre contenidos de elementos y valores de atributos.
Esta asimetría también implica que cuando se transcodifique desde una codificación más rica a una más pobre, el transcodificador no puede simplemente reemplazar los caracteres inconvertibles de datos de scripts o estilo a las referencias numéricas de caracteres correspondientes; debe analizar el documento HTML y conocer la sintaxis de los lenguajes de scripts y hojas de estilo para poder procesar los datos correctamente.
Cuando los datos de scripts o estilo sean el contenido de un elemento (SCRIPT y STYLE), los datos comienzan inmediatamente después de la etiqueta inicial del elemento y terminan en el primer delimitador ETAGO ("</") seguido por un carácter inicial de nombre ([a-zA-Z]); obsérvese que esto puede no ser la etiqueta final del elemento. Los autores deberían por tanto transformar el carácter "</" en su secuencia de escape cuando aparezca dentro del contenido. Los mecanismos de escape son específicos de cada lenguaje de scripts o de hojas de estilo.
EJEMPLO ILEGAL:
Los siguientes datos de script contienen, incorrectamente, la secuencia "<"
(como parte de "</EM>") antes de la etiqueta final de SCRIPT:
<SCRIPT type="text/javascript">
document.write ("<EM>Esto no funcionará</EM>")
</SCRIPT>
En JavaScript, este código puede expresarse legalmente ocultando el delimitador ETAGO antes del carácter inicial del nombre SGML:
<SCRIPT type="text/javascript">
document.write ("<EM>Esto funcionará<\/EM>")
</SCRIPT>
En Tcl, esto puede hacerse de la siguiente manera:
<SCRIPT type="text/tcl">
document write "<EM>Esto funcionará<\/EM>"
</SCRIPT>
En VBScript puede evitarse el problema con el uso de la función Chr():
"<EM>Esto funcionará<" & Chr(47) & "EM>"
Cuando los datos de scripts o estilo sean el valor de un atributo (o bien style o bien los atributos de eventos intrínsecos), los autores deberían transformar en secuencias de escape todas las apariciones de comillas delimitadoras dobles o simples que aparezcan dentro del valor de acuerdo con la convención del lenguaje de scripts o de hojas de estilo. Los autores deberían también transformar las apariciones del carácter "&" si éste no se utiliza como comienzo de una referencia de caracteres.
Así, por ejemplo, se podría escribir:
<INPUT name="num" value="0"
onchange="if (comparar(this.value, "ayuda")) {obtenerayuda()}">
Los sistemas SGML conformes con [ISO8879] reconocen, en teoría, un cierto número de características que no están ampliamente soportadas por los agentes de usuario HTML. Recomendamos a los autores que eviten el uso de todas estas caracterísicas.
Los autores deberían saber que muchos agentes de usuario sólo reconocen la forma minimizada de los atributos booleanos, y no la forma completa.
Por ejemplo, es posible que los autores quieran especificar:
<OPTION selected>
en lugar de
<OPTION selected="selected">
Las secciones marcadas juegan un papel similar a la estructura #ifdef reconocida por los preprocesadores C.
<![INCLUDE[ <!-- esto será incluido --> ]]> <![IGNORE[ <!-- esto será ignorado --> ]]>
SGML también define el uso de secciones marcadas para contenido CDATA, dentro de las cuales "<" no se considera como el comienzo de una etiqueta, p.ej.,
<![CDATA[ <un> ejemplo de código <sgml> que no es <difícil> de escribir con < y similares. ]]>
Lo que delata que un agente de usuario no reconoce una sección marcada es la aparición del "]]>", que sólo se ve cuando el agente de usuario considera por error al primer carácter ">" como el final de la etiqueta que comienza por "<![".
Las instrucciones de procesamiento son un mecanismo para capturar órdenes específicas de la plataforma. Una instrucción de procesamiento comienza con <? y termina con >
<?instruccion >
Por ejemplo:
<?> <?style tt = font courier> <?page break> <?experiment> ... <?/experiment>
Los autores deberían saber que muchos agentes de usuario representan las instrucciones de procesamiento como parte del texto del documento.
Algunas estructuras SGML SHORTTAG permiten escribir menos pero no añaden capacidad expresiva a la aplicación SGML. Aunque estas estructuras no introducen ambigüedades desde el punto de vista técnico, reducen la robustez de los documentos, especialmente cuando se amplía el lenguaje para incluir nuevos elementos. Así, si bien las construcciones SHORTTAG de SGML relacionadas con los atributos son ampliamente usadas y soportadas, no sucede lo mismo con aquéllas relacionadas con los elementos. Los documentos que las usen serán documentos conformes con SGML, pero es poco probable que funcionen con muchas herramientas HTML existentes.
Las estructuras SHORTTAG en cuestión son las siguientes:
<name/.../
<name1<name2>
<>
</>
Esta sección proporciona algunas sugerencias simples que harán sus documentos más accesibles a los motores de búsqueda.
<LINK rel="alternate"
type="text/html"
href="midoc-fr.html" hreflang="fr"
lang="fr" title="La vie souterraine">
<LINK rel="alternate"
type="text/html"
href="midoc-de.html" hreflang="de"
lang="de" title="Das Leben im Untergrund">
<META name="keywords" content="vacaciones,Grecia,sol"> <META name="description" content="Vacaciones idílicas en Europa">
<LINK rel="start"
type="text/html"
href="pagina1.html"
title="Teoría General de la Relatividad">
Cuando un robot visita un sitio web, digamos http://www.blabla.com/, lo primero que hace es comprobar y analizar sus contenidos para ver si le está permitido obtener el documento. Se puede editar el fichero robots.txt para que se aplique sólo a robots específicos, y para impedir el acceso a ficheros o directorios específicos.
Aquí se muestra un fichero robots.txt de ejemplo que impide a todos los robots visitar todo el sitio
User-agent: * # se aplica a todos los robots
Disallow: / # impedir el indexado de todas las páginas
El robot simplemente buscará un URI "/robots.txt" en su sitio, estando el sitio definido por un servidor HTTP ejecutándose en una máquina determinada y en un número de puerto determinado. Aquí tenemos algunas localizaciones de ejemplo para robots.txt:
| URI del Sitio | 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ólo puede haber un único fichero "/robots.txt" en un sitio. Más concretamente, no debería poner ficheros "robots.txt" en los subdirectorios de los usuarios, ya que los robots no los mirarán nunca. Si quiere que sus usuarios puedan crear sus propios ficheros "robots.txt", tendrá que mezclarlos todos en un "/robots.txt" único. Si no quiere hacer esto, es posible que sus usuarios quieran utilizar el elemento META Robots en su lugar.
Un par de consejos: Los URI's distinguen entre mayúsculas y minúsculas, y todas las cadenas de "/robots.txt" deben estar en minúsculas. No se permiten líneas en blanco dentro de un registro simple del fichero "robots.txt".
Debe haber exactamente un campo "User-agent" por registro. El robot debería ser liberal al interpretar este campo. Se recomienda un emparejamiento, sin distinguir entre mayúsculas y minúsculas, entre una subcadena y el nombre sin la información de la versión.
Si el valor es "*", el registro decribe la política de acceso por defecto para cualquier robot que no se haya emparejado con ninguno de los demás registros. No está permitido tener más de uno de estos registros en el fichero "/robots.txt".
El campo "Disallow" especifica un URI parcial que no debe ser visitado. Éste puede ser un ruta de acceso completa, o una ruta parcial; cualquier URI que comience con este valor no será accedido. Por ejemplo,
Disallow: /help impide tanto /help.html como /help/index.html, mientras que
Disallow: /help/ impediría /help/index.html pero permitiría /help.html.
Un valor vacío para "Disallow" indica que se puede acceder a todos los URIs. Debe haber al menos un campo "Disallow" en el fichero robots.txt.
El elemento META permite a los autores HTML decir a los robots que les visiten si un documento puede ser indexado, o usado para obtener más vínculos. No se requiere ninguna acción por parte del administrador.
En el siguiente ejemplo, el robot no debería ni indexar este documento, ni analizarlo para encontrar vínculos.
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
La lista de términos en el contenido es ALL, INDEX, NOFOLLOW, NOINDEX.
Nota. A principios de 1997 eran muy pocos los robots que implementaban esto, pero se espera que esta situación cambie a medida que se preste más atención pública al control de los robots de indexado.
El modelo de tablas de HTML ha evolucionado a partir de estudios de modelos de tablas SGML existentes, del tratamiento de tablas en varios paquetes comunes de procesamiento de textos, y de un amplio rango de técnicas de composición tabular en revistas, libros y otros documentos basados en papel. El modelo fue elegido para permitir que las tablas simples se pudieran expresar con simplicidad, con complejidad adicional cuando fuera necesaria. Gracias a ello puede crearse fácilmente el código para tablas sencillas con editores de texto normales y se reduce el proceso inicial de aprendizaje. Esta característica ha sido muy importante para el éxito actual del HTML.
Cada vez son más las personas que crean tablas convirtiéndolas desde otros formatos de documento, o creándolas directamente con editores WYSIWYG. Es importante el hecho de que el modelo de tablas de HTML se acomode bien a estas herramientas de creación, incluyendo el modo en que se presentan las celdas que abarcan varias filas o columnas, y cómo se asocian las propiedades de alineación y otras propiedades de presentación a grupos de celdas.
Una de las consideraciones principales respecto al modelo de tablas de HTML es que el autor no controla qué tamaño dará un usuario a la tabla, qué fuentes usará, etc. Esto hace que sea arriesgado basarse en anchuras de columna especificadas en términos de unidades absolutas en píxeles. En lugar de ello, las tablas deben poder modificar su tamaño dinámicamente para ajustarse al tamaño actual de la ventana y a las fuentes disponibles. Los autores pueden proporcionar pautas para los tamaños relativos de las columnas, pero los agentes de usuario deberían asegurarse de que las columnas sean lo suficientemente anchas para representar la anchura del mayor elemento contenido en la celda. Si la especificación del autor debe ser anulada, no deberían cambiar drásticamente las anchuras relativas de las columnas.
Para tablas grandes o conexiones lentas a la red, la representación incremental de las tablas es importante para la satisfacción del usuario. Los agentes de usuario deberían empezar a representar una tabla antes de que se hayan recibido todos los datos. La anchura de ventana por defecto de la mayoría de los agentes de usuario muestra unos 80 caracteres, y los gráficos de muchas páginas HTML están diseñadas con estos valores por defecto en mente. Si se especifica el número de columnas, y si se incluyen medios para controlar la anchura de la tabla y las anchuras de las diferentes columnas, los autores pueden dar a los agentes de usuario indicaciones que les permitan representar incrementalmente los contenidos de la tabla.
Para la representación incremental, el navegador necesita el número de columnas y sus anchuras. La anchura por defecto de la tabla es el tamaño actual de la ventana (width="100%"). Esto puede alterarse estableciendo el atributo width del elemento TABLE. Por defecto todas las columnas tienen la misma anchura, pero se pueden especificar las anchuras de las columnas con uno o más elementos COL antes de que comiencen los datos de la tabla.
El otro problema a resolver es el número de columnas. Algunas personas han sugerido esperar hasta que se haya recibido la primera fila de la tabla, pero esto podría llevar bastante tiempo si las celdas tienen mucho contenido. Por lo general, si lo que se pretende es la representación incremental, tiene más sentido que los autores especifiquen explícitamente el número de columnas en el elemento TABLE.
Los autores aún necesitan un modo de decir a los agentes de usuario si usar la representación incremental o si dimensionar automáticamente la tabla para acomodar los contenidos de las celdas. En el modo de auto-dimensionado de dos pasadas, el número de columnas se determina en la primera pasada. En el modo incremental, el número de columnas debe declararse al principio (con elementos COL o COLGROUP).
HTML distingue entre código estructural, como párrafos y citas, e instrucciones de presentación, como márgenes, fuentes, colores, etc. ¿Cómo afecta esta distinción a las tablas? Desde el punto de vista del purista, la alineación del texto dentro de las celdas de una tabla y las líneas entre las celdas son cuestiones de representación, y no de estructura. En la práctica, sin embargo, es útil agrupar éstas con la información estructural, ya que estas características son muy transportables de una aplicación a la siguiente. El modelo de tablas de HTML deja la mayor parte de la información de presentación a las hojas de estilo asociadas. El modelo presentado en esta especificación está diseñado para sacar provecho de dichas hojas de estilo, pero no obliga a usarlas.
Los paquetes actuales de publicación electrónica proporcionan gran control sobre la representación de las tablas, y sería impracticable reproducir esto en HTML sin convertir a HTML en un formato de texto enriquecido muy abultado como RTF o MIF. Sin embargo, esta especificación ofrece a los autores la posibilidad de elegir entre un conjunto de clases o estilos de bordes usados normalmente. El atributo frame controla la apariencia del borde que rodea a la tabla, mientras que el atributo rules determina la elección de las divisiones que habrá en el interior de la tabla. Por medio de anotaciones de representación se logrará un nivel de control más preciso. El atributo style puede utilizarse para especificar información de representación de elementos individuales. Y se puede dar más información de representación con el elemento STYLE de la cabecera del documento o por medio de hojas de estilo vinculadas.
Durante el desarrollo de esta especificación, se investigaron diferentes posibilidades para la especificación de los patrones de líneas de división en tablas. Una de las cuestiones se refiere a las clases de declaraciones que pueden hacerse. Si se incluye soporte para sustracción de bordes así como para adición de bordes, se obtienen algoritmos relativamente complejos. Por ejemplo, para incluir en todo el conjunto de elementos de tabla los atributos frame y rules fue necesario definir un algoritmo de 24 pasos para determinar si en un borde dado de una celda dada debería haber una línea de división o no. Ni siquiera esta complejidad adicional proporciona suficiente control sobre la representación como para satisfacer el espectro completo de necesidades relacionadas con las tablas. La especificación actual se atiene deliberadamente a un modelo simple e intuitivo, suficiente para la mayoría de los propósitos. Se necesita más trabajo experimental antes de que se estandarice una aproximación más compleja.
Esta especificación proporciona un superconjunto del modelo más simple presentado en el trabajo anterior en HTML+. Se considera que las tablas están formadas por un título opcional con una secuencia de filas, las cuales consisten a su vez en una secuencia de celdas de tabla. El modelo distingue además entre celdas de encabezado y celdas de datos, y permite que las celdas abarquen varias filas y columnas.
Siguiendo el modelo de tablas de CALS (ver [CALS]), esta especificación permite que las filas de una tabla se agrupen en secciones de cabecera, cuerpo y pie. Esto simplifica la representación y puede usarse para repetir la cabecera y el pie de la tabla cuando ésta se extienda a lo largo de varias páginas, o para proporcionar cabeceras fijas sobre un panel desplazable para el cuerpo. En el código, la sección del pie se coloca antes de las secciones de cuerpo. Esto es una optimización compartida con CALS para trabajar con tablas muy largas. Permite que se represente el pie sin tener que esperar a que se procese la totalidad de la tabla.
Para aquéllos con discapacidades visuales, HTML ofrece la esperanza de enmendar el daño causado por la adopción de interfaces gráficas de usuario basadas en ventanas. El modelo de tablas de HTML incluye atributos para anotar cada celda, para permitir una conversión de texto a voz de mayor calidad. Los mismos atributos pueden usarse para permitir la importación y exportación automatizada de datos de tablas a bases de datos o a hojas de cálculo.
Si hay elementos COL o COLGROUP presentes, éstos especifican el número de columnas, y la tabla puede ser representada usando una composición fija. En caso contrario debería usarse el algoritmo de autocomposición descrito más adelante.
Si el atributo width no está especificado, los agentes de usuario visuales deberían suponer un valor por defecto del 100% a la hora de dar formato.
Se recomienda a los agentes de usuario que incrementen las anchuras de las columnas por encima del valor especificado por width en aquellos casos en que los contenidos de las celdas se desbordaran si no lo hicieran. Los agentes de usuario que redefinan la anchura especificada deberían hacerlo de manera razonable. Los agentes de usuario pueden optar por dividir las palabras entre líneas para evitar la necesidad del desplazamiento horizontal o cuando dicho desplazamiento sea poco práctico o no deseable.
En lo que a la composición se refiere, los agentes de usuario deberían considerar que los títulos de las tablas (especificados con el elemento CAPTION) se comportan como las celdas. Cada título es una celda que abarca todas las columnas de la tabla si está en la parte superior o inferior de la tabla, o todas las filas si está a la izquierda o a la derecha de la tabla.
Para este algoritmo, se supone que el número de columnas es conocido. Las anchuras de las columnas deberían establecerse por defecto al mismo tamaño. Los autores pueden cancelar esto especificando anchuras de columnas relativas o absolutas, usando los elementos COLGROUP o COL. La anchura por defecto de la tabla es el espacio entre los márgenes izquierdo y derecho actuales, pero puede redefinirse con el atributo width del elemento TABLE, o determinarse a partir de las anchuras absolutas de las columnas. Para operar con mezclas de anchuras de columnas absolutas y relativas, el primer paso es reservar espacio de la anchura de la tabla para las columnas con anchuras absolutas. Después de eso, el espacio restante se divide entre las columnas con anchuras relativas.
La sintaxis de tablas es de por sí insuficiente para garantizar la consistencia de los valores de los atributos. Por ejemplo, el número de elementos COL y COLGROUP puede ser inconsistente con el número de columnas que se deriva de las celdas de la tabla. Otro problema se produce cuando las columnas son demasiado estrechas y los contenidos de las celdas se desbordan. La anchura de la tabla especificada con el elemento TABLE o con elementos COL puede hacer que los contenidos de las celdas se desborden. Se recomienda que los agentes de usuario intenten recuperarse elegantemente de estas situaciones, p.ej., dividiendo palabras o, como último recurso, partiendo palabras si los puntos de separación son desconocidos.
En el caso en que un elemento indivisible cause desbordamiento en una celda, el agente de usuario puede considerar ajustar las anchuras de las columnas y volver a representar la tabla. En el peor de los casos, puede optar por recortar el elemento si no es posible ajustar la anchura de la columna o desplazar el contenido de la celda. En cualquier caso, si el contenido de la celda se parte o se recorta, debería indicarse al usuario de manera apropiada.
Si el número de columnas no está especificado con elementos COL y COLGROUP, entonces el agente de usuario debería usar el algoritmo de autocomposición. Éste hace dos pasadas por los datos de la tabla y aumenta linealmente con el tamaño de la tabla.
En la primera pasada se deshabilita el ajuste automático de líneas, y el agente de usuario lleva la cuenta de la anchura mínima y máxima de cada celda. La anchura máxima viene dada por la línea más ancha. Como el ajuste de líneas ha sido deshabilitado, los párrafos se consideran como líneas muy largas a menos que estén partidos por elementos BR. La anchura mínima viene dada por el elemento de texto más ancho (palabra, imagen, etc.) teniendo en cuenta la sangría, los marcadores de lista, etc. En otras palabras, es necesario determinar la anchura mínima que necesita una celda antes de que la celda comience a desbordarse. Si se permite a los agentes de usuario dividir palabras se minimizará la necesidad de desplazamiento horizontal o, en el peor de los casos, el recorte de los contenidos de la celda.
Este proceso también se aplica a cualquier tabla anidada que aparezca en el contenido de las celdas. La anchuras mínimas y máximas de las celdas de las tablas anidadas se usan para determinar las anchuras mínimas y máximas de estas tablas, y por tanto de la propia celda de la tabla padre. El algoritmo es lineal con el contenido agregado en celdas, y en términos generales, independiente del nivel de anidamiento.
Para hacer frente a la alineación de caracteres en los contenidos de las celdas, el algoritmo mantiene tres valores min/max para cada columna: a la izquierda del carácter de alineación, a la derecha del carácter de alineación, y sin alineación. La anchura mínima de una columna es entonces: max(min_left + min_right, min_non-aligned).
La anchuras de celda mínimas y máximas se usan entonces para determinar las anchuras mínimas y máximas correspondientes de las columnas. Éstas, a su vez, se usan para hallar la anchura mínima y máxima de la tabla. Obsérvese que las celdas pueden contener tablas anidadas, pero esto no complica el código significativamente. El siguiente paso es asignar anchuras a las columnas según el espacio disponible (es decir, el espacio entre los márgenes izquierdo y derecho actuales).
Para las celdas que abarquen varias columnas, una aproximación simple consiste en dividir uniformemente las anchuras min/max entre todas las columnas abarcadas. Una aproximación ligeramente más compleja es usar las anchuras min/max de las celdas que no abarcan más de una columna para ponderar las proporciones en que se dividen las anchuras. Los experimentos sugieren que una mezcla de ambas aproximaciones da buenos resultados para un amplio espectro de tablas.
Es necesario incluir los bordes de las tablas y los márgenes entre celdas cuando se asignen las anchuras de las columnas. Hay tres casos:
Para cada columna, sea d la diferencia entre las anchuras máxima y mínima de esa columna. Ahora se hace la anchura de la columna igual a la mínima más d por W partido por D. Esto hace que las columnas cuya diferencia entre las anchuras mínima y máxima sea grande sean más anchas que las columnas en que esta diferencia sea menor.
Este paso de asignación se repite entonces para las tablas anidadas usando las anchuras mínimas y máximas obtenidas para estas tablas en la primera pasada. En este caso, la anchura de la celda de la tabla padre hace el papel del tamaño actual de la ventana en la descripción precedente. Este proceso se repite recursivamente para todas las tablas anidadas. La tabla más exterior se representa entonces usando las anchuras asignadas. Las tablas se representan a continuación como parte de los contenidos de las celdas de la tabla padre.
Si la anchura de la tabla se especifica con el atributo width, el agente de usuario intenta establecer las anchuras de las columnas para respetar este valor. El atributo width no es obligatorio si hace que haya columnas que tengan anchuras menores que su anchura mínima (es decir, indivisible).
Si se especifican anchuras relativas con el elemento COL, se modifica el algoritmo para incrementar las anchuras de las columnas sobre la anchura mínima para cumplir con las restrucciones de las anchuras relativas. Los elementos COL deberían tomarse como simples indicaciones, de modo que las columnas no deberían establecerse en una anchura menor que la mínima. Análogamente, las columnas no deberían hacerse tan anchas que la tabla se extendiera más allá de los límites de la ventana. Si un elemento COL especifica una anchura relativa de cero, la columna debería establecerse siempre en su anchura mínima.
Cuando se use el algoritmo de dos pasadas, la posición de alineación por defecto, en ausencia de un atributo charoff explícito o heredado, puede determinarse eligiendo la posición que centraría las líneas para las cuales las anchuras antes y después del carácter de alineación tengan los valores máximos para cualquiera de las líneas de la columna en que align=char. Para la composición incremental de tablas el valor por defecto sugerido es charoff="50%". Si hay varias celdas en diferentes filas de una misma columna que usen un carácter de alineación, entonces por defecto todas estas celdas deberían alinearse, independientemente del carácter usado para la alineación. Se aplicarán reglas para el tratamiento de objetos demasiado grandes para una columna cuando la alineación explícita o implícita conduzca a una situación en que los datos excedan la anchura asignada para la columna.
Elección de nombres de atributos. Habría sido preferible elegir valores para el atributo frame consistentes con el atributo rules y con los valores usados para la alineación. Por ejemplo: none, top, bottom, topbot, left, right, leftright, all. Desafortunadamente, SGML requiere que los valores de atributos enumerados sean únicos para cada elemento, independientemente del nombre del atributo. Esto provoca problemas inmediatos para "none", "left", "right" y "all". Los valores del atributo frame se han elegido para evitar conflictos con los atributos rules, align y valign. Esto sirve como aviso para el futuro, ya que se anticipa que los atributos frame y rules se añadirán a otros elementos de tabla en revisiones futuras de esta especificación. Una alternativa habría sido hacer frame un atributo CDATA. El consenso del Grupo de Trabajo HTML del W3C fue que los beneficios de poder usar herramientas de validación SGML para comprobar los atributos basándose en valores enumerados compensaban la necesidad de nombres consistentes.
La representación incremental de los documentos que se reciben de la red da lugar a ciertos problemas relacionados con los formularios. Los agentes de usuario deberían evitar que los formularios fueran enviados antes de que se hayan recibido todos los elementos del formulario.
La representación incremental de los documentos plantea algunas cuestiones relacionadas con la navegación con tabulador. La heurística de dirigir el foco hacia el tabindex de menor valor del documento parece razonable a primera vista. Sin embargo, esto implica que se debe esperar a que se haya recibido todo el texto del documento, ya que hasta ese momento el tabindex de menor valor aún puede cambiar. Si el usuario pulsa el tabulador antes, es razonable que los agentes de usuario dirijan el foco al tabindex de menor valor disponible actualmente.
Si se asocian formularios con scripts en el lado del cliente, hay más problemas potenciales. Por ejemplo, un procesador de scripts para un cierto campo puede hacer referencia a un campo que aún no exista.
Esta especificación define un conjunto de elementos y atributos lo suficientemente potentes como para cubrir las necesidades generales de producción de formularios. Sin embargo aún hay sitio para muchas posibles mejoras. Por ejemplo, en el futuro podrían intentar resolverse los siguientes problemas:
Otra posible extensión sería añadir el atributo usemap a INPUT para usar mapas de imágenes en el lado del cliente cuando "type=image". El elemento AREA correspondiente al punto pulsado contribuiría al valor pasado al servidor. Para evitar la necesidad de modificar los scripts del servidor, sería apropiado extender AREA para que proporcionara los valores x e y para su uso con el elemento INPUT.
Esta especificación reserva sintaxis para el soporte futuro de macros de scripts en atributos CDATA HTML. La intención es permitir que se especifiquen atributos dependiendo de las propiedades de los objetos que aparezcan anteriormente en la página. La sintaxis es:
atributo = "... &{ cuerpo de la macro }; ... "
El cuerpo de la macro se compone de una o más sentencias en el lenguaje de scripts por defecto (como los atributos de eventos intrínsecos). El punto y coma que sigue a la llave derecha es siempre necesario, ya que de otro modo el carácter de llave cerrada "}" se considera como parte del cuerpo de la macro. También vale la pena recordar que las comillas siempre son necesarias para los atributos que contengan macros de scripts.
El procesamiento de los atributos CDATA es el siguiente:
El procesamiento de macros tiene lugar cuando el documento es cargado (o recargado) pero no vuelve a tener lugar cuando el documento se redimensiona, se redibuja, etc.
EJEMPLO DESAPROBADO:
Aquí tenemos algunos ejemplos en JavaScript. El primero de ellos elige un color
de fondo al azar para el documento:
<BODY bgcolor='&{randomrgb};'>
Tal vez lo que queramos es oscurecer el fondo por las tardes:
<BODY bgcolor='&{if(Date.getHours > 18)...};'>
El siguiente ejemplo usa JavaScript para establecer las coordenadas de un mapa de imágenes en el lado del cliente:
<MAP NAME=blabla>
<AREA shape="rect" coords="&{mirect(uri-imagen)};" href="&{miuri};" alt="">
</MAP>
Este ejemplo establece el tamaño de una imagen según las propiedades del documento:
<IMG src="barra.gif" width='&{document.banner.width/2};' height='50%' alt="banner">
Podemos establecer el URI de un vínculo o imagen con un script:
<SCRIPT type="text/javascript">
function fabricante(herramienta) {
...
}
function localidad(fabricante) {
...
}
function logo(fabricante) {
...
}
</SCRIPT>
<A href='&{localidad(fabricante("herramienta"))};'>herramienta</A>
<IMG src='&{logo(fabricante("herramienta"))};' alt="logo">
Este último ejemplo ejemplo muestra cómo los atributos CDATA de SGML pueden entrecomillarse con comillas simples o con comillas dobles. Si se usan comillas simples alrededor de la cadena del atributo entonces pueden incluirse comillas dobles como parte de la cadena del atributo. Otra aproximación es usar " para las comillas dobles:
<IMG src="&{logo(fabricante("herramienta"))};" alt="logo">
Al no haber garantía de que un nombre de destino de un marco sea único, es apropiado describir la práctica actual para encontrar un marco con un nombre de destino dado:
La Iniciativa por la Accesibilidad en la Web del W3C (W3C Web Accessibility Initiative, [WAI]) está produciendo una serie de guías para mejorar la accesibilidad a la Web por parte de personas con discapacidades. Hay tres conjuntos de guías:
Los vínculos, las imágenes incluidas, y todos los demás elementos que contengan URIs como parámetros pueden provocar que el URI sea derreferenciado en respuesta a la entrada directa por el usuario. En este caso, deberían considerarse las cuestiones sobre seguridad de [RFC1738], sección 6. Los métodos ampliamente utilizados para el envío de peticiones de formularios -- HTTP y SMTP -- proporcionan poca garantía de confidencialidad. Los suministradores de información que soliciten información sensible por medio de formularios -- especialmente con el elemento INPUT, type="password" -- deberían ser conscientes de ello y alertar a sus usuarios de la falta de confidencialidad.
Un agente de usuario no debería enviar ningún fichero que el usuario no haya pedido explícitamente que se envíe. Así, se espera que los agentes de usuario confirmen cualquier nombre de fichero por defecto que pudiera ser sugerido por el atributo value del elemento INPUT. Los controles ocultos no deben especificar ficheros.
Esta especificación no contiene ningún mecanismo para el cifrado de los datos; esto debería controlarse con cualquier otro mecanismo que sea apropiado para la transmisión segura de datos.
Una vez que se ha subido un fichero, el agente procesador debería procesarlo y almacenarlo correctamente.