Beautifier für HTML-Code für ganze Site (Ordner samt Unterordnern) gesucht

T

thulium

Aktives Mitglied
Thread Starter
Dabei seit
12.11.2011
Beiträge
3.651
Reaktionspunkte
390
Moin.

Es gibt ein handgestricktes CMS für ein kleines Web-Projekt. Die Rohartikel liegen als plain HTML vor.

Gerne möchte ich mal den Code aller HTML-Dokumente in einem Rutsch einheitlich formatieren und suche daher einen Beautifier (Pretty Printer, ...), der nicht nur ein Dokument behandelt, sondern alle, die sich in einem Ordner und dessen Unterordnern befinden.

Ideal wäre ein Tool mit GUI und einigen Konfigurationsoptionen. *

Bisher fand ich nix. Kennt jemand eins? Danke.

* Kleiner netter Artikel:
https://www.fewbutripe.com/swift/html/dsl/2017/07/17/pretty-printing-html.html

Insbesondere das Ausrichten von Attributen innerhalb von Start-Tags schätze ich.
 
Zuletzt bearbeitet:
Welche IDE benutzt Du? Ggf. gibt es dort bereits Plugins für und Du kannst diese mit einer Save-Action verbinden. Alternativ gibt es prettier. Einfach via npm installieren, konfigurieren und ab dafür. Einige IDEs bieten bereits von Haus aus prettier Support.
 
Welche IDE benutzt Du? Ggf. gibt es dort bereits Plugins für und Du kannst diese mit einer Save-Action verbinden. Alternativ gibt es prettier. Einfach via npm installieren, konfigurieren und ab dafür. Einige IDEs bieten bereits von Haus aus prettier Support.
IDE für HTML ist Dreamweaver. Es gibt keine für die Aufgabe geeigneten Plugins.
DW hat zwar einen integrierten Code Formatter, er wirkt jedoch nur ein einzelnes Dokument.
Und solche fortgeschrittenen Optionen wie fluchtende Attribute wie im Ausgangsposting erwähnt, kann er nicht.

prettier.io ist, wenn ich es richtig sehe, ein Kommandozeilentool. Typischerweise tue ich mich damit schwer. Lieber wäre mir eines mit GUI.
 
prettier.io ist, wenn ich es richtig sehe, ein Kommandozeilentool. Typischerweise tue ich mich damit schwer. Lieber wäre mir eines mit GUI.

Wenn du dich mittelfristig tiefer mit Terminal und Shell-scripting befassen würdest, hättest du halt ein sehr mächtiges Werkzeug, mit dem du deine oft sehr individuellen Wünsche durchaus sehr elegant und effekitv lösen könntest.

Gut, es dauert halt einige Zeit, die Kniffe im scripting zu erlernen und es entspricht wohl auch nicht deinem UX-Steckenpferd, aber dieser Wunsch hier ließe sich wahrscheinlich mit einer Zeile Shellcode und prettier.io lösen.

Da wärst du schon mit der website fertig, bevor du im Forum das erste Posting verfasst hast.
 
  • Gefällt mir
Reaktionen: ruerueka und BuzzGo
Ich verstehe Deinen Gedanken. Aber für Werkzeuge, egal welcher Art, gilt meiner Erfahrung nach: wenn man sie nicht regelmäßig nutzt (Du tust das im Gegensatz zu mir aus beruflichen Gründen) ist ein selbsterklärendes GUI hilfreich und dem Konzept der Kommandozeile überlegen.

Und mit nutzen meine ich: die Werkzeuge justiert, anpasst, etc.

Wie auch immer: Hätte ja sein können, dass es ein GUI-Tool gibt. Das scheint nicht der Fall zu sein.
 
hhmm, das Problem mit deiner Herangehensweise steckt halt in dem Wort "selbsterklärend". Eine GUI scheint auf den ersten Blick oft besser zu sein, da man mehr Informationen sieht und es mit der Maus bedienen kann. Aber das mit dem "selbsterklärend" ist halt so ne Sache. Das ist ja auch eines deiner liebsten Kritikpunkte an allen möglichen Programmen oder macOS-Möglichkeiten. Es gibt einfach sehr viele unterschiedliche Ansätze, wie eine GUI gestaltet wird. Sieh dir nur mal vergleichend die GUI von Handbrake und balenaEtcher an. Komplett andere Philosophie.

Auf der Kommandzeile sieht man zwar nicht jede Einsellung auf einen Blick (was für dich negativ besetz ist), aber die Kommandozeile ist drastisch konsistenter in der Bedienung als jede GUI. Und man nutzt immer die Tastatur, nicht Maus und Tastatur.

Fast jedes Tool / Befehl bedient sich gleich: "command option1 option2 ....". Wenn man wissen will was das Teil kann "man command". Und weiß man mal gar nicht weiter kriegt man mit "apropos Begriff" eine Übersicht der Befehle / manpages, in denen der Begirff in der Übersichtsbeschreibung verwendet wird.

Die Tools und Befehle sind meist sehr spezialisiert und können einen Teil und den sehr gut und sind sehr oft auch drastisch mächtiger als GUIs. Und hier kommt dann der riesige Vorteil der Kommandozeile: Man kann all diese spezialisierten Tools mit anderen Tools verknüpfen, Ausgaben des einen als Eingabe des anderen verwenden und ganze Folgen von Befehlen hintereinander ablaufen lassen und sich diesen Ablauf abspeichern und wieder verwenden und so faktisch sich selbst ein neues Tool erstellen.

Klar muss man dann oft Englisch beherrschen, da die IT-Welt halt sehr englisch-sprachig orientiert ist, aber man gewöhnt sich an, erst mal zu lesen. Und im Laufe der Zeit, tritt denn genau das ein, was ein Sprichwort besagt: "Lesen bildet".

Dein Wunsch wäre mit prettier.io nach der Installation, die auf der website einfachst beschrieben ist und nur abgetippt werden müsste, mit

Code:
npx prettier --write /Pfad/zum/Ort/deiner/Webseite

erledigt.

Willst du finetuning betreiben: Hilfe lesen, weitere Option hinzufügen

Das Problem an "GUI vs. CLI" ist nicht, dass die GUI einfacher ist oder die CLI kryptisch wäre. Meiner Erfahrung nach ist das Problem, das die wenigsten User lesen wollen, sondern nur schnell wo drauf klicken nach dem Motto "wird schon klappen". Selbst das Lesen der Hilfe-Anzeige in GUI-Anwendungen ist verpönt, wie man sehr oft hier im Forum erkennen kann. Oder gar Lesen der Apple Support Seiten, nee, das ist old-school, in Foren ellenlange Postings schreiben, Antworten zerpflücken, Haar spalten und sich dann in selbige kriegen, all das wird lieber getan, als "man command" und lesen.

Dennoch, wenn du da keinen Zugang findest oder Energie investieren möchtest, ist das ja ok. Ich dachte halt nur, da du sehr oft sehr lange nach der optimalen GUI suchst und dabei viel Zeit investierst, könntest du diese viele Zeit vielleicht in die CLI stecken. Ich würde mal behaupten, dass du da mittelfristig mehr davon hast, als mit deinem aktuellen Zeitaufwand.
 
  • Gefällt mir
Reaktionen: Macschrauber, BuzzGo, agrajag und eine weitere Person
Das Problem an "GUI vs. CLI" ist nicht, dass die GUI einfacher ist oder die CLI kryptisch wäre. Meiner Erfahrung nach ist das Problem, das die wenigsten User lesen wollen, sondern nur schnell wo drauf klicken nach dem Motto "wird schon klappen".
So sehe ich es auch. Bei Buildsystemen und/oder prettifier ist eine GUI überflüssig, da die ganze "Magie" eh im Hintergrund läuft. Eine Übersichtliche Konfiguration z. B. in einer JSON, YAML etc. Datei und eine gute Dokumentation sollte mehr als ausreichend sein.
 
UX-Experten könnten sicher besser aus Sicht der Kognitionsforschung erläutern, warum sich GUIs und nicht Kommandozeilenwerkzeuge durchgesetzt haben, als ich.

Insgesamt ist das ein großes und sehr komplexes Thema, ohne Frage.

Mit vielen Deiner Argumente, @lisanet, gehe ich konform.
Klar, man muss in beiden Interfaces lesen. Es gibt in beiden Welten schludrig gemachte und schludrig dokumentierte Werkzeuge.

Ein Punkt, den ich bei GUI-Tools immer vorteilhaft fand, dass es eine "Vorschau-Funktion" gibt.

Vor zwei Jahren habe ich für eine befreundete Hilfsorganisation 20.000 Dateien normalisiert. Die Namen waren Kraut und Rüben, vor allem aber: nicht kompatibel für Server.
Die Aufgabe war komplex. Ich musste mich mit diversen regulären Ausdrücken und logischen Operatoren mehrschrittig rantasten.
Das GUI-Tool "Renamer.app" war dafür exzellent.


Denn gerade am Anfang muss man sich erstmal mit den Optionen vertraut machen, sicherstellen, dass die Wirkung (im hier diskutierten Fall wäre es die Formatierung von HTML) wirklich im Ergebnis so wird, wie man es möchte.
Kurz: Herumspielen.
Schalter umlegen, gucken. Schalter zurück, gucken.

Es nach mehrfacher Prüfung, wird man so einen Prozess auf eine Gesamtheit von Seiten anwenden.

Kommandozeilenwerkzeuge richten sich meiner Erfahrung nach typischerweise an Profis, an Nerds, die hochabstrakte Dokus goutieren.
Beispiele sind oft Fehlanzeige.

Zu prettier.io konkret:

* Es ist nach Selbstaussage "opinionated", bietet also explizit kaum Optionen an.
https://prettier.io/docs/en/option-philosophy.html

* Es lässt sich nicht in meinen Editor integrieren
https://prettier.io/docs/en/editors.html


Edit:
Aber es bietet die Option "--single-attribute-per-line".
Im Playground https://prettier.io/playground/ kann man diese Option nicht wählen.

Ich werd's mal installieren und ausprobieren.

Bin z.B. gespannt, wie es aufeinander folgende Whitespaces (space, tab, non-breaking space als named entity und als UTF-8 character, line endings) normalisiert.
 
Zuletzt bearbeitet:
Derartige Behandlungen von Whitespaces, Tabs, Umbrüche bieten IDEs wie Webstorm / PHPStorm von Haus aus (Code Style) und können derartige Formatierungen direkt als Save-Action und/oder beim Commit (quasi vor dem Commit) in ein CVS wie Git zum Beispiel ausführen.

Ich weiß nicht ob Du auch PHP Code in Deinen Projekten hast. Hier bieten sich ebenfalls Tools wie PHPStan und Reactor (neben PHP Unittests) an.
 
Dein Wunsch wäre mit prettier.io nach der Installation
Auch die Installation gehört bei Kommandozeilentools zu dem was ich als "typisch kompliziert" empfinde.

https://prettier.io/docs/en/install.html
Dort heißt es lapidar:
"npm install --save-dev --save-exact prettier"

Geht natürlich nicht. Weil man "irgendwas exotisches benötigt".

npm

Um npm zu installieren braucht man homebrew.

OK, also habe ich homebrew installiert. Ein halbes Gigabyte wird geladen.

https://bodo-schoenfeld.de/node-js-und-npm-unter-macos-installieren/

brew install node
-bash: brew: command not found

Ich mache morgen weiter.



Solche Prozesse habe ich schon immer abgrundtief gehasst.
 
Zuletzt bearbeitet:
Was braucht man noch um node zu installieren? Homebrew oder so.
Nee, nur node (und das Terminal)

https://nodejs.org/en/#home-downloadhead (Link mit dem Mac aufrufen)

Denn gerade am Anfang muss man sich erstmal mit den Optionen vertraut machen, sicherstellen, dass die Wirkung (im hier diskutierten Fall wäre es die Formatierung von HTML) wirklich im Ergebnis so wird, wie man es möchte.
Kurz: Herumspielen.
Schalter umlegen, gucken. Schalter zurück, gucken.

nicht anders geht man im Terminal vor. Das unterscheidet sich nicht.

Es nach mehrfacher Prüfung, wird man so einen Prozess auf eine Gesamtheit von Seiten anwenden.

Kommandozeilenwerkzeuge richten sich meiner Erfahrung nach typischerweise an Profis, an Nerds, die hochabstrakte Dokus goutieren.
Beispiele sind oft Fehlanzeige.

Das die eher was für erfahrene User oder Profis sind, ist sicher richtig. Das sind aber auch viele GUI-Tools, auch wenn sie bunt daher kommen.

Der wesentliche Unterschied ist aber meiner Erfahrung nach, dass professionelle GUI-Tools auch von Einsteigern genutzt werden, die damit nicht zurecht kommen oder nur glauben, sie könnten es (bestes Beispiel ist LittleSnitch / LuLu und solche Tools) und dann oftmals nicht das gewünschte Ergebnis erzielen oder gar andere Probleme erst verursachen.

Wer auf der CLI unterwegs ist, hat sich meist eben angewöhnt, vorher zu lesen und die Sache zu verstehen. Und das macht viel aus.

Und apropos Dokus: Zu GUI-Tools und Shell-scripting gibts garantiert deutlich mehr Dokus, Hilfen, Foren und websites, als zu GUI-Tools. Vorallem sind diese Hilfen dann eben eher von erfahrenen Usern oder Profis verfasst und nicht wie bei GUI-Tools von Einsteigern für Einsteiger.

Wie schon gesagt, wenn du keinen Zugang dazu findest, ist es ja ok. Du hast aber halt immer sehr spezielle Szenarien, die meines Erachtens eher für CLI prädestiniert sind.

Übrigens, ich befasse mich beruflich nicht mit IT.
 
Geht natürlich nicht. Weil man "irgendwas exotisches benötigt".

npm

Um npm zu installieren braucht man homebrew.

OK, also habe ich homebrew installiert. Ein halbes Gigabyte wird geladen.

https://bodo-schoenfeld.de/node-js-und-npm-unter-macos-installieren/

brew install node
-bash: brew: command not found

Tja, bitte nicht falsch verstehen: lesen, lesen, lesen und nicht irgendwas was man irgendwo aufschnappt probieren ohne zu wissen, was man genau tut.

Das läuft dann so ab:

Wenn du node installieren willst, bietet es sich an auf die Website von node zu gehen. Bei GUI-Programmen empfiehlt es sich ja auch, direkt von der Website des Herstellers downzuloaden, anstatt von den x 100en Download-Portalen. Nur weil man ein CLI-Tools will, ist das Vorgehen nicht anders.

Also, einfach bei Google "node" eintippen und den ersten Link nehmen (node ist garantiert immer ganz oben, so oft wie das genutzt wird)

Du kommst zu https://nodejs.org/en/

Und schon siehst du, dass die Webseite dein System macOS erkennt und anbietet, den Installer downzuloaden. Du kannst natürlich auch nach "node download" suchen und kommst dann ebenso zum Downloadbereich. https://nodejs.org/en/download/

Wenn du nun homebrew deinstallieren willst... du ahnst es, lesen, lesen und auf die website von homebrew gehen. Also google "homebrew uninstall" und finde den Link von brew -> https://nodejs.org/en/download/. Dann lesen, lesen und den Anweisungen des dort angebotenen Links mit dem uninstaller script folgen.

Und ich kann schon vermuten, was kommen wird: "Das ist mir alles zu viel". hhmm, naja, den Teil mit brew hast du halt etwas vorschnell gemacht.
 
Danke @lisanet

Installation klappte, erster Test der Anwendung von prettier auch.

Jetzt probiere ich noch die Optionen aus.

Dann passt das für mein Ziel. Klar, ideal wäre eine geschmeidige Integration in den Editor, so dass bei jedem Speichern formatiert wird. Ist verschmerzbar.
 
ideal wäre eine geschmeidige Integration in den Editor,

ich kenne DreamWeaver nciht, aber wenn du damit im HTML-Code direkt arbeitest, dann probiere doch mal Visual Studio Code. Dafür gibt es so ziemlich alles an Plugins und Prettifiern was man sich vorstellen kann. ABER, es ist zwar ein GUI-Tool, aber so mächtig, dass es schon einiges braucht um alle Möglichkeiten zu erkennen. Und, es ist ein Editor, keine HTML-Generierer oder so.
 
Danke für den Hinweis zu Visual Studio Code. Aber es gibt Gründe für die Nutzung von Dreamweaver. Das möchte ich aber hier nicht vertiefen.
Ja, ich arbeite in DW - auch - im Code.

prettier habe ich jetzt erfolgreich mit der Option "--single-attribute-per-line=true" ausprobiert.

Resultat:


Code:
<html>
  <body
    class="foo"
    id="bar"
  >
    <p>Hello World!</p>
  </body>
</html>

Also ganz so elegant wie im Artikel aus dem Ausgangsposting

Code:
<html>
  <body class="foo"
        id="bar">
    <p>
      Hello World!
    </p>
  </body>
</html>

oder gar

Code:
<html>
  <body class="foo
               zot"
        id="bar">
    <p>
      Hello World!
    </p>
  </body>
</html>

wird nicht umbrochen, aber irgendwas ist immer, klar.

Mein eigener Favorit für Attribute und Werte wäre übrigens:


Code:
<html>
  <body class="foo"
           id="bar">
    <p>
      Hello World!
    </p>
  </body>
</html>

Aber das habe ich noch nirgends gesehen.

Also erstmal vielen Dank für eure Antworten hier.
Ich werde erstmal prettier verwenden - bis ich bezüglich Umbruch von Attributen noch was Besseres finde.

Eine Option zum Normalisieren der Abfolge von "&nbsp; " oder " &nbsp;" zu "&nbsp;" (etc.) wird nicht angeboten. Das muss man also weiter händisch tun.
 
Zuletzt bearbeitet:
Übergabe von Optionen via Konfigurationsdatei ".prettierrc" klappt auch.

Funktioniert also alles prima. Und Prettier hat wirklich gute Defaults.

Ich werde mich noch einlesen in die Möglichkeiten - bei fehlender Integration in den Editor - dennoch einen automatisierten Ablauf zu realisieren.
https://prettier.io/docs/en/watching-files.html

Das habe ich noch nicht verstanden. Vermutlich führt aber so eine Methode dazu, dass nach jedem Speichern im Editor eine weitere Bestätigung im Editor erfolgen müsste: "Die Datei wurde außerhalb des Editors verändert, soll sie neu geladen werden." Das wäre nicht praxistauglich.

Weiterhin werde ich nach einem bequemen Weg suchen, einen Terminalbefehl (hier "npx prettier ...") mit einem Klick zu starten, während ich im Editor bin.
 
Zurück
Oben Unten