2009-06-19 14 views
16

Esta pregunta fue inspirada un poco por this question, en la que la respuesta más votada recomendaba usar una característica de HTML 5. Sin duda, parecía ser un buen método para mí, pero me dio curiosidad sobre el uso de características de una especificación futura en general .HTML 5 - Adopción temprana donde sea posible - ¿Bueno o malo?

HTML 5 ofrece muchas mejoras, muchas de las cuales se pueden usar sin causar problemas en los navegadores actuales.

Algunos ejemplos:

// new, simple HTML5 doctype (puts browsers in standards mode) 
<!doctype HTML> 

// new input types, for easy, generic client side validation 
<input type="email" name="emailAddress"/> 
<input type="number" name="userid"/> 
<input type="date" name="dateOfBirth"/> 

// new "required" attribute indicates that a field is required 
<input type="text" name="userName" required="true"/> 

// new 'data-' prefixed attributes 
// for easy insertion of js-accessible metadata in dynamic pages 
<div data-price="33.23"> 
    <!-- --> 
</div> 
<button data-item-id="93024">Add Item</button> 

Muchas de estas nuevas características están diseñadas para hacer posible que los navegadores para validar automáticamente las formas, así como les dan mejores insumos (por ejemplo, un selector de fechas). Algunos son convenientes y parecen una buena forma de prepararse para el futuro.

Actualmente no rompen nada (hasta donde puedo decir) en los navegadores actuales y permiten un código limpio y genérico.

Sin embargo, aunque todos son válidos en HTML 5, NO son válidos para HTML 4, y HTML 5 sigue siendo un borrador en este momento.

¿Es una buena idea seguir adelante y usar estas funciones antes?

¿Hay problemas de implementación del navegador con ellos de los que no me he dado cuenta?

¿Deberíamos estar desarrollando páginas web ahora que utilizan funciones de borrador de HTML 5?

+0

Depende de qué navegadores necesites admitir. Si necesita hacer que el sitio funcione con IE, diría que probablemente sea demasiado pronto. – Scott

+1

@Scott por lo que puedo decir, ninguna de estas características interrumpe nada en IE o en cualquier otro navegador (aunque me puede faltar algo). –

+0

@TM Oh, subestimas la habilidad de IES para hacer cosas realmente extrañas en condiciones extrañas. – Scott

Respuesta

12

hay varias cosas a tener en cuenta:

  1. En primer lugar, la validación no significa que mucho, porque una página HTML puede muy bien ser válida pero mal escrito, inaccesible, etc. Ver Say no to "Valid HTML" icons y Sending XHTML as text/html Considered Harmful (en referencia a las pruebas de hobo-web mencionadas en otra respuesta)
  2. Dado esto, recomiendo usar el nuevo DOCTYPE: la única razón para tenerlo en HTML5 es que es lo más pequeño que activa el modo estándar en los navegadores, por lo que si quieres el modo estándar, ve con él; usted tiene poca o ninguna razón para utilizar otro, DOCTYPE detallado, propenso a errores
  3. En cuanto a las mejoras formas, puede utilizar la biblioteca JS webforms2 de Weston Ruter para llevarlo a los navegadores no-conscientes
  4. y, finalmente, sobre la data-* atributos, a) funciona en todos los navegadores (siempre que use getAttribute()), b) es mejor que abusar de los atributos title o class yc) no le molestará con la validación, como dijimos anteriormente que la validación no es que es importante (por supuesto que sí, pero no importa que su página no sea válida si los errores de validez son deliberados, y usted ya puede usar la validación HTML5 en el validador W3C, así que ...); así que no hay una razón real para no usarlos tampoco.
+1

"la validación no significa mucho, porque una página HTML puede ser muy válida pero mal escrita", correcto, pero solo para su propio desarrollo, la validación es una manera fácil y automática de detectar algunos errores. –

2

¡Buena pregunta!

En resumen: que depende de su contexto y tolerancia al riesgo :)

Ligeramente más largo:

  • Yo creo que siempre es bueno para empujar el sobre en la rápida adopción de la tecnología. Le da una ventaja sobre los recién llegados en el mundo comercial, y también le da mucha más influencia para influenciar la tecnología a medida que surge.

  • Si no desea tener que volver a escribir el código o actualizar su fuente, entonces la adopción anticipada puede no ser para usted. Es perfectamente respetable a querer escribir código sólida y estable que nunca tiene que cambiar, pero es totalmente de usted (y su contexto de negocios)

1

Ver Robustness principle:

En el RFC 761 (Transmisión Control Protocolo, 1980) Computadora estadounidense científico Jon Postel resumió comunicaciones anteriores del deseado criterios de interoperabilidad para el protocolo de Internet (cf.IEN 111 1, RFC 760) de la siguiente manera:

implementaciones TCP deben seguir un principio general de robustez : ser conservador en lo que hace, sea liberal en lo que acepta de otros .

Así que, imho, no.

+1

Este también es un buen principio. (Pero, ¿cómo vamos a mejorar el estado de la tecnología si todos son conservadores en lo que hacen?) Sin embargo, señalaría que este principio se aplica específicamente a las piezas de la arquitectura central que tienen que ser muy estables ... al igual que mi segundo punto :) +1 para una buena respuesta. –

+0

@ John Weldon, creo que históricamente hubo diferencias entre las implementaciones TCP de diferentes proveedores. Por lo tanto, ser conservador en este contexto se refiere a ser conservador al seguir las especificaciones. Creo que este principio se aplica a todo lo que requiera interoperabilidad multiplataforma, incluyendo html con muchos navegadores. –

+0

Buen punto. Estoy de acuerdo, por un lado, pero, por otro lado, eso parece ser un poco limitante para * cada * situación. Tal vez sí en un sitio corporativo, o en una página web del gobierno, pero ¿qué pasa con otros entornos menos rigurosos? Buena discusión :) –

2

Si su página se basa en gran medida en la colocación del motor de búsqueda, puede valer la pena considerar que algunos motores dan prioridad a la validación de HTML (Fuente: http://www.hobo-web.co.uk/seo-blog/index.php/official-google-prefers-valid-html-css/).

Además, vale la pena considerar que confiar en los nuevos elementos de entrada de fecha (como los de Opera, posiblemente otros) permite una mayor conveniencia por parte del desarrollador, por lo general impide controles de Javascript más complejos que mejorarían servidores de navegadores más antiguos (por lo general, volviendo a un campo de entrada de texto simple).

Por supuesto, y como siempre, no confíe en las comprobaciones del lado del navegador y valide todo el lado del servidor de entrada.

+0

+1 para la validación del lado del servidor! – Treb

+1

Por supuesto, nunca me quedaría sin validación en el servidor. Tener validación del lado del cliente además (¡nunca en reemplazo!) Puede hacerlo mucho más fácil de usar. Sin embargo, –

+0

Nada como enviar una página no verificada y luego recuperarla marcada en rojo o vaciada con oscuros errores de validación, debo admitir. – Jon

2

No utilice las nuevas funciones antes de poder probarlas en al menos un navegador. Por ejemplo, si usa las funciones de formulario now, asegúrese de probar en Opera. De lo contrario, es probable que haga más daño que bien contribuyendo a un legado envenenado por ahí.

Cuando una función ya está implementada en los navegadores y está probando con esos navegadores, asegúrese de usar las nuevas funciones.

Véase también un older answer.

1

No implementaré nuevas características de HTML hasta que al menos tengan soporte de todos los principales navegadores.

A los clientes no les importa si su página es válida, les importa mucho más si funciona en el navegador.Incluso si luchamos por implementar los últimos estándares, todavía habrá clientes y compañías que nunca perderán su IE6, e IE6 estará en la lista de requisitos de su navegador por un tiempo.

Los nuevos tipos de formulario son bienvenidos, sin embargo, los formularios deben verificarse en el servidor.

Pasar a documentos existentes en HTML5 requerirá mucho esfuerzo y adaptación, y en mi estimación no ocurrirá de la noche a la mañana. Espere al menos 3 años hasta que llegue a la corriente principal.

0

Usaría HTML 5 solo por diversión y aprendizaje, pero definitivamente no tocaría ninguno de mis códigos de producción (código existente) con este nuevo estándar, al menos hasta ahora y hasta que tenga una razón válida para apoyar esto movimiento.

Cuestiones relacionadas