HTML/XML-opmaker en -validator
Plak HTML of XML en krijg het netjes ingesprongen terug, met welgevormdheidsfouten (XML) of waarschuwingen voor niet-gesloten tags (HTML) gemarkeerd.
1.240 weergaven
Hoe het werkt
De opmaker doorloopt uw markup en houdt de nestdiepte bij terwijl het verdergaat: elke openings-tag verhoogt de dieptedeller met één niveau, elke bijbehorende sluitings-tag verlaagt deze weer. Elke uitvoerregel krijgt een aantal inspringeenheden dat evenredig is met de huidige diepte — een tag die één niveau diep zit krijgt één inspringeenheid, een tag die vier niveaus diep zit krijgt er vier, enzovoort. Tekstknooppunten, commentaar en attributen erven de diepte van het element dat ze bevat, zodat het eindresultaat de werkelijke boomstructuur van het document visueel weerspiegelt in plaats van een muur ononderbroken tekst.
Zo wordt bijvoorbeeld een krappe eenregelige code zoals <ul><li>A</li><li>B</li></ul> teruggegeven als <ul> op het hoogste niveau, met <li>A</li> en <li>B</li> elk één niveau ingesprongen, en de sluitende </ul> weer terug op het hoogste niveau — drie regels in plaats van één, en de diepte van elke regel direct afleesbaar aan de inspringing alleen. Lege elementen zoals <br> of <img> verhogen de dieptedeller nooit, omdat ze geen kinderen hebben om iets in te nestelen.
Goed om te weten
Kies XML-modus en de parser is strikt: elke schending van welgevormdheid — een niet-gesloten tag, verkeerde nesting, een ongeldig teken — wordt gemeld met een specifieke foutmelding in plaats van stilzwijgend hersteld te worden. Kies HTML-modus en de tool voert in plaats daarvan een best-effort tagbalanscontrole uit, omdat browsers zelf HTML soepel parseren en er geen equivalente harde "ongeldige" status is om te detecteren. Dit onderscheid weerspiegelt een echt verschil tussen de twee formaten: de XML-specificatie eist dat een document welgevormd is, of anders volledig wordt afgewezen, zonder tussenweg, terwijl HTML5 bewust zo is ontworpen dat kleine schrijffouten — zoals een vergeten sluitings-tag — de pagina niet breken. Die tolerante traditie is ook de reden waarom <br/> verplicht is in XML, terwijl <br> en <br/> in HTML allebei geldig en onderling verwisselbaar zijn.
Dit is nuttig, ver voorbij het opschonen van handgeschreven markup. Geminificeerde HTML die van een live pagina is opgehaald, een XML API-antwoord dat als één dichte regel wordt teruggegeven, of een configuratiebestand dat zonder enige opmaak is geëxporteerd — ze worden allemaal veel leesbaarder, en een verkeerd geplaatste tag valt veel sneller op, zodra diepte-gebaseerde inspringing wordt toegepast. Omdat de inspringing opnieuw wordt berekend vanuit de geparseerde structuur in plaats van te worden overgenomen uit de invoer, is de uitvoer consistent, hoe inconsistent de oorspronkelijke spatiëring ook was.
Veelgestelde vragen
Waarom vangt XML-modus fouten op die HTML-modus mist?
XML heeft een strikte welgevormdheidsspecificatie — de XML-parser van de browser wijst alles af wat deze schendt. HTML-parsing is bewust soepel (een kerndoel van het ontwerp, zodat het web niet breekt bij kleine fouten), dus is er geen equivalente harde fout — deze tool voert in plaats daarvan een best-effort tagbalanscontrole uit voor HTML.
Hoe bepaalt de tool hoeveel elke regel moet inspringen?
Het houdt de nestdiepte bij tijdens het parseren: het openen van een tag verhoogt de diepte met één, het sluiten ervan verlaagt deze met één, en elke regel wordt ingesprongen met een hoeveelheid die evenredig is met de diepte op dat moment. Een element dat drie niveaus diep in de boom zit, krijgt drie inspringeenheden, ongeacht hoe lang of kort de omliggende tags zijn.
Waarom is <br/> verplicht in XML maar optioneel in HTML?
XML heeft geen ingebouwd begrip van een "leeg" element — elke tag moet expliciet worden gesloten, hetzij met een aparte sluitings-tag, hetzij met de zelfsluitende schuine streep, anders is het document niet welgevormd. HTML5 definieert in plaats daarvan een vaste lijst van lege elementen (br, img, input, hr en andere) waarvan browsers al weten dat ze nooit kinderen bevatten, zodat zowel <code><br></code> als <code><br/></code> identiek worden geparseerd.
Verandert opmaak mijn inhoud?
Nee — alleen witruimte en inspringing veranderen. Tags, attributen, tekst en commentaar blijven exact behouden (attribuutwaarden worden voor de veiligheid opnieuw ge-escaped, wat alleen aanhalingstekens kan veranderen, nooit de waarde zelf).
Werkt dit op een diep geneste of geminificeerde document?
Ja — de op diepte gebaseerde aanpak maakt niet uit hoe de invoer oorspronkelijk was opgemaakt of hoe diep deze genest is; een geminificeerd bestand van één regel en een rommelig met de hand ingesprongen bestand leveren dezelfde nette uitvoer op, omdat de inspringing opnieuw wordt berekend vanuit de tagstructuur zelf in plaats van te worden overgenomen uit de invoer.
Vergelijkbare tools
Probleem melden
HTML/XML-opmaker en -validator
Reacties
Nog geen reacties — schrijf de eerste!