angularjs - invalid - ¿Debería importarme la validación W3C?
angularjs validation bootstrap (9)
Estoy aprendiendo AngularJS y encontré un código simple como este:
<!DOCTYPE html>
<html>
<head>
<meta charset=''utf-8''>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.js"></script>
</head>
<body ng-app ng-init="name = ''World''">
<h1>Hello, {{name}}!</h1>
</body>
</html>
no pasa la prueba de validación W3C, principalmente porque hay atributos no estándar ( ng-app , ng-init ).
La pregunta es: ¿debería preocuparme la validación W3C de mi aplicación? ¿Debería abandonar AngularJS?
Las convenciones de HTML están ahí para ayudar a prevenir antipatrones y mantener el código mantenible.
Sí. En ese sentido, escribí sobre eso un poco más de longitud recientemente en una sección "¿Por qué validar?" Que agregué a la sección "Acerca de" del validador de HTML5:
http://validator.w3.org/nu/about.html#why-validate
La fuente del texto de esa sección está aquí:
https://github.com/validator/validator/blob/master/site/nu-about.html#L160
Y las solicitudes de extracción con mejoras / adiciones sugeridas son bienvenidas.
Lo que tengo allí actualmente es esto:
La razón principal para ejecutar sus documentos HTML a través de un comprobador de conformidad es simple: detectar errores involuntarios, errores que de otro modo podría haber pasado por alto, para que pueda solucionarlos.
Más allá de eso, algunos requisitos de conformidad de documentos (reglas de validez) en las especificaciones de HTML están ahí para ayudarlo a usted y a los usuarios de sus documentos a evitar ciertos tipos de problemas potenciales. Para explicar el razonamiento detrás de esos requisitos, la especificación de HTML contiene estas dos secciones:
- razonamiento para los errores de nivel de sintaxis
- justificación de las restricciones en los modelos de contenido y en los valores de los atributos
Para resumir lo que está establecido en esas dos secciones:
- Hay algunos casos de marcado definidos como errores porque son posibles problemas de accesibilidad, usabilidad, interoperabilidad, seguridad o capacidad de mantenimiento, o porque pueden dar como resultado un rendimiento deficiente o que pueden provocar fallas en las secuencias de comandos que son difíciles de solucionar.
- Junto con estos, algunos casos de marcado se definen como errores porque pueden provocar problemas potenciales en el análisis de HTML y en el comportamiento de manejo de errores, por lo que, por ejemplo, terminarías con un resultado no intuitivo e inesperado en el DOM.
La validación de sus documentos le alerta sobre esos posibles problemas.
Depende del tamaño de tu proyecto.
En general, las convenciones HTML están ahí para ayudar a prevenir antipatrones y mantener el código mantenible.
Esa regla en particular (que requiere una etiqueta con el prefijo -data para ser un atributo válido) es en mi opinión un poco extraña, ya que tiende a promover el marcado extra que no sirve para nada.
Yo diría que limítese a validar su HTML en contra de las convenciones de WC3 si está trabajando en un gran proyecto con muchos desarrolladores. De lo contrario, no hay ventajas reales.
Intente ejecutar script en el dominio seguro con el https:
Consulte el mismo a continuación utilizando https:
<!DOCTYPE html>
<html>
<head>
<meta charset=''utf-8''>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.js"></script>
</head>
<body ng-app ng-init="name = ''World''">
<h1>Hello, {{name}}!</h1>
</body>
</html>
Lo que "debería" importarle o no depende de usted. Hay muchas páginas que no son HTML válidas .
HTML5 permite atributos personalizados con el prefijo de data- , por lo que puede utilizar una de las otras directivas equivalentes, como:
<span data-ng-bind="name"></span>
Podría usar el atributo data- html5 que es estándar y, por lo que yo sé, funciona igual para Angular. Algo como:
data-ng-app=""
data-ng-init="xxx"
Funcionará igual en Angular y será validado por W3C.
Mira también esto: ng-app vs. data-ng-app, ¿cuál es la diferencia?
Aparte de eso, de mi experiencia trabajando con estándares siempre es mejor cuando su producto será entregado a una gran multitud posible (por lo que está construyendo un sitio web o una aplicación web pública, etc.) con diferentes clientes, versiones, etc. Si usted '' Re construir un SPA utilizando angular y tal vez phonegap para crear una aplicación móvil que se instalará en dispositivos móviles como una aplicación nativa, el estándar no podría ser tan importante, lo importante es que funcionará en sus dispositivos de destino.
Puede install with npm :
$ npm install --save-dev gulp-angular-htmlify
Puedes usar el sistema de compilación GulpJs y probar un complemento que escribí que hace exactamente lo que quieres:
convirtiendo ng-directives en data-ng-directives que es la especificación de W3C para la validación html5.
Está fuertemente probado y se encuentra aquí: https://github.com/pgilad/gulp-angular-htmlify
Use el prefijo "data-" en su aplicación angular. Ejemplo:
<body data-ng-app data-ng-init="name = ''World''">
<h1>Hello, {{name}}!</h1>
</body>
W3C HTML5 validator manteiner aquí. Hemos tenido discusiones sobre cómo lidiar con una mejor validación de documentos que contienen atributos personalizados, como Angular''s ng-* attributes-attributes que aunque no estándar todavía se usan de forma muy amplia y correcta, y que el validador emita un "error" los mensajes sobre ellos no están realmente ayudando a los autores.
Una característica que agregué al validador HTML5 para mitigar esto es una función de "filtrado de mensajes" que le permite ignorar persistentemente los mensajes de error / advertencia que no son importantes o útiles para usted. La interfaz está aquí:
Después de enviar un documento para su verificación, en la página de resultados verá un botón de filtrado de mensajes , y si presiona eso, obtendrá una lista de todos los mensajes de error agrupados en conjuntos, con casillas Mostrar / Ocultar.
Actualización 2017-02-06: propuesta de especificaciones de HTML para atributos personalizados en discusión
Hace poco agregué soporte para elementos personalizados al verificador HTML (validador W3C); por lo tanto, para agregar soporte para atributos personalizados, podría usar un mecanismo similar al que utilicé para implementarlo.
Pero el verificador HTML no se puede cambiar para permitir nombres de atributos personalizados hasta que se actualice la especificación HTML para permitirlos. Para eso, vea la propuesta que se discute en el rastreador de problemas de especificaciones de HTML .