Utilice Dreamweaver 8 para lograr "estándares web"

Prefacio del traductor: esta serie de artículos originales contiene un total de 8 artículos. Comienza con la popularización de los estándares web y describe cómo utilizar Dreamweaver 8 para crear una web compatible con los estándares. Dado que el artículo del autor original es una revisión de "Build Your". Sitio web propio que cumple con los estándares usando Dreamweaver 8" (Este artículo es un extracto pago), por lo que eliminé el contenido apropiadamente. El orden es consistente con el artículo original, pero la extensión se ajustará. Por la presente les informo. El nivel de traducción es limitado, por favor comprenda.

Si está leyendo este artículo, probablemente ya esté interesado en los estándares web y tenga mucha curiosidad sobre la aplicación de estándares en sitios creados con DW (abreviatura de Dreamweaver).

Tal vez ya tenga ciertos conocimientos de WS (abreviatura de Estándares web), pero no sepa cómo utilizar DW para escribir código compatible. O es usuario de DW y le gustaría cumplir con WS, utilizar CSS más ampliamente y crear documentos más fáciles de usar. No importa de qué tipo sea, este artículo le dará la respuesta que desea: le dirá cómo usar DW para manejar WS.

Definición de estándares web

En lo que respecta a los WS que nos preocupan a lo largo de este artículo, primero tomemos un momento para aclarar de qué estamos hablando:

los WS son especificaciones que guían los lenguajes de desarrollo web y están formulados por el W3C. Estas especificaciones incluyen varios lenguajes, como HTML, XHTML y CSS, así como algunos otros lenguajes relacionados, como MathML, que se utilizan para representar ecuaciones en matemáticas. Cuando tenga necesidades especiales, es posible que pueda utilizarlos. . El W3C también publica las Pautas de accesibilidad al contenido web (WCAG), que promueven la accesibilidad de las páginas web (a través de WAI).

Consejo: obtenga estas pautas directamente

Puede leer estas pautas en el sitio web del W3C, aunque a veces

es

poco

:

HTML

4.01

¿Quién necesita WS?

Quizás tenga sólo una vaga idea de que WS es algo bueno, pero muchos sitios, incluidos muchos sitios bien conocidos, no cumplen con WS y parecen estar bien administrados. Entonces, ¿por qué deberíamos esforzarnos por cumplir con WS? ¿Hay beneficios reales al hacerlo? ¿Quién necesita prestar atención a las especificaciones y recomendaciones del W3C?

El primer grupo de personas que debemos prestar atención a WS somos nosotros.

desarrolladores y diseñadores

El marcado limpio acelera la corrección de errores.

Si validas tus páginas con el W3C, al menos sabrás que el marcado irregular no es la causa de los errores que has experimentado. A veces, el proceso de validar una página y corregir los errores encontrados puede solucionar problemas de visualización causados ​​por elementos interminables o etiquetas mal escritas.

Incluso si verificar su documento no soluciona los problemas, al menos sabrá que los problemas existen en el documento canónico. Ahora que sabe que este problema no es un error, puede comenzar a centrarse en otros problemas, como las diferencias en el manejo de CSS en diferentes navegadores.

Cumplir con los requisitos de accesibilidad es fácil.

Si escribe un marcado XHTML canónico, podrá asegurarse de que el documento sea semánticamente correcto y podrá separar el contenido del documento de la presentación, lo que le permitirá trabajar mucho en muchas de las direcciones. problemas de accesibilidad enumerados en WCAG1.0. También es importante reconocer que la accesibilidad no es sólo para personas con discapacidad. Se puede acceder a un sitio amigable mediante muchos dispositivos diferentes, como teléfonos móviles y PDA, que no tienen la capacidad de procesamiento para manejar marcas dispersas y no estándar.

Compatibilidad futura

Si solo considera el rendimiento de su página recién desarrollada en los navegadores actuales, ¿cómo puede garantizar su rendimiento en nuevos navegadores en el futuro? El nuevo navegador puede cambiar su página. La visualización es terrible y usted tendrá dificultades. para encontrar y solucionar problemas molestos.

Cumplir con WS no erradicará por completo este problema; sin embargo, la compatibilidad de los estándares reduce en gran medida el riesgo de que su diseño falle y las empresas de software de navegador actuales también están comenzando a admitir estándares. Pueden malinterpretar accidentalmente alguna parte de la especificación, pero no pueden desaprobarla por completo. Si sucede lo peor y un nuevo navegador produce efectos extraños en su sitio estandarizado, es mucho más fácil arreglarlo que un sitio incompatible. Si encuentra un problema, también afectará a otros sitios que cumplen con los estándares. La sabiduría colectiva de la comunidad web señalará esto y escribirá artículos para abordarlo. Por lo tanto, todos discutieron colectivamente que es más fácil corregir este ERROR en un documento compatible que en un documento incompatible.

Refactorización más sencilla ¿

Alguna vez ha tenido que quitar el texto de un sitio, refactorizarlo y empezar de nuevo? ¿Alguna vez has visto esas etiquetas que están repletas de etiquetas de fuentes y celdas de tabla diminutas (que nos hacen tener que empezar desde cero)? Lo único que sé es que lo he hecho, y es un proceso largo, con mucho tiempo y dinero, todo quemado? la refactorización de este sitio.

Separar el contenido y la presentación de un documento le brinda la belleza del cumplimiento de estándares: significa que la próxima vez que alguien quiera refactorizar el sitio, no tendrá que copiar el documento web. Todo el texto del sitio estará marcado con (X)HTML semántico y toda la información de presentación, que es lo que el webmaster quiere cambiar, se almacenará en un archivo CSS fácilmente reemplazable.

Algunos clientes no esperarán a que se refactorice antes de empezar a pedirle que haga algunos cambios. Esperarán hasta haber visitado Mammoth Fossil Pit y luego le pedirán que diga: "Simplemente mueva la columna de la izquierda a la derecha". ." Para sitios compatibles estandarizados, todas las páginas están controladas por CSS. Puede mover fácilmente las etiquetas en la página sin tener que pensar en trucos en muchas páginas con tablas complejas como estructuras. Esto facilita el cambio del diseño de la página.

Separar la estructura de la presentación también puede facilitar la adición de nuevos elementos, como una versión de un sitio con imágenes pequeñas y de alto contraste que puede resultar más atractiva para algunos espectadores. ¿Por qué crear versiones separadas de páginas de sólo texto cuando se pueden cambiar fácilmente las hojas de estilo?

Empresas de software de navegador

Las empresas de software de navegador están empezando a prestar atención a WS. En el pasado, las empresas de software de navegador añadían sus propias etiquetas y atributos al lenguaje básico. Pero ahora, como nunca antes, todos están empezando a cumplir con los estándares, y algunos de los navegadores más recientes ya están haciendo un esfuerzo para mostrarlos de acuerdo con (X)HTML y CSS como se define en la especificación.

En el futuro previsible, los navegadores podrán mostrar la mayoría de códigos y marcas no estándar, porque si no lo hacen, miles de sitios no estándar no se mostrarán correctamente, y entonces es probable que el público empiece a culpar al navegador. no los diseñadores web. Sin embargo, otros dispositivos (aquellos sin la potencia de procesamiento de las computadoras de escritorio) dependerán más de la compatibilidad estandarizada del código que encuentren.

Proveedores de software de herramientas de creación

Los proveedores de software de herramientas de creación, como Macromedia, que fabrica Dreamweaver, también están empezando a cumplir con WS, al igual que los diseñadores web, por ejemplo, a medida que cada vez más clientes exigen que estas herramientas de creación produzcan marcado canónico. Originalmente, estos entornos de desarrollo visual no tenían una buena reputación porque producían marcas confusas y no estándar; sin embargo, los principales entornos de desarrollo visual más recientes han invocado elementos estandarizados de compatibilidad y accesibilidad, lo que también se ha convertido en un principal punto de venta; Los proveedores de software deben escuchar y responder a las necesidades del mercado.

Usuarios web

Los usuarios de los sitios que diseñamos también se benefician de nuestra adopción de WS, incluso si no se dan cuenta. ¡Quizás estén usando inconscientemente sitios desarrollados específicamente para los navegadores más populares de hoy en día! Si estos usuarios cambian a otro navegador, es posible que descubran que la experiencia en línea ya no les resulta agradable porque el nuevo navegador no aceptará esas etiquetas de propiedad. Un sitio estandarizado y compatible funciona bien en diferentes navegadores, ya sean navegadores existentes o futuros.

Además, un sitio web que sigue las recomendaciones de accesibilidad será más accesible para los usuarios que encuentran insatisfactoria la navegación en la web. La Web debería ofrecer condiciones de compra, lectura y búsqueda más cómodas para las personas con discapacidad visual u otras discapacidades. No se les debe impedir navegar por un sitio porque utiliza etiquetas patentadas u otra tecnología exclusiva (refiriéndose al navegador).

¿Cómo podemos garantizar el uso correcto de WS cuando

usamos WS

Primero, debemos cumplir con la especificación. Esto significa que sólo debemos usar aquellos elementos y atributos definidos en la especificación y evitar el uso de ciertos atributos específicos del navegador, como la etiqueta de marquesina de IE y la etiqueta de parpadeo de Netscape. Tampoco utilice elementos que aparecieron en especificaciones anteriores (como HTML 3.2) o que se eliminaron de especificaciones posteriores.

Crear un documento XHTML canónico

En este artículo usaremos XHTML, por lo que seguiremos las recomendaciones XHTML 1.0 del W3C [según el W3C, Recomendación significa especificación]. XHTML es básicamente la última versión de HTML y está diseñado para reemplazar HTML, el lenguaje de marcado web. Aunque es una variante HTML de XML, XHTML es casi idéntico a HTML, con diferencias sutiles que discutiremos más adelante en XHTML y Semántica.

Puede generar un documento XHTML a través del cuadro de diálogo Nuevo documento en Dreamweaver (Archivo>Nuevo...). Asegúrese de que Página base esté seleccionada en la lista Categoría y luego seleccione HTML de la lista Página base, como se muestra en la Figura 2.1, "Creación de un nuevo documento XHTML en Dreamweaver". Luego puede seleccionar cualquier tipo de documento de la lista desplegable.

Figura 2.1: Creación de un nuevo documento XHTML en Dreamweaver

Figura 2.2: Visualización del nuevo documento XHTML en vista de código

Haga clic en "Crear" para generar un nuevo documento. Haga clic en el botón de código en la parte superior de la ventana del documento y vaya a la "vista de código". Puede ver claramente qué código se incluye en un documento XHTML simple. Como se muestra en la Figura 2.2, la primera línea del documento "Mostrar nuevo documento XHTML en vista de código"

mostrará el siguiente contenido

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http: / /www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">Esto

se denomina declaración de tipo de documento o DOCTYPE. Como sugiere el nombre, DOCTYPE declara cuál es su documento, qué especificación (X)HTML está cumpliendo. En este ejemplo, seguimos XHTML 1.0 Transitional, que es la configuración predeterminada para DW 8. La sección Transicional nos brinda información adicional sobre la versión XHTML. XHTML1.0 tiene tres "sabores": estricto, transicional y conjunto de marcos. DW utiliza el tipo Transicional de forma predeterminada y, si desea insertar un marco en el documento, es Frameset.

XHTML Strict es el formato XHTML más estricto, como probablemente puedas adivinar. Un tipo de documento estricto se ve así:

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">Si

está utilizando un DOCTYPE estricto, no puede usarlo en el documento. Cualquier elemento (etiqueta) o atributo que declara obsolescencia no se puede utilizar en marcos. Los elementos declarados obsoletos se eliminarán en una versión futura de XHTML. Muchos de estos elementos se utilizan para controlar la apariencia de la página, que puede ser reemplazada completamente por CSS. La mayor diferencia entre Strict y Transitional es que cuando se usa Strict DOCTYPE, los atributos y elementos que pensaba que podrían usarse para el rendimiento están muy restringidos.

Nota: Usar Strict DOCTYPE en DW

DW no es muy estricto en el cumplimiento del estándar. Si utiliza Strict DOCTYPE, preste especial atención a validar su documento y corregir atributos irregulares. Básicamente, es fácil reemplazarlos con CSS.

Frameset DOCTYPE admite el uso de marcos. Si inserta un marco en el documento, DW utilizará automáticamente este tipo. La página del marco debe estar relacionada con al menos otras dos páginas y no hay límite en el tipo de documento de las páginas relacionadas. El código de Frameset DOCTYPE es el siguiente:

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

HTML 4.01 también proporciona estos tres "sabores" de tipos de documentos: transicional, estricto y Conjunto de marcos: funcionan exactamente igual que los DOCTYPE XHTML mencionados anteriormente. Si utiliza cualquiera de los tipos, debe indicarlo en el documento HTML (no XHTML). Discutiremos las diferencias entre HTML y XHTML en profundidad más adelante en la sección sobre creación de un sitio web.

Original: Dreamweaver 8 cumple con los estándares por Rachel Andrew

Compilado: x5