html - para - ¿Qué tan importante es seguir los estándares web?
historia de html-origen y evolución del hipertexto para internet (22)
Como nota al margen, no es un gran esfuerzo seguir los estándares web. Cuando te acostumbras, te das cuenta rápidamente de cuánto esfuerzo no debes hacer. El uso de estándares web generalmente produce un código LESS (= menos tiempo para escribir), un código MÁS LISTO y un código "a prueba de futuro" en comparación con cualquier técnica de diseño de old school que desee utilizar.
Recientemente me enteré de que la mayoría de los principales sitios web no superan las pruebas de validación de CSS y marcado del W3C . Por lo tanto, ¿qué tan importante es realmente seguir los estándares web?
En resumen, muy. Para fines de compatibilidad entre plataformas y navegadores cruzados, es importante.
¿Necesitas seguirlos al T? Si no lo haces, probablemente estarás bien.
Muchas cosas que no siguen estándares estrictos son aplicaciones heredadas que se han modificado a lo largo del tiempo.
En mi opinión, no hay razón para no seguir estrictos estándares en un nuevo proyecto.
Ian
Las únicas razones por las que históricamente los diseñadores de sitios web no han seguido los estándares web son (1) desconocer los estándares en absoluto, o (2) hacer que los navegadores que no cumplen con los estándares (* tos IE tos ) hagan cosas geniales. Pero Internet Explorer recientemente ha dado un paso importante hacia la compatibilidad de estándares, por lo que reason (2) es cada vez menos relevante y obviamente no está sujeto a ninguna razón (1), ¿por qué no escribir sitios web compatibles con estándares? Como otros han dicho, hará que su código sea mucho más fácil de depurar porque solo tiene que trabajar con un estándar en lugar de con varios navegadores diferentes.
Lo importante de estos grandes sitios es que tienen un ejército de programadores para garantizar que el sitio siga funcionando .
¿Vos si? ¿Estás dispuesto a gastar tu dinero en eso?
El problema con no seguir los estándares es que no tienes garantías de cómo funcionará tu sitio en los navegadores del futuro.
Luego, hay otros problemas, como la accesibilidad, o la habilitación de herramientas automatizadas para analizar su sitio. Si esto es rastreadores web de motores de búsqueda o sitios que agregan información disponible de microformatos, o lectores de pantalla para personas ciegas o cualquiera de las docenas de otras herramientas que necesitan para poder leer su sitio, no tiene garantías de que puedan analizar su sitio si es una sopa de etiquetas al azar.
Luego están las herramientas que tú mismo usamos. ¿JQuery u otras bibliotecas de JavaScript podrán descifrar su extraño DOM no estándar? Tal vez tal vez no. ¿La versión de la próxima semana? ¿Quién sabe?
Y finalmente, ¿cuál es el costo? No es tan difícil escribir HTML / CSS compatible. Se necesita algo de práctica para descubrir algunos de los trucos de CSS para evitar depender del HTML obsoleto o no estándar, pero una vez que lo hayas descifrado, es tan fácil de escribir como tu típico código no estándar descuidado. Y, por supuesto, incluso puede hacer las cosas más fáciles, porque le permite utilizar de manera significativa herramientas como el validador de HTML cuando se depura. Es difícil usar eso para cualquier cosa útil si su sitio contiene 50 errores HTML en cualquier caso. ¿Cuál de ellos, si corresponde, está relacionado con el problema que intentas solucionar?
Lo primero que hago es probar en mis entornos objetivo. Si está funcionando y no puede validar, probablemente sea un punto más pequeño pero, naturalmente, vale la pena explorarlo. Por supuesto, debes esforzarte por obtener accesibilidad tanto como sea posible.
Los navegadores y otros lectores basados en la web confían en que los desarrolladores sigan los estándares y, en su mayor parte, no es difícil cumplirlos. Así que haz lo mejor que puedas pero no te vuelvas improductivo para seguirlos.
Muy importante. Accesibilidad, usabilidad, portabilidad, es la ley (en algunos casos), escalabilidad, más fácil de integrar con varios marcos de aplicaciones y CMS. La lista continúa, pero otros carteles han cubierto los puntos lo suficientemente bien.
El propietario de un negocio promedio generalmente dice "a quién le importa", al igual que el OP. Hasta ahora, mi respuesta más efectiva ha sido "el bot de Google no es más que un usuario final ciego. ¿No quieres que aparezca tu sitio de manera efectiva?"
Si sigue los estándares, cualquier error de diseño será mucho más fácil de depurar. Cuando ignoras los estándares, el navegador puede mostrar tu página como se sienta, y cambiar un carácter puede cambiar completamente la forma en que se renderiza tu página. La depuración de un navegador es difícil, pero la depuración de IE 7, IE 6, Firefox, Opera, Safari ... e ignorar los estándares solo hará tu vida más difícil.
Si está utilizando jQuery u otras bibliotecas de manipulación DOM, puede obtener resultados inesperados e incoherentes si su marcado no es válido.
Entonces, no pierdas tu tiempo. Asegúrese de escribir HTML y CSS válidos. Es realmente muy fácil y te ahorrará tiempo.
Si todo funciona en todos los navegadores que desea admitir, no es realmente tan importante que el código HTML valide realmente. Sin embargo, para XHTML, es importante: el uso de XHTML implica que desea que su código sea legible mediante analizadores XML, por lo que cualquier cosa que no sea XHTML válida no debe declararse como tal.
Pero crear un código que cumpla con los estándares no es difícil, es decir, cualquiera que no se moleste en corregir los errores muestra una falta de profesionalismo. A veces uno puede decidir ignorar los estándares, pero eso siempre debe ser una decisión consciente: por ejemplo, la página de inicio de Google está optimizada para la velocidad y compatibilidad con navegadores cruzados y se ha probado ampliamente. Si no tiene los recursos para tales pruebas y soporte continuo, debe cumplir con los estándares.
Depende del tamaño de tu audiencia. Si es para tu blog, puedes ser bastante descuidado. Sin embargo, realicé sitios web gubernamentales donde fue sumamente importante que sigamos los estándares web y sigamos las pautas de accesibilidad.
Pero si, solo hazlo. ¿Por qué no?
Bueno, como dijiste, la mayoría de los sitios web grandes no cumplen con los estándares, por lo que si quieres un sitio web grande, es mejor que no sigas los estándares. :)
Pero no, es mejor seguir los estándares, porque eso le dará el mayor cambio que su sitio funcionará en la mayoría de los navegadores, y continuará funcionando en la mayoría de los navegadores futuros también durante mucho tiempo.
Hay algunas excepciones, y se producen principalmente debido a algunos navegadores (o algunas versiones de navegadores) que no siguen los estándares. Por lo tanto, es posible que a veces necesite algunos trucos o hacks para que su sitio funcione en todos los navegadores que desee. La mayoría de estos trucos se pueden aplicar sin dejar de seguir los estándares, pero algunos otros pueden conducir a un mejor rendimiento o una implementación o mantenimiento más sencillos.
Entonces, si bien es mejor seguir los estándares en general, siempre puede haber una o dos excepciones ...
Puede ir por reglas simples que se aplican a html, css, c, java ... cualquier cosa.
Siga los estándares a menos que tenga una buena razón para ignorarlos. Si no se apega al documento estándar, ¿por qué no?
Algunas veces se encontrará con situaciones en las que tiene que violar los estándares para escribir una solución temporal, o acelerar su código o ... lo que sea.
Cada vez que sienta que tiene que ignorar los estándares, debe escribir una nota. POR QUÉ lo hizo, para que usted u otro desarrollador que se encuentre con un trozo de html (o código CMS) sepa que esto NO es un error.
Y sí, a veces la "buena razón" es una fecha límite o un servidor bloqueado. Mientras documente, está bien.
Pro adicional: si escribir html no estándar (o código) que no cumple con el estándar es una excepción, es probable que te acostumbres a escribir código limpio.
Se trata de hacer que su sitio web funcione de acuerdo con sus especificaciones, y funcione de manera consistente en todos los navegadores más utilizados actualmente. Pragmáticamente, los estándares web no tienen prioridad.
¿Alguien aquí usa Hotmail? ¿Alguna vez te has dado cuenta de que con cada lanzamiento importante de Firefox, Microsoft tiene que volver atrás y realizar cambios en su sitio web de Hotmail para que no se queden atrás en la última versión de Firefox?
¿Habrían tenido que hacer eso si los desarrolladores respetaran los estándares? ¿Cuánto tiempo / dinero ahorrarían? ¿Cuánto de ese tiempo / dinero podrían invertir en nuevas tecnologías o nuevas características?
Usted dice que la mayoría de los principales sitios web no superan las pruebas de validación de CSS y marcado del W3C. Mira la mayoría de los sitios web. ¿Se ven modernos? ¿Se ven como los que validan? ¿Son los primeros en implementar las últimas y mejores características o están estancados manteniendo tecnologías viejas y desactualizadas, intentando febril e incansablemente mantener un castillo de naipes y esperando que los vientos de cambio no lo derriben?
Hay un costo de oportunidad por cada decisión que tomamos. A veces, el costo de oportunidad de omitir un estándar puede forjar una asociación comercial rentable. Otras veces, especialmente cuando no se siguen los estándares debido a la ignorancia, el costo se está dejando debido a errores, comportamiento aleatorio y juegos de adivinanzas. Algunas veces, seguir los estándares puede crear una plataforma de extensibilidad donde se pueden agregar nuevas características para los próximos años.
La validación W3C es un factor importante a tener en cuenta cuando se buscan errores que rompan la funcionalidad de su sitio (o aquellos que potencialmente pueden romper algo). Es algo así como un radar que podría detectar errores antes de que comiencen a interrumpir su trabajo.
Por ejemplo, si tiene un problema con su sitio y desea publicar una pregunta al respecto sobre SO, se recomienda utilizar el validador W3C y asegurarse de que no lo dirige al origen de su problema.
Pero ... no todo el HTML validará. El caso más importante, aunque no el único, probablemente sea HTML5. En CSS, los prefijos de los proveedores tampoco validarán. ¿Eso significa que no deberías usarlos? ¡De ningún modo!
Los servicios de validación son excelentes para encontrar el nombre de atributo mal escrito, la etiqueta no cerrada, el punto y coma faltante o una etiqueta <br> con un doctype XHTML. No me preocuparía por los elementos que no se validan solo porque el validador no sabe lo que hace la etiqueta <video> . Esto sigue siendo correcto
ESTÁNDARES!
Un poco de historia
Antes de ir directamente a la respuesta, creo que es importante establecer el contexto del último estándar.
¿Sabías que el W3C ha estado tratando de desarrollar un estándar XHTML 2 ? Si hubiera salido, no sería compatible con versiones anteriores de HTML. De hecho, se formó una rebelión dentro del W3C y terminó con un grupo que simplemente separó las formas de crear el WHATWG . Los WHATWG son las verdaderas mentes maestras detrás de HTML5 .
¿Alguna vez se ha preguntado por qué lleva tanto tiempo obtener los estándares del WC3 ? La forma en que funciona WC3 es muy democrática. Discuten todo hasta que todos acepten. El WHATWG hace esto con un pequeño giro: se plantean y discuten los problemas, pero la última palabra recae en el editor. Citando a Jeremy Keith : "Mientras HTML5 se estaba desarrollando en el WHATWG , el W3C continuó trabajando en XHTML 2. Sería incorrecto decir que no iba a ningún lado rápido. No iba a ninguna parte muy, muy lentamente".
Terminó con el W3C eliminando XHTML 2 y, en lugar de ir desde cero, tomaron la decisión de trabajar con WHATWG , después de todo.
El retorno de la marca de Spaghetti?
Si bien HTML5 ya no es estricto como XHTML, no significa que ya no existan buenas prácticas de codificación. HTML5 no es machiavellian. A diferencia de XHTML 2, se basa en las especificaciones existentes (admite contenido existente).
Sobre todo, los árbitros detrás de las especificaciones son los diferentes proveedores de navegadores. ¿Alguna vez has visto elementos CSS propietarios con webkit (Safari, Chrome), moz (Firefox) o o (Opera)? Esto es realmente normal, porque eso significa que los proveedores están trabajando en próximas especificaciones y, a veces, en funcionalidades que están fuera de las especificaciones. Durante un tiempo, Microsoft tuvo la mentalidad de estar por encima de los estándares porque tenían el monopolio de las acciones del navegador y creaban sus propios elementos de CSS. Microsoft creó elementos CSS como filter y, sin embargo, encontramos algo peculiar. Hay dos recomendaciones para las especificaciones que son dos formas diferentes de jugar con opacidad en CSS: RGBA en el elemento de color y el elemento de opacidad.
La importancia de los estándares
Para finalizar, diría que los diseñadores / desarrolladores web tienen una gran responsabilidad de mantenerse al día con lo que está sucediendo en términos de tecnología y estándares como HTML5. Eso no significa leer todas las especificaciones que hay. Estoy de acuerdo en que esto sería largo y aburrido. De hecho, lea libros sobre el tema, siga los blogs de desarrolladores del proveedor del navegador y diviértase de vez en cuando probando cosas. Ya no estoy de acuerdo con seguir el 100% de todos los estándares web porque siempre habrá excepciones. Prefiero utilizar buenas prácticas de codificación que ayudarán a los desarrolladores, pero que al mismo tiempo serán compatibles con el navegador. Es importante comprender que HTML5 se basa en estándares existentes y está hecho para admitir contenido existente.
Una última opinión: http://dowebsitesneedtobeexperiencedexactlythesameineverybrowser.com/
Depende del tamaño del proyecto y su presupuesto. Si necesita hacer algo rápidamente, eso no tiene demasiada funcionalidad y su objetivo principal es hacer algo y seguir adelante, entonces los estándares no son importantes. Usted gastará el doble de la cantidad de tiempo que se adhiere a las normas cuando su proyecto es muy pequeño.
Los estándares W3C son muy útiles, pero son un medio para un fin y no un fin en sí mismos. El objetivo final de estos estándares es la compatibilidad entre navegadores, lo cual es muy importante. Los estándares en W3C son los segundos para asegurarse de que su aplicación funcione correctamente en todos los navegadores diferentes que serán utilizados por su audiencia. Los estándares web también ganan mucho valor cuando se tiene en cuenta el SEO. Cumplir con los estándares hará que su sitio sea más visible para los usuarios no humanos, por lo que si la visibilidad del motor de búsqueda le preocupa, los estándares web también deberían serlo. Esto puede no ser una gran preocupación para los "principales sitios web" (ya que ya están bien establecidos en los motores de búsqueda), pero puede ser para usted.
Por lo tanto, los estándares web son importantes para la compatibilidad entre navegadores y para la optimización de motores de búsqueda .
Rompe todos los estándares que quieras si quieres entregar tu proyecto AHORA.
Pero cumpla estrictamente con los estándares si desea entregar ahora y en el futuro (sin ningún esfuerzo adicional).
Aquí está mi opinión sobre esta pregunta.
En primer lugar, abordaré este aspecto:
"Recientemente me enteré de que la mayoría de los principales sitios web no superan las pruebas de validación de CSS y marcado del W3C. Por lo tanto, [...]"
Las grandes empresas a menudo pueden sufrir parálisis, lo que hace que sea muy difícil lograr cambios pequeños. En la mayoría de los casos, las prácticas de "grandes empresas" no son un buen ejemplo a seguir. No son "grandes compañías" porque tienen un sitio web mal construido, es al revés. Se vuelven grandes, y hacer un cambio en su sitio web para arreglar un error de validación se convierte en un proceso cada vez más largo que cuesta más y más dinero (¡con largas listas de personas que necesitan cerrar los cambios!)
¡Pasemos ahora a lo siguiente, sin preocuparnos por el equipaje de las grandes empresas!
"[...] ¿Cuán importante es realmente seguir los estándares web?"
Esto puede ser respondido en dos contextos. Creo que el primer párrafo probablemente se aplique a usted cuando pregunte sobre :)
Si usted es un desarrollador web profesional, siempre debe seguir los estándares a menos que se le solicite explícitamente que no lo haga (consulte 1 ). Las razones por las que haría esto son que poder validar su margen de beneficio, la accesibilidad y la compatibilidad del navegador son parte del arte de crear sitios web profesionales.
Si eres un entusiasta del tema (por ejemplo, un experto en insectos raros), es posible que publiques una página web que contenga marcas terribles y todos los navegadores deberían tratar los errores de la misma manera: en el momento mismo. menos, todos deberían poder leer la información. Menciono esto porque la web está abierta para que cualquiera pueda publicar una página web, no solo desarrolladores expertos.
1) ¿ "explícitamente solicitó no hacerlo"? ¿Qué demonios significa eso? Significa que es posible crear un sitio web que funcione en todos los navegadores sin seguir los estándares. Google usa deliberadamente un margen de ganancia muy extraño en su página de búsqueda como se explica en este artículo:
http://www.stevefenton.co.uk/Content/Blog/Date/201008/Blog/Google-Deliberately-Write-Awful-HTML/
En última instancia, un estándar se entiende que brinda comodidad a los desarrolladores. Al ser "estándar", actúa como un proxy para un conjunto de requisitos dispares, por lo que si sigue el estándar:
- sepa que su código funcionará en diferentes tecnologías (navegador, plataformas, versiones)
- sepa que su código funcionará para diferentes personas (accesibilidad)
- el cliente acepta su código basado en ese hecho (el proyecto requiere el cumplimiento de las normas)
- otras cosas en las que no estoy pensando
El historial de "ahorrar tiempo" para los estándares web es bastante variado: a menudo pasábamos horas luchando para obtener la validación, solo para descubrir que los navegadores no son compatibles con los estándares. Para mí, obtener páginas para validar generalmente ahorra tiempo.
Volviendo a la pregunta: cuándo usarlos. Aquí está mi perspectiva pragmática: eche un vistazo a sus requisitos (en términos de navegadores, plataformas, versiones, accesibilidad). Compare el enfoque de apuntar a todos aquellos con el objetivo de un estándar más lo que sea que carezcan los estándares. ¿Agregar un "estándar" a la lista de requisitos le ahorra tiempo, o simplemente agrega otra carga para completar el proyecto?
Encuentro que la validación de HTML puede ser útil HASTA UN PUNTO.
Después de ese punto (es decir, donde la validación toma el control del sentido común) se convierte en un obstáculo, creo que la validación es una herramienta de DESARROLLO muy útil, pero no es necesario cumplirlo al 100%. Por ejemplo, la especificación XHTML Strict rechaza el target="" selector, lo que hace que no valide, pero todavía funciona a la perfección, para lograr la misma acción sin utilizar el código anterior se requiere el código javascript al efecto:
jQuery(document).ready(function($) {
$(''a'').each(function(){
if (($(this).attr(''rel'')==''external'') ||
($(this).attr(''rel'')==''nofollow''))
{
$(this).attr(''target'',''_blank'');
}
});
});
Ahora, para implementar lo anterior más que el target="" simple target="" desafía la lógica y la buena programación, CSS por otro lado generalmente tiene que validar, pero hay excepciones; pirateos de navegador y etiquetas específicas de proveedores, que en el clima actual del navegador son un mal necesario, hará que su código sea inválido, pero FUNCIONARÁ en la mayoría de los navegadores principales, por lo que depende de usted, puede cumplir 100% y saltar a través de aros para tener una pequeña placa en su sitio que diga "XHTML válido" o "HTML5 válido" o lo que sea, o puede tener un sitio limpio, funcional y limpio que simplemente funciona.
PD: Antes de que me llame y me llame hipócrita, sí tengo uno en mi blog personal, pero mi código no es válido en este momento.
Lectura adicional: http://net.tutsplus.com/articles/general/but-it-doesnt-validate/