HyperText Markup Language is een eenvoudige markup-taal (markeertaal) die wordt gebruikt om platformonafhankelijke hypertekstdocumenten voor het World Wide Web te maken. De meeste hypertekstdocumenten op het web zijn in HTML geschreven.
Cascading Style Sheets vormen een op standaarden gebaseerd mechanisme voor het suggereren van weergavestijlen (bijv. lettertypes, kleuren, opmaak) voor HTML-documenten. CSS is flexibel en platformoversteigend, en is ontworpen om de toegankelijkheid van de gestructureerde inhoud van een document te bewaren (zelfs als de stylesheet van de auteur geheel of gedeeltelijk wordt genegeerd). Een enkele stylesheet kan door meerdere documenten worden gebruikt om een gezamenlijke consistente stijl aan te geven, wat efficiënter is dan het veelvuldig toepassen van presentationele markup in elk individueel document.
Standard Generalized Markup Language is een taal die wordt gebruikt om de syntax van markup-talen te definiëren. HTML is een SGML-toepassing (een markup-taal gedefineerd in SGML).
Extensible Markup Language is een andere taal die wordt gebruikt om de syntax van markup-talen te definiëren. XML is een deelverzameling van SGML, en is ontworpen om willekeurige gestructureerde gegevens in een tekstformaat op te slaan.
Extensible Hypertext Markup Language is een herformulering van HTML als een XML-toepassing. Omdat het een XML-toepassing is, zijn de syntax-vereisten van XHTML strenger dan die van HTML. Voor de rest weerspiegelt XHTML 1.0 de functionaliteit van HTML 4.01.
Met Server-Side Includes kunnen diverse opdrachten (bijv. om de inhoud van een ander bestand in te voegen) worden ingebed in webdocumenten. De webserver verwerkt SSI-opdrachten iedere keer als een document dat SSI gebruikt wordt opgehaald. Documenten die SSI gebruiken zijn vaak te herkennen aan een .shtml bestandsnaam-uitgang, maar "SHTML" is zelf geen taal. Implementatie-details variëren tussen de webservers; raadpleeg de serverdocumentatie voor details.
Common Gateway Interface is een standaard communicatielaag tussen externe programma's en webservers. In tegenstelling tot statische HTML-documenten, kunnen CGI-programma's dynamisch informatie produceren op basis van gegevens die door een gebruiker met een formulier zijn ingediend, op basis van informatie in een database, of op basis van andere gegevens die beschikbaar zijn voor het programma.
De huidige W3C Recommendation (aanbeveling) is XHTML 1.0, wat een herformulering van HTML als een XML 1.0-toepassing is. HTML 4.01 is een update met kleine verbeteringen op HTML 4.0. HTML 4.0 breidt HTML 3.2 uit met ondersteuning voor frames, internationalisatie, stylesheets, geavanceerde tabellen en meer. De nieuwe in HTML 4.0 geïntroduceerde markup wordt niet goed ondersteund door de huidige browsers, maar veel kan veilig worden gebruikt in niet ondersteunende browsers.
Aanbevolen teksten over HTML 4.0:
Aanbevolen teksten over HTML 3.2:
Enkele teksten met betrekking tot browserspecifieke versies van HTML:
Het lijkt erop dat iedereen een ander idee heeft over welk hulpmiddel voor hem het beste werkt. Lijsten met hulpmiddelen voor HTML-ontwerp zijn te vinden op:
Houd in je achterhoofd dat (in het algemeen) hoe minder HTML je hoeft te kennen om het hulpmiddel te gebruiken, des te slechter de geproduceerde HTML is. Oftewel, je kunt het altijd beter met de hand doen, zolang je de tijd neemt om een beetje HTML te leren.
Vervang binnen het HTML-voorbeeld eerst overal waar het voorkomt het "&" teken door "&". Vervang daarna op dezelfde manier het "<" teken door "<" en het ">" teken door ">".
De volgende Q&A behandelt het meer algemene geval van het weergeven van willekeurige tekens in HTML-documenten.
Het antwoord op de vorige vraag behandelde het speciale geval van het kleiner-dan-teken ('<'), het groter-dan-teken ('>') en de ampersand ('&'). In het algemeen is het het veiligst om HTML te maken met (7-bit) US-ASCII, en de tekens uit de bovenste helft van de 8-bit-code aan te geven met behulp van HTML-entities. Zie het antwoord op "Wat kan ik het beste gebruiken, &entitynaam; of &#nummer; ?".
Ook het werken met 8-bit tekens kan in veel praktijksituaties het gewenste resultaat hebben: Unix en MS-Windows (met gebruik van Latin-1), en ook de Mac (waarvoor enkele voorbehouden gelden).
De beschikbare tekens komen uit ISO-8859-1, opgesomd op <URL:http://www.htmlhelp.com/reference/charset/>. Dit zijn de enige tekens die breed worden ondersteund op het web. In het bijzonder zijn de tekens 128 tot en met 159, zoals gebruikt in MS-Windows, geen onderdeel van de ISO-8859-1 code-set, en worden ze niet weergegeven zoals Windows-gebruikers verwachten. Hieronder vallen de em-streep, en-streep, gekrulde aanhalingstekens, bullet, en het TM-symbool; het echte teken noch &#nnn; zijn correct. (Zie de laatste alinea van dit antwoord voor meer over deze tekens)
Op systemen die niet ISO-8859-1 als eigen tekenset hebben, zoals MS DOS en Macintosh, kunnen er problemen zijn: je zou tekst-transfermethodes moeten gebruiken die converteren tussen de tekenset van het systeem en ISO-8859-1 (bijv. Fetch voor de Mac), of apart converteren (bijv. GNU recode). Gebruik maken van 7-bit ASCII met entities voorkomt deze problemen, en deze FAQ is te klein om andere mogelijkheden in detail te behandelen. Voor Mac-gebruikers geldt: zie de aantekeningen bij de laatstgenoemde URL.
Wanneer je een webserver (httpd) draait op een systeem dat niet zelf ISO-8859-1 als tekenset heeft, zoals een Mac, of een IBM-mainframe, is het de taak van de server om tekstdocumenten te converteren naar ISO-8859-1 code zodra ze naar het netwerk worden verzonden.
Als je tekens van buiten het ISO-8859-1-repertoire wilt gebruiken, moet je HTML 4.0 gebruiken in plaats van HTML 3.2. Zie de HTML 4.01 Recommendation op <URL:http://www.w3.org/TR/html4/> en de Babel-site op <URL:http://babel.alis.com:8080/> voor meer details. Een andere bruikbare gegevensbron voor internationalisatiekwesties is te vinden op <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/charset/>.
Het is nooit verkeerd om aanhalingstekens gebruiken rondom attribuutwaarden, en veel mensen bevelen aan om alle attribuutwaaren van aanhalingstekens te voorzien, zelfs waarneer ze eigenlijk optioneel zijn. XHTML 1.0 vereist dat attribuutwaarden worden aangehaald. Net zoals in vorige HTML-specificaties, staat HTML 4 toe dat attribuutwaarden in vele gevallen niet aangehaald worden (bijv. wanneer de waarde alleen letters en cijfers bevat). Zie <URL:http://www.w3.org/TR/html4/intro/sgmltut.html#attributes> voor de exacte regels.
Wees voorzichtig wanneer de attribuutwaarde dubbele aanhalingstekens bevat, bijvoorbeeld als je een ALT-tekst als "the "King of Comedy" takes a bow" wilt gebruiken voor een afbeelding. Mensen kunnen dit ontleden om te weten waar het aangehaalde materiaal eindigt, maar browsers kunnen dat niet. Je moet de attribuutwaarde speciaal coderen zodat het eerste interne aanhalingsteken niet de waarde voortijdig beëindigt. De twee belangrijkste technieken zijn:
Beide methoden zijn correct volgens de specificaties en worden ondersteund door de huidige browsers, maar beiden werden slecht ondersteund in sommige eerdere browsers. Het enige echt veilige advies is om de tekst te herschrijven zodat de attribuut-waarde geen aanhalingstekens hoeft te bevatten, of om de binnenste dubbele aanhalingstekens te vervangen door enkele aanhalingstekens, zoals hier: ALT="the 'King of Comedy' takes een bow".
Een commentaardeclaratie begint met "<!", gevolgd door nul of meer commentaar-eenheden, gevolgd door ">". Een commentaar-eenheid begint en eindigt met "--", en bevat geen enkele maal "--" tussen de begin- en eindparen. Dit betekent dat de volgende teksten allemaal geldige HTML-commentaren zijn:
<!-- Hallo --><!-- Hallo -- -- Hallo--><!----><!------ Hallo --><!>Maar sommige browsers ondersteunen niet de volledige syntax. Daarom bevelen we de volgende eenvoudige regel aan om valide en geaccepteerde commentaren te maken:
Een HTML-commentaar begint met "
<!--", eindigt met "-->" en bevat geen "--" of ">" ergens in het commentaar.
Zie <URL:http://www.htmlhelp.com/reference/wilbur/misc/comment.html> voor een completere behandeling.
De opbouw van een URL definieert een hiërarchie die te vergelijken valt met de hiërarchie van een bestandssysteem in subdirectories of mappen. De onderdelen van een URL worden gescheiden door 'slash'-tekens ("/"). Bij het navigeren door de URL-hiërarchie valt het laatste deel van de URL (bijv. alles na de laatste slash) te vergelijken met een bestand in een bestandssyteem. De andere delen van de URL zijn de vergelijken met de subdirectories en mappen van een bestandssysteem.
Een relatieve URL bevat niet alle informatie die nodig is om het betrokken document te localiseren. De ontbrekende informatie wordt geacht hetzelfde te zijn als voor het basisdocument dat de relatieve URL bevat. Dit beperkt de lengte die nodig is voor URL's die verwijzen naar gerelateerde documenten, en maakt het mogelijk om de documentstructuur te benaderen via meerdere toegangsschema's (bijv. "file", "http", en "ftp"), of om de documenten te verplaatsen zonder de in deze documenten opgenomen URL's te hoeven veranderen.
Voordat de browser een relatieve URL kan gebruiken, dient deze eerst te worden opgelost om een absolute URL te maken. Als de relatieve URL met een dubbele slash begint (bijv. //www.htmlhelp.com/faq/html/), dan zal het enkel het schema overnemen van de basis-URL. Als de relatieve URL met een enkele slash begint (bijv. /faq/html/), dan zal het het schema en de netwerklocatie van de basis-URL overnemen.
Als de relatieve URL niet met eem slash begint (bijv. all.html , ./all.html of ../html/), dan heeft het een relatief pad. Dat wordt als volgt opgelost.
Mogelijk maken enkele voorbeelden dit duidelijker. Als het basisdocument <URL:http://www.htmlhelp.com/faq/html/basics.html> is, dan verwijst
Merk a.u.b. op dat de browser relatieve URL's oplost, er niet de server. De server ziet alleen de resulterende absolute URL. Verder navigeren relatieve URL's in de URL-hiërarchie. Het (mogelijke) verband tussen de URL-hiërarchie en de hiërarchie van het bestandssysteem van de server is niet relevant.
Zie voor een complete behandeling van het juiste formaat van URL's <URL:http://www.w3.org/addressing/>.
De opbouw van een URL definieert een hiërarchie die te vergelijken valt met de hiërarchie van een bestandssysteem in subdirectories of mappen. De onderdelen van een URL worden gescheiden door 'slash'-tekens ("/"). Bij het navigeren door de URL-hiërarchie valt het laatste deel van de URL (bijv. alles na de laatste slash) te vergelijken met een bestand in een bestandssyteem. De andere delen van de URL zijn de vergelijken met de subdirectories en mappen van een bestandssysteem.
Bij het oplossen van relatieve URL's (zie het antwoord op de vorige vraag), is de eerste stap van de browser het weghalen van alles wat na de laatste slash in de URL van het huidge document komt. Eindigt de URL van het huidge document met een slash, dan is het laatste deel (het "bestand") van de URL nul. Als je de laatste slash weghaalt, dan is het laatste deel van de URL niet langer nul; het is dan gelijk aan datgene wat komt na de laatste overblijvende slash in de URL. Het verwidjeren van de slash verandert de URL; de gewijzigde URL verwijst naar een ander document en relatieve URL's zullen anders worden opgelost.
Zo is bijvoorbeeld het laatste deel van de URL http://www.htmlhelp.com/faq/html/ leeg; er volgt niets na de laatste slash. In dit document wordt de relatieve URL all.html opgelost als http://www.htmlhelp.com/faq/html/all.html (een bestaand document). Als de laatste slash ontbreekt, dan is het laatste deel van de veranderde URL http://www.htmlhelp.com/faq/html "html". In dit (niet bestaande) document zou de relatieve URL all.html oplossen tot http://www.htmlhelp.com/faq/all.html (nog een niet bestaand document).
Wanneer een webserver een aanvraag ontvangt waarbij de laatste slash ontbreekt, kan de webserver de ontbrekende slash niet negeren en het document gewoon versturen. Dat zou alle relatieve UR's in het document onbruikbaar maken. Meestal zijn servers zo ingesteld, dat ze een "redirect"-bericht sturen bij de ontvangst van zo'n aanvraag. IAls reactie op het "redirect"-bericht, vraagt de browser de juiste URL aan, en dan verzend de server het aangevraagde document. (Overigens kan de browser de URL niet zelf corrigeren; alleen de server kan bepalen of een de laatste slash van een URL ontbreekt.)
Dit foutcorrectie-methode betekent dat URL's zonder de laatste slash blijven werken. De methode verspilt echter wel tijd en netwerkbronnen. Als je de laatste slash toevoegt wanneer dat nodig is, hoeven browsers geen tweede aanvraag naar de server te versturen.
De enige uitzondering is het verwijzen naar een URL met alleen maar een hostnaam. Aangezien het duidelijk is dat je met het gebruik van http://www.htmlhelp.com de hoofdindex "/" van de server wilt, hoef je de / in dit geval niet toe te voegen. Het wordt als netter beschouwd om het wel te doen.
Zie voor een complete behandeling van het juiste formaat van URL's <URL:http://www.w3.org/addressing/>.
Er is diverse software beschikbaar om automatisch fouten te ontdekken in je webdocumenten. HTML-validators zijn programma's die HTML-documenten controleren tegen een formele definitie van de HTML-syntax en daarna een lijst produceren met fouten. Validatie is belangrijk om de beste kans te hebben op juistheid met onbekende browsers (zowel bestaande browsers die je nog niet hebt gezien, als toekomstige browsers die nog niet zijn geschreven).
HTML-linters (checkers) zijn ook nuttig. Deze programma's controleren documenten op specifieke overdraagbaarheidsproblemen, zowel veroorzaakt door ongeldige markup als andere problemen veroorzaakt door bekende browser bugs. Linters kunnen sommige ongeldige documenten doorlaten en ze kunnen sommige geldige weigeren.
Alle validators zijn functioneel gelijkwaardig; alhoewel ze verschillende manieren kunnen gebruiken om fouten te rapporteren, zullen ze bij gelijke input dezelfde fouten vinden. Verschillende linters zijn geprogrammeerd om te kijken naar verschillende problemen, zodat hun rapporten aanzienlijk van elkaar zullen verschillen. Verder worden enkele programma's validators genoemd (bijv. de "CSE HTML Validator") die in werkelijkheid linters/checkers zijn. Ze zijn nog steeds nuttig, maar ze moeten niet verward worden met echte HTML validators.
Bij het de eerste keer controleren van een site op fouten, is het meestal nuttig om vast te stellen wat algemene problemen zijn die herhaldelijk voorkomen in je markup. Los deze problemen overal waar ze voorkomen op (met een geautomatiseerde methode indien mogelijk), en ga dan terug om de overblijvende problemen te identificeren en op te lossen.
Bij het controleren op fouten in de HTML, is het ook een goed idee om te controleren op hypertext links die niet meer geldig zijn. Er zijn diverse link-checkers beschikbaar voor verschillende computersystemen die alle links van een site volgen, en een lijst produceren van de links die niet meer werken.
Een lijst met validators, linters en link-checkers is te vinden op <URL:http://www.htmlhelp.com/links/validators.htm>. Bijzonder aanbevolen is het gebruik van een op SGML gebaseerde validator, zoals de WDG HTML Validator <URL:http://www.htmlhelp.com/tools/validator/> of de W3C HTML Validation Service <URL:http://validator.w3.org/>.
Volgens de HTML-standaarden begint elk HTML-document met een DOCTYPE-declaratie die aangeeft welke versie van HTML het document gebruikt. De DOCTYPE-declaratie is vooral nuttig voor op SGML gebaseerde hulpmiddelen zoals HTML-validators, die moeten weten welke versie van HTML gebruikt moet worden bij het controleren van de syntax van het document. Browsers negeren DOCTYPE-declaraties over het algemeen.
Zie <URL:http://www.htmlhelp.com/tools/validator/doctype.html> voor informatie over het kiezen van een toepasselijke DOCTYPE-declaratie.
Merk op dat het deel dat de zogenaamde public identifier bevat van de DOCTYPE-declaratie hoofdlettergevoelig is. Van sommige versies van Netscape Composer is het bekend dat ze het kleinletterige "-//w3c//dtd html 4.0 transitional//en" invoegen, in plaats van het correcte gemengde "-//W3C//DTD HTML 4.0 Transitional//EN".