Comencé a aprender estándares web a principios del año pasado y he adquirido algo de experiencia en los últimos dos años. Recientemente cambié de trabajo y estoy libre en casa, así que escribí algo para compartir con todos.
1. Comprensión de los estándares web y las especificaciones W3C XHTML.
Según el entendimiento habitual, estos dos conceptos parecen referirse a lo mismo (estas "teorías avanzadas" que discutimos en esta edición ^_^). Pero creo que, de hecho, desde un punto de vista técnico, estas dos cosas casi no tienen correlación alguna. En resumen, los estándares web implementan de forma independiente la estructura, el rendimiento y el comportamiento de la página. Más comúnmente, es el lenguaje popular "div + css" en el reclutamiento actual. Sin embargo, ninguna versión de W3C XHTML impone restricciones al concepto de estándares web. Obviamente, podemos usar xhtml 1.1 para escribir una página web posicionada en una tabla. Llegados a este punto, puedes pensar que estoy diciendo muchas tonterías. Pero con cualquier tecnología, sólo puedes usarla correctamente cuando tienes una comprensión suficientemente clara de los conceptos básicos. Permítanme hablar sobre los dos caminos equivocados en la aplicación actual de los estándares web desde los dos aspectos siguientes:
El primer caso es sencillo. Creo que siempre que se utilice XHTML+CSS, es un estándar web. La página está llena de clases e identificaciones. Siéntase libre de definir clases separadas para cada detalle. La diferencia entre una página de este tipo y el HTML tradicional es que hay un "/" adicional en la etiqueta img. De hecho, es mejor volver al HTML tradicional. Al menos puedo usar fuentes fácilmente sin tener que buscar la hoja de estilos como si fuera un diccionario. Otro uso más sutil e informal de CSS del que hablaré más adelante.
Creo que la segunda situación es más difícil de entender, es decir, intentar utilizar varias declaraciones complicadas de anidamiento div y css para lograr el rendimiento deseado. Un ejemplo muy simple está en una publicación que acabo de ver "Página con esquinas redondeadas sin cortar la imagen". En primer lugar, quiero estar seguro de que esta idea es realmente buena: utilizar la función CSS para "dibujar" las esquinas redondeadas. Para hacer esto, el diseñador debe agregar una gran sección de código de la siguiente manera en la ubicación correspondiente:
| El siguiente es el contenido citado: Código fuente de ejemplo [www.52css.com] <b clase="b1"></b><b clase="b2"></b><b clase="b3"></b><b clase="b4"></b> <b clase="b4"></b><b clase="b3"></b><b clase="b2"></b><b clase="b1"></b> |
Sin embargo, esto viola gravemente el concepto básico de los estándares web: la separación entre estructura y presentación. Porque coloca el código utilizado para controlar el rendimiento de la página web en el documento estructural. Quizás se diría que en realidad pone el código de rendimiento real en CSS. Pero creo que este es un concepto robado. Debido a que las etiquetas b anteriores no tienen nada que ver con la estructura de la página web, todas son etiquetas vacías. Es decir, no existe para poner algo donde la estructura del documento lo requiera. Entonces son solo código basura para la estructura del documento.
Otro ejemplo puede ser más sutil. He visto un artículo en alistapart.com antes sobre cómo implementar columnas de tres vías en una página web. El principio probablemente sea usar tres o cuatro divs para anidar entre sí. Creo que esto también es una violación de los estándares web. Porque el orden en el que se colocan estas etiquetas div en el código no es simplemente por necesidades estructurales, sino también por el rendimiento de la página web.
Por supuesto, admito que el punto de vista anterior es excesivo hasta cierto punto (pero por otro lado, si tienes que implementar esquinas redondeadas que no sean imágenes, ¿no es también excesivo, jaja)? A veces, la estructura y el rendimiento no se separan tan fácilmente. Para lograr un rendimiento rico, tenemos que dejar que la estructura se adapte (piense en el uso de <div style="clear:both" />). Pero es importante saber qué está bien y qué está mal. Incluso si a veces tenemos que hacer algo mal.
Finalmente, quiero afirmar que no estoy diciendo que "esquinas redondeadas que no son imágenes" no tenga sentido o sea incorrecto. También admiro la inteligencia y la inspiración del autor. Creo que este tipo de investigación técnica es como antes usar CSS para dibujar la bandera nacional, y es muy útil para dominar la tecnología CSS. Sin embargo, su uso debería ser tan limitado como el indicador CSS y no debería adoptarse en aplicaciones prácticas. Porque viola los principios básicos de los estándares web.
2. La semántica de las etiquetas HTML.
Los estándares web actuales se denominan coloquialmente "div+css" o "diseño de capas". No me opongo a esta conveniencia. Pero esto conducirá a un malentendido: utilizar una gran cantidad de etiquetas div como elementos estructurales. De hecho, esta es una forma más avanzada de abuso de div (mencionada por Jeffrey Zeldman en el libro "Website Refactoring").
HTML nos proporciona una gran cantidad de etiquetas, cada una de las cuales tiene su propio significado. Creo que a la hora de diseñar, además de seguir la sintaxis HTML, debemos aprovechar y cumplir al máximo la "semántica" de cada etiqueta. Por ejemplo, el texto del título debe incluirse en h1-h6, los párrafos grandes de contenido de texto deben segmentarse por <p> en lugar de <br />, los elementos de la lista deben colocarse en ul, ol o dl, y los datos en forma tabular. todavía debería ser el diseño de la tabla.
¿Por qué hacer esto? Una razón muy convincente es garantizar que cuando el usuario elimina la visualización de CSS, la página web pueda mostrar la jerarquía estructural del contenido de la manera más efectiva posible. Si se utilizan todos los divs, cuando se elimina el CSS, toda la página web perderá su jerarquía, dejando solo algunos fragmentos de texto desordenados. Esto no cumple con los requisitos del estándar web para compatibilidad de configuración baja.
Permítanme enumerar en detalle mi comprensión de la semántica de algunas etiquetas:
p br
Hablemos primero del más simple. Utilice etiquetas p en lugar de br (incluso dos <br /> consecutivas) para los párrafos. Parece que esto es innecesario decir mucho. Pero a veces tenemos que renunciar a este principio. Un ejemplo común es una publicación en un foro; si quiero segmentarla, presiono Enter. Lo que se transmite al fondo y se muestra de esta manera se segmenta obviamente mediante <br />.
mesa th
Debido a la vigorosa promoción de div+css, parece que quien utiliza el diseño de tablas es un nativo incivilizado. Pero creo que esta visión es incorrecta. El significado de tabla es una tabla, por lo que cualquier dato que deba aparecer en forma tabular aún debe presentarse en una tabla. Un ejemplo simple es la lista de compañeros de clase, incluidos nombres, identificaciones de estudiantes, géneros, etc. Obviamente, estos son datos en forma tabular, por lo que se debe utilizar un diseño de tabla. Otro ejemplo que vale la pena explorar es la navegación por el calendario del blog. Una vez vi un programa de blog. Las fechas en la navegación de su calendario están todas envueltas en divs del 1 al 30, y luego se usa el estilo float:left para organizar el calendario del mes actual en una fila de 7. Cuando cancelo la visualización CSS del navegador, la parte del calendario se organiza verticalmente del No. 1 al No. 30. Creo que esto está mal. Debido a que el calendario debe contener datos en forma tabular, aún se debe utilizar el diseño de tabla. Después de cancelar el CSS, aún deberían agruparse en una tabla con 7 seguidos.
Esta es otra etiqueta que será ignorada. Debido a la omnipotencia de CSS, todas las celdas de la tabla se pueden crear usando td y un atributo de clase. Pero semánticamente, algunas celdas de la tabla deberían etiquetarse con th. Por ejemplo, en la tabla de calendario mencionada anteriormente, las unidades "LUN MAR MIÉ... DOM" que identifican la semana deben usar th en lugar de td.
h1-h6
Para las etiquetas h1-h6, semánticamente deberían funcionar para todo el texto del título. Por lo tanto, algunos métodos de escritura como <div class="diary-title> son redundantes. Escríbalo directamente como <h1> y luego defina directamente CSS para h1 en lugar de .diary-title. ¿No tendría el mismo efecto? Por supuesto, esta regla I no puede ser demasiado rígida, porque a veces los elementos estructurales de la parte del título no se pueden resolver simplemente usando un h1, pero a lo sumo uso un método como <h1><span></ span></h1> para cambiar el título. La estructura está anidada de manera más compleja para satisfacer las necesidades de rendimiento.
Pero aquí surge un desacuerdo semántico. ¿Debería entenderse h1 como un título de primer nivel o como un título con un tamaño de fuente de tamaño 1? Normalmente lo entiendo como un título de primer nivel, y si hay subtítulos debajo del título de primer nivel, uso h2. Pero, de hecho, mirando hacia atrás al comienzo del diseño HTML, se entiende más que los números después de h1-h6 controlan el tamaño del texto del título. h3 se puede usar solo para usar una fuente de tamaño tres, no es que sea un título de tercer nivel. De lo contrario, todos los títulos de primer nivel usan h1, y todos son fuentes muy grandes, y hay que usar CSS para controlar el tamaño de la fuente, lo cual parece muy engorroso. Entonces, esta es una cuestión para debate.
ul ol
Siempre que necesite enumerar términos, debe usar ul u ol en lugar de p. Por ejemplo, requisitos laborales en anuncios de contratación, como precauciones, como instrucciones de pasos de operación. Además, un uso popular es utilizar ulli para enumerar el menú de navegación de una página web y luego utilizar CSS para controlar su disposición.
Cabe agregar que no olvide que ul u ol se pueden usar en li para formar una lista de segundo nivel.
dl dt dd
Este es un conjunto de etiquetas casi olvidado, pero Jeffrey Zeldman promueve firmemente su uso en la "refactorización de sitios web". dl debe ser el nombre completo de "lista de definición (¿o lista de definición? Si alguien lo sabe, dímelo)". El nombre de la palabra se coloca en dt y la explicación de la palabra se coloca en dd. El sitio web alistapart.com es aún más inteligente y define toda la columna derecha como dl, usando dt para el título de cada unidad y dd para el contenido de la unidad.
imagen
La etiqueta img en sí no tiene mucho que decir. Solo quiero hablar de un lugar común, es decir, usar img solo cuando este elemento sea realmente una imagen necesaria en el contenido. De lo contrario, debe definirse como un estilo usando CSS. Como ilustraciones, avatares, emoticones, estas son imágenes que deben aparecer en el contenido, use img. Otros, como la imagen de fondo del título y el pequeño icono delante del elemento de la lista, no deben utilizar la etiqueta img.
durar
span ahora es tan popular como div. Pero, de hecho, creo que deberíamos ceñirnos a su uso original. Mi entendimiento personal es que span se usó originalmente para llevar atributos de clase o estilo. En sí mismo no tiene una semántica clara. Por lo tanto, en el flujo de texto, si necesitamos realizar cambios de estilo en algún texto, usamos span para encerrarlo. Por ejemplo, si es necesario agregar algunas palabras en rojo, uso <span class="red">.
Sin embargo, vale la pena señalar que esto puede causar los problemas mencionados anteriormente en h1. Debido a que algunos estilos de texto en realidad tienen etiquetas listas para usar, como <strong>, <sub>, etc., también debemos brindarles algunas oportunidades de manera adecuada.
a
a es la etiqueta que controla la hiperconexión. Pero hay algunos casos especiales en los que quizás no nos guste utilizarlo. Por ejemplo, es necesario que aparezca una pequeña ventana. No presté mucha atención, pero creo que algunos diseñadores definirán onclick directamente en la etiqueta <img> del ícono "reproducir". Personalmente, creo que deberíamos agregar a fuera de img, luego definir onclick dentro de a y recordar escribir return false al final de la función js. Si es posible, el atributo href de la etiqueta a también debe escribirse con la URL de la ventana emergente para garantizar que los usuarios aún puedan abrir la página de manera efectiva incluso si JS está deshabilitado.
Eso es todo lo que enumeraré por ahora.
Finalmente, resumamos la importancia de seguir la semántica de las etiquetas HTML. Uno de los requisitos de los estándares web es la compatibilidad de bajo perfil: cuando un usuario desactiva imágenes, desactiva CSS o desactiva JS, aún podemos permitirle navegar por contenido web de forma eficaz. Como todos sabemos, el atributo alt obligatorio es considerar la compatibilidad al desactivar imágenes. Seguir correctamente la semántica de las etiquetas HTML garantiza la compatibilidad cuando CSS está deshabilitado. Solo cuando las etiquetas HTML se usan correctamente y nuestra página web tiene "rayas CSS", las personas aún podrán ver dónde está el menú de navegación, dónde está el título del artículo y la tabla del calendario no se desmoronará.