El buen código HTML es la base de un hermoso sitio web. Cuando enseño a otros CSS, siempre les digo primero: Un buen CSS solo existe en buenas etiquetas HTML. Es como si una casa necesitara una base sólida, ¿verdad? Las etiquetas HTML ordenadas y semánticas tienen muchas ventajas, pero todavía hay muchos sitios web que usan una escritura de etiquetas hostil.
Veamos algunas etiquetas HTML no escritas y discutamos para aprender a escribir etiquetas HTML ordenadas y estándar.
Nota de Wulin.com : Chris Cyier usa dos documentos aquí para explicar el código de este artículo: código malo y buen código. Consulte estos dos documentos cuando estudie.Para hacer esto, solo necesitamos seguir los pasos correctos. No es necesario discutir si usar HTML 4.01 o XHTML 1.0, los cuales ponen requisitos estrictos en nuestra escritura del código correcto.
Pero pase lo que pase, nuestro código no debe usar ninguna tabla de tablas para el diseño, por lo que no es necesario usar DOCTYPE de transición.
Recursos relacionados:En nuestra sección <Head>, lo primero es declarar el conjunto de caracteres. Usamos UTF-8, pero lo pusimos detrás del <title>. Mueva la declaración del conjunto de caracteres a la parte superior porque queremos que el navegador sepa qué personaje establecido manejarlo antes de leer cualquier cosa.
Además de la posición de la declaración del conjunto de caracteres, los personajes extraños que aparecen en <title> también son problemas a los que deben prestarse atención. Por ejemplo, los caracteres más utilizados y los caracteres deben ser reemplazados por entidad de personajes & amp ;.
Recursos relacionados:Al escribir código, la sangría no afecta la apariencia de la página web, pero el uso de la sangría apropiada puede hacer que el código sea más legible. El método de sangría estándar es sangrar un bit de pestaña (o algunos espacios) cuando comienza un nuevo elemento. Además, recuerde que la etiqueta del elemento cerrado está alineada con la etiqueta de inicio.
Nota de Wulin.com : Algunos amigos piensan que es más problemático sangrar al escribir código. Si solo está leyendo este código, puede que no haya ningún problema. Solo piense que está bien. Pero si se trata de colaboración o su trabajo se publica y se comparte públicamente, es necesario escribir un código hermoso y más legible. Recursos relacionados:Tenemos algunos código CSS que se ha extendido a nuestra sección <Head>. Esta es una falta grave porque solo puede funcionar en una sola página HTML. Mantener un archivo CSS independiente significa que las páginas web futuras pueden vincularlas y usar el mismo código. Lo mismo ocurre con JavaScript.
Nota de Wulin.com : Por supuesto, este problema puede no ser tan grave. Por ejemplo, como tema de WordPress, el código escrito en <HEAD> se usa en todas las páginas de WordPress. Pero escribir CSS en <BEAD> sigue siendo un hábito muy malo.En el título de nuestro sitio web, utilizamos <h1> como la etiqueta de título del sitio web, que es perfecta. Y se agregó un enlace a la página de inicio, pero el error fue que el enlace se colocó fuera de <h1>, y el enlace rodeado <h1>. La mayoría de los navegadores manejan bien este simple error de anidación, pero técnicamente, no funciona.
Un enlace de anclaje es un elemento en línea, y el título <h1> es un elemento de bloque, y el elemento de bloque no debe colocarse en el elemento en línea.
No sé quién lo inventó primero, pero me gusta la palabra divitis, que se refiere al uso excesivo de divs en etiquetas HTML. En una cierta etapa de aprendizaje del diseño web, aprendemos cómo usar un DIV para envolver muchos otros elementos para lograr un diseño y estilo convenientes. Esto lleva al abuso de elementos DIV. Utilizamos las áreas requeridas y las áreas completamente innecesarias.
En el ejemplo que se muestra arriba, usamos un DIV (Topnav) para contener la lista UL (Bigbarnavigation). Sin embargo, tanto DIV como UL son elementos de bloque, por lo que no hay necesidad de usar DIV para envolver el elemento UL.
Recursos relacionados:Ahora hablemos de la gestión de nombres. En el ejemplo mencionado en el artículo anterior, nuestro UL usa el nombre de identificación Bigbarnavigation. La navegación explica muy bien el contenido del bloque, pero Big y Bar describen el diseño en lugar del contenido. Puede estar diciendo que este menú es una gran barra de herramientas, pero si el diseño de este menú se vuelve vertical, el nombre parecerá confuso e irrelevante.
Nombres amigables de clase e identificación como Mainnav, Subnav, Barra lateral, pie de página, metadatos, que describen lo que está incluido. Los nombres de la clase y la identificación de la mala clase describen el diseño, como Bigboldheader, LeftSideBar y RoundedBox.
Nota de Wulin.com : Chris enfatiza si lo nombrar por contenido o diseño. Personalmente, me gustaría agregar a los nombres de identificación y clase para capitalizar o minúsculas , o capitalizar la letra inicial de la palabra . En primer lugar, las palabras completamente capitalizadas no conducen a la lectura y se excluyen. En cuanto a si usar letras minúsculas o mayúsculas de la primera letra de la palabra, depende de sus hábitos personales. Es importante que no importa qué regla se use, sea consistente . No seas puramente en minúsculas y capitalices en la primera letra a la vez, será muy confuso.Además, lo que estoy personalmente confundido es si subrayar, o guión, o no usar nombres más largos. O tal vez creo que es demasiado complicado. Es bueno usar cualquier tipo, y está bien mantenerlo consistente.
Página anterior 1 2 Página siguiente Lea el texto completo