una paso para paginas pagina notas hechas hacer etiquetas ejemplos crear completa como codigos codigo bloc xhtml strict

xhtml - paso - ¿Vale la pena el tiempo de desarrollo para generar HTML válido?



pagina web html codigo (13)

¿Por qué no escribir el prototipo en HTML válido (X) en primer lugar? Nunca he encontrado que sea más un esfuerzo que usar HTML no válido. Producir XHTML válido debería ser una tarea trivial. (Por otro lado, producir XHTML semánticamente significativo podría ser más agotador).

En resumen, no veo ninguna ventaja en el uso de HTML no válido para prototipos.

Desarrollar sitios web consume mucho tiempo. Para mejorar la productividad, codificaría un prototipo para mostrar a nuestros clientes. No me preocupa hacer el prototipo de acuerdo con el estándar. La mayoría de las veces, nuestros clientes aprobarían el prototipo y darían un plazo irrazonable. Suelo terminar usando el prototipo en producción (hey, el prototipo funciona. No hay necesidad de hacer mi trabajo más difícil).

Podría refactorizar el código para generar HTML válido. Pero, ¿vale la pena el esfuerzo de producir HTML válido?


Absolutamente. El código no válido puede causar todo tipo de comportamientos extraños y errores que no oscurecen los que ocurren cuando se obtiene un informe de validación.

Caso en punto:

Un fondo amarillo salía de una lista de mensajes y sobre el encabezado para la siguiente lista de mensajes, pero solo en Internet Explorer.

¿Por qué? El fondo se aplicó a un elemento de la lista, pero la persona que escribió la página lo había escrito como una lista única con un encabezado en el medio. Los encabezados no están permitidos entre los elementos de la lista y los diferentes navegadores intentaron recuperarse de ellos de diferentes maneras. Internet Explorer terminó el elemento de la lista (con el color de fondo) cuando vio el inicio del siguiente elemento (después del encabezado), mientras que otros navegadores lo finalizaron cuando vieron la etiqueta final para el primer elemento de la lista.

Era el único error de validez en la página, por lo que tomó solo un par de minutos localizar el problema y solucionarlo.


En mi opinión, el criterio clave es "adecuado para su propósito": si sus clientes desean algo para un mercado pequeño / interno (y no les importa si eso aleja a los clientes potenciales que tienen discapacidades o utilizan navegadores menos comunes), esa es su elección.

Al mismo tiempo, creo que es nuestra responsabilidad (como desarrolladores) asegurarse de que conozcan las implicaciones de sus decisiones: algunas organizaciones estarán obligadas por los requisitos legislativos a que los sitios web sean utilizables por lectores de pantalla, lo que normalmente significa HTML compatible con estándares.


HTML válido solo para poder tener una insignia en su sitio - no.

Tener "HTML válido" en el sentido de "HTML que funciona en todos los principales navegadores o motores de navegación" - sí.


Hay dos reglas para escribir sitios web:

  1. El sitio debe funcionar para tus usuarios.
  2. El sitio debe funcionar para tus usuarios.

Para cumplir con la primera regla, debe codificar de manera que su sitio se visualice correctamente al usar Internet Explorer. A menos que tenga la libertad de alterar el diseño de su sitio para usar solo aquellas características que IE representa correctamente, esto significa escribir HTML no válido.

Para cumplir con la segunda regla, debe codificar de manera que su sitio se muestre correctamente al usar lectores de pantalla y pantallas braille. Aunque algunos lectores de pantalla más nuevos pueden trabajar con sitios orientados a IE, en general esto significa escribir HTML válido.

Si está trabajando en un proyecto pequeño o forma parte de un equipo grande, puede codificar un sitio que emite HTML dirigido a IE para IE y, en caso contrario, HTML válido. Pero si está tomando un proyecto mediano a grande por su cuenta, debe decidir qué norma va a seguir y cuál va a ignorar.

ACTUALIZAR:

Esto es votado por los usuarios que piensan que siempre se puede salir con HTML válido en IE. Eso puede ser cierto si tiene la flexibilidad de cambiar su diseño para evitar las deficiencias de IE, pero si un cliente le ha dado un diseño y debe hacerlo funcionar, es posible que deba recurrir a HTML no válido. Es triste, pero es verdad, lo que sea que puedan pensar.


Honestamente, no sé por qué es un esfuerzo extra hacer HTML basado en estándares. No es como si fuera difícil y deberías hacerlo como una cuestión de profesionalismo.

Si le pagaste a alguien para que te construyera una casa y él cortaba las esquinas por pereza, entonces no te dabas cuenta en ese momento, pero en 10 años aparecieron grietas en tus paredes, ¿serías feliz?


Porque, si te apegas a los estándares, tu trabajo será compatible en el futuro. Los Agentes de usuario se esforzarán por el cumplimiento estándar y sus peculiaridades en el modo de incumplimiento siempre estarán sujetas a cambios. Este es el camino que se supone que es.

A menos que te interese todo lo relacionado con la perpetuación de estándares IE8 que quieran habilitar por defecto. - ese es otro argumento.
Webkit, Gecko, Presto? (¿Es el motor de la ópera?), y los demás siempre serán más compatibles con cada lanzamiento.

A menos que su trabajo html esté en un control de navegador incrustado en IE, entonces realmente no hay razón para generar un html válido mientras lo renderice.


Probablemente no, si tiene un sitio que no cumple, para empezar, y tiene poco tiempo.

Sin embargo, no me creerá porque no le creí a los demás, pero es más fácil hacer que un sitio sea compatible desde el principio, le ahorra dolores de cabeza en términos de compatibilidad con el navegador, comportamiento CSS e incluso comportamiento de JavaScript y generalmente es menos marcado para mantener.

El cumplimiento del sitio (al menos para Transitional) es bastante fácil.


Sí. Ya es bastante difícil tratar cómo diferentes navegadores presentarán HTML válido, sin importar qué intente predecir qué harán con un código no válido. Lo mismo aplica para los motores de búsqueda: suficientes problemas en el HTML pueden hacer que el sitio no se indexe correctamente o no se indexe.

Supongo que la verdadera respuesta es "depende de lo que no es válido sobre el HTML". Si las partes no válidas se relacionan con problemas de accesibilidad, incluso puede encontrar que su cliente tiene problemas legales si utiliza el sitio de forma comercial.


Si desea que su vista sea accesible para personas con y sin discapacidades, así como también para sistemas externos, entonces sí, definitivamente debe asegurarse de obtener un código HTML válido.

Es fácil probar su HTML con validadores automáticos .

Agregaré a lo que Mike Edwards dijo sobre las ramificaciones legales y le recordaré que también tiene una obligación moral :)


Solo vale la pena si te proporciona un beneficio práctico. Cumplir con los estándares podría facilitar la construcción de un sitio web que funcione en la mayoría de los navegadores. Por otra parte, si está contento con la forma en que un sitio web se muestra en los navegadores que le interesan (tal vez uno, tal vez todo), entonces pasar por aros para que pase la validación es una pérdida de tiempo.

Además, la diferencia en SEO entre un sitio web html totalmente válido y un sitio web html principalmente válido es insignificante.

Por lo tanto, siempre busque el beneficio práctico, hay algunos en algunas situaciones, pero no lo haga por el simple hecho de hacerlo.


Creo que generar resultados html válidos no perjudicará tanto tu tiempo de desarrollo si te has entrenado para codificar html válido desde el principio.

por un lado, no es tan difícil saber qué etiquetas no están permitidas dentro de un elemento
y los atributos requeridos en una etiqueta a veces son los que de todos modos necesitaría, creo que estos son los principales errores que hacen que su html no sea válido, así que ¿por qué no simplemente aprenderlos tan pronto como ahora si planea permanecer en la web para ¿largo?
Además de generar un html válido, puede ayudar a mejorar el ranking de su sitio.


Producir HTML conforme es similar a garantizar que no tengas advertencias durante una compilación; las advertencias están ahí por una razón, es posible que no te des cuenta de cuál es esa razón, pero ignora las advertencias y, antes de saber dónde estás, hay tantas como , no puede detectar el relevante para el problema que está tratando de corregir.

Si utiliza Firefox para ver sus páginas web, obtendrá una útil marca verde o una cruz roja en la esquina inferior derecha, mostrándole rápidamente si ha cumplido o no. Al hacer clic en una cruz roja, le mostrará todos los lugares donde se equivocó. Algunas de las advertencias / errores pueden parecer un poco pedantes, pero corrígelas y te beneficiarás de muchas maneras.

  1. Es mucho más probable que su página funcione con una mayor variedad de navegadores.
  2. El cumplimiento de la accesibilidad será más fácil (por ejemplo, tendrá atributos ''alt'' en sus imágenes)
  3. Si elige XHTML como estándar, es más probable que su marcado sea útil en un entorno AJAX.

La falla en hacer esto resulta en impredecibilidad.

Uno de los mayores problemas con los navegadores web es que han perpetuado los malos hábitos (y todavía lo hacen, en algunos casos) corrigiendo silenciosamente ciertos problemas de marcado, como la imposibilidad de cerrar las celdas y / o filas de la tabla. Este único hecho ha resultado en miles de páginas web que no son compatibles, pero que funcionan, lo que arrulla a sus desarrolladores con una falsa sensación de seguridad.

Cuando considera cuántas cosas pueden fallar en un sitio web, ser perezoso en lo que respecta al cumplimiento es solo agregar más problemas a su carga de trabajo.

EDITAR: después de haber leído su publicación original nuevamente, noto que usted dice que no se molesta con el cumplimiento cuando trabaja en un prototipo, y luego continúa diciendo que usualmente utiliza el prototipo en producción, esto significa que no es estrictamente un prototipo , pero un candidato. La situación normal en tales circunstancias es que una vez que el cliente acepta un candidato, no se asigna tiempo para la corrección o reparación de errores, fortaleciendo así el argumento para hacer que el marcado cumpla en primer lugar.

Si no te darán tiempo más tarde, hazlo ahora.

Si te dan tiempo más tarde, entonces tienes tiempo para hacerlo de todos modos.