Html5-boilerplate: Pensez à utiliser un HTMLLinter?

Comment les règles utilisées seraient-elles choisies? Certaines des règles standard sont vraiment des préférences personnelles. Par exemple:

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-double-quotes sont tous deux parfaitement valides HTML5 et je ne pense pas que ce passe-partout devrait choisir le style par défaut.

https://github.com/yaniswang/HTMLHint/wiki/Tag-self-close sont tous deux du HTML5 valide, et ce dernier est en fait le moyen le plus moderne de le faire, car le précédent est pour XHTML et est autorisé dans HTML5 pour la compatibilité ascendante lors de la migration de XHTML vers HTML5 pour autant que je sache.

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-not-empty les deux sont valides et ce dernier est ce que la plupart des gens utilisent, mais c'est considéré comme le mauvais moyen.

Un grand nombre de ces règles sont douteuses et entraîneraient le marquage de certaines parties du passe-partout comme des erreurs ou des avertissements. Pour cette raison, je suis contre l'ajout de cela et je préférerais que ces préférences soient laissées au développeur et ne pas les regrouper avec ce projet. Peut-être ajouter une section HTML linter aux documents et fournir des liens vers divers linters?

@quantumpacket Comme vous l'avez mentionné tag-self-close il y a toujours au moins une justification pour choisir l'un par rapport à l'autre et n'est-ce pas là où la communauté peut peser comme elle le peut sur le contenu du passe-partout? Là où il n'y a aucune justification, nous n'ajoutons tout simplement pas cette règle. Pour référence, si nous regardons tous les styles de code pour JS https://github.com/rcorp/standard-project-structure/issues/6 en particulier AirBNB, nous pouvons voir qu'il y a beaucoup de règles mais chacune d'elles a un raisonnement que le développeur appréciera.

Je comprends parfaitement votre point de vue, mais ce ne sont que des règles. Ceux que nous ne choisissons pas ne sont pas appliqués. Cela peut donc être une approche très clémente . et un passe- partout pour que les développeurs ajoutent / suppriment des règles de .htmlhintrc

@ gaurav21r Désolé d'avoir laissé cela persister. Je pense que ce serait une bonne idée. (vouliez-vous en proposer un avec un PR? Je signale cette aide recherchée pour le moment.)

Quant aux valeurs à choisir, le point de départ sera évident à partir du projet lui-même. Dans le cas des exemples @quantumpacket shared- nous utilisons des guillemets doubles, des attributs vides et ne nous fermons pas automatiquement. À partir de là, je suis sûr que les gens auront des opinions.

@roblarsen Nous aimerions contribuer avec un PR. Nous avons déjà sélectionné une bonne base de départ pour l'ensemble de règles. https://github.com/rcorp/standard-project-structure/issues/13

Il est utilisé par quelques grosses organisations. Je vais voir si cela correspond au passe-partout et n'est pas trop opiniâtre. Reste que nous pouvons discuter dans le PR lui-même!

Des progrès sur cette question?

@ gaurav21r Une mise à jour? Si non, quelqu'un d'autre veut essayer cela?

@roblarsen S'il arrive que @ gaurav21r ne puisse pas continuer, je serai heureux de le faire.

@AlexxNica sonne bien. Nous aimons toujours l'aide.

Désolé pour la réponse très tardive! @roblarsen @AlexxNica essaiera de le faire d'ici le 15. Sinon, nous serons heureux d'aider qui que ce soit!

pas de soucis!

Le 15 est venu et reparti! Ceci est ouvert à quiconque veut essayer de le faire!

Sommes-nous sûrs que HTMLHint est la meilleure option?

@AlexxNica Je n'ai aucune expérience sur ce front, donc je suis

Nous devrons y jeter un œil avant d'ajouter plus de code dans le projet. Choses à être sûrs avant d'agir:

· Est-ce suffisamment utile pour justifier la nécessité de mettre en œuvre?
· Est-il facile à expédier et à entretenir?
· A-t-il été testé par quelqu'un / nous?
· Constatons-nous une réelle amélioration par rapport au modèle actuel?
· Avons-nous exécuté les tests sur notre code pour voir si nous ne devrons rien changer pour être conforme à l'analyseur? (pour que les utilisateurs ne restent pas bloqués avec plus d'erreurs à l'écran que leur moniteur ne peut en afficher)
· Aura-t-il une présence à long terme? (Je ne pense pas que ce soit une bonne idée de mettre en œuvre quelque chose qui n'existera pas pendant une longue période)
· Quelle est sa facilité d'utilisation?

@roblarsen Pouvez-vous envisager de changer les étiquettes à ce sujet? Je pense que " awaiting feedback " et (peut-être) " HTML " seraient plus appropriés.

J'ai ajouté ceux-ci. C'est toujours recherché et toujours une nouvelle fonctionnalité. Je ne vais pas y toucher personnellement, donc c'est certainement quelque chose avec lequel la communauté devra fonctionner.

Je pense qu'il y a deux questions ici:

• Devrions-nous inclure un .htmlhintrc dans les dossiers src / dist pour les utilisateurs?
  HTMLHint est uniquement destiné à être utilisé pour lint des pages HTML complètes et compilées (par exemple, par défaut, il vérifie que chaque fichier a une balise <title> donc il n'est pas vraiment adapté à la plupart des langages côté serveur ou de création de modèles. Par conséquent Je pense que sa valeur est limitée car de nombreux utilisateurs utilisent Angular, React, PHP, ASP ou des langages de création de modèles comme Liquid où cela donnera de nombreuses erreurs ou ne fonctionnera pas du tout. mais alors, cela va à l'encontre de l'objectif de l'inclure. Et tous les utilisateurs devraient installer un plugin pour leur IDE pour pouvoir l'utiliser. Je ne pense tout simplement pas que suffisamment d'utilisateurs codent des pages Web en HTML pur sans inclure de garantie son inclusion (personnellement, j'utilise uniquement HTMLHint lors du codage des e-mails HTML - c'est idéal pour trouver des bogues) - et nous n'incluons aucun fichier de configuration JS ou CSS linters / hinter.

• Devrions-nous inclure un HTMLHint dans le système de construction pour vérifier les erreurs?
  Oui, je pense que cela pourrait être une bonne idée. Notre système de construction utilise actuellement Gulp et il existe un package NPM pour l'intégrer: https://www.npmjs.com/package/gulp-htmlhint. J'examinerai cela au cours des prochains jours. Cela vérifierait les erreurs HTML lors de la compilation et pourrait être utile pour trouver des problèmes avant de déployer un site.

L'incapacité d'utiliser des linters html avec des langages de modélisation est quelque chose qui nous a toujours empêchés de l'utiliser. React est un peu une autre histoire, car jsx peut être efficacement lint avec ESLint.

La construction pelucheuse semble être bénéfique pour le projet, mais pas pour l'utilisateur final. Mais semble être mieux que rien, au moins cela évitera des erreurs occasionnelles dans la source du passe-partout.

Btw, je ne vois pas de raisons d'utiliser Gulp pour des tâches aussi triviales. Il est toujours plus facile et plus fiable d'éviter des couches supplémentaires pour les linters et de les appeler directement depuis npm test (voir exemple ).

OMI, vous devez rester à l'écart des outils non standard.

C'est comme si vous n'utilisiez aucun validateur du tout, et je parle d'expérience puisque sur Bootstrap v4-dev, ils étaient passés à htmlhint qui, en gros, n'a pas détecté de vraies erreurs.

Ma suggestion serait d'utiliser le validateur officiel vnu.jar même s'il nécessite Java. Vous pouvez avoir un script wrapper qui l'exécuterait si Java est disponible.

J'ai récemment fait un changement similaire dans Bootstrap (voir https://github.com/twbs/bootstrap/pull/24149) parce que j'étais ennuyé par le fait que nous étions fondamentalement sans aucune validation avec htmlhint.

HTMLHint n'est malheureusement plus activement maintenu (https://github.com/yaniswang/HTMLHint) et comme le dit @XhmikosR - il y a des problèmes avec donc je vote pour fermer ce problème.

Grillons + ce qui précède