La brisa primaveral de la "reconstrucción" sopla por todo el país e Internet está en un estado de confusión desde hace un tiempo. "div + CSS" se ha convertido en una "moda". Innumerables sitios web han comenzado su propia "reconstrucción". Sin embargo, abrir el código fuente de estos diversos sitios web a menudo hace que la gente se ría——
Vemos diseños div con 6 o 7 capas anidadas, tablas sin tablas, páginas compuestas de div+a puro y cientos de clases de capas de presentación... Hoy en día, cada vez hay más libros sobre estándares, excepto algunos libros que anuncian. "técnicas avanzadas", pocas personas no enfatizarían esa frase en los primeros capítulos de sus libros: "separación de estructura y expresión". Sin embargo, ¿cuántos lectores de estos libros han leído seriamente los primeros capítulos? ¿O prefieres saltarte las aburridas explicaciones de la estructura y sumergirte en técnicas de diseño y trucos aparentemente avanzados?
De hecho, el término div+CSS ha engañado a demasiadas personas desde el principio, y la mentalidad ansiosa por lograr un éxito rápido es la culpable de este fenómeno. El primer paso para que una persona que está acostumbrada a la producción de páginas web con diseño de tablas entre en contacto con los estándares no debería ser buscar ciegamente técnicas CSS para implementar varios diseños, sino esforzarse por cambiar su forma de pensar.
A continuación hablaré sobre la forma de pensar en el cumplimiento de los estándares basándose en mi experiencia personal. Muchos de ellos son desvíos que he tomado y espero que sean de ayuda para los XDJM que acaban de entrar en contacto con los estándares:
1. El “código guardado” es una herramienta de marketing, no un propósito
"El uso del diseño div puede ahorrar más código que el diseño de tabla", he visto esta frase en muchos libros y sitios web. Esta frase en sí es correcta. "Guardar código" es de hecho uno de los beneficios de la estandarización de páginas web. Sin embargo, recuerde que es sólo "uno de los beneficios", no el "único beneficio", y no es el propósito. “Guardar código” suele ser una estrategia de marketing que utilizamos para convencer a los jefes testarudos. El único propósito de la estandarización de páginas web es "separar la estructura y el rendimiento", y nunca se trata de guardar código por guardar código. Una vez usé una clase unificada porque la barra lateral e incluso el contenido principal del sitio web tienen la misma forma de presentación (todavía hay algunos libros que enseñan esto). De hecho, esto ahorra más código que nombrar las ID por separado. de esto es que el código pierde su buena estructura. Las consecuencias de perder una buena estructura son: 1. El código fuente ya no es legible. 2. El sitio web aumenta los costos de mantenimiento desconocidos. Imagínese, cuando un determinado contenido cambia su presentación debido a necesidades, como el color de un enlace, etc., tenemos que modificar el archivo fuente de la página y agregar clases adicionales. La carga de trabajo es mucho mayor que simplemente ajustar la identificación. agrupación. Y si las cosas siguen así, la estructura irá de mal en peor, formando un círculo vicioso difícil de revertir.
Hay otra situación que ocurre en la denominación de ids, que también es un error que he cometido. En ese momento, para "guardar código", el menú principal se llamaba "mm", el menú secundario se llamaba "m2" y el menú de tercer nivel se llamaba "m3". La página web se redujo seriamente, lo que dificultó que otros colegas tomaran el control, tratando de evitar problemas pero cansándome a mí mismo. De la misma manera, no es recomendable simplificar demasiado la denominación de archivos y carpetas. Por ejemplo, "Reconstrucción de sitios web" recomienda almacenar todas las imágenes en el directorio "i". Personalmente, creo que no es recomendable a menos que sepas escribir para ello. una estructura de directorio muy abreviada. Explique en detalle y asegúrese de que todos los involucrados, incluido el resto del personal de producción, los desarrolladores e incluso los jefes con conocimientos ... puedan comprenderlo e implementarlo; de lo contrario, solo le agregará problemas innecesarios.
2. La identificación es un rifle de francotirador, la clase es un arma de doble filo.
Si desea tener una buena estructura de página web, debe dominar con fluidez tanto la identificación como la clase. El llamado "agarre con ambas manos, ambas manos deben ser fuertes". ID es como un rifle de francotirador, que puede ayudarnos a ubicar con precisión los elementos que queremos cargar; estilos y clase es la espada del caballero, que es más liviana y flexible al alcance de tu mano. La combinación de los dos puede lograr una página con buena estructura. y rico rendimiento. Sin embargo, ahora existe una visión incorrecta de que la identificación se puede reemplazar completamente por clase. De hecho, esto es cierto para muchos códigos fuente de páginas web. Cuando abre la clase completa, no puede encontrar una identificación. Hay muchas razones para este fenómeno, pero el concepto profundamente arraigado de "clase = CSS" transmitido desde la era de las tablas es la causa principal. Es cierto que class es más versátil y flexible que id, pero también hay que tener en cuenta que class es mucho menos eficaz que id a la hora de crear una buena estructura de página web. La unicidad obligatoria de id nos facilita recuperar cualquier módulo que necesitemos a través de id, mientras que la clase no tiene esta ventaja. Aunque podemos definir un nombre de clase único para el módulo, la premisa es que solo el propio productor puede cambiar el estilo de la página web. De lo contrario, busquemos a un tipo un poco vago. Al ver que los estilos son los mismos, aplicará directamente la clase anterior. El resultado es que hay más de una docena de módulos en la página web llamados "gonggao" o "xinwen". ", por lo que es difícil distinguirlos. Sin agregar muchos comentarios html, este resultado obviamente no es el que queremos. Además, como se mencionó anteriormente, el código guardado a través de clases universales debe desperdiciarse en cada clase definida individualmente.
La identificación es un rifle de francotirador y la clase es un arma de doble filo. Juntos, ambos nos beneficiamos y, separados, ambos perdemos.
3. No todo el contenido requiere div como "contenedor"
¿Debo usar <div id="mainnav"><ul> o <ul id="mainnav"> para el menú principal? Este es un problema del juego. Hasta el momento nadie puede dar una respuesta clara a esta pregunta, ni siquiera yo. Es cierto que cuando <div id="mainnav"> solo contiene un elemento <ul>, este div parece un poco redundante, pero a veces para que coincida con el magnífico diseño, una capa más de etiquetas significa una capa más de cambios (. algunas personas también usan span en la etiqueta a). La ventaja inherente de div sin ningún atributo original no tiene comparación con otras etiquetas. Solo quiero ilustrar una cosa con esta proposición, es decir, debemos darnos cuenta de que además de <div id="mainnav"><ul>, también existe <ul id="mainnav"> esta forma de escribir, que también tiene buena estructura y semántica y elimina una capa de anidamiento. Cuando no tenemos que preocuparnos por el arte magnífico, ¿podemos también hacer que la estructura sea más simple?
En realidad, esta proposición se puede extender a: "No todo el contenido necesita elementos de bloque como contenedores" y "No todos los enlaces necesitan otros elementos como contenedores", como "más" que tienen muchas páginas. Algunas personas escriben "<div class="more"><a>", mientras que otras escriben <p><a> o <strong><a>. ¿Todavía necesitan existir cuando estos "contenedores" solo contienen una etiqueta <a>? ¿Escribir directamente<a class="more">rompería la estructura? ¿Le faltará semántica? ¿Afectará el diseño? Si piensas diferente, puedes ganar algo diferente.
4. Lograr la "separación de estructura y desempeño" en el trabajo
Con respecto a este punto, muchos expertos en Internet sugieren esto, es decir, primero abra el editor, escriba la estructura por completo, luego vaya a CSS para escribir la interpretación y trate de no tocar la estructura ya escrita.
Sin embargo, es difícil de entender para las personas que utilizan la lectura de libros como su principal método de aprendizaje, porque la mayoría de los libros sobre estándares enseñan paso a paso, lo que significa que deben combinar estructura y expresión paso a paso. Aunque algunos libros tienen sugerencias a este respecto, unas pocas frases cortas son muy inferiores a los efectos sutiles durante el proceso de lectura. Cuando el personal de producción pueda comprender bien la estructura, escribir la estructura y el rendimiento al mismo tiempo no tendrá mucho impacto en los resultados. Pero en mi experiencia, el método de trabajo de separar estructura y presentación es mucho más eficiente que escribir estructura y presentación al mismo tiempo. Al mismo tiempo, no es fácil pasar por alto elementos en la página.
Por supuesto, la llamada "separación de estructura y rendimiento" no significa que el rendimiento se ignore por completo. Si desea tener en cuenta el rendimiento, debe asegurarse de que el selector CSS pueda seleccionar la mayor cantidad de contenido posible sin destruir la estructura. . Dónde agregar clases o qué etiquetas usar para distinguirlas es una cuestión de opinión. Creo que cada uno tiene su propia experiencia. Al combinar diferentes borradores de diseño, a veces es necesario realizar los cambios correspondientes. Sin embargo, todos estos cambios deben tener la misma premisa: no destruir la estructura y la legibilidad del código.
Además, debemos darnos cuenta de que cualquier herramienta visual es un demonio. Los efectos presentados en sus interfaces visuales están a menudo a miles de kilómetros de los de los navegadores reales. Lo que realmente queremos ser compatibles es el navegador, no la interfaz visual del editor.
5. CSS no es una panacea y no es imposible vivir sin CSS.
En comparación con la era CSS1.0, CSS puede lograr más cosas hoy. Sin embargo, la demanda siempre está por delante de la tecnología. CSS no puede completar todo el trabajo de la capa de presentación de las páginas web. A veces debemos combinar JS u otros lenguajes para lograr algunos efectos. . Otras veces, usar JS es mucho más sencillo que confiar únicamente en CSS y el código está mejor estructurado; el ejemplo más típico es el menú desplegable. En estos momentos, tenemos que convencernos a nosotros mismos, o a nuestros jefes y clientes, de utilizar métodos más simples y razonables. Debido a que DOM también es un componente importante de los estándares de páginas web, no significa que el uso de JS hará que nuestras páginas web sean menos eficientes o dejen de ser estándar. Al contrario, este es el mayor malentendido de JS. Dicho esto, debo mencionar que en la era actual, todas las profesiones deben conocer conocimientos más relevantes que nunca. Quienes diseñan deben saber un poco sobre interacción y producción, y quienes hacen producción también deben comprender el diseño y la programación. Especialmente con tecnologías front-end como JS, solo así usted y sus colegas podrán trabajar mejor juntos y sus perspectivas de desarrollo personal serán más brillantes.
Sin CSS se refiere a cuando nuestro sitio web no puede cargar el archivo CSS debido a varias razones desconocidas. No entre en pánico por esto. Este es el mejor momento para probar la calidad de nuestro código. Si la página web aún mantiene una buena legibilidad sin CSS, este logro es mucho más digno de nuestro orgullo que pasar la verificación del W3C.