Deze lijst van Frequently Asked Questions (Veel Voorkomende Vragen) wordt bijgehouden door de WDG. Deze vertaling is gemaakt door Rijk van Geijtenbeek, en is gebaseerd op de versie van 15 juli 2000. Dit document kan worden gevonden op de volgende URL's:
De oorspronkelijke Engelstalige tekst is te vinden op:
Als je een bijdrage wilt leveren aan de FAQ, stuur dan een (Engelstalige) e-mail naar <darin@htmlhelp.com>. Alle bijdragenden zullen onder aan deze FAQ worden vermeld.
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".
Veel providers bieden webruimte aan hun inbelklanten aan. Dit is gewoonlijk minder dan 5MB, en er kunnen verdere beperkingen zijn; het is bijvoorbeeld vaak niet toegestaan om commercieel gebruik te maken van deze ruimte.
Er zijn meerdere bedrijven en individuen die gratis webruimte aanbieden. Dit varieert gewoonlijk van 100KB tot en met 1MB, en er zijn ook vaak weer beperkingen aan het gebruik. Het gebeurt ook dat ze een link naar hun homepage vereisen. Zie voor verwijzingen naar aanbieders van gratis webruimte <URL:http://www.freewebspace.net/>.
Er zijn ook veel aanbieders van webruimte (ook bekend als 'presence providers') die ruimte op hun servers verkopen. Prijzen lopen uiteen van niet meer dan $1 per maand, tot $100 per maand of meer, afhankelijk van je behoeften. Niet-virtuele webruimte is meestal het goedkoopste, hierbij krijg je een URL zoals: http://www.een-aanbieder.com/jouwnaam/. Voor iets meer, en de kosten voor het registreren van een domeinnaam, kun je virtuele webruimte krijgen, waardoor je kunt beschikken over een URL zoals http://www.jouwnaam.com/.
Als je de een of andere permanente verbinding met Internet hebt, bijvoorbeeld via een gehuurde lijn van je provider, dan kun je een httpd installeren en een eigen webserver beheren. Er zijn diverse webservers beschikbaar voor praktisch alle computersystemen.
Als je enkel informatie wilt uitwisselen met andere lokale gebruikers, of mensen op een LAN of WAN, dan kun je je HTML-bestanden gewoon op het LAN plaatsen waar iedereen erbij kan, of anders, als jouw LAN TCP/IP ondersteunt, een webserver installeren op je eigen computer.
De Internet Corporation for Assigned Names and Numbers (ICANN) houdt een overzicht bij van aangezen registreerders op <URL:http://www.icann.org/registrars/accredited-list.html>. Elk van de bedrijven op deze lijst kan een domeinnaam voor je registreren.
Lees de Voorwaarden voor gebruik (Terms of Service, TOS) die je bent overeengekomen met jouw hosting-dienstverlener. Hierin wordt het hoogstwaarschijnlijk verboden om in te grijpen in de advertenties die zij toevoegen aan je webpagina's. Als je zelf de een of andere truc gebruikt om hun advertenties tegen te houden, kan de hosting dienst jouw account opzeggen wegens het overtreden van de TOS.
Er kunnen echter wel andere mogelijkehden zijn. Sommige hosting-diensten halen de advertenties weg als je een laag maandelijks bedrag betaalt. Anderen verwijderen hun standaard pop-up advertenties als je zelf vaste banners plaatst.
Er is niet één vaste techniek, maar een aantal factoren kunnen helpen.
<TITLE>, gebruik zinvolle koppen (<H1>, <H2>, enzovoort), en zorg voor zinvolle ALT-teksten voor afbeeldingen.<META NAME="keywords" CONTENT="..."> tags die voorkomen in het <HEAD> deel van je documenten. Maar META keywords zijn ook gebruikt om zoekmachines om de tuin te leiden, dus velen zullen je keyword-lijst negeren als je een bepaald keyword te vaak herhaald. Op het moment dat dit wordt geschreven, betekent "te vaak" "meer dan 7 keer" voor enkele populaire zoekmachines, maar dat kan in de toekomst veranderen als indexeer programmas worden veranderd ter verdeding tegen "valsspelers."<META NAME="description" CONTENT="..."> tag opneemt in het <HEAD> deel van je documenten, zullen sommige zoekmachines de inhoud van deze tag gebruiken als beschijving van je site bij het weergeven van zoekresultaten. Dit heeft geen invloed op je ranking in zoekopdrachten, maar het kan gebruikers van zoekmachines helpen bij het begrijpen wat je site hen biedt, wanneer een zoekopdracht jouw site vindt.Merk op dat het CONTENT attribuut van de META keywords en description tags tot maximaal 1022 tekens mogen bevatten, maar behalve entities geen markup.
Je kunt je site bekijken met een text-only browser zoals Lynx, om er een idee van te krijgen hoe je site er uitziet voor zoekmachines. Search Engine Watch op <URL:http://searchenginewatch.com/> is een website gericht op zoekmachines en strategieën voor webpagina ontwerpers.
Merk ook nog op, dat sommige zoekmachines sites negeren die worden geplaatst bij bekende gratis hosting-diensten. Andere zoekmachines indexeren maar een beperkt aantal documenten per server, zodat vroege klanten van gratis hosting-diensten mogelijk worden geïndexeerd, terwijl latere klanten mogelijk worden genegeerd.
Zie <URL:http://info.webcrawler.com/mak/projects/robots/exclusion.html>.
De meest betrouwbare manier is het configureren van de server om een verwijzingsinstructie (redirect) te versturen als de oude URL wordt aangevraagd. Dan zal de browser automatisch de nieuwe URL krijgen. Dit is de snelste en meest efficiënte manier, en het is de enige van de hier beschreven manieren die indexeer-robots kan overtuigen de oude URL te vergeten. Raadpleeg voor details met betrekking tot de configuratie je serverbeheerder of de documentatie (gebruik met NCSA of Apache servers een Redirect statement in .htaccess).
Als je geen redirect kunt opzetten zijn er andere mogelijkheden. Deze zijn minderwaardig omdat ze de zoekmachines vertellen dat er nog steeds een pagina bestaat op de oude locatie, niet dat de pagina verhuisd is naar een nieuwe locatie. Maar als het niet mogelijk is om een redirect te configureren op de server, zijn er twee alternatieven:
META HTTP-EQUIV="Refresh" CONTENT="x; URL=nieuw.URL">Wachtwoordbeveiliging gebeurt door middel van HTTP-authenticatie. Aangezien de configuratie-details verschillen van server tot server moet je hiervoor het onderdeel authenticatie lezen van de serverdocumentatie. Neem contact op met de serverbeheerder als je hierbij hulp nodig hebt.
Als je server bijvoorbeeld Apache is, kijk dan op <URL:http://www.apache.org/docs/misc/FAQ.html#user-authentication>.
Wachtwoord-scripts in JavaScript geven alleen de suggestie van veiligheid. In beginsel werken ze op een van twee manieren. Sommige scripts zetten het wachtwoor dom in een URL, waardoor het document geheim blijft doordat het aantal mensen dat de URL kent beperkt is. Sommige scripts controleren een wachtwoord en gaan dan naar een specifieke URL, wat het docuemnt alleen maar beschermt tegen degenen, die die niet in de broncode van het JavaScript kijken om de URL van het document te verkrijgen. Geen van deze twee methoden is echt veilig.
Browsers 'cachen' webdocumenten; ze slaan een lokale kopie op van documenten om herhaalde verzoeken naar documenten die niet zijn veranderd te versnellen. Ook zijn veel browsers ingesteld om een publieke proxy cache te gebruiken, die vele gebruikers dient (bijv. alle klanten van een ISP, of alle werknemers achter een bedrijfs-firewall). Om effectief te beheersen hoe je documenten worden gecached, moet je je server instellen om de juiste HTTP headers te verzenden.
De Expires-header wordt door praktisch alle caches begrepen. Het gecachete document zal opnieuw worden opgehaald zodra het is verlopen. De Expires-header moet een HTTP-datum bevatten, die werkt met Greenwich Mean Time (GMT), niet met de lokale tijd.
HTTP 1.1 introduceert de Cache-Control-header, die meer flexibiliteit biedt voor het aan caches duidelijk maken, hoe ze met het document moeten omgaan. Zie de HTTP 1.1 draft (zie <http://www.w3.org/Protocols/>) voor meer informatie.
De configuratie-details verschillen van server tot server, dus zoek dit op in je serverdocumentatie. Als je server bijvoorbeeld Apache is, zie dan <URL:http://www.apache.org/docs/mod/mod_expires.html> voor informatie over het instellen van de Expires header, en <URL:http://www.apache.org/docs/mod/mod_headers.html> voor informatie over het instellen van andere headers.
De Pragma-header is over het algemeen ineffectief omdat de betekenis niet gestandaardiseerd is en slechts weinig caches het honoreren. Het gebruik van <META HTTP-EQUIV=...> elementen in HTML-documenten is ook in het algemeen ineffectief; sommige browsers kunnen deze markup honoreren, maar andere caches negeren dit geheel.
Verdere behandeling kan worden gevonden op <http://www.mnot.net/cache_docs/>.
Dat kan je niet. De browser heeft de broncode nodig om jouw document weer te geven. Je moet de complete, niet-versleutelde broncode naar de browser sturen. Zelfs als een bepaalde browser geen "Bron Tonen" mogelijkheid heeft, zijn er vele anderen die dat wel hebben, en je kunt altijd een document met de hand ophalen (met behulp van telnet) om de broncode te krijgen. Of de cache van de browser bekijken.
Er zijn trucs die het voor sommige lezers moeilijker maken om de bron te bekijken of op te slaan (bijv. het wijsmaken van newbies dat er niks is, door het toevoegen van een paar dozijn lege regels aan het begin van het document, of het gebruik van JavaScript om de rechter-muis-knop af te vangen). Maar deze trucs hebben, net als met trucs die proberen te voorkomen dat afbeeldingen worden opgeslagen, maar een heel beperkt effect en ze kunnen diverse problemen veroorzaken voor legitieme gebruikers.
Dat kan je niet. URL's zijn de grondslag van de navigatie op het WWW. De URL is onmisbaar voor de browser om je document binnen te kunnen halen. Het is onmogelijk om de URL van een bron voor de browser te verbergen.
Veel browsers identificeren zichzelf wanneer ze een document aanvragen. Een CGI script zal deze informatie beschikbaar hebben in de HTTP_USER_AGENT omgevings-variabele, en kan deze gebruiken om een versie van het document te versturen, die is geoptimaliseerd voor die browser.
Bedenk dat niet alle browsers zichzelf correct identificeren. Microsoft Internet Explorer, bijvoorbeeld, claimt "Mozilla" te zijn om voor Netscape verbeterde documenten te krijgen.
En als een cache-proxy voor Netscape verbeterde document bewaart, zal iemand met een andere browser dit document natuurlijk ook krijgen als hij gebruikt maakt van deze cache.
Vanwege deze en andere redenen, is het geen goed idee om het raad-de-browser-spel te spelen.
Daar kom je niet achter. Alhoewel iedere aanvraag voor een document normaal gesproken wordt gelogd met het naam of het adres van de 'remote host', wordt de werkelijke usernaam bijna nooit gelogd. Dit is vooral zo vanwege performance redenen, aangezien het vereist dat de server het 'ident protocol' gebruikt om te kijken wie er aan de andere kant is. Dat kost tijd. En als een 'cache proxy' de aanvraag doet, krijg je geen zinvolle resultaten.
Maar denk eens even na... wil je nu echt dat elke site die je bezoekt jouw e-mailadres weet? Stel je voor hoeveel bergen automatische dankjewel's je zou ontvangen. Als je 20 sites bezocht, zou je minstens 20 e-mails krijgen die dag, en ongetwijfeld ook nog uitnodigingen om later terug te komen. Het zou een nachtmerrie zijn en een schending van de privacy!
In Netscape 2.0 was het mogelijk om automatisch een formulier te versturen met een mailto als actie, met behulp van JavaScript. Hiermee werd een e-mail gestuurd naar de eigenaar van het document, met het adres dat de bezoeker had ingesteld in de 'From' regel. Dat kan natuurlijk "mickey.mouse@disney.com" zijn. In Netscape 2.01 is dit opgelost.
De meest betrouwbare manier is het plaatsen van een formulier, waarin je de bezoeker vraagt zijn e-mailadres in te vullen. Om de kans te verhogen dat bezoekers dat ook werkelijk doen, kan je iets nuttigs aanbieden als wederdienst.
Recente versies van Internet Explorer gebruiken standaard "gebruikersvriendelijke" HTTP foutberichten. Als een speciaal HTTP antwoord (bijv. een 404 antwoord) korter is dan 512 bytes, zal de browser het eigen bericht gebruiken in plaats van het door de server geleverde bericht. Als gebruiker van Internet Explorer kunt je dit uitschakelen in het "Geavanceerde" opties paneel. Voor webauteurs is het groter maken van de foutpagina's de enige oplossing.
HTML biedt van zichzelf geen mogelijkheid om de inhoud van de het ene bestand naadloos in een ander bestand in te voegen.
Echte dynamische invoeging van het ene HTML-document (zelfs met een andere "charset") in een ander wordt geboden door het OBJECT element, maar vanwege tekortkomingen van de browserversies die nu gebruikt worden, lijkt het onverstandig om hierop te rekenen voor belangrijke inhoud. Hetzelfde kan worden gezegd voor IFRAME.
Twee populaire manieren om de inhoud van de het ene bestand naadloos in een ander bestand in te voegen voor het WWW zijn preprocessing en server-side inclusion.
'Preprocessing' technieken omvatten de C preprocessor en andere algemene tekstbewerkings methoden, en diverse HTML-specifieke processors. Er staat een aardige lijst met beschreven HTML-preprocessors op <http://www.idocs.com/wmr/software/html+preprocessors/>.
Pas op voor het niet-overdraagbaar maken van je "broncode". Ook kan de HTML enkel na het preprocessen worden gevalideerd, dus de normale cyclus van "Schrijven, Controleren, Uploaden" wordt "Schrijven, Preprocessen, Controleren, Uploaden" ("Controleren" omvat hier de stappen die je onderneemt om je pagina's van te voren te bekijken: validatie, linting, management walk-through enz.; en "uploaden" betekent alles wat je doet om je nieuwe pagina's uiteindelijk te plaatsen op de web-server.)
Een veel krachtiger en veelzijdiger pre-processing techniek is het gebruik van een SGML processor (zoals het SP pakket) om de HTML te genereren; dit kan zelf-validerend zijn.
Voorbeelden van 'server-side inclusion' zijn Server Side Includes (SSI, ondersteund door Apache, NCSA en sommige andere webservers) en Microsoft's Active Server Pages (ASP, ondersteund door MS IIS). Verwerken gebeurt op het moment dat de documenten werkelijk worden opgevraagd. Een invoeging kan er bijvoorbeel zo uitzien
<!--#include virtual="/urlpath/to/myfile.htm" -->
maar zorg ervoor de documentatie van de eigen webserver te raadplegen, aangezien de details wat variëren tussen de implementaties. Het gehele commando wordt vervangen door de inhoud van het aangegeven bestand.
Het gebruiken van server-side invoegingen (een potentieel krachtig hulpmiddel) enkel als manier om statische bestanden als standaard koppen/voetteksten in te voegen heeft gevolgen voor de merkbare toegangssnelheid en voor de serverbelasting, en kan beter vermeden worden op zwaar belaste servers. Als je het op deze manier gebruikt, overweeg dan om het resultaat cache-baar te maken (bijv. via "XBitHack full" op Apache; eigenschappen instellen van het "Response"-object in ASP). De details vallen buiten het bereik van deze FAQ maar dit kan nuttig zijn: http://www.pobox.com/~mnot/cache_docs/
Echte HTML-validatie van server-side invoegingen is alleen mogelijk nadat de server-side processing is gebeurt, bijvoorbeeld met behulp van een on-line validator die het bestand van de server ophaalt.
En bedenk ook nog dat, als het ingevoegde bestand willekeurige platte tekst bevat, er iets moet worden geregeld om de tekens "&" en "<" (in het platte tekstbestand) om te zetten naar "&" en "<" (in het HTML-document).
In HTML kunnen tekens (characters) op drie manieren worden aangeduid:
In theorie zijn al deze wijzen van aanduiden even geldig. In de praktijk wordt de zaak ingewikkelder door schrijfgemak en beperkte ondersteuning door browsers.
Aangezien HTTP een gegarandeerd "8-bit clean" protocol is, kun je veilig 8-bit of multibyte gecodeerde tekens versturen, in de diverse coderingen die worden ondersteund door browsers.
Er bestaat geen goede argumenten meer om een voorkeur te hebben voor &entitynaam; dan wel &#nummer;, dus gebruik gewoon datgene wat het handigste is.
Als je vertrouwd bent met het werken met 8-bit-gecodeerde tekens dan is dat ook mooi, en waarschijnlijk te verkiezen voor het schrijven in talen met veel tekens met accenten. Let er op, bij het schrijven op niet-ISO-8859-gebaseerde systemen zoals Mac, Psion, IBM-mainframes enz., dat de upload-techniek een op de juiste wijze gecodeerd document aan de server levert. Het gebruik van &-aanduidingen vermijdt zulke problemen.
In coderingen als ISO-8859-7 Greek, koi8-r Russisch Cyrillisch, en Chinese, Japanse en Koreaanse (CJK) coderingen, is het gebruik van gecodeerde tekens de meest breed ondersteunde en meest gebruikte techniek.
Alhoewel dit niet onder HTML 3.2 valt, hebben browsers dit al enige tijd tamelijk breed ondersteund; het is een geldige mogelijkheid in de HTML 4.0 specificatie--gebruik een validator zoals de HTML Validator van de WDG op http://www.htmlhelp.com/tools/validator/, die HTML 4.0 ondersteunt en verschillende teken-coderingen begrijpt.
Browserondersteuning voor gecodeerde tekens kan afhangen van instellingen en beschikbare lettertypes. In sommige gevallen verzorgen aanvullende programma's, genaamd "helpers" of "add-ins", virtuele lettertypes in browsers.
"Add-in" programma's zijn in het verleden gebruikt om numerieke aanduidingen van 15-bit- of 16-bit-code protocollen zoals Chinees Big5 of Chinees GB2312 te ondersteunen.
In theorie zou het mogelijk moeten zijn om niet alleen gecodeerde tekens maar ook numerieke teken-aanduidingen in Unicode te gebruiken, maar browserondersteuning hiervoor is over het algemeen slecht. Numerieke verwijzingen naar de "charset-specified" codering lijken de gewenste tekens te produceren in sommige browsers, maar dit is verkeerd gedrag en zou niet moeten worden gebruikt. Teken-entiteiten zijn ook problematisch, behalve de voor HTML belangrijke tekens <, & enz.
Recente versies van de populaire browsers ondersteunen sommige van deze mogelijkheden, maar op dit moment lijkt het niet verstandig om hier afhankelijk van te zijn wanneer je schrijft voor een algemeen publiek. Als je de mogelijkheden wilt onderzoeken, kun je uitgebreide achtergrondinformatie en enkele praktische suggesties vinden op
Tags zijn ongevoelig voor het gebruik van hoofdletters of kleine letters, dus dat maakt niet uit. Dit is gewoon een kwestie van smaak. Veel mensen verkiezen hoofdletters, omdat de tags tussen de tekst dan "eruit springen".
Attribuut-namen kunnen ook zowel in hoofdletters als in kleine letters worden geschreven, naar eigen voorkeur. Maar sommige attribuut-waarden zijn wel gevoelig voor hoofdlettergebruik. Zo zijn bijvoorbeeld <OL TYPE=A> en <OL type=A> hetzelfde, maar <OL TYPE=a> verschilt hiervan. (Voor een heldere communicatie is het nuttig om de juiste terminologie te gebruiken. In dit voorbeeld is OL het element, TYPE is de attribuut-naam, en A en a zijn de attribuut-waarden. De tag is <OL TYPE=A>.)
Entiteit-namen zoals worden soms onterecht tags genoemd. Zij zijn allemaal hoofdlettergevoelig. É en é zijn twee verschillende en geldige entiteiten; &NBSP; is ongeldig.
Merk op dat XHTML 1.0 (een herformulering van HTML 4.01 als een XML 1.0-toepassing) vereist dat element- en attribuutnamen met kleine letters worden geschreven.
HTML is niet afhankelijk van schermgrootte. In het algemeen zal de browser de tekst laten teruglopen zodra het einde van het venster wordt bereikt. (Merk op dat grafische browsers vaak worden gebruikt met vensters die kleiner zijn dan het volledige scherm.)
'Preformatted' regels (tekst binnen <PRE>-elementen) zouden alleen langer mogen zijn dan 70 tekens indien de aard van de inhoud dit onvermijdelijk maakt. Langere regels zorgen voor lelijke afbrekingen in tekst-browsers, en dwingen horizontaal scrollen af in grafische browsers. Lezers hebben een grote hekel aan horizontaal scrollen, behalve wanneer ze zich kunnen realiseren dat de aard van de inhoud het onvermijdelijk maakt.
Een afbeelding kan niet teruglopen, daar moet je dan ook voorzichtig mee zijn. Het lijkt erop dat 400 of 500 pixels een redelijke breedte is; alles boven 600 betekent dat een bepaald percentage van de gebruikers moet scrollen om het meest rechtse deel te zien. Dit percentage neemt toe naarmate de breedte van je afbeelding toeneemt. Bedenk dat niet iedereen zijn browser in een volledig scherm draait!
(WebTV gebruikers hebben geen mogelijkheid om horizontaal te scrollen, dus alles voorbij 544 pixels zal door hun browser worden samengeperst. Sommige andere apparaten kunnen zelfs nog beperkter zijn.)
Het gebruik van tabellen voor layout, vooral als cellen met vaste breedte worden gebruikt, is de meest gebruikelijke factor die voorkomt dat pagina's zich kunnen aanpassen aan diverse venstergroottes. Dit wordt in detail uitgelegd op <URL:http://www.dantobias.com/webtips/tables.html>.
Er zijn verschillende mogelijkheden.
Ten eerste kun je foutieve HTML hebben. Browsers verschillen in hun mogelijkheden om te gokken wat je bedoelde. Zo doet Netscape veel moeilijker over tabellen dan MS Internet Explorer, waardoor een pagina met foutieve tabellen er prima uit kan zien in MSIE, maar helemaal niet te zien is in Netscape. Zie het antwoord op "Hoe controleer ik op fouten?" voor tips met betrekking tot het vinden van je HTML-fouten. (Feitelijk worden zelfs correct genestte tabellen mogelijk niet juist weergegeven in Netscape. Zie "Kan ik een tabel in een tabel plaatsen (nesten)?" voor wat je daaraan kunt doen.)
Ten tweede kun je valide HTML hebben dat door de diverse browsers verschillend wordt geïnterpreteerd. Zo is het bijvoorbeeld niet helder vanuit de specificaties wat er moet gebeuren met een serie tekens. Sommige browsers zullen deze samen laten vallen voor weergave als een enkele spatie; anderen zullen een spatie per weergeven.
Ten derde kan je server verkeerde MIME-types versturen voor enkele van je bestanden. Internet Explorer negeert ten onrechte door de server opgegeven MIME-types, zodat het some "goed werkt" terwijl de server verkeerd is ingesteld. Andere browsers houden terecht rekening met de door de server opgegeven MIME-types, zodat ze de verkeerd ingestelde server ontmaskeren.
Andere mogelijkheden zijn een bug in de ene of de andere browser, of verschillende gebruikers-opties instellingen.
Zie ook de antwoorden op "Waarom worden mijn hyperlinks verkeerd weergegeven, of willen ze niet laden?" en "Waarom worden mijn afbeldingen verkeerd weergegeven, of willen ze niet laden?"
Als Microsoft Internet Explorer je document normaal weergeeft, maar andere browsers geven je HTML-bron als platte bron, dan verstuurt je webserver hoogstwaarschijnlijk het document met het MIME type "text/plain". Je webserver moet worden ingesteld om deze bestandsnaam met het MIME type "text/html" te versturen. Zie het antwoord op "Ik probeerde te linken naar een ... bestand maar ik kreeg alleen maar een stel tekens te zien na het downloaden?" voor meer details.
Dit is een "feature" bij het gebruik van frames: de browser geeft de URL weer van het frameset-document, in plaats van dat van de geframede documenten. (Zie het antwoord op de vraag "Hoe geef ik een bepaalde combinatie van frames aan in plaats van het standaarddocument?").
Dit verschijnsel kan echter makkelijk ontweken worden door de gebruiker. Veel browsers maken het mogelijk om links in een eigen venster te openen, een bookmark te maken van het document in een specifiek frame (in plaats van het frameset-document), of om een bookmark te maken van links. Er is dus geen betrouwbare manier om het een gebruiker te verhinderen, de URL van een specifiek document te achterhalen.
Overigens jaag je gebruikers alleen maar tegen je in het harnas als je voorkomt dat ze een bookmark maken van specifieke documenten. Een bookmark of een link die niet het gewenste document vindt is waardeloos, en wordt waarschijnlijk genegeerd of verwijderd.
Een veelgebruikte techniek hiervoor, is het maken van een twee-koloms tabel met je links in de linkerkolom, en de inhoud in de rechterkolom. Dit wordt vaak aangevuld met een achtergrondplaatje, dat een gekleurde strook achter de links geeft. Het achtergrondplaatje kan verticaal herhaald worden, maar om horizontaal herhalen te voorkomen, moet het plaatje bijzonder breed zijn (bijv. 1600 pixels).
Een variant van deze techniek (waarmee enkele van problemen met het gebruik van tabellen voor layout worden beperkt) gebruikt een een-cel-tabel met ALIGN="left". Alleen de links staan in de tabel, die aan de linkerkant zweeft. De inhoud van het document vult de rest van de ruimte naast en onder de tabel.
Layout-tabellen kunnen geheel worden vermeden door CSS te gebruiken. De navigatie-links en de inhoud van de pagina worden in aparte DIV-elementen geplaatst, waarna deze DIV-elementen met CSS naast elkaar worden geplaatst. De stylesheet kan een kleinere achtergrondafbeelding gebruiken, die verticaal wordt herhaald en links is uitgelijnd, bijvoorbeeld:
body { color: black; background: white url(foo.gif) repeat-y left }
Meer informatie over Cascading Style Sheets kan worden gevonden op: http://www.htmlhelp.com/reference/css/
Een navigatiestrook aan de linkerkant kan ook nog worden gerealiseerd met frames. Maar frames veroorzaken problemen die beter kunnen worden vermeden.
Zie het antwoord op de vraag "Hoe voeg ik het ene bestand in in een ander bestand?" voor suggesties die je helpen om gemeenschappelijke inhoud zoals navigatielinks voor alle documenten op je site bij te houden.
Gebruik het 'anchor'-(anker)element. Het HREF-attribuut geeft de URL van het document waarnaar je wilt linken. Het volgende voorbeeld linkt naar de tekst "Webontwerp FAQ" op <URL:http://www.htmlhelp.com/nl/faq/html/>:
<A HREF="http://www.htmlhelp.com/nl/faq/html/">WebOntwerp
FAQ</A>
Zie voor meer informatie over links en het 'anchor'-element: http://www.htmlhelp.com/reference/html40/special/a.html
Eerst moet de bestemming van de link worden geïdentificeerd met een benoemd anker (een anker dat het NAME-attribuut gebruikt). Bijvoorbeeld:
<H2><A NAME="sectie2">Sectie 2: Na de introducties</A></H2>
Daarna maak je een link naar het benoemde anker. De URL van de benoemde anker is gelijk aan de URL van het document, met "#" en de naam van het anker er aan vastgeplakt. Zo kun je bijvoorbeeld elders in hetzelfde document gebruiken:
<A HREF="#sectie2">ga naar Sectie 2</A>
En net zo kun je in een ander document gebruiken:
<A HREF="thesis.html#sectie2">ga naar Sectie 2 van mijn thesis</A>
<A TARGET="_blank" HREF=...> opent een nieuw, onbenoemd venster.
<A TARGET="foobar" HREF=...> opent een nieuw, "foobar" genaamd venster, voorzover er nog geen venster of frame met die naam bestaat.
Merk op dat links waarmee nieuwe vensters worden geopend, irritant kunnen zijn voor je lezers als er geen goede reden (vanuit de lezer bekeken) voor is.
Met HTML is er geen methode om de afmetingen (of andere venster-eigenschappen) van een nieuw venster te beheersen. Maar in JavaScript kun je zulke details opgeven als je de window.open() functie gebruikt.
Begin met een normale HTML link (mogelijk een die een nieuw venster opent zoals beschreven in het antwoord op de vorige vraag). Gebruik daarna het ONCLICK-attribuut om een venster te openen met de gewenste eigenschappen voor de lezers die JavaScript aankunnen en ingeschakeld hebben. Het volgende voorbeeld specificeert een venster genaamd "popup", dat 300 bij 150 pixels groot is.
<A HREF="foo.html" TARGET="popup" ONCLICK="window.open('foo.html', 'popup', 'width=300,height=150'); return false">Zie Foo</A>
Op deze manier kan in JavaScript een nieuw venster worden opgegeven met de gewenste eigenschappen, zonder de toegang te blokkeren indien JavaScript is uitgeschakeld of niet wordt ondersteund.
Behalve de parameters height en width (die een aantal pixels als waarde kennen), kan het derde argument van window.open() de volgende booleaanse parameters bevatten (die de waarde "yes" of "no" kennen): directories, location, menubar, resizable, scrollbars, status, en toolbar. Deze booleaanse parameters beheersen de aanwezigheid van de overeenkomende vensteruitrusting in het resulterende venster.
Dit krijg je het makkelijkst voor elkaar met een klein formulier:
<FORM ACTION="[URL]" METHOD=GET>
<INPUT TYPE=submit VALUE="Tekst op knop" NAME=foo>
</FORM>
Als je knoppen naast elkaar wilt uitlijnen, moet je ze in een één-rij-tabel stoppen, met elke knop in een aparte cel.
Merk op dat zoekmachines mogelijk het doeldocument niet kunnen vinden, tenzij er ergens anders op de pagina ook een normale link is.
Een ga-naar-een-andere-pagina knop kan ook worden geprogrammeerd in JavaScript, maar het bovenstaande is standaard HTML en werkt voor meer lezers.
Dat is onmogelijk in HTML. "Terug" gaan betekent dat je naar de vorige pagina in je browse-geschiedenis gaat. Je zou een link kunnen maken naar de URL die wordt gespecificeerd in de 'HTTP Referer header' (beschikbaar in de "HTTP_REFERER" omgevingsvariabele in CGI-programma's), maar dat creëert enkel een voorwaartse link naar een nieuwe locatie in je browse-geschiedenis. En zelfs dan kan de informatie in de variabele fout zijn. Sommige browsers zenden ten onrechte deze variabele als je een bookmark gebruikt of een URL handmatig intypt, en sommigen zenden deze variabele helemaal niet (het is niet verplicht).
Je kunt "history.back()" (JavaScript) gebruiken om een terug-knop (of link) te maken. Dit werkt natuurlijk alleen als JavaScript wordt ondersteund en ingeschakeld is.
Kijk voor een meer uitgebreide uitleg naar Abigail's "Simulating the back knop" te vinden op <URL:http://www.foad.org/%7Eabigail/HTML/Misc/back_button.html>.
Denk er aan dat het enige navigatie-middel dat vaker wordt gebruikt dan de "terug"-functie de hyperlink is. Je lezers weten vrijwel zeker hoe ze de terug-knop van hun browser moeten gebruiken. Gebruikers die de meest basale functies van hun browser niet onder de knie hebben, raken alleen maar in de war wanneer verschillende pagina's die functies op verschillende manieren nabootsen.
Dit kan niet met HTML. Maar Internet Explorer 4+ ondersteund de 'method' window.external.AddFavorite(), een zelfgemaakte uitbreiding op JavaScript die een "Toevoegen aan Favorieten"-dialoogscherm opent. Het volgende voorbeeld voorkomt, dat een niet werkende knop wordt gemaakt in andere browsers of bij hen die JavaScript hebben uitgeschakeld:
<script type="text/javascript"><!--
function addf() {
window.external.AddFavorite('http://www.htmlhelp.org/',
'Web Design Group'); }
if(document.all) {
document.write('<input type="button" onclick="addf()"'+
' value="Bookmark WDG Site">'); }
//--></script>Denk er aan dat lezers die weten hoe ze bladwijzers kunnen openen, vrijwel zeker ook weten hoe ze bladwijzers moeten aanmaken. En de enkeling die niet weet hoe hij/zij jouw site kan toevoegen aan de bladwijzers, weet waarschijnlijk ook niet hoe hij/zij de bladwijzer, die jij voor ze maakt, kunnen gebruiken. Gebruikers die de meest basale functies van hun browser niet onder de knie hebben, raken alleen maar in de war wanneer verschillende pagina's die functies op verschillende manieren nabootsen.
Dit kan niet met HTML. Maar enkele browsers ondersteunen de JavaScript 'method' window.print(), die een "Afdrukken"-dialoogscherm opent. Het volgende voorbeeld voorkomt, dat een niet werkende knop wordt gemaakt in andere browsers of bij hen die JavaScript hebben uitgeschakeld:
<script type="text/javascript"><!--
if (window.print) {
document.write('<input type="button" onclick="window.print()"'+
' value="Deze pagina afdrukken">'); }
//--></script>Denk er aan dat lezers die printers hebben, vrijwel zeker weten hoe de afdrukfunctie van hun browser werkt. Gebruikers die de meest basale functies van hun browser niet onder de knie hebben, raken alleen maar in de war wanneer verschillende pagina's die functies op verschillende manieren nabootsen.
Gebruik een "mailto:"-link, bijvoorbeeld
Stuur me een e-mail op
<A HREF="mailto:mij@mijndomein.com">mij@mijndomein.com</A>.
Note that any email address that you publish on the WWW like this will probably start receiving unsolicited commercial email (UCE, junk email). It's a good idea to protect your real email address (e.g., by filtering incoming email, or by using a separate address only for mailto links).
Dat kan je niet, niet op een betrouwbare manier. De methodes die regelmatig worden genoemd doen het niet op alle combinaties van browsers en e-mailprogramma's (niet eens op alle veelvoorkomende combinaties), en hebben vaak een belangrijk nadeel: als het mislukt, gaat de e-mail verloren.
Als je echt een subject nodig hebt, kan dat door een formulier op je pagina aan te bieden, dat gegevens stuurt naar een CGI-programma, dat de formuliergegevens naar je mailt met de gewenste onderwerpregel. Het formulier moet echter een input-veld hebben voor het emailadres van de bezoeker, en je moet maar hopen dat de bezoeker dit foutloos invult.
Hier zijn enkele andere manieren om onderwerp-achtige informatie over te brengen:
<A HREF="mailto:user@site" TITLE="Jouw Onderwerp">. De meeste browsers zullen het TITLE-attribuut negeren, maar sommige minder gebruikte browsers zullen het gebruiken als een subject voor het email-bericht. Alle browsers zullen de mail verzenden.<A HREF="mailto:user@site?subject=Jouw%20Onderwerp">, waarmee "Jouw Onderwerp" (de spatie wordt gecodeerd als "%20") in het "Subject" header veld van het e-mailbericht wordt gestopt door de meeste huidige browsers. De details van deze RFC kunnen worden gevonden op <URL:http://info.internet.isi.edu/in-notes/rfc/files/rfc2368.txt>. Merk wel op dat je mail zult kwijtraken van gebruikers van oudere browsers, dus je zult je moeten afvragen of het voor-ingevulde subject de verloren mail waard is.Gebruik gewoon de afbeelding als inhoud van de link, zoals hier:
<A HREF=...><IMG ...></A>
Gebruik het BORDER="0"-attribuut in hte <IMG>-element. Bijvoorbeeld:
<A HREF="doc.html"><IMG SRC="doc.gif" ALT="Bekijk document." BORDER="0"></A>
Gebruik een 'image map'. Client-side image maps hebben geen verwerking op de webserver nodig, waardoor de responssnelheid groter is. Server-side image maps verbergen de linkbestemmingen voor de browser, en kunnen dienen als backup voor client-side image maps voor de enkele hele oude browsers die wel server-side image maps ondersteunen maar geen client-side image maps.
De configuratiedetails van server-side image maps verschillen van server tot server. Zoek in de serverdocumentatie naar details.
Client-side image maps worden geïmplementeerd met HTML. Het MAP-element definieert een enkele image map en het AREA-element definieert specifieke gelinkte gebieden binnen die image map. Het USEMAP-attribuut van het IMG-element associeerd een image map met een bepaalde afbeelding. Een uitgebreide uitleg (met voorbeelden) is te vinden op <http://www.htmlhelp.com/reference/html40/special/map.html>. Een handleiding is te vinden op <http://ppewww.ph.gla.ac.uk/~flavell/www/imgmaptut.html>.
Als je de onderstreping van links uit wilt zetten bij het bekijken van pagina's in je browser, moet je de instellingen van je browser aanpassen . Bijvoorbeeld in Netscape 3, bij Options | General Preferences | Appearance; in Netscape 4 is het Edit | Preferences | Appearance | Colors; in Internet Explorer: View | Options | General.
Wanneer je wilt voorkomen dat links op jouw pagina worden onderstreept als bezoekers ze bekijken, is er geen manier voor om dit met HTML te bereiken. Je kunt het suggereren met behulp van stylesheets door te definiëren
a:link, a:visited, a:active {text-decoration: none}
Je kunt zo'n weergave suggereren met behulp van stylesheets. Stel in je stylesheet zoiets in:
a:link {color: blue; background: white}
a:visited {color: purple; background: white}
a:active {color: red; background: white}
a.foo:link {color: yellow; background: black}
a.foo:visited {color: white; background: black}
a.foo:active {color: red; background: black}
Gebruik dan CLASS="foo" om de links met de tweede kleur te identificeren in je HTML, zoals hier:
<A CLASS="foo" HREF=...>...</A>
Gebruik in je stylesheet de hover pseudo-class om een ander uiterlijk aan te geven voor links wanneer de cursor er boven hangt. Specificeer de hover pseudo-class na de link en visited pseudo-classes. Bijvoorbeeld:
A:link { color: blue ; background: white }
A:visited { color: purple ; background: white }
A:hover { color: red ; background: white }
Het meest waarschijnlijke is dat je een paar aanhalingstekens bent vergeten te sluiten aan het einde van een HREF-attribuut. Of je hebt misschien een ">"-teken gebruikt ergens anders binnen een tag. Alhoewel dit is toegestaan zullen sommige oudere browsers denken dat de tag daar ophoudt, zodat de rest wordt weergegeven als normale tekst.
Dit gebeurt vooral als je commentaartags gebruikt om tekst met HTML-tags "weg te commenten". (Zie het antwoord op "Hoe voeg ik commentaar in HTML in?") Alhoewel de juiste syntax <!-- --> is (zonder dat "--" ergens anders in het commentaar voorkomt), zullen sommige browsers denken dat het commentaar ophoudt bij de eerste ">" die ze zien.
Validators zullen je elke syntaxfout in je markup laten zien, maar checkers zoals Weblint en HTMLchek kunnen laten zien waar je bekende browserbugs uitlokt. Zo is het bijvoorbeeld van enkele versies van Netscape Navigator bekend dat ze moeite hebben met links naar benoemde ankers ("anchors") als de ankers zich in een tabel bevinden die het ALIGN-attribuut gebruikt. Zie ook het antwoord op "Hoe controleer ik op fouten?"
Een andere mogelijkheid is, dat de webontwerpsoftware gebruikt maakt van bestands-URL's (bijv. file:C:\pad\bestand.html). Als dat het geval is kun je ze vervangen door relatieve URL's (bijv. bestand.html) of http-URL's (bijv. http://server/pad/bestand.html).
Staat er een spatie, #, ?, of een ander speciaal teken in het pad van de bestandsnaam? Spaties zijn niet toegestaan in URL's. Wanneer je de spatie codeert door hem te vervangen door %20, werkt de link wel.
Elk teken in een URL kan worden gecodeerd als % plus de tweetallige hex waarde van het teken. (A-F in hexadecimale getallen kunnen zowel kleine letters als hoofdletters zijn.) Volgens de specificatie hoeven alleen alfanumerieke tekens en de speciale tekens $-_.,+!*'() niet te worden gecodeerd.
Alle andere tekens moeten worden gecodeerd wanneer ze in een URL voorkomen, behalve wanneer ze gebruikt worden voor hun gereserveerde doeleinden. Als je bijvoorbeeld de waarde "Jan&Jans" aan een CGI-script wilt doorgeven, moet je het "&"-teken coderen als "%26", wat bijvoorbeeld de volgende URL kan opleveren: http://www.foo.com/foo.cgi?rijm=Jan%26Jans&publiek=kind.
Merk op dat de "?" en andere "&" tekens in deze URL niet zijn gecodeerd, aangezien ze worden gebruikt voor hun gereserveerde doeleinden. Maar als deze URL wordt gebruikt als een attribuut-waarde in een HTML-document, moet het "&"-teken worden gedoceerd als "&", zoals hier: <A HREF="http://www.foo.com/foo.cgi?rijm=Jan%26Jans&publiek=kind">
Zie <URL:http://www.w3.org/Addressing/> voor de technische details.
Zodra het bestand geüploaded is naar de server, hoef je enkel nog met een ankerreferentie-tag ernaar te linken. Een voorbeeld kan zijn:
<a href="../files/foo.zip">Download Foo Nu! (100kb ZIP)</a>
Het is mogelijk dat de server anders ingesteld moet worden voor bepaalde bestandstypes. (Zie de volgende Q&A.)
Als je probeert een link te maken naar een bepaald bestandstypes en je krijgt niet de gewenste respons, dan bestaat de mogelijkheid dat de server ingesteld moet worden voor dat bestandstype. Neem contact op met de systeembeheerder om een bepaald 'content type' te laten toevoegen. Hier is een lijst van algemene bestandstypes die vaak een instelling nodig hebben:
| Content Type | Beschrijving |
|---|---|
| Application/msword | Microsoft Word-document |
| application/octet-stream | Ongeclassificeerde binaire data (vaak gebruikt voor gecomprimeerde of uitvoerbare bestanden) |
| application/pdf | PDF-document |
| application/wordperfect6.0 | WordPerfect 6.0-document |
| application/zip | ZIP-archief |
| audio/x-wav | WAV audio-bestandsformaat |
| audio/midi | MIDI audio-bestandsformaat |
| audio/x-pn-realaudio | RealAudio |
| image/gif | GIF afbeelding-bestandsformaat |
| image/jpeg | JPEG afbeelding-bestandsformaat |
| image/png | PNG afbeelding-bestandsformaat |
| text/html | HTML-document |
| text/plain | Gewone tekst |
| video/mpeg | MPEG video-bestandsformaat |
| video/quicktime | QuickTime video-bestandsformaat |
| video/x-msvideo | AVI video-bestandsformaat |
Een nadere manier om zeker te stellen dat jouw bestand goed wordt verzonden naar de aanvrager, is het comprimeren naar een standaard compressie-bestandsformaat. Praktisch alle servers zijn ingesteld om om te gaan met de .zip extensie en dit wordt ook algemeen herkend door gebruikers.
Sommige servers (NCSA, Apache, en anderen) kunnen worden ingesteld om door gebruikers geconfigureerde content types te ondersteunen. De details hangen van de server af, dus vraag je serverbeheerder of lees de documentatie.
Merk op dat Internet Explorer ten onrechte door de server geleverde MIME-types negeert, zodat het soms "goed werkt" terwijl de server verkeerd staat ingesteld. Andere browsers letten terecht wel op de door de server geleverde MIME-types, zodat ze verkeerd ingestelde servers ontmaskeren.
Dat kan je niet, want het web werkt niet op zo'n manier.
Als de browser een document aanvraagt (hypertext, afbeelding, geluid, multimedia, enz.), vertelt de server aan de browser wat het voor een soort bestand is. De server zou moeten worden ingesteld om de bestandssoort van een document's juist weer te geven, zoals beschreven in het antwoord op de vorige vraag.
De browser beslist dan wat er mee gaat gebeuren. De verschillende browsers zijn in staat om verschillende soorten documenten zelf weer te geven, en kunnen daar ook toe worden ingesteld. Browsers zijn meestal ingesteld om andere bestandssoorten te verwerken door ze door te geven aan een hulptoepassing, of ze bieden aan om het bestand op te slaan. Een webschrijver heeft geen mogelijkheid om de manier waarop de browser is ingesteld om een bepaalde bestandssoort te behandelen, te veranderen.
Dat kan je niet, want het web werkt niet op zo'n manier.
Zoals uitgelegd in het antwoord op de vorige vraag, is de server verantwoordelijk voor het juist identificeren van het bestandssoort van een document, en is de browser verantwoordelijk voor de keuze hoe her document afgehandelt moet worden (gebaseerd op het bestandssoort). Een webschrijver heeft geen mogelijkheid om de manier waarop de browser is ingesteld om een bepaalde bestandssoort te behandelen, te veranderen.
De meeste browsers laten de gebruiker naar schijf downloaden als de gebruiker dat wil. Als het bestand op de harde schijf moet worden bewaard, als er echt GEEN andere manier is om hiermee om te gaan, dan moet het MIME-type "application/octet-stream" zijn.
Zie de volgende informatiebronnen:
Een thumbnail is gewoon een kopie van de volledige afbeelding, die is aangepast om de bestandsgrootte te verminderen. Het is gelinkt met de volledige afbeelding met een normale link:
<A HREF="groot-formaat.jpg"><IMG SRC="thumbnail.jpg" ALT=...></A>
Er zijn diverse technieken voor het verminderen van de bestandsgrootte van de thumbnail, waaronder
Thumbnails kunnen meeerdere technieken gelijktijdig gebruiken. Jakob Nielsen bijvoorbeeld bepleit "Relevance-Enhanced Image Reduction", waarin resamplen/resizen en uitsnijden worden gecombineerd.
Dat komt door het opnemen van "witruimte" (spaties en regeleindes) voor of na een IMG binnen een link-anker. Bijvoorbeeld:
<A HREF=...>
<IMG SRC=...>
</A>
leidt tot witruimte links en rechts van de afbeelding. Aangezien veel browsers ankers standaard weergeven met gekleurde onderstrepingen, geven ze de spaties links en rechts van de afbeelding aan met een gekleurd liggend streepje.
Oplossing: laat geen enkele witruimte achter tussen de anker-tags en de IMG- tag. Als de regel te lang wordt, breek hem dan binnen de tag af in plaats van daarbuiten, zoals hier:
<A HREF=...><IMG
SRC=...></A>
'Style checkers' zoals Weblint zullen je van dit probleem in je HTML broncode op de hoogte stellen.
Er zijn twee manieren om dit aan te pakken. De meest cache-vriendelijke manier is het gebruik van een normale IMG-tag die verwijst naar een CGI-script, dat de browser willekeurig doorverwijst naar een van de diverse afbeeldingen. Er is een voorbeeld van zo'n CGI-script op <URL:http://www.foad.org/%7Eabigail/CGI/random_images.html>. Zie de 'CGI Programming FAQ' <URL:http://www.htmlhelp.com/faq/cgifaq.html> voor meer informatie over CGI.
De tweede manier is om de HTML dynamisch aan te maken met een methode als Server Side Includes (SSI) of CGI. Deze manier is minder cache-vriendelijk, maar het maakt het mogelijk dat de omringende markup (bijv. HEIGHT- en WIDTH-attributen, of de URLs voor gelinkte of image-map afbeeldingen) verschillen al naar gelang de afbeelding. Als jouw server SSI ondersteund, kunnen de details in je serverdocumentatie worden gevonden.
Het meest waarschijnlijke is dat je een paar aanhalingstekens bent vergeten te sluiten aan het einde van een SRC-attribuut. Of je hebt misschien een ">"-teken gebruikt binnen een ALT-tekst of ergens anders binnen een tag. Dit is toegestaan, maar sommige oudere browsers zullen denken dat de tag daar ophoudt, zodat de rest wordt weergegeven als normale tekst.
Dit gebeurt vooral als je commentaar-tags gebruikt om tekst met HTML-tags "weg te commenten". (Zie het antwoord op "Hoe voeg ik commentaar in HTML in?") Alhoewel de juiste syntax <!-- --> is (zonder dat "--" ergens anders in het commentaar voorkomt), zullen sommige browsers denken dat het commentaar ophoudt bij de eerste ">" die ze zien./p>
Validators zullen je elke syntax-fout in je markup laten zien, maar checkers zoals Weblint en HTMLchek kunnen laten zien waar je bekende browserbugs uitlokt. Zie ook het antwoord op "Hoe controleer ik op fouten?"
Hier zijn enkele andere mogelijkheden:
Dat kun je niet voorkomen. De browser heeft het afbeeldingsbestand nodig om het document weer te geven; je moet het versturen aan de browser. Zelfs als een bepaalde browser geen "Afbeeldingen Opslaan" mogelijkheid heeft, zijn er velen die dat wel hebben, en iemand kan altijd het bestand met de hand ophalen (met behulp van telnet) of uit de browser's cache halen.
Er zijn trucs die het voor sommige lezers moeilijker maken om je afbeeldingen op te slaan. Maar, net zoals met trucs die proberen om de HTML-broncode te verbergen, veroozaken deze trucs diverse problemen voor rechtschapen gebruikers, en voorkomen ze niet echt dat dieven jouw afbeeldingen opslaan.
Nee. Teken-entiteiten (©, &#nnn; enzo) zijn echter wel toegestaan.
Als je wilt weten hoe je goede ALT-teksten kunt schrijven zonder markup, bekijk dan eens Alan Flavell's essay met betrekking tot het kiezen van ALT-teksten op <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/alt/alt-text.html>.
De meeste browsers ondersteunen het EMBED-element hiervoor, vooropgesteld dat de gebruiker een geschikte plug-in heeft voor het geluidsbestand. Je kunt een iets groter publiek bereiken als je ook BGSOUND gebruikt. Plaats de BGSOUND in een NOEMBED container om problemen te vermijden met browsers die beiden ondersteunen:
<EMBED SRC="jouw_geluidsbestand" HIDDEN="true" AUTOSTART="true">
<NOEMBED><BGSOUND SRC="jouw_geluidsbestand"></NOEMBED>
Zie voor meer informatie over het EMBED-element <URL:http://developer.netscape.com/docs/manuals/htmlguid/tags14.htm#1286379>. Zie <URL:http://msdn.microsoft.com/developer/sdk/inetsdk/help/dhtml/references/html/BGSOUND.htm> voor meer informatie over het BGSOUND-element. Merk op dat deze elementen proprietary zijn en niet zijn opgenomen in enige HTML-standaard. (De HTML-standaard manier om dit te doen wordt niet goed ondersteund.)
Wees er op bedacht dat sommige gebruikers het vervelend vinden als muziek automatisch begint te spelen. Mogelijk staat de geluidssterkte niet goed op hun speakers, of zijn ze naar iets anders aan het luisteren. Je zou, uit beleefdheid naar de gebruikers, het geluidsbestand kunnen aanbieden als een link:
<A HREF="jouw_geluidsbestand">Luister naar mijn geluid! (5 kB MIDI)</A>
De meeste browsers hebben een "save as" functie die het mogelijk maakt om het bestand als platte tekst op te slaan. Een andere manier is het selecteren van alle tekst, dit kopiëren naar het kladblok en het te plakken in een tekstverwerker.
Lynx gebruikers kunnen "lynx -dump http://..." op de commandoregel gebruiken om te printen naar een bestand en een lijst van gelinkte URL's als voetnoten toe te voegen. Als je het uitgevoerde bestand wilt zonder de voetnoten, gebruik dan het "p" commando om te "printen" naar een tekst bestand.
Sommige HTML-ontwerp hulpmiddelen hebben ook een optie om alle HTML te verwijderen. Twee interessante programma's zijn
Als je een andere manier zoekt (oftewel, je wilt het jezelf moeilijk maken), dan kun je programma's gebruiken die alle HTML markup van een document verwijderen. Probeer het met een zoekopdracht bij <URL:http://www.altavista.com/> met de tekst "HTML stripper".
De beste mogelijkheid is waarschijnlijk het gebruik van een gecentreerde IMG met een lijn van "--" tekens als ALT-tekst:
<P ALIGN=center><IMG SRC="custom-line.gif" ALT="--------------------"></P>
Voor een experimentele maar wat elegantere aanpak, kun je over "CSS1 and the Decorative HR" lezen op <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/www/hrstyle.html>.
Voor aangepaste bullets zijn er verschillende methodes, geen van allen echt bevredigend:
<DL> met <DD> -tags met voorafgaande afbeeldingen (met ALIGN en een geschikte ALT-tekst) en geen <DT>; dit zal niet zo mooi zijn als een "echte" lijst.Een bezoekteller is een klein script of programma dat, telkens als een document wordt benaderd vanaf de server, een nummer ophoogt.
Waarom wil je er een? Als je denkt dat het je zal vertellen hoe vaak jouw documenten worden benaderd, dan heb je het mis. Geen enkele teller kan bezoeken vanaf browser-caches of proxy-caches bijhouden. Sommige tellers gebruiken het inlezen van afbeeldingen om de teller te verhogen; deze tellers negeren bezoeken van tekst-browsers, of van browsers met het inladen van afbeeldingen uitgeschakeld, of van gebruikers die de overdracht hebben onderbroken. Sommige tellers vereisen zelfs toegang tot een site op afstand, die onbereikbaar of overbelast kan zijn, wat een vertraging veroorzaakt bij het weergeven van je documenten.
De meeste webservers houden een logboek bij van bezoeken aan documenten die opgeslagen zijn op de server. Deze 'logs' kunnen worden bewerkt om informatie te verkrijgen over het *relatieve* aantal bezoeken over een langere periode. Er is geen reden om dit getal op te presenteren aan je bezoekers, omdat zij geen referenties hebben om dit getal mee te vergelijken. Niet alle dienstverleners geven toegang tot server logs, maar velen hebben scripts die informatie geven over bezoek aan een bepaald document. Raadpleeg je systeembeheerder of dienstverlener voor details.
Teller-diensten en informatie zijn beschikbaar vanaf Yahoo's lijst met tellers: http://dir.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/Programming/Access_Counters/
Een bespreking van de beperkingen van webverkeerstatistieken is te vinden op <URL:http://www.cranfield.ac.uk/docs/stats/>
Met 'server-side includes'. Vraag aan je webmaster of dit wordt ondersteund, en wat de exacte syntax is voor jouw server. Maar dit zal de lokale tijd op de server weergeven, niet de tijd bij de gebruiker. En als het document is gecached, dan zal de datum na verloop van tijd natuurlijk verkeerd zijn. JavaScript kan worden gebruikt voor de lokale tijd van de gebruiker, maar nogmaals, aangezien de meeste mensen al een of meer klokken op hun scherm hebben, waarom nog eentje erbij?
Als je van plan bent de huidige datum of tijd op je pagina's te plaatsen, met behulp van een CGI, JavaScript of VBScript, tel tot tien en bedenk dat het netwerkbronnen verbruikt, de laadtijd van je pagina doet toenemen en goede caching voorkomt. Als je denkt dat het echt nodig is, bijvoorbeeld om lezers te informeren over de up-times van een FTP-server, prima, ga je gang. Maar als, aan de andere kant, de enige reden is 'het ziet er cool uit!' - denk dan nog eens na.
Dit is geen HTML-vraag; het wordt gedaan met JavaScript. Bekijk een pagina die het heeft, en kopieer het script vanuit de bron.
Dit script heeft twee grote problemen. Ten eerste: gewoonlijk gebruikt het script ergens de decrement operator (c--). De "--" tekst in een commentaar sluit dit commentaar af in sommige browsers, waardoor je code kan "lekken". Hetzelfde geldt voor ">".
Ten tweede, bedenk dat veel mensen dit zelfs erger dan <BLINK> vinden, en dat het ook de status informatie onderdrukt die normaal gesproken in de statusbalk verschijnt. Het belemmert mensen in het zien waar een link naar toe gaat.
Je kan het ALIGN=right attribuut gebruiken met paragrafen, divisies en headers, net zoals je align=center gebruikt om gecentreerde paragrafen te maken en dergelijke. Dit zorgt voor het rechts uitlijnen van de tekst (links gebroken).
Misschien wil je eigenlijk de tekst uitvullen, waarmee zowel op de linker- als op de rechterkantlijn is uitgelijnd, zodat alle regels even lang zijn. (Dit wordt soms onterecht "rechts uitvullen" genoemd.) Er is geen manier om tekst uit te vullen in HTML 3.2, maar het kan wel met een CSS1 stylesheet met "text-align: justify". (Voordat je dit doet, een voorbehoud: alhoewel uitgevulde tekst er mooier uit kan zien, blijkt uit analyse van menselijke eigenschappen dat links uitlijnen, rechts gebroken, in de praktijk makkelijker te lezen en te begrijpen is.)
Voor afbeeldingen kan je <IMG ALIGN=right SRC="..." ALT="..."> gebruiken voor de lopende tekst. De afbeelding zal gaan zweven aan de rechterkantlijn, en de lopende tekst zal er omheen vloeien. Vergeet niet om <BR CLEAR=right> of <BR CLEAR=all> te gebruiken om het einde van de tekst aan te geven die op deze manier beïnvloed wordt.
Zorg ervoor, als de afbeeldingen zich in en tabel bevinden, dat de BORDER-, CELLSPACING- en CELLPADDING-attributen op 0 staan. Extra ruimte tussen afbeeldingen wordt ook vaak veroozaakt door witruimte ronden om <IMG>-tag in de markup. Vervang bijvoorbeeld dit:
<TD ...>
<IMG SRC=... ALT=...>
<IMG SRC=... ALT=...>
</TD>
door dit:
<TD ...><IMG SRC=... ALT=...><IMG SRC=... ALT=...></TD>
Volgens de laatste specificaties zouden deze twee hetlzefde moeten betekenen. Maar gebruikelijke browsers houden zich in dit geval niet aan de specificaties.
Gebruik een stylesheet met de volgende regel:
P { text-indent: 5% }
Zie <URL:http://www.rc.tudelft.nl/mirhtml/css/css.htm> voor meer informatie over stylesheets.
Gebruik een stylesheet om een linkermarge voor het hele document of een deel daarvan in te stellen:
/* Het hele document */
BODY { margin-left: 20% }
/* Een deel van een document met CLASS="foo" */
.foo { margin-left: 15% }
Zie <URL:http://www.rc.tudelft.nl/mirhtml/css/css.htm> voor meer informatie over stylesheets.
De meest geëigende manier is het voorstellen van marges met een stylesheet. Cascading Style Sheets gebruiken de margin-eigenschap om margen vast te stellen. Meer informatie over Cascading Style Sheets kan worden gevonden op: http://www.rc.tudelft.nl/mirhtml/css/css.htm
Meer informatie over de margin-eigenschap van CSS kan worden gevonden op: http://www.rc.tudelft.nl/mirhtml/css/margin.htm
Met fabrikant-eigen HTML-uitbreidigen, kunt u de marges voor bepaalde browsers instellen. Internet Explorer 3+ ondersteund de TOPMARGIN- en LEFTMARGIN-attributen. Internet Explorer 4+ voegde ondersteuning toe voor de BOTTOMMARGIN- en RIGHTMARGIN-attributen. Navigator 4+ ondersteunt de MARGINWIDTH- en MARGINHEIGHT-attributen. De meeste andere browsers negeren deze fabrikant-eigen uitbreidigen.
CSS en fabrikant-eigen HTML kannen worden geombineerd. Het volgende is in de meeste browse-situaties effectief:
<body marginheight="0" topmargin="0" vspace="0" marginwidth="0" leftmargin="0" hspace="0" style="margin:0">
Meer informatie is beschikbaar op <URL:http://www.hut.fi/u/jkorpela/www/margins.html
Merk ook op dat Navigator altijd rechts ruimte overlaat voor een schuifbalk, maar deze alleen op het scherm tekent als het document lang genoeg is om chuiven nodig te hebben. Als het document geen schuiven nodig heeft, blijft er een rechter"marge" achter die niet kan worden verwijderd.
Pagina-eindes zijn mogelijk met Cascading stylesheets, Level 2, maar dat wordt niet goed ondersteund door browsers. Zie <URL:http://www.w3.org/TR/REC-CSS2/page.html#page-breaks> voor informatie over CSS2 pagina-eindes.
In het algemeen geldt, dat pagina-eindes niet toepasselijk zijn op het web omdat wat voor jou een leuk pagina-einde is, met jouw lettertype en -grootte, voor mij een onhandig pagina-einde kan zijn, met mijn lettertype en -grootte.
Als je een netjes opgemaakt afdrukexemplaar moet hebben van je HTML-documenten, kun je ook overwegen om speciaal daarvoor gemaakte hulpmiddelen te gebruiken, in plaats van de Afdrukfunctie van de browser. Zo maakt html2ps netjes opgemaakte PostScript output van HTML-documenten, en gebruikt HTML Scissor speciale HTML-commentaren om pagina-einders te suggereren.
Als je wilt dat anderen jouw webpagina met een bepaald lettertype zien, is de meest geschikte manier hiervoor het voorstellen van de lettertype-weergave met een stylesheet. Cascading Style Sheets gebruikt de font-family-eigenschap om lettertypes op te geven. Meer informatie over Cascading Style Sheets is te vinden op: http://www.rc.tudelft.nl/mirhtml/css/css.htm
Meer informatie over de CSS-eigenschap font-family is te vinden op: http://www.rc.tudelft.nl/mirhtml/css/font.htm#font-family
In HTML kan ook het BASEFONT-element worden gebruikt om een bepaald lettertype voor te stellen voor het gehele document. Het BASEFONT-element beïnvloed het gehele document. Meer informatie over het BASEFONT-element is te vinden op: http://www.rc.tudelft.nl/mirhtml/element/basefont.htm
In HTML kan ook het FONT-element worden gebruikt om een bepaald lettertype voor te stellen. Het FONT-element moet binnen elke blok-element worden herhaald, aangezien het zelf alleen maar inline (tekst-niveau) elementen kan bevatten. Gebruik van het FONT-element brengt meerdere bruikbaarheids- en toegankelijkheidsproblemen met zich mee, zie: http://www.mcsr.olemiss.edu/%7Emudws/font.html
Meer informatie over het FONT-element is te vinden op: http://www.rc.tudelft.nl/mirhtml/element/font.htm
Met beide methodes lopen auteurs het risico dat het systeem van een lezer een lettertype heeft met dezelfde naam, dat heel anders is. "Chicago" kan bijvoorbeeld een leuk tekst-lettertype, of een display-lettertype met letters gemaakt met "kogelgaten", of een dingbat-lettertype met plaatjes van gebouwen zijn (voor het maken van skylines).
Verder moeten auteurs ofwel een lettertypes (of een groep van verwante lettertypes) gebruiken die algemeen beschikbaar zijn op veel systemen, of dynamische fonts aanbieden aan hun lezers. Als het lettertype niet is geïnstalleerd op het systeem van de lezer, of de lezer haalt het dynamische lettertype niet binnen, dan krijgt deze een standaard lettertype te zien. Sommige browsers kunnen een vervangend lettertype gebruiken dat minder leesbaar is dan hun normale standaard lettertype, indien het voorgestelde lettertype niet is gevonden.
Netscape en Microsoft hebben concurrende formaten voor dynamische lettertypes ontwikkeld. TrueDoc werkt met Navigator 4+ en (met een plug-in) met Internet Explorer 4+. OpenType werkt met Internet Explorer 4+. Zie voor meer informatie over TrueDoc (inclusief de WebFont Maker): http://www.truedoc.com/webpages/intro/
Zie voor meer informatie over OpenType (inclusief Microsoft's Web Embedding Fonts Tool (WEFT)) http://www.microsoft.com/typography/web/
Zie voor practisch advies met betrekking tot het gebruik van lettertypes op het web Todd Fahrner's "Beyond the FONT tag: Practical HTML text styling" op: <http://style.metrius.com/font_size/livetext.html>
Als je wilt dat anderen uw webpagina met bepaalde kleuren zien, is de meest geschikte manier hiervoor het voorstellen van de kleuren met een stylesheet. Cascading Style Sheets gebruiken de eigenschappen color en background-color om tekst- en achtergrondkleur op te geven. Om tegenstrijdigheden tussen de standaard-kleuren van de lezer en de door de auteur opgegeven kleuren te voorkomen, dienen deze twee eigenschappen altijd tegelijk te worden gebruikt. Meer informatie over Cascading Style Sheets is te vinden op: http://www.rc.tudelft.nl/mirhtml/css/css.htm
Meer informatie over de CSS-eigenschap color is te vinden op: http://www.rc.tudelft.nl/mirhtml/css/color.htm#color
Meer informatie over de CSS-eigenschap background-color is te vinden op: http://www.rc.tudelft.nl/mirhtml/css/color.htm#background-color
In HTML kun je kleuren voorstellen met de TEXT-, LINK-, VLINK- (bezochte link), ALINK- (actieve link) en BGCOLOR- (achtergrondkleur) -attributen van het BODY-element. Als een van hen wordt gebruikt, dan moeten ze allemaal worden gebruikt om te verzekeren dat de standaardkleuren van de lezer niet door de kleuren die door de auteur zijn opgegeven heen lopen. Hier volgt een voorbeeld:
<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#800080" alink="#000080">
Meer informatie over het BODY-element is te vinden op: http://www.rc.tudelft.nl/mirhtml/element/body.htm
Auteurs moeten er niet van uit gaan dat de opgegeven kleuren worden gebruikt, aangezien browsers het voor de gebruikers mogelijk maken, om de in documenten opgegeven kleuren uit te schakelen.
De meest geschikte manier is het gebruiken van toepasselijke structurele markup, en de gewenste kleur op te geven met een stylesheet. Als je een kleur alleen in bepaalde gevallen wilt opgeven voor een element, kun je een 'class' gebruiken om aan te geven welke gevallen dat zijn. In het volgende CSS-voorbeeld is opgegeven dat benadrukte tekst met de 'class' "speciaal" groen moet zijn (met een witte achtergrond):
EM.speciaal { color: green; background: white; }
Wanneer de weergave plaatsvind met deze CSS-regels, zal de benadrukte tekst in het volgende HTML-voorbeeld in het groen worden weergegeven:
normale tekst <EM CLASS="speciaal">nebadrukte tekst</EM> normale tekst
Meer informatie over Cascading Style Sheets is te vinden op: http://www.rc.tudelft.nl/mirhtml/css/css.htm
In HTML kan ook het FONT-element worden gebruikt om kleuren voor te stelllen. Gebruik van het FONT