¿Debo seguir estrictamente cada estándar HTML y CSS?

Hace unos años, me consideraba un desarrollador web que conocía los 3 idiomas básicos (HTML, CSS, JS) y mucho PHP. Pasar de un texto simple a sitios web reales fue un dolor debido a los llamados "estándares", que en ese momento eran ridículamente complicados para mí. Se redujo a esto (menos las cosas relacionadas con IE):

Los estándares están ahí para reemplazar las viejas formas de hacer las cosas de una manera más simple. Sin embargo, al intentar implementar algunas de las cosas (diseño completamente basado en CSS, por ejemplo), me tomó 10 veces más tiempo hacerlo, si hice la solución más simple y aún funciona. Si se hizo lo mismo, ¿por qué debería usar el ejemplo más complicado que toma 10 veces más tiempo y se rompe una vez que cambia los navegadores? Esto provocó muchos largos debates religiosos en ## php, ## css y ## js en Freenode IRC y, de hecho, me expulsó de ## css porque me metí con su pequeño mundo allí.

Mi pregunta: ¿Debería seguir todas las convenciones estándar y de codificación, incluso si me toman 10 veces más tiempo pero me dan el mismo resultado que el simple?

Para la etiqueta de sondeo, los que tienen sitios web de cualquier tamaño (grande o pequeño), hace que sigue todas las normas?

Producto primero, luego pulir.

Haga que su sitio / aplicación / juego haga lo que se supone que debe hacer. Ponlo en marcha y haz que la gente se interese.

Luego, cuando tenga tiempo, regrese y púlselo. Pero solo porque te importa, no porque a nadie más le importe.

Por supuesto, si los problemas de incumplimiento significan que las personas no pueden verlo, o es increíblemente feo, o tarda un mes en cargarse, o es difícil de mantener, o bloquea el navegador, este es un problema importante. Pero seguiría siendo un problema importante incluso si cumpliera con los estándares.

Los usuarios comunes no miran la fuente de un sitio web que no se carga y dicen: "Bueno, no muestra las imágenes, pero es completamente compatible con el W3C". Simplemente navegan a otro sitio web y nunca regresan.

En pocas palabras, los estándares están ahí para facilitar la escritura de navegadores y cerrar posibles agujeros de seguridad. Amazon, Penny-Arcade y Stack Overflow no ganan dinero al ejecutar un sitio web que cumple con los estándares. Y a menos que esté en una competencia de redacción de sitios web, tampoco lo hará.

Los redactores de normas han pensado en cosas que no se te han ocurrido, como problemas de accesibilidad. Las normas existen por una razón. Y, con HTML5, los estándares son bastante fáciles de seguir.

En ocasiones, puede haber razones para no seguir el estándar, pero seguirlo debería ser su comportamiento predeterminado.

La pereza no es una excusa para no seguir el estándar. A veces, si el estándar es estúpido, esa es una razón para no seguirlo. ¿Cómo sabes cuando el estándar es estúpido? Cuando ha estado haciendo un esfuerzo de buena fe durante un período prolongado para seguir todos los estándares relevantes en letra y en espíritu y ha llegado a una conclusión razonable y bien respaldada de que el estándar en algún caso de nicho es realmente culpable, no tú.

Sin embargo, la mayoría de las veces esto no será aplicable.

Yo diría 'adherirse' a los estándares lo mejor que pueda, pero no pierda demasiado tiempo, a veces puede crear un HTML / CSS estándar en la búsqueda de la perfección de los estándares y quedar en el peor estado.

Como ejemplo, en una de nuestras aplicaciones web tenemos una página para la facturación. La página enumera una larga lista de artículos a facturar y contiene varias columnas. El desarrollador original fue tan exagerado con el síndrome "Las tablas son malvadas" que diseñó toda la estructura de 'tablas' en CSS.

Bastante impresionante, hasta que usted sea el que ahora necesite agregar algunas columnas adicionales al informe, observe cómo esas columnas van por todos lados porque necesita reajustar la configuración de CSS, el ancho, etc. ... pesadilla.

Si el desarrollador no fuera tan anal sobre seguir los llamados estándares hasta el tee, se habría dado cuenta de que, en realidad, una tabla html normal tendría mucho más sentido, la fecha de la factura es, después de todo, tabular.

Esto me lleva al HTML semántico. Creo que su HTML solo debe contener elementos que describan su página. Los estilos deben almacenarse en CSS y, en el peor de los casos, ingresarse en el atributo 'Estilo' de la etiqueta HTML cuando corresponda.

Tampoco veo una razón válida por la que uno no deba poner su HTML a través de un validador, siempre que obtenga un HTML válido, ya está allí.

Su primera consideración debe ser el soporte de los navegadores que usan sus clientes. En segundo lugar, debe cumplir con las normas cuando corresponda.

Por ejemplo, en un proyecto reciente, el único navegador que teníamos que soportar era Firefox 3.5. Esto significaba que podíamos usar las propiedades -moz css sin preocuparnos de cómo se vería la página en otro navegador. ¿Realmente habría valido la pena hacer esquinas redondeadas en el largo camino, solo para que estuviéramos usando CSS estándar?

Dicho esto, al crear sitios para varios navegadores, los estándares generalmente lo ayudarán, en lugar de obstaculizarlo. Intentaría cumplir con la mayoría de los estándares, pero no perder el sueño si tuviera que desviarme de la compatibilidad del navegador.

Para la encuesta, la respuesta de mí es No.

No sigas los estándares a ciegas. Algunas normas son buenas, algunas son malas. Sirven para varios propósitos y algunos, como los borradores de HTML5, sirven para impulsar una colección de los grandes fabricantes de navegadores y desarrolladores web en una dirección particular que parece mayormente buena. Pero recuerde siempre que hay muchas cosas terribles que se han estandarizado ...

COBOL también era un estándar.