Diseño Paginas WEB en Colombia HTML 5 – Introducción

 

En el Grupo de Trabajo de HTML, tenemos representantes de diferentes comunidades, incluyendo el WHATWG y otros Grupos de Trabajo del W3C.

 

El esfuerzo de HTML 5 en WHATWG y gran parte del trabajo sobre las normas del W3C sobre varios de los últimos años, se han basado en diferentes objetivos e ideas diferentes de lo que lo convierte en un buen diseño de paginas web. Para hacer un progreso útil, tenemos que tener algún acuerdo básico sobre las metas para este grupo.

 

Estos principios de diseño son un intento de capturar a un consenso sobre el enfoque de diseño.

 

Son las reglas pragmáticas generales que debe ponderarse con el otro, no son absolutos.

Son similares en espíritu a los resultados de la etiqueta en Arquitectura de la World Wide Web, pero adaptadas a las prestaciones de este grupo.

 

1,1. Conformidad de los documentos e implementaciones

 

Muchas especificaciones de lenguaje define un conjunto de requisitos de conformidad de los documentos válidos, y los requisitos correspondientes de conformidad para las implementaciones de procesamiento de estos documentos válidos.

 

HTML 5 es algo inusual en la definición de los requisitos de implementación también de conformidad para muchas construcciones que no están permitidos en los documentos conformes.

 

Esta doble naturaleza de la especificación nos permite disponer de un lenguaje relativamente limpio y comprensible para los autores, mientras que al mismo tiempo, el apoyo a los documentos existentes que hacen uso de las construcciones antiguas o no estándar, y permite una mejor interoperabilidad en la gestión de errores.

 

Algunos de los principios de diseño a continuación se aplican mucho más a los requisitos de conformidad para el contenido (el “conforme el lenguaje”), mientras que otras se aplican mucho más a los requisitos de conformidad para las implementaciones (el “lenguaje soportado”). Dado que el lenguaje soportado es un superconjunto estricto de la lengua conforme, hay una considerable superposición, pero los principios hará todo lo posible para dejar en claro que un conjunto de requisitos que se aplican.

 

2. Compatibilidad

 

Hay muchas maneras de interpretar la compatibilidad. A veces los términos “compatibilidad hacia atrás” y “la compatibilidad hacia delante” se utilizan, pero a veces el significado de esos términos puede ser poco clara. Los principios de esta sección frente a las diferentes facetas de la compatibilidad.

 

2,1. Apoyar el contenido existente

 

Este principio se aplica principalmente a los idiomas soportados.

 

El contenido existente a menudo se basa en el procesamiento esperado agente de usuario y el comportamiento que funcionan como se esperaba. Requisitos de procesamiento de modo que pueda asegurarse de que los agentes de usuario de aplicación del presente pliego será capaz de manejar contenido más actual. En particular, debería ser posible para procesar los documentos HTML existentes como HTML 5 y obtener resultados que sean compatibles con las expectativas actuales de los usuarios y autores, con base en el comportamiento de los navegadores existentes. Debe ser posible, aunque no necesariamente sea necesario, para hacer esto sin cambiar de modo.

 

El contenido basándose en el comportamiento del navegador existente puede tomar muchas formas. Puede basarse en los elementos, atributos o las API que forman parte de las primeras especificaciones de HTML, pero no forman parte de HTML 5, o en las características que son totalmente de propiedad. Esto puede depender de las normas específicas de control de errores. En casos raros, puede depender de una característica de las anteriores especificaciones de HTML no se están aplicando como se especifica.

 

Al considerar los cambios en las características heredadas o el comportamiento, en relación con las implementaciones actuales y las expectativas de autor, las siguientes preguntas deben ser considerados:

 

• ¿Tiene una cantidad significativa de los contenidos existentes dependen de la característica o comportamiento?

• ¿Tiene alguno de los contenidos depende ocurren en los sitios web más populares sobre todo?

• ¿Está el contenido depende realmente destinados al consumo, en vez de ocurrir únicamente en los casos de prueba o ejemplos?

• ¿Es el contenido depende de la red pública, en lugar de encontrarse únicamente en los sitios internos con un ambiente controlado por el usuario?

• ¿El contenido depende en la actualidad funciona como es debido en múltiples aplicaciones de usuario más populares, más que explícitamente orientada solamente a un agente de usuario particular, o sólo muy viejo o de lo contrario los impopulares?

 

El beneficio de la modificación propuesta debe sopesarse contra el costo probable de romper el contenido, según lo medido por estos criterios. En algunos casos, puede ser deseable hacer una característica no estándar o comportamiento parte del lenguaje conforme, si se satisface un caso de uso válido. Sin embargo, el hecho de que algo es parte del lenguaje soportado por sí misma no significa que confiar en que se tolera o alienta.

 

2.1.1. Ejemplos

 

Muchos sitios utilizan el marcado roto, como elementos de mal anidados (<b> un <i> b </ b> c </ i>), y ambos autores y los usuarios tienen expectativas basadas en el manejo de errores utilizado por los agentes de usuario existentes. Tenemos que definir los requisitos de procesamiento que siguen siendo compatibles con el manejo de espera de dicho contenido.

 

Algunos sitios se basan en el elemento <u> dando el efecto de presentación de un subrayado.

 

2,2. Degradarse de forma elegante

 

Este principio se aplica principalmente a la lengua conforme.

 

En la World Wide Web, los autores suelen ser reacios a utilizar las nuevas características del lenguaje que causan problemas en los agentes de usuario antiguos o que no ofrecen algún tipo de reserva agraciado. HTML 5 requisitos de conformidad de documentos deben ser diseñados de forma que de contenido Web pueden degradarse de forma elegante en los agentes de usuario antiguos o menos capaces, incluso al hacer uso de nuevos elementos, atributos, APIs y modelos de contenido.

 

No es necesariamente apropiado considerar todos los agentes de usuario de la web jamás se ha hecho, incluidas las versiones, incluso muy antiguas de los navegadores o herramientas que son sumamente impopulares, incluso en sus mercados de nicho. Sin embargo, una fuerte consideración se debe dar a las siguientes categorías de agentes de usuario. Es muy probable que los autores de contenido será más importante centrarse en estas categorías:

• Las versiones actuales de los navegadores Web más populares tradicionales.

• Las versiones más antiguas de gran popularidad de los principales navegadores web.

• Los agentes de usuario los mejores diseñados para satisfacer necesidades específicas o dirigirse a mercados especializados, tales como las tecnologías de asistencia, los navegadores móviles o agentes de usuario los medios de comunicación dirigidos a menos típicos, tales como terminales de sólo texto o material impreso.

 

En algunos casos, una nueva característica no puede simplemente se aplican a una cierta clase de agentes de usuario, o puede no ser práctico para diseñar de una manera que puede degradar. Por ejemplo, la nueva API de secuencias de comandos no se puede hacer para trabajar en los agentes de usuario scriptless. Pero en muchos casos, los enfoques como el siguiente puede ser utilizado:

• Un nuevo elemento o atributo puede proporcionar una semántica adicional sin perder la funcionalidad esencial cuando no lo entienden.

• Un nuevo método de secuencia de comandos o un atributo puede ser probado antes de su uso en la secuencia de comandos con las instalaciones de ECMAScript introspección.

• Un nuevo elemento o atributo puede proporcionar una representación semántica y la omisión simple que se puede lograr usando CSS, por lo que la adición de una hoja de estilo pequeño permite la degradación agraciada.

• Un nuevo elemento, atributo o API de secuencias de comandos pueden tener un comportamiento que puede ser emulada por el uso de la escritura adicional, aunque el enfoque de secuencias de comandos no puede proporcionar el mismo nivel de rendimiento y comodidad.

• Un nuevo elemento puede requerir una interpretación muy especializada, pero permiten a los diferentes contenidos que se ofrece como reserva para los agentes de usuario que no entienden el elemento.

 

Esta lista no es exhaustiva, y en algunos casos un poco más complicados enfoques son más eficaces.

 

2.2.1. Ejemplos

 

La presentación por defecto del atributo irrelevante propuesta puede servir de ejemplo a través de la regla CSS [irrelevante] {display: none;}.

 

Propuestas de nuevos elementos multimedia como reserva <canvas> </ lienzo> o <video> reserva </ video> permitir que el contenido de reserva. Mayores agentes de usuario se mostrará “de reserva”, mientras que los agentes de usuario de apoyo de lona o de vídeo se mostrará el contenido multimedia.

 

El getElementsByClassName propuesto () puede ser considerablemente más rápido que puros implementaciones ECMAScript que se encuentran en las bibliotecas existentes, pero una aplicación basada en comandos se puede utilizar cuando la versión nativa no está disponible.

 

El elemento <datalist> puede estar asociado con un elemento <input> y puede contener un elemento oculto <select>. De esta manera la reserva prevista para el “cuadro combinado” de control puede ser un campo de texto o un campo de texto asociado con un menú emergente en los navegadores convencionales existentes

 

2,3. No reinventar la rueda

 

Si ya existe una tecnología ampliamente utilizada e implementada que cubre los casos particulares de uso, es recomendable especificar que la tecnología en lugar de inventar algo nuevo para el mismo propósito. A veces, sin embargo, nuevos casos de uso puede llamar a un nuevo enfoque en lugar de más extensiones en un enfoque de edad.

 

= contenteditable “” ya fue utilizado y aplicado por los agentes de usuario. No hay necesidad de inventar una nueva característica.

 

2,4. Pavimentar los Cowpaths

 

Cuando una práctica está ya muy extendida entre los autores, considerar la adopción de ella en lugar de prohibirlo o inventar algo nuevo.

 

Los autores ya utilizan la sintaxis <br/> a diferencia de <br> en HTML y no hay daño hecho al permitir que, para ser utilizado.

 

2,5. La evolución no revolución

 

Las revoluciones a veces cambian el mundo para mejor. Muy a menudo, sin embargo, es mejor para evolucionar un diseño ya existente en lugar de tirarlo a la basura. De esta manera, los autores no tienen que aprender los nuevos modelos y el contenido va a vivir más tiempo. En concreto, esto significa que uno debe preferir a sus características para que el contenido de edad pueden tomar ventaja de las nuevas características sin tener que hacer cambios que no. Y las implementaciones deben ser capaces de añadir nuevas características al código existente, en lugar de tener que desarrollar modos independientes enteros.

 

El cambio a la sintaxis XML requiere un cambio global, por lo que continuará apoyando la sintaxis HTML clásico también.

 

3. Utilidad

 

Estos principios requieren un diseño que hace HTML que puede ser utilizado efectivamente para los fines previstos muchos.

 

3,1. Resolver problemas reales

 

Los cambios en las especificaciones actuales deben resolver problemas del mundo real. Arquitecturas abstractas que no responden a una necesidad existente son menos favorecidos que las soluciones pragmáticas a los problemas que enfrenta hoy el contenido web. Y ya existentes problemas generalizados deben ser resueltos, cuando sea posible.

 

3,2. Prioridad de los distritos electorales

 

En caso de conflicto, considerar a los usuarios sobre los autores sobre los ejecutores sobre los especificadores de más de pureza teórica. En otras palabras, los costos o las dificultades para el usuario se debe dar más peso que los costos a los autores, que a su vez se debe dar más peso que los costos para los ejecutores, lo que se debe dar más peso que los costos a los autores de la misma especificación, que debe ser da más peso que aquellos que proponen cambios por razones teóricas solo. Por supuesto, es preferible hacer las cosas mejor para los grupos a la vez.

 

3,3. Seguro por diseño

 

Asegúrese de que las características de trabajar con el modelo de seguridad de la web. Preferiblemente abordar consideraciones de seguridad directamente en el pliego de condiciones.

 

La comunicación entre los documentos de diferentes sitios es útil, pero una versión sin restricciones podría poner en riesgo los datos del usuario. Entre documentos de mensajería está diseñado para permitir esto sin violar las restricciones de seguridad.

 

3,4. La separación de las preocupaciones

 

HTML debe permitir la separación de contenido y presentación. Por esta razón, el marcado que expresa la estructura general se prefiere que el marcado solamente a la presentación. Sin embargo, el marcado estructural es un medio para un fin, como la independencia de los medios de comunicación. Codificación semántica profunda y detallada no es necesaria si el final se puede llegar a lo contrario. Definición de presentación por defecto razonable para distintos medios de comunicación puede ser suficiente. HTML establece un equilibrio entre expresividad semántica y utilidad práctica. Los nombres de elementos y atributos en el margen de beneficio puede ser pragmático (por brevedad, la historia, la simplicidad) en lugar de totalmente exacta.

 

El artículo define los elementos de un artículo individual, pero no los detalles de cómo se muestra. Un artículo de revista puede ser el único artículo en una página, con el formato en varias columnas, mientras que una entrada de blog puede compartir una página con varios otros artículos y se presenta en una caja con un borde.

 

La b y los elementos i son ampliamente utilizados – que es mejor darles una buena representación predeterminada de diversos medios de comunicación, incluyendo fonética, que tratar de prohibirlos.

 

3,5. DOM consistencia

 

Los dos serializaciones deben ser diseñados de tal manera que los árboles DOM producidos por los analizadores respectivos aparecen como consistente como sea posible a los guiones y de funcionamiento otro programa de código en los árboles de documentos. Las discrepancias se puede permitir la compatibilidad con las implementaciones existentes, pero las diferencias deben reducirse al mínimo.

 

Además, salvo que sea necesario para la compatibilidad con las implementaciones existentes y el contenido desplegado, la diferencia en el aspecto sintáctico gratuita debe ser evitado también.

 

El HTML (text / html) analizador pone elementos en el espacio de nombres http://www.w3.org/1999/xhtml en el DOM para la compatibilidad con la sintaxis XML de HTML 5.

 

4. Interoperabilidad

 

Estos principios existen para mejorar las posibilidades de las implementaciones de HTML son realmente interoperable.

 

4,1. Comportamiento bien definido

 

Prefiero definir con claridad el comportamiento que los autores de contenido pueden confiar, en lugar de un comportamiento impreciso o aplicación definida. De esta manera, es más fácil al contenido autor que trabaja en una variedad de aplicaciones de usuario. Sin embargo, las implementaciones aún debe ser libre de hacer mejoras en áreas tales como la interfaz de usuario y la calidad de la prestación.

 

4,2. Evitar una complejidad innecesaria

 

Las soluciones simples son preferibles a las más complejas, cuando sea posible. Características más simples son más fáciles para los agentes de usuario para poner en práctica, es más probable que sean interoperables, y más fácil para los autores de entender. Pero esto no debe ser utilizada como una excusa para evitar el pago de los demás principios.

 

4,3. Controlar los errores

 

El manejo de errores debe ser definido de manera que las implementaciones interoperables que puede lograrse. Prefiere la recuperación de errores graciosa al fracaso duro, por lo que los usuarios no están expuestos a errores de edición.

 

5. El acceso universal

 

Características deben estar diseñados para el acceso universal. Esta categoría abarca varios principios relacionados con eso.

 

5,1. Medios de Comunicación de la Independencia

 

Características que, cuando sea posible, trabajar en diferentes plataformas, dispositivos y medios de comunicación. Esto no debe interpretarse en el sentido de que una característica se debe omitir sólo porque algunos medios de comunicación o plataformas, no puede apoyarla. Por ejemplo, características interactivas no debe ser omitido simplemente porque no se puede representar en un documento impreso.

 

El reflowability general de texto HTML hace que sea más adecuado para las dimensiones de pantalla variables que una representación de las posiciones exactas de glifos.

 

Un hipervínculo no puede ser accionado en un documento impreso, pero eso no es razón para omitir el elemento a.

 

5,2. Apoyo a diferentes idiomas del mundo

 

Habilitar publicación en todos los idiomas del mundo. Pero esto no debe ser tomada como igualar los sistemas de escritura mediante la prohibición de las características que no se aplican a todos ellos. Características para el embalaje de múltiples traducciones de un documento en un solo archivo están fuera de alcance.

 

Apoyo a Unicode permite que el texto en la mayoría de las lenguas del mundo, incluida la mezcla de texto en diferentes idiomas.

 

El texto en cursiva es útil porque se aplica a muchos scripts bicamerales, a pesar de que algunas secuencias de comandos no tienen ese concepto. Del mismo modo, el rubí es útil para muchos scripts, a pesar de que tiene un enfoque CJK.

 

Texto en el contenido del elemento tiene un mejor soporte de texto en idioma contenido atributo; en el contenido del elemento anotaciones rubí puede ser insertado, así como atributos dir y elementos BDO en caso de que el algoritmo bidireccional Unicode es insuficiente para ordenar correctamente tramos adyacentes de texto dirección mixta.

 

5,3. Accesibilidad

 

Las características del diseño para ser accesible a usuarios con discapacidades. El acceso de todos, independientemente de la capacidad es esencial. Esto no quiere decir que las características se debe omitir por completo si no todos los usuarios pueden hacer uso completo de ellos, pero los mecanismos alternativos debe ser proporcionada.

 

La imagen de una img no sean visibles para los usuarios ciegos, pero eso es una razón para ofrecer un texto alternativo, por no dejar de lado las imágenes.

 

El elemento de progreso es intrínsecamente accesibles, ya que tiene una semántica sin ambigüedades la barra de progreso que permite el acceso a las APIs de mapeo que puede representar a los indicadores de progreso.

 

Agradecimientos

 

Los editores desean agradecer a Charles McCathieNevile, Chris Wilson, Dan Connolly, Sivonen Henri, Ian Hickson, Kosek Jirka, Hunt Lachlan, Thierry Nik, Felipe Taylor, Richard Ishida, Stephen Stewart y Steven Faulkner por su contribución a este documento, así como a todas las personas que han contribuido a HTML 5 en los últimos años para mejorar la web!

 

Si usted ha contribuido a este documento, pero su nombre no aparece en la lista anterior, por favor deje que los editores saben para que puedan corregir esta omisión.