Html5-boilerplate: ¿Considere utilizar una HTMLLinter?

¿Cómo se elegirían las reglas utilizadas? Algunas de las reglas estándar son preferencias realmente personales. Por ejemplo:

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-double-quotes ambos son HTML5 perfectamente válidos y no creo que este texto estándar deba elegir qué estilo debe ser el predeterminado.

https://github.com/yaniswang/HTMLHint/wiki/Tag-self-close ambos son HTML5 válidos, y la última es en realidad la forma más moderna de hacerlo, ya que la anterior es para XHTML y está permitida en HTML5 para compatibilidad con versiones anteriores al migrar de XHTML a HTML5 que yo sepa.

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-not-empty ambos son válidos y el último es lo que la mayoría de la gente usa, pero se considera de mala manera.

Muchas de estas reglas son dudosas y harían que partes de la placa de calderas se marquen como errores o advertencias. Debido a eso, estoy en contra de agregar esto y preferiría dejar esas preferencias en manos del desarrollador y no incluirlas en este proyecto. ¿Quizás agregar una sección de linters HTML a los documentos y proporcionar enlaces a varios linters?

@quantumpacket Como mencionaste tag-self-close siempre hay al menos alguna justificación para elegir uno sobre el otro y ¿no es aquí donde la comunidad puede opinar como lo hace sobre el contenido del texto estándar? Donde no hay justificación, simplemente no agregamos esa regla. Como referencia, si miramos todos los estilos de código para JS https://github.com/rcorp/standard-project-structure/issues/6 especialmente AirBNB, podemos ver que hay muchas reglas, pero cada una de ellas tiene una razonamiento que el desarrollador agradecerá.

Entiendo totalmente tu punto, pero estas son solo reglas. Los que no elegimos no se hacen cumplir. Por tanto, puede ser un enfoque muy indulgente . y un texto estándar para que los desarrolladores agreguen / eliminen reglas de .htmlhintrc

@ gaurav21r Lo siento por dejar que esto se demore. Creo que esta sería una buena idea. (¿Querías proponer uno con un PR? Marcaré esta ayuda necesaria por ahora).

En cuanto a qué valores elegir, el punto de partida será evidente desde el propio proyecto. En el caso de los ejemplos @quantumpacket shared , usamos comillas dobles, usamos atributos vacíos y no

@roblarsen Nos encantaría contribuir con un PR. Ya hemos seleccionado una buena base de partida para el conjunto de reglas. https://github.com/rcorp/standard-project-structure/issues/13

Es utilizado por un par de grandes organizaciones. Veré si coincide con el modelo estándar y no es demasiado obstinado. ¡Descanso que podemos discutir en el propio PR!

¿Algún progreso en este tema?

@ gaurav21r ¿ Alguna actualización? Si no, ¿alguien más quiere intentarlo?

@roblarsen Si sucede que @ gaurav21r no puede continuar, estaré encantado de hacerlo.

@AlexxNica suena bien. Siempre amamos la ayuda.

¡Perdón por la respuesta tan tardía! @roblarsen @AlexxNica Intentará hacer esto antes del día 15. Si no, ¡será un placer ayudar a quien sea!

¡sin preocupaciones!

¡El 15 ha venido y se ha ido! ¡Esto está abierto a quien quiera intentarlo!

¿Estamos seguros de que HTMLHint es la mejor opción que existe?

@AlexxNica No tengo experiencia en este frente, así que me

Tendremos que echarle un buen vistazo a esto antes de agregar más código al proyecto. Cosas de las que estar seguro antes de emprender cualquier acción:

· ¿Es lo suficientemente útil para justificar la necesidad de implementar?
· ¿Es fácil de enviar y mantener?
· ¿Fue probado por alguien / nosotros?
· ¿Vemos una mejora real con respecto al modelo actual?
· ¿Ejecutamos las pruebas con nuestro código para ver si no tendremos que cambiar nada para cumplir con el analizador? (para que los usuarios no se queden atascados con más errores en la pantalla de los que puede mostrar su monitor)
· ¿Tendrá presencia a largo plazo? (No creo que sea una buena idea implementar algo que no existirá durante un período de tiempo sólido)
· ¿Cuál es su facilidad de uso?

@roblarsen ¿Puedes considerar cambiar las etiquetas de esto? Creo que " awaiting feedback " y (tal vez) " HTML " serían más apropiados.

Yo agregué esos. Todavía se necesita ayuda y sigue siendo una característica nueva. No voy a tocar esto personalmente, así que definitivamente es algo con lo que la comunidad tendrá que trabajar.

Creo que hay dos preguntas aquí:

• ¿Deberíamos incluir un .htmlhintrc en las carpetas src / dist para los usuarios?
  HTMLHint solo está destinado a ser utilizado para lint páginas HTML compiladas y completas (por ejemplo, de forma predeterminada, verifica que cada archivo tenga una etiqueta <title> por lo que no es realmente adecuado para la mayoría de los lenguajes del lado del servidor o de plantillas. Creo que tiene un valor limitado ya que muchos usuarios están usando Angular, React, PHP, ASP o lenguajes de plantillas como Liquid, donde dará muchos errores o no funcionará en absoluto. Un usuario podría editar todas las reglas para que no muestre errores pero eso frustra el propósito de incluirlo. Y todos los usuarios tendrían que instalar un complemento para que su IDE pueda usarlo. Simplemente no creo que suficientes usuarios estén codificando páginas web en HTML puro sin inclusiones para garantizar su inclusión (yo personalmente solo uso HTMLHint al codificar correos electrónicos HTML; es excelente para encontrar errores), y no incluimos ningún archivo de configuración JS o CSS linters / hinter.

• ¿Deberíamos incluir un HTMLHint en el sistema de compilación para comprobar si hay errores?
  Sí, creo que esto podría ser una buena idea. Nuestro sistema de compilación utiliza actualmente Gulp y hay un paquete NPM para que se integre: https://www.npmjs.com/package/gulp-htmlhint. Examinaré esto durante los próximos días. Esto buscaría errores HTML al compilar y podría ser beneficioso para encontrar problemas antes de implementar un sitio.

La incapacidad de usar linters html con lenguajes de plantillas es algo que siempre nos impidió usarlo. React es otra historia, ya que jsx se puede vincular de manera efectiva con ESLint.

La construcción de linting parece ser beneficiosa para el proyecto, pero no para el usuario final. Pero parece ser mejor que nada, al menos evitará errores ocasionales en la fuente de repetición.

Por cierto, no veo razones para usar Gulp para tareas tan triviales. Siempre es más fácil y confiable evitar capas adicionales para linters y llamarlos directamente desde npm test (ver ejemplo ).

En mi opinión, debe mantenerse alejado de las herramientas no estándar.

Es como si no usaras ningún validador, y hablo por experiencia, ya que en Bootstrap v4-dev habían cambiado a htmlhint, que básicamente no detectó ningún error real.

Mi sugerencia sería utilizar el validador oficial vnu.jar aunque requiera Java. Puede tener un script de envoltura que lo ejecute si Java está disponible.

Hice un cambio similar recientemente en Bootstrap (ver https://github.com/twbs/bootstrap/pull/24149) porque me molestó el hecho de que básicamente no teníamos ninguna validación con htmlhint.

Lamentablemente, HTMLHint ya no se mantiene activamente (https://github.com/yaniswang/HTMLHint) y, como dice @XhmikosR , hay problemas, así que voto para cerrar este problema.

Grillos + lo anterior