Ik bouw tools voor de kost, en het meest voorkomende dat ik doe voordat ik iemand lees' s front end is hun HTML door een formatter te laten lopen Server templates spit markup uit op één regel Bundlers vouwen het in Een fragment dat iemand in Slack plakt, komt met drie niveaus van nesten platgedrukt in een muur van hoekhaken Ik kan niet debuggen wat ik niet kan lezen, dus de eerste zet is altijd hetzelfde: plak het in, raak verfraaien, en laat de structuur zich openbaren Deze gids is degene waarvan ik wou dat ik het mijn jongere zelf had overhandigd, die vroeger de markup met de hand opnieuw insprak en het de helft van de tijd verkeerd had.
tl;dr: Een HTML-formatter geeft de opmaak opnieuw aan, zodat u de structuur ervan kunt lezen en verkleint deze weer zodat deze klein wordt verzonden. Gebruik verfraaien terwijl u aan het bouwen en debuggen bent, minify voor productie. De HTML Formatter op Toolz.dev doet beide in uw browser, houdt uw script, stijl, en pre content byte-voor-byte, en nooit uploadt een ding.
Wat is een HTML-formatter?
Een HTML-formatter is een tool die je opmaak in zijn tagboom parseert en terugprint met consistente inspringing, één niveau per nestdiepte Dat is de verfraaiingsrichting Het omgekeerde, minify, ontdoet de onbeduidende witruimte tussen tags zodat het bestand zo klein mogelijk is zonder te veranderen hoe een browser het weergeeft De meeste goede opmaakapparaten, waaronder die op Toolz.dev, doen beide vanuit dezelfde invoer.
Het woord "insignificant" is echt werk aan het doen in die zin In HTML is sommige witruimte belangrijk en sommige niet De nieuwe regel en twee spaties die je tussen een afsluiting plaatst </li> en de volgende <li> wijzig niets aan de weergegeven pagina, dus een formatter is vrij om ze toe te voegen, te verwijderen of te normaliseren. Maar de spaties binnenin a <pre> blok, of de enkele spatie tussen twee inline <a> elementen, zijn onderdeel van wat de gebruiker ziet Een formatter die dat verschil niet begrijpt zal je lay-out met plezier breken Dit is de lijn tussen een formatter die helpt en een die je leert wantrouwen.
Als u gebruikt heeft Prettier in uw editor kent u het gevoel al: u geeft niet meer om inspringen omdat een tool dit garandeert Een browsergebaseerde opmaakmaker geeft u dezelfde garantie voor eenmalige fragmenten, gegenereerde uitvoer en markup die u niet beheert, zonder een project in te stellen.
Waarom eindigt HTML überhaupt rommelig?
Het helpt om te weten waar de rommel vandaan komt, omdat het je vertelt wat een formatter moet overleven.
De eerste bron is server rendering Een PHP-sjabloon, een Rails-weergave of een Blade-bestand zendt HTML uit met welke witruimte de sjabloon-engine ook voelde produceren, en na minificatie middleware draait het vaak een enkele regel van duizenden tekens lang Wanneer er iets mis ziet in de browser en u op & quot; Bron bekijken, & quot; dat is wat u krijgt.
De tweede bron is kopiëren en plakken Je pakt een component uit een ontwerpsysteem, een fragment uit een CMS, of een e-mailsjabloon die iemand je heeft gestuurd, en het heeft de afstand tussen de bron die wordt gebruikt: gemengde tabbladen en spaties, inconsistente nesten, achterliggende witruimte Ik breng een groot deel van mijn week door in WordPress en headless CMS-uitvoer, en CMS-gegenereerde opmaak is een van de ergste, omdat het is samengesteld uit fragmenten die elk anders zijn geformatteerd.
De derde bron is gegenereerde markup Bouw tools, WYSIWYG editors, en export functies produceren HTML die nooit bedoeld was om gelezen te worden door een mens Het is correct, maar het is ondoorzichtig Een formatter maakt het weer om in iets dat je kunt controleren.
De rode draad is dat geen van deze bronnen het uitmaakt of je het resultaat kunt lezen Dat is jouw taak, en een formatter is de snelste manier om het te doen.
Hoe formatteer ik HTML online?
De workflow op Toolz.dev duurt ongeveer tien seconden
- Open de HTML Formatter en plak je opmaak in het invoerpaneel Het maakt niet uit of het op één regel is ingesprongen, inconsistent ingesprongen of op een kaal fragment.
- Kies Verfraaien om het uit te breiden of Minify om het te comprimeren.
- Kies voor verfraaiing uw inspringing: 2 spaties, 4 spaties of tabbladen. Twee spaties zijn de gebruikelijke webstandaard.
- Optioneel vink " Reacties en quot verwijderen; om HTML-opmerkingen uit de uitvoer te verwijderen.
- Kopieer het resultaat of download het als een
.htmlbestand.
Alles draait clientzijde De parser is JavaScript in je browser, dus de markup raakt nooit een server Dat doet er meer toe dan men aanneemt, waar ik nog op terugkom.
Wat is het verschil tussen verfraaien en minificeren?
Dit zijn tegengestelde bewerkingen die een parser delen, en weten wanneer je naar elk bewerkingen moet reiken, is de meeste vaardigheid.
Verfraaien is voor mensen Het voegt regeleindes en inkepingen toe zodat het nestelen zichtbaar is, wat je wilt tijdens het bewerken, debuggen, verspreiden van twee versies of het beoordelen van een pull-verzoek. Wanneer ik op een lay-outbug jaag, verfraai ik eerst zodat ik kan zien welk element niet gesloten is of een niveau te diep genest is.
Minifying is voor machines Het verwijdert de witruimte die een browser negeert zodat het bestand kleiner en sneller over te zetten is U minify HTML om dezelfde reden waarom u CSS of JavaScript minify: bytes over de draad kost tijd, en op een grote pagina de witruimte telt op Als u al leunt op de html-minifier voor productiecompressie is de formatter het hulpmiddel dat u gebruikt om die uitvoer opnieuw te lezen wanneer er iets kapot gaat.
Hier ziet u hoe de twee richtingen zich verhouden tot de beslissingen die feitelijk verschillen:
| Aspect | mooi maken | klein worden |
|---|---|---|
| doelwit | leesbaarheid | Kleinste bestand |
| Witruimte tussen tags | Toegevoegd en genormaliseerd | vergelgen |
| Uitvoergrootte | Groter | Kleinere |
| Wanneer te gebruiken? | Bewerken, debuggen, beoordelen | Productie, overdracht |
| Inspringing | 2 spaties, 4 spaties of tabbladen | niet een |
| Gesmolten resultaat | volkomen hetzelfde | volkomen hetzelfde |
De laatste rij is de belangrijke Geen van beide bewerkingen verandert hoe de pagina eruit ziet Alleen de witruimte die een browser als onbeduidende wijzigingen behandelt Als een formatter ooit uw weergegeven uitvoer wijzigt, is dat een bug in de formatter, geen eigenschap van formatteren.
Zal de opmaak mijn JavaScript, CSS of vooraf opgemaakte tekst verbreken?
Dit is de vraag die speelgoed van een gereedschap scheidt, en het is de reden dat ik kieskeurig ben over welke formatter ik gebruik.
Bepaalde elementen bevatten inhoud waar witruimte en karakters significant zijn en mogen niet worden aangeraakt. De WHATWG HTML-standaard classificeert script en style als ruwe tekstelementen en textarea en title als escapable ruwe tekst elementen Daarin moet een formatter de inhoud als ondoorzichtig behandelen, Als het probeert het JavaScript opnieuw te laten inspringen in een script tag, het kan de inhoud van een sjabloon letterlijk verschuiven, een reguliere expressie veranderen, of een regel binnen een meerregelige tekenreeks verplaatsen, en nu gedraagt uw code zich anders Dat is geen opmaakwijziging, dat is een bug die de opmaakmaker heeft geïntroduceerd.
de pre element is een verwant geval Het hele doel is om witruimte te behouden, dus de tekstinhoud wordt precies weergegeven zoals geschreven. Een opmaakmachine die binnenin opnieuw wordt aangegeven <pre> verandert zichtbaar de pagina.
De Toolz.dev-formatter verwerkt deze allemaal door te behandelen script, style, pre, textarea, en title als ruwe content: het geeft de HTML om hen heen opnieuw een invoeging maar kopieert hun binnenste tekst woordelijk Je code en voorgevormde tekst komen byte-voor-byte identiek uit Toen ik dit testte tijdens het bouwen, was de acceptatiebalk eenvoudig: a <script> bevattende if(a<b){x=1} moet onaangeroerd overleven, en dat doet het. Als u werkt met een opmaak die inline scripts of stijlen bevat, is dit de eigenschap die u moet controleren voordat u een opmaakmaker vertrouwt.
Kan een opmaakster kapotte of onvolledige HTML aan?
Echte HTML is zelden goed gevormd zoals XML is, en een formatter die perfectie vereist is nutteloos Browsers zijn beroemd tolerant: de HTML parsing algoritme definieert precies hoe om te gaan met weggelaten eindtags en verkeerd geneste elementen, daarom ontbreekt een pagina </li> geeft nog steeds prima weer Een goede opmaakster leent dezelfde tolerantie.
Het meest voorkomende geval is optionele eindtags Met HTML kunt u de afsluitende tag op elementen zoals li, p, td, tr, en option, omdat de specificatie een open zegt li is impliciet gesloten wanneer de volgende li begint. Dus <ul><li>a<li>b</ul> is geldig, en de Toolz.dev-formatter past deze impliciet-dichte regels toe om te produceren <li>a</li> en <li>b</li> op hun eigen lijnen, precies zoals een browser de boom zou bouwen. A <p> wordt automatisch gesloten wanneer er een blokelement in wordt geopend, omdat een alinea geen blokinhoud kan bevatten.
Het tweede geval is echt gebroken markup: een tag geopend en nooit gesloten, of een verdwaalde afsluitende tag zonder overeenkomende open De opmaakmaker sluit alles wat nog bungelt aan het einde van het document en rapporteert het als een waarschuwing, dus je weet dat de invoer onvolledig was in plaats van stil te raden Die waarschuwingen zijn vaak de snelste manier om de exacte bug te vinden die je kwam repareren.
Vergelijk dat gedrag met een strenge opmaakster, en tegen het met de hand doen van
| toegang | Weggelaten eindtags | Niet-gesloten tags | tempo |
|---|---|---|---|
| Tolerante opmaakmachine (Toolz.dev) | Past impliciet-dichte regels toe | Automatisch sluit en waarschuwt | nadrukkelijk |
| Strikte XML-stijl opmaak | Vaak fouten eruit | Fouten eruit | Direct als het werkt |
| Handmatige herinspringing | Je volgt het zelf | Makkelijk te missen | Langzaam en foutgevoelig |
Ik zat vroeger op die onderste rij, waar ik met de hand weer insprong en een niet-gesloten exemplaar miste div drie keer op tien Het tolerante gereedschap wint omdat echte markup rommelig is en je wilt dat de puinhoop boven water komt, niet afgewezen.
Wanneer moet ik een opmaakapparaat gebruiken versus mijn editor?
Als u eigenaar bent van het bestand en het bevindt zich in uw project, dan is uw editor plus Prettier of een equivalent de juiste thuisbasis voor het formatteren, omdat het op save draait en consistent blijft in het hele team Ik stel niet voor dat u dat vervangt.
Een browser-gebaseerde formatter verdient zijn plaats in de gaten die workflow achterlaat U plakt een fragment uit een bugrapport en moet het nu meteen lezen U bevindt zich op een machine die niet uw dev box is U kijkt naar CMS-uitvoer, een e-mailsjabloon of gegenereerde markup die nooit in een repo heeft geleefd U wilt een enkel fragment minifiëren zonder een build-stap te bedraden In al die gevallen is het openen van een tab sneller dan het configureren van een project, en het resultaat is hetzelfde.
Er is ook de privacyhoek, die niet een kleinigheid is Omdat de Toolz.dev parser volledig in uw browser draait, markup die interne URL's, onuitgegeven kopie, API-reacties ingebed in een sjabloon, of een klant bevat' s gegevens nooit uw apparaat verlaten Veel online formatters POST uw invoer naar een server om het werk te doen Voor alles van een werkcodebase, dat is een gegevensblootstelling die u niet hoeft te nemen Ik geef hier genoeg om dat het een ontwerpregel is voor elke tool op de site, waarover ik meer schreef in de Webontwikkelaar Toolkit en de gids voor Gegevensprivacy in online tools.
Een praktische workflow die mij uren heeft bespaard
Hier is de lus die ik eigenlijk uitvoer als een lay-out zich misdraagt Verfraai de markup zodat de nesting zichtbaar is Scan de inspringing voor het niveau dat er verkeerd uitziet, want een verdwaalde extra inspringing betekent bijna altijd een tag die nooit gesloten is Lees de waarschuwingen van de opmaakster, die vaak het exacte niet-gesloten element noemen Fix het in de bron Als het fragment bestemd is voor productie, minifieer het op de terugweg naar buiten De hele cyclus is een minuut, en het grootste deel van die minuut lees ik, niet vechten tegen de tool.
Dezelfde lus werkt voor content audits Wanneer ik markup check op toegankelijkheid of SEO, verfraai ik eerst zodat ik de kopstructuur en oriëntatiepuntelementen in één oogopslag kan zien, dan trek ik specifieke stukken in andere tools: een chunk omzetten naar Markdown voor documentatie met de HTML naar markdown converter, of het genereren van een vergelijkingstabel met de Markdown-tabelgenerator. Formatteren is de stap die de structuur leesbaar genoeg maakt om mee te werken. Als je de bredere routine wilt waarin deze tools passen, is de Productiviteitstools voor ontwikkelaar gids legt het uit.
Veelgestelde vragen
Hoe formatteer ik HTML online?
Plak je HTML in het invoerpaneel, kies Verfraaien, kies een inspringbreedte en klik op Opmaak De tool parseert de tagboom en splitst deze opnieuw in, waarna je het resultaat kunt kopiëren of downloaden Alle verwerking gebeurt in je browser, dus er wordt niets geüpload.
Wat is het verschil tussen HTML verfraaien en minificeren?
Verfraaien voegt regeleindes en inspringing toe zodat het nestelen gemakkelijk te lezen is, wat ideaal is voor bewerken en debuggen Minifying verwijdert de onbeduidende witruimte tussen tags om een kleiner bestand voor productie te produceren Beide behouden hetzelfde weergegeven resultaat; alleen de witruimte verandert.
Zal de opmaak de manier veranderen waarop mijn pagina eruit ziet?
Nee. De opmaakmachine verandert alleen de witruimte tussen tags, niet de elementen, attributen of tekst Inhoud waarbij witruimte significant is, zoals pre, tekstgebied en inline tekst, blijft behouden, dus een pagina geeft hetzelfde weer voor en na het opmaken.
Herformatteert de formatter mijn JavaScript en CSS?
Nee. Inhoud in script- en stijltags wordt behandeld als onbewerkte tekst en woordelijk gekopieerd. De tool geeft de HTML eromheen opnieuw aan, maar raakt nooit de code zelf aan, dus sjabloonletterlijke waarden, reguliere expressies en CSS-waarden blijven byte-voor-byte identiek.
Kan het kapotte of onvolledige HTML aan?
Ja, binnen redelijke grenzen De parser is tolerant: het past dezelfde impliciete sluitregels toe die browsers gebruiken voor tags als li, p en td, en het sluit automatisch tags die aan het einde van het document open zijn gelaten. Als dat het geval is, wordt er een waarschuwing weergegeven, zodat u weet dat de opmaak onvolledig was.
Is het veilig om HTML te formatteren die gevoelige gegevens bevat?
Ja. de parser draait volledig in JavaScript in uw browser Geen netwerkverzoek draagt uw markup, niets wordt opgeslagen, en de tool werkt offline eenmaal geladen HTML met interne links, API-reacties of niet-uitgebrachte kopie verlaat nooit uw machine.
Welke inspringmogelijkheden zijn er?
Verfraai uitvoer ondersteunt 2 spaties, 4 spaties, of tabbladen Twee spaties is de gebruikelijke standaard voor webprojecten, vier spaties past bij teams die een bredere inspringing verkiezen, en tabbladen laten elke ontwikkelaar zijn eigen weergavebreedte instellen in de editor.
Hoe verschilt een HTML-formatter van een HTML-minifier?
Een formatter heeft beide richtingen in één tool: verfraaien om markup uit te breiden voor het lezen, en minify om het in te klappen voor verzending Een speciale minifier comprimeert alleen Als je voornamelijk productiecompressie nodig hebt, richt de HTML minifier zich daarop; als je schakelt tussen lezen en verzenden, dekt de formatter beide.
Formatteer uw markup met de gratis HTML Formatter. Het draait volledig in uw browser, houdt uw scripts en vooraf opgemaakte inhoud intact en uploadt nooit een byte.
