css - verificador - w3c validator español
¿Qué tan importante es la validación W3C XHTML/CSS al finalizar el trabajo? (9)
Aunque siempre aspiro a la validación completa en estos días, a menudo me pregunto si es una pérdida de tiempo. Si el código se ejecuta y se ve igual en todos los navegadores (uso browsershots.org para verificarlo), ¿necesito llevarlo más lejos o estoy siendo excesivamente anal?
¿A qué nivel mantienes tu código cuando lo creas para:
a) usted mismo b) sus clientes
PS Jeff y compañía, ¿por qué no apila validación de desbordamiento? :)
EDITAR: Algunas buenas ideas, creo que como he estado tan obsesionado durante tanto tiempo, programo sabiendo lo que causará problemas y lo que no, así que estoy en una mejor posición que las personas que primero crean un sitio y luego "vuelve y arregla los problemas de validación"
Creo que puedo publicar otra pregunta sobre el desbordamiento de pila; "¿Validas a medida que avanzas o acabas y luego vuelves y validas?" ya que parece ser donde va esta pregunta
Creo que esta es un área en la que deberías esforzarte por utilizar el principio de robustez en la medida de lo posible (lo cual es un buen consejo para cualquier área de codificación). El hecho de que algo funcione hoy no significa que funcionará mañana: si se basa en un hack de HTML / CSS particular o incluso si se ha mostrado un poco flojo en la emisión de código estrictamente válido, la próxima iteración de navegadores bien podría descanso. Hacerlo una vez de la manera correcta minimiza este problema (aunque no lo mitiga por completo).
Sin embargo, hay un cierto elemento de pragmatismo que tomar aquí. Ciertamente haré todo lo que pueda para que el sitio de un cliente sea válido, pero estaría dispuesto a correr más riesgos en mi propio espacio.
Creo que la validación es una buena prueba de fuego para saber si has hecho las cosas correctamente, por lo tanto, si solo hay algunos problemas menores, ¿por qué no corregirlos y garantizar que los navegadores entiendan mejor tu sitio en el futuro (incluso si hacer las cosas de manera diferente por otras razones)?
OTOH, para la mayoría de los proyectos, la validación parece un gran dolor de cabeza y si puede hacer que las cosas funcionen en todos los navegadores, no vale la pena gastar un día / semana extra en la validación.
Creo que son solo los "tecnológicos" los que realmente se preocupan por el "cumplimiento 100% estándar". A mis consumidores de página habituales (= usuarios) no les importa si no hay un atributo alternativo para un "elemento de imagen de borde de menú".
Normalmente solo me aseguro de que no veo ningún error obvio (todas las etiquetas están cerradas, todas minúsculas, los atributos entre comillas, ...), pero si se ve bien en IE y FF, eso es todo lo que me importa. Realmente no me importa si uso un atributo no estándar en cualquier etiqueta HTML, para que la página no valide contra una DTD, siempre que obtenga los resultados visuales que pretendo obtener.
Sé que esto no responde a toda tu pregunta, pero vale la pena considerar que al usar html completamente válido, puedes estar seguro de que tu sitio web debería funcionar correctamente en futuros navegadores web que aún no se hayan lanzado.
a) Debe tener el mismo aspecto
b) Lo más compatible con los estándares, pero no tan anal que bloquea el trabajo de acabado
En una situación en la que tiene acceso perpetuo al código, no creo que el cumplimiento de las normas sea tan importante, ya que siempre puede hacer cambios en el código si algo se rompe. Si no tiene acceso perpetuo (es decir, cierra la sesión con el código y se convierte en responsabilidad de otra persona), probablemente sea mejor cumplir con los estándares para minimizar dolores de cabeza de mantenimiento más adelante ... incluso si nunca tiene que hacerlo. vuelva a tratar con el código, su reputación persiste y puede transmitirse a otros clientes potenciales, y muchos equipos prefieren culpar al desarrollador anterior por los problemas que surgen.
Mi enfoque tiende a ser para asegurarme de que puedo validar por completo en todas las páginas, sin embargo, sigo enviando la página como texto / html en lugar de application / xhtml + xml para que no haya feos errores XML en caso de que haya omitido algo.
Para mí, siento que he hecho un buen trabajo si mi código lo valida. Ver la casilla de verificación verde en las páginas w3c solo me da un poco de vértigo. En cuanto al grupo b, por lo general solo les importa que se vea y funcione de la misma manera en todos los navegadores. Solo colocan. He encontrado que esto no es cierto, es el sector gubernamental. Requieren una validación completa no solo con el w3c sino también con las pruebas ADA (básicamente, cómo suena con un lector de pantalla).
ps cuando digo sector del gobierno, me refiero específicamente al estado de California y algunos condados dentro de él. No he tenido ninguna experiencia con otros grupos de gobierno además de ellos.
Excepto que los validadores en sí mismos son tan positivamente anales, cuando marcan un error o advertencia cuando se usa un -moz- o -webkit o -o- es decir, un término de calificación específico del navegador. también quieren que especifique 0px en lugar de 0 u otras unidades. ¡Cero es cero, independientemente de las unidades con las que el validador lo quiera comparar!
simplemente intente validar el WordPress twentyeleven style.css arroja 140 errores impares que son todos de la naturaleza anterior o el validador se está recuperando de errores de análisis
¡Los validadores son inútiles si no puedes ordenar el trigo de la paja!
¡Necesitamos validadores que reconozcan los términos de calificación específicos del navegador!
Para entender por qué es importante la validación, es necesario comprender cómo funciona un navegador en sus diferentes capas, y también un poco sobre la historia de la web desde la perspectiva de los navegadores web.
El código HTML que le da a un navegador es interpretado por el navegador siguiendo el DOM, una interfaz de programación de aplicaciones que mapea la página entera como una jerarquía de nodos. Cada parte de ese árbol es un tipo de nodo que contiene diferentes tipos de datos. DOM (Document Object Model) fue necesario debido a la diversidad de páginas HTML que los primeros navegadores web (Netscape, IE ...) implementaron para permitir alterar la apariencia y el contenido de una página web sin tener que volver a cargarla. Para preservar la naturaleza multiplataforma de la web, W3C quería corregir las diferentes implementaciones de esos navegadores, proponiendo DOM.
El soporte DOM se convirtió en una gran prioridad para la mayoría de los proveedores de navegadores web, y se han realizado esfuerzos para mejorar el soporte en cada lanzamiento. Entonces, funcionó.
DOM es el paso básico con el que se inicia un navegador web. Su flujo principal es:
- analizar HTML para construir el árbol DOM
- render árbol construcción
- diseño del árbol de renderizado
- pintar el árbol render
El paso 1 da el árbol de contenido , con las etiquetas convertidas en nodos DOM. El paso 2 proporciona el árbol de renderizado , que contiene información de estilo.
Entonces, por qué la validación importa: porque el árbol de contenido y el árbol de render son la base desde la cual el navegador web comienza su trabajo. Cuanto más estén bien definidos, mejor será para el navegador web.
En definitiva, el DOM también es la base de tus eventos de JavaScript. Por lo tanto, su validación ayuda a la capa de interacción también.