Html5-boilerplate: Erwägen Sie die Verwendung eines HTMLLinter?

Wie würden die verwendeten Regeln gewählt? Einige der Standardregeln sind wirklich persönliche Vorlieben. Zum Beispiel:

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-double-quotes Beide sind perfekt gültiges HTML5, und ich denke nicht, dass dieses Boilerplate den Standard auswählen sollte.

https://github.com/yaniswang/HTMLHint/wiki/Tag-self-close beide sind gültiges HTML5, und letzteres ist tatsächlich die modernere Methode, da das vorherige für XHTML gilt und aus Abwärtskompatibilität in HTML5 zulässig ist soweit ich weiß, bei der Migration von XHTML nach HTML5.

https://github.com/yaniswang/HTMLHint/wiki/Attr-value-not-empty beide sind gültig und letzteres wird von den meisten Leuten verwendet, aber es wird als der schlechte Weg angesehen.

Viele dieser Regeln sind zweifelhaft und würden dazu führen, dass Teile der Kesselplatte als Fehler oder Warnungen gekennzeichnet werden. Aus diesem Grund bin ich dagegen, dies hinzuzufügen, und möchte, dass solche Einstellungen dem Entwickler überlassen bleiben und nicht mit diesem Projekt gebündelt werden. Fügen Sie den Dokumenten möglicherweise einen HTML-Linter-Abschnitt hinzu und stellen Sie Links zu verschiedenen Lintern bereit?

@quantumpacket Wie Sie bereits erwähnt haben tag-self-close gibt es immer zumindest eine Rechtfertigung dafür, eine über die andere zu wählen, und ist es nicht hier, wo die Community genau wie über den Inhalt der Boilerplate abwägen kann? Wo es keine Rechtfertigung gibt, fügen wir diese Regel einfach nicht hinzu. Wenn wir uns als Referenz alle Codestile für JS https://github.com/rcorp/standard-project-structure/issues/6 ansehen, insbesondere AirBNB, können wir sehen, dass es viele Regeln gibt, aber jeder von ihnen hat eine Argumentation, die der Entwickler zu schätzen wissen wird.

Ich verstehe Ihren Standpunkt voll und ganz, aber das sind nur Regeln. Diejenigen, die wir nicht auswählen, werden nicht durchgesetzt. Es kann also ein sehr nachsichtiger Ansatz sein. und ein Boilerplate für Entwickler zum Hinzufügen / Entfernen von Regeln zu .htmlhintrc

@ gaurav21r Tut ich das hier verweilen lasse. Ich denke, das wäre eine gute Idee. (Wollten Sie einen mit PR vorschlagen? Ich werde diese Hilfe vorerst markieren.)

Was die zu wählenden Werte betrifft, wird der Ausgangspunkt aus dem Projekt selbst ersichtlich. Bei den Beispielen @quantumpacket shared verwenden wir doppelte Anführungszeichen, verwenden leere Attribute und schließen uns nicht selbst. Von dort aus werden die Leute sicher Meinungen haben.

@roblarsen Wir würden gerne mit einer PR beitragen. Wir haben bereits eine gute Startbasis für den Regelsatz ausgewählt. https://github.com/rcorp/standard-project-structure/issues/13

Es wird von ein paar großen Organisationen verwendet. Ich werde sehen, ob es zum Boilerplate passt und nicht zu eigensinnig ist. Ruhe können wir in der PR selbst besprechen!

Irgendwelche Fortschritte in diesem Bereich?

@ gaurav21r Irgendein Update? Wenn nein, möchte noch jemand einen Stich machen?

@roblarsen Wenn es passiert, dass @ gaurav21r nicht weitermachen kann, mache ich das gerne.

@AlexxNica klingt gut. Wir lieben immer die Hilfe.

Entschuldigung für die sehr späte Antwort! @roblarsen @AlexxNica Wird versuchen, dies bis zum 15. zu tun. Wenn nicht, helfen wir Ihnen gerne weiter!

keine Sorgen!

Der 15. ist gekommen und gegangen! Dies ist offen für alle, die es versuchen wollen!

Sind wir sicher, dass HTMLHint die beste Option ist?

@AlexxNica Ich habe keine Erfahrung an dieser Front, also bin ich mit dabei. Wer dies übernehmen möchte, kann hier eine Diskussion eröffnen, und ich werde mein Bestes tun, um gegebenenfalls Feedback zu geben, aber dies liegt definitiv in den Händen der Community.

Wir müssen uns das genauer ansehen, bevor wir mehr Code in das Projekt einfügen. Dinge, die sicher sein müssen, bevor wir etwas unternehmen:

· Ist es hilfreich genug, um die Notwendigkeit einer Implementierung zu rechtfertigen?
· Ist es einfach zu versenden und zu warten?
· Wurde es von jemandem / uns getestet?
· Sehen wir eine echte Verbesserung gegenüber dem tatsächlichen Modell?
· Haben wir die Tests anhand unseres Codes durchgeführt, um festzustellen, ob wir nichts ändern müssen, um mit dem Analysegerät kompatibel zu sein? (damit Benutzer nicht mit mehr Fehlern auf dem Bildschirm hängen bleiben, als ihr Monitor anzeigen kann)
· Wird es langfristig präsent sein? (Ich denke nicht, dass es eine gute Idee ist, etwas zu implementieren, das für eine solide Zeitspanne nicht existiert.)
· Wie einfach ist die Bedienung?

@roblarsen Kannst du darüber awaiting feedback " und (vielleicht) " HTML " wären angemessener.

Ich habe diese hinzugefügt. Es ist immer noch Hilfe gesucht und immer noch eine neue Funktion. Ich werde das nicht persönlich anfassen, also ist es definitiv etwas, mit dem die Community laufen muss.

Ich denke, hier gibt es zwei Fragen:

• Sollten wir ein .htmlhintrc in die src / dist-Ordner für Benutzer aufnehmen?
  HTMLHint ist eigentlich nur dazu gedacht, vollständige, kompilierte HTML-Seiten zu fusseln (standardmäßig wird jedoch überprüft, ob jede Datei ein <title> -Tag hat, sodass es für die meisten serverseitigen Sprachen oder Vorlagen-Sprachen nicht wirklich geeignet ist Ich denke, es ist von begrenztem Wert, da so viele Benutzer Angular-, React-, PHP-, ASP- oder Template-Sprachen wie Liquid verwenden, bei denen entweder viele Fehler auftreten oder überhaupt nicht funktionieren. Ein Benutzer könnte alle Regeln bearbeiten, um keine Fehler anzuzeigen Aber diese Art von Niederlage macht den Zweck des Einschlusses zunichte. Und alle Benutzer müssten ein Plugin installieren, damit ihre IDE es verwenden kann. Ich glaube einfach nicht, dass genug Benutzer Webseiten in reinem HTML ohne Includes codieren, um dies zu rechtfertigen seine Aufnahme (ich persönlich benutze HTMLHint nur beim Codieren von HTML-E-Mails - es ist großartig, um Fehler zu finden) - und wir schließen keine JS- oder CSS-Linters / Hinter-Konfigurationsdateien ein.

• Sollten wir einen HTMLHint in das Build-System aufnehmen, um nach Fehlern zu suchen?
  Ja, ich denke das könnte eine gute Idee sein. Unser Build-System verwendet derzeit Gulp und es gibt ein NPM-Paket, das integriert werden kann: https://www.npmjs.com/package/gulp-htmlhint. Ich werde das in den nächsten Tagen untersuchen. Dies würde beim Kompilieren nach HTML-Fehlern suchen und könnte hilfreich sein, um Probleme vor dem Bereitstellen einer Site zu finden.

Die Unfähigkeit, HTML-Linters mit Vorlagensprachen zu verwenden, hat uns immer daran gehindert, sie zu verwenden. Reagieren ist eine etwas andere Geschichte, da jsx mit ESLint effektiv fusseln kann.

Das Fusseln scheint für das Projekt von Vorteil zu sein, nicht jedoch für den Endbenutzer. Aber scheint besser als nichts zu sein, zumindest verhindert es gelegentliche Fehler in der Quelle der Kesselplatte.

Übrigens sehe ich keine Gründe, Gulp für solch triviale Aufgaben zu verwenden. Es ist immer einfacher und zuverlässiger, zusätzliche Ebenen für Linters zu vermeiden und sie direkt von npm test aufzurufen (siehe Beispiel ).

IMO, Sie sollten sich von nicht standardmäßigen Tools fernhalten.

Es ist, als ob Sie überhaupt keinen Validator verwenden, und ich spreche aus Erfahrung, da sie auf Bootstrap v4-dev auf htmlhint umgestellt hatten, was im Grunde keine wirklichen Fehler auffing.

Mein Vorschlag wäre, den offiziellen Validator vnu.jar zu verwenden, obwohl er Java erfordert. Sie können ein Wrapper-Skript haben, das es ausführen würde, wenn Java verfügbar ist.

Ich habe kürzlich eine ähnliche Änderung in Bootstrap vorgenommen (siehe https://github.com/twbs/bootstrap/pull/24149), weil ich mich darüber geärgert habe, dass wir im Grunde keine Validierung mit htmlhint hatten.

HTMLHint wird leider nicht mehr aktiv gepflegt (https://github.com/yaniswang/HTMLHint) und wie @XhmikosR sagt - es gibt Probleme mit, daher

Grillen + die oben genannten