diff options
Diffstat (limited to 'files/nl/learn/html/introduction_to_html/debugging_html/index.html')
| -rw-r--r-- | files/nl/learn/html/introduction_to_html/debugging_html/index.html | 162 |
1 files changed, 0 insertions, 162 deletions
diff --git a/files/nl/learn/html/introduction_to_html/debugging_html/index.html b/files/nl/learn/html/introduction_to_html/debugging_html/index.html deleted file mode 100644 index 3e961f9e5d..0000000000 --- a/files/nl/learn/html/introduction_to_html/debugging_html/index.html +++ /dev/null @@ -1,162 +0,0 @@ ---- -title: HTML debuggen -slug: Learn/HTML/Introduction_to_HTML/Debugging_HTML -translation_of: Learn/HTML/Introduction_to_HTML/Debugging_HTML -original_slug: Learn/HTML/Introduction_to_HTML/HTML_Debuggen ---- -<div>{{LearnSidebar}}</div> - -<div>{{PreviousMenuNext("Learn/HTML/Introduction_to_HTML/Document_and_website_structure", "Learn/HTML/Introduction_to_HTML/Marking_up_a_letter", "Learn/HTML/Introduction_to_HTML")}}</div> - -<p class="summary">HTML schrijven is oké maar wat als er iets fout gaat en je kan er maar niet achter komen waar de fout in je code zit? In dit artikel zullen we je kennis laten maken met een aantal instrumenten die je kunnen helpen om de fouten in je HTML op te sporen en te herstellen.</p> - -<table class="learn-box standard-table"> - <tbody> - <tr> - <th scope="row">Vereisten:</th> - <td>Basiskennis HTML zoals die is aangeboden in <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/Getting_started">Beginnen met HTML, HTML tekst: basisprincipes</a> en <a href="/en-US/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks">Hyperlinks maken</a>.</td> - </tr> - <tr> - <th scope="row">Objective:</th> - <td>Je verwerft basiskennis over het gebruik van debugging-instrumenten waarmee je de bron van problemen in HTML kan vinden.</td> - </tr> - </tbody> -</table> - -<h2 id="Van_debuggen_hoef_je_niet_bang_te_zijn">Van debuggen hoef je niet bang te zijn</h2> - -<p>Als je de één of andere code zit te schrijven, is alles meestal dik in orde, tot het gevreesde moment waarop een fout zich voordoet. Je hebt dus iets verkeerd gedaan zodat je code niet werkt — of hij doet het helemaal niet of toch niet helemaal zoals jij dat wil. Hieronder vind je bijvoorbeeld een foutmelding die verschijnt wanneer men een simpel programma probeert te {{glossary("compileren")}} in de <a href="https://www.rust-lang.org/">Rust</a>-taal.</p> - -<p><img alt="A console window showing the result of trying to compile a rust program with a missing quote around a string in a print statement. The error message reported is error: unterminated double quote string." src="https://mdn.mozillademos.org/files/12435/error-message.png" style="display: block; height: 520px; margin: 0px auto; width: 711px;">Hier is de foutmelding vrij gemakkelijk te begrijpen — "unterminated double quote string" (niet afgesloten dubbele aanhalingstekens string). Als je de lijst bekijkt, zie je waarschijnlijk hoe <code>println!(Hello, world!")</code> een dubbel aanhalingsteken mist. Foutmeldingen kunnen echter snel een stuk ingewikkelder worden en minder gemakkelijk om te interpreteren omdat programma's groter worden en zelfs simpele gevallen kunnen nogal intimiderend overkomen bij iemand die niets over Rust weet. </p> - -<p>Toch hoeft debuggen niet angstaanjagend te zijn. De sleutel tot een comfortabel gevoel bij het schrijven van code, is je vertrouwdheid met de taal en de instrumenten die hij aanbiedt.</p> - -<h2 id="HTML_en_debuggen">HTML en debuggen</h2> - -<p>HTML is niet zo complex en makkelijker te begrijpen als Rust. HTML wordt niet eerst in een andere vorm gecompileerd voor de browser die ontleedt en het result toont. HTML wordt <em>geïnterpreteerd</em>, niet <em>gecompileerd</em> en HTML's {{glossary("element")}} syntaxis is een stuk makkelijker te begrijpen dan een "echte programmeertaal" zoals Rust, {{glossary("JavaScript")}} of {{glossary("Python")}}. De manier waarop browsers HTML ontleden (i.e. parsen in het Engels) is veel <strong>toleranter </strong>dan de wijze waarop programmeertalen worden uitgevoerd, wat zowel goed als slecht is.</p> - -<h3 id="Tolerante_code">Tolerante code</h3> - -<p>Dus wat bedoelen we met tolerant? Wel, als je iets fout doet in je code, zal je een aantal fouten tegenkomen. De twee voornaamste zijn :</p> - -<ul> - <li><strong>Syntactische fouten</strong>: Deze zijn spelfouten in je code die ervoor zorgen dat je programma niet wordt uitgevoerd, zoals de Rust fout die we hierboven hebben getoond. Deze kan je meestal makkelijk herstellen als je vertrouwd bent met de syntaxis van de taal en als je weet wat de foutmeldingen betekenen.</li> - <li><strong>Logische fouten</strong>: Dit zijn fouten waarbij de syntaxis correct is maar de code is niet wat je eigenlijk wil, wat inhoudt dat het programma niet correct wordt uitgevoerd. Deze zijn vaak veel moeilijker te repareren dan syntactische fouten omdat er geen foutmelding is die je naar de bron van de fout leidt.</li> -</ul> - -<p>HTML zelf lijdt niet onder syntactische fouten omdat browsers HTML op een tolerante manier ontleden (d.w.z. parsen). Dit houdt in dat de pagina zal worden weergegeven zelfs als er syntactische fouten in zitten. Browsers hebben ingebouwde regels die zeggen hoe ze incorrect geschreven opmaak moeten interpreteren zodat je pagina toch wordt uitgevoerd al ziet die er misschien niet uit zoals je verwacht. Dit kan naturlijk nog altijd een groot probleem zijn!</p> - -<div class="note"> -<p><strong>Opmerking</strong>: HTML wordt tolerant geparst. Toen het web namelijk werd gecreëerd, werd er beslist dat het belangrijker was dat mensen hun inhoud konden publiceren dan er zeker van te zijn dat de syntaxis volledig correct was. Het web zou waarschijnlijk niet zo populair zijn, als het vanaf het begin stricter was geweest.</p> -</div> - -<h3 id="Actief_leren_De_studie_van_tolerante_code">Actief leren: De studie van tolerante code</h3> - -<p>Het is tijd om de tolerante aard van HTML-code te bestuderen</p> - -<ol> - <li>Eerst download je ons <a href="https://github.com/mdn/learning-area/blob/master/html/introduction-to-html/debugging-html/debug-example.html">debug-example demo</a> en sla je die locaal op. Deze demo is opzettelijk met fouten erin geschreven die we kunnen onderzoeken (we zeggen dat de HTML-opmaak <strong>slecht is gevormd</strong> in tegenstelling tot <strong>goed gevormd</strong>).</li> - <li>Vervolgens open je de demo in een browser. Die zal er ongeveer zo uitzien:<img alt="A simple HTML document with a title of HTML debugging examples, and some information about common HTML errors, such as unclosed elements, badly nested elements, and unclosed attributes. " src="https://mdn.mozillademos.org/files/12437/badly-formed-html.png" style="display: block; margin: 0 auto;"></li> - <li>Dat ziet er niet echt geweldig uit. We gaan daarom de broncode bekijken en zien of we erachter kunnen komen waarom dat zo is (enkel de inhoud van de body wordt getoond): - <pre class="brush: html"><h1>HTML debugging voorbeelden</h1> - -<p>Wat veroorzaakt er fouten in HTML? - -<ul> - <li>Elementen die niet zijn afgesloten : als een element <strong>niet correct word afgesloten, - dan kan zijn effect zich uitbreiden naar gebieden die daarvoor niet zijn bedoeld - - <li>Slecht geneste elementen: Het is ook belangrijk om je elementen correct te nesten - zodat je code zich correct gedraagt. <strong>strong <em>sterk benadrukt?</strong> - wat is dat?</em> - - <li>Attributen die niet zijn gesloten : Nog een vaak voorkomende bron van problemen met HTML. Laat ons - daarvoor een voorbeeld bekijken: <a href="https://www.mozilla.org/>link naar de homepage van - Mozilla</a> -</ul></pre> - </li> - <li>We gaan deze problemen nu één voor één bekijken: - <ul> - <li>De {{htmlelement("p","paragraaf")}} en {{htmlelement("li","lijstonderdeel")}}-elementen hebben geen eindtags. Als je naar de afbeelding hierboven kijken, zie je dat dit de weergegeven opmaak niet zo erg beïnvloedt want het is makkelijk om te zien waar een element zou moeten stoppen en een ander beginnen.</li> - <li>Het eerste {{htmlelement("strong")}} element heeft geen eindtag. Dit is iets problematischer want het is niet zo gemakkelijk om te weten waar het element zou moeten eindigen. In feite is de rest van de tekst sterk benadrukt. </li> - <li>Een van de secties is slecht genest: <code><strong>strong <em>sterk benadrukt emphasised?</strong> wat is dat?</em></code>. Het is niet gemakkelijk om te zeggen hoe dit is geïnterpreteerd door het vorige probleem.</li> - <li>De {{htmlattrxref("href","a")}}-attribuutwaarde mist een dubbel aanhalingsteken. Dat heeft blijkbaar het grootste probleem veroorzaakt — de link is gewoon niet weergegeven.</li> - </ul> - </li> - <li>We kunnen nu ook de opmaak bekijken die de browser heeft gegenereerd in plaats van de opmaak in de broncode. Om dat te doen, kunnen we de hulpprogramma's voor ontwikkelaars bekijken (de browser developer tools in het Engels). Als je niet vertrouwd bent met het gebruik van deze programma's kan je er meer over leren. Neem een paar minuten de tijd en bekijk <a href="/en-US/docs/Learn/Discover_browser_developer_tools">Discover browser developer tools</a>.</li> - <li>Met de DOM Inspecteur kan je zien hoe de weergegeven opmaak eruit ziet: <img alt="The HTML inspector in Firefox, with our example's paragraph highlighted, showing the text "What causes errors in HTML?" Here you can see that the paragraph element has been closed by the browser." src="https://mdn.mozillademos.org/files/12439/html-inspector.png" style="display: block; margin: 0 auto;"></li> - <li>Met de DOM inspecteur kunnen we onze code in detail onderzoeken en zien hoe de browser heeft geprobeerd om onze HTML-fouten te herstellen. We hebben dat in Firefox gedaan; andere moderne browsers <em>zouden</em> hetzelfde resultaat moeten produceren: - <ul> - <li>De paragrafen en de lijstonderdelen hebben eindtags gekregen.</li> - <li>Het is niet duidelijk waar het eerste <code><strong></code>-element zou moeten worden gesloten, dus heeft de browser elke apart tekstblok in zijn eigen strong-tag ingesloten, helemaal tot aan de onderkant van het document!</li> - <li>De incorrect geneste element zijn door de browser op deze manier hersteld: - <pre class="brush: html"><strong>sterk - <em>sterk benadrukt</em> -</strong> -<em> wat is dat?</em></pre> - </li> - <li>De link met het ontbrekende dubbele aanhalingsteken is helemaal verwijderd. Het laatste lijstonderdeel ziet er zo uit: - <pre class="brush: html"><li> - <strong>Attributen die niet zijn afgesloten: Een andere vaak voorkomende bron van HTML-problemen. - Laat ons daarvoor een voorbeeld bekijken: </strong> -</li></pre> - </li> - </ul> - </li> -</ol> - -<h3 id="HTML_validatie">HTML validatie</h3> - -<p>Door het voorbeeld hierboven begrijp je dat je er echt zeker van wil zijn dat je HTML goed gevormd is. Maar hoe doe je dat? In een klein voorbeeld zoals dat hierboven, is het gemakkelijk om de fouten te vinden, maar wat moet met je een enorm en complex HTML document? </p> - -<p>De beste strategie is om je HTML-pagina eerst door de <a href="https://validator.w3.org/">Markup Validation Service</a> (Opmaak Validatie Dienst) te laten beoordelen. Deze dienst is gecreëerd door de W3C en word er ook door onderhouden. De organisatie zorgt voor de specificaties die HTML, CSS en andere webtechnologieën definiëren. De webpagina aanvaardt je HTML als invoer, verwerkt die en geeft je dan een verslag waarin staat wat er mis is met je HTML.</p> - -<p><img alt="The HTML validator homepage" src="https://mdn.mozillademos.org/files/12441/validator.png" style="display: block; margin: 0 auto;"></p> - -<p>Om de HTML in te voeren de je wil laten valideren, kan je een webadres opgeven, een HTML-bestand uploaden of de HTML-code direct invoeren.</p> - -<h3 id="Actief_leren_Een_HTML-document_valideren">Actief leren: Een HTML-document valideren</h3> - -<p>We gaan dit met ons <a href="https://github.com/mdn/learning-area/blob/master/html/introduction-to-html/debugging-html/debug-example.html">sample document</a> uitproberen.</p> - -<ol> - <li>Eerst laad je de <a href="https://validator.w3.org/">Markup Validation Service</a> in een tabblad van een browser, als je dat nog niet hebt gedaan.</li> - <li>Klik op <a href="https://validator.w3.org/#validate_by_input">Validate by Direct Input</a>.</li> - <li>Kopiëer de volledige code van het sample document (dus niet enkel de body) en plak die in het tekstinvoerveld.</li> - <li>Klik op de <em>Check</em> knop.</li> -</ol> - -<p>Nu zou je een lijst met fouten en andere informatie moeten zien.</p> - -<p><img alt="A list of of HTML validation results from the W3C markup validation service" src="https://mdn.mozillademos.org/files/12443/validation-results.png" style="display: block; margin: 0 auto;"></p> - -<h4 id="De_interpretatie_van_de_foutmelding">De interpretatie van de foutmelding</h4> - -<p>Al zijn de foutmeldingen meestal een hulp, soms zijn ze dat toch niet helemaal maar met een beetje oefening kan je erachter komen hoe je ze moet interpreteren om je code te repareren. We gaan ze nu één voor één bekijken en hun betekenis ontcijferen. Je zal merken dat elke boodschap een regel en kolomnummer krijgt zodat je kan zien waar de fout zich bevindt.</p> - -<ul> - <li>"End tag <code>li</code> implied, but there were open elements" (2 instances): (eindtag li geïmpliceerd maar er waren open elementen (twee gevallen)). Deze boodschappen duiden aan dat een element nog open is en gesloten moet worden. De eintag is geïmpliceerd maar staat er niet echt. De regel/kolom informatie wijst naar de eerste regel na de regel waar de eindtag eigenlijk zou moeten zijn, maar deze aanwijzing is goed genoeg om te zien wat er fout is.</li> - <li>"Unclosed element <code>strong</code>" (niet gesloten element strong) : Dit is echt makkelijk te begrijpen — een {{htmlelement("strong")}}-element is niet afgesloten en de lijn/kolom informatie wijst recht naar de plaats van het element.</li> - <li>"End tag <code>strong</code> violates nesting rules" (eind tag strong schendt regels voor geneste elementen): Dit verwijst naar de incorrect geneste elementen en de regel/kolom informatie wijst naar waar die zitten.</li> - <li>"End of file reached when inside an attribute value. Ignoring tag" (einde van het bestand is bereikt binnen een attribuutwaarde): Deze is vrij cryptisch; hij verwijst naar het feit dat er ergens een attribuutwaarde zit die niet correct werd gevormd, misschien dicht bij het einde van het bestand want het einde van het bestand verschijnt binnen de attribuutwaarde. Het feit dat de browser de link niet weergeeft, is een goede aanwijzing die ons vertelt welk element de fout bevat.</li> - <li>"End of file seen and there were open elements" (einde van het bestand gezien en er waren open elementen) : Dit is een beetje dubbelzinnig, maar in feite verwijst de foutmelding naar het feit dat er open elementen zijn die moeten worden gesloten. De regelnummers wijzen naar de laaste regels van het bestand en deze foutmelding verschijnt samen met een regel code die een voorbeeld van een open element aanduidt: - <pre>example: <a href="https://www.mozilla.org/>link naar de startpagina van Mozilla homepage</a> ↩ </ul>↩ </body>↩</html></pre> - - <div class="note"> - <p><strong>Opmerking</strong>: Een attribuut dat het aanhalingsteken mist dat de attribuutwaarde afsluit, kan resulteren in een open element omdat de rest van het document wordt geïnterpreteerd als de inhoud van het attribuut.</p> - </div> - </li> - <li>"Unclosed element <code>ul</code>" (niet afgesloten element ul): Dit is niet erg behulpzaam omdat het {{htmlelement("ul")}}-element wel degelijk correct is afgesloten. Dese fout verschijnt omdat het {{htmlelement("a")}}-element niet is afgesloten en dat komt door het ontbrekende aanhalingsteken op het einde van de attribuutwaarde.</li> -</ul> - -<p><span>Als je niet de betekenis van elke foutmelding kan uitdokteren, hoef je je daarover niet te veel zorgen te maken — het is een goed idee om niet alle fouten tegelijk te herstellen. Bewerk er een paar en probeer dan opnieuw je HTML te valideren en kijk welke fouten er nog over schieten. Soms is het genoeg om één fout weg te werken. De rest van de fouten verdwijnt dan vanzelf omdat meerdere fouten door één enkel probleem veroorzaakt kunnen worden. Het probleem creëert dan een domino-effect.</span></p> - -<p><span>Als alle fouten hersteld zijn, zal je de volgende tekst met groene achtergrond in je uitvoer zien. Dit is de vertaling: het document is gevalideerd volgens de gespecifiëerde schema's en volgens bijkomende beperkingen die door de validator zijn gecontroleerd. </span></p> - -<p><img alt='Banner that reads "The document validates according to the specified schema(s) and to additional constraints checked by the validator."' src="https://mdn.mozillademos.org/files/12445/valid-html-banner.png" style="display: block; margin: 0 auto;"></p> - -<h2 id="Samenvating">Samenvating</h2> - -<p>En dat is het dus, een inleiding op het debuggen van HTML. Je zou nu een paar nuttige vaardigheden onder de knie moeten hebben. Je zal er later in je carrière op kunnen rekenen wanneer je CSS, Javascript en andere soorten code gaat debuggen. Dit betekent ook het einde van onze introductie op HTML — Je kan nu verder gaan door jezelf te testen met onze evaluaties: de link naar de eerste vind je hieronder.</p> - -<p>{{PreviousMenuNext("Learn/HTML/Introduction_to_HTML/Document_and_website_structure", "Learn/HTML/Introduction_to_HTML/Marking_up_a_letter", "Learn/HTML/Introduction_to_HTML")}}</p> |