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-element brengt meerdere gebruiks- 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
Als je wilt dat anderen jouw webpagina zien met een bepaalde achtergrondafbeelding, is de meest geschikte manier hiervoor het voorstellen van de achtergrond met een stylesheet. Cascading Style Sheets gebruiken de eigenschap background-image om een achtergrondafbeelding 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 background-image is te vinden op: http://www.rc.tudelft.nl/mirhtml/css/color.htm#background-image
Met HTML kun je een gestapelde achtergrondafbeelding voorstellen met het BACKGROUND-attribuut van het BODY-element. Hier volgt een voorbeeld:
<body background="afbeeldingsbestand.gif" 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
Als je een achtergrondafbeelding opgeeft, moet je ook tekst-, link-, en achtergrondkleuren opgeven (zie het antwoord op de vraag "Hoe kan ik kleuren aangeven?") aangezien de standaardkleuren van de lezer mogelijk niet genoeg contrast geven tegenover jouw achtergrondafbeelding. De achtergrondkleur zal worden toegepast door degenen die geen afbeeldingen laden. Auteurs moeten er niet rekenen op de opgegeven achtergrondafbeelding, aangezien browsers het voor de gebruikers mogelijk maken om het laden van afbeeldigen uit te zetten, of om in documenten opgegeven achtergronden uit te schakelen.
Gebruik een stylesheet met de volgende regel:
body { color: black; background: white url(foo.gif) fixed }
Merk op dat de fixed
eigenschap, die in het bovenstaande stylesheet is gebruikt, wordt ondersteund door Internet Explorer 3+, Netscape Navigator 5+, en andere browsers. Het proprietary BGPROPERTIES=fixed
attribuut daarentegen wordt alleen ondersteund door Internet Explorer 3+.
Gebruik een stylesheet met de volgende regel:
body { color: black; background: white url(foo.gif) no-repeat }
Dit is een mogelijkheid die door Internet Explorer 5.x is geïntroduceerd. De browser vraagt standaard een bestand genaamd "favicon.ico" aan, op hetzelfde basis-URL als het document dat wordt gebookmarkt. Als het dit bestand niet kan vinden, zal het ook nog eens een poging doen in de rootdirectory van je site. Webauteurs kunnen een ander pad opgeven voor het pictogrambestand met een <LINK>
-element zoals dit: <LINK REL="SHORTCUT ICON" HREF="/padnaam/bestandsnaam.ico">
De afbeelding moet 16 bij 16 pixels groot zijn, in het Windows pictogram-bestandsformaat. Als je grafische programma het Windows pictogram-bestandsformaat niet ondersteunt, kun je een hulpmiddel gebruiken zoals de gratis Java-gebaseerde pictogram-generator op <URL:http://www.favicon.com/> om je pictogram te converteren/creeëren.
Zie voor meer informatie <URL:http://msdn.microsoft.com/workshop/Author/dhtml/howto/ShortcutIcon.asp> of zoek naar "favicon.ico" op <URL:http://msdn.microsoft.com/workshop/essentials/versions/ICPIE5.asp>
Zie Alan Flavell's document met betrekking tot tabellen voor een goede behandeling, te vinden op <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/www/tablejob.html>.
Ja, een tabel kan worden opgenomen in een cel van een andere tabel. Hier is een eenvoudig voorbeeld:
<table>
<tr>
<td>dit is de eerste cel van de buitenste tabel</td>
<td>dit is de tweede cel van de buitenste tabel,
met de binnenste tabel daarin opgenomen<br>
<table>
<tr>
<td>dit is de eerste cel van de binnenste tabel</td>
<td>dit is de tweede cel van de binnenste tabel</td>
</tr>
</table>
</td>
</tr>
</table>
De belangrijkste valkuil met genestte tabellen is dat Netscape er problemen mee heeft, wanneer je de TD- and TR-tags niet consequent afsluit. Het is het verstandigste om elke </TD> en </TR> te plaatsen, ook al wordt dat niet vereist in de HTML specificatie; als je dat niet doet, kunnen Netscape-gebruikers mogelijk jouw pagina niet bekijken.
Kleine formulieren worden soms binnen een TD-element in een tabel gezet. Dit kan nuttig zijn voor het plaatsen van een formulier ten opzichte van andere inhoud, maar het helpt niet bij plaatsen van de formulier-items ten opzichte van elkaar.
Om formulieren-items ten opzichte van elkaar te plaatsen, moet de gehele tabel zich binnen het formulier bevinden. Je kunt niet een formulier beginnen in het ene TH- of TD-element en eindigen in een andere. Je kunt geen formulier in een tabel plaatsen zonder het binnen een TH- of TD-element te zetten. Je kunt wel de tabel binnen in het formulier zetten, en dan de tabel gebruiken om de INPUT-, TEXTAREA-, SELECT- en andere formulier-items te plaatsen, zoals in het volgende voorbeeld wordt getoond.
<FORM ACTION="[URL]">
<TABLE BORDER="0">
<TR>
<TH>Account:</TH>
<TD><INPUT TYPE="text" NAME="account"></TD>
</TR>
<TR>
<TH>Password:</TH>
<TD><INPUT TYPE="password" NAME="wachtwoord"></TD>
</TR>
<TR>
<TD> </TD>
<TD><INPUT TYPE="submit" NAME="Inloggen"></TD>
</TR>
</TABLE>
</FORM>
De "juiste" manier om dit te doen is <TABLE ALIGN=CENTER>
, maar dit werkt niet in meerdere populaire browsers. Zet <CENTER>
rondom de hele tabel voor deze browsers.
Dit veroorzaakt enkele problemen met browsers die wel CENTER ondersteunen, maar geen tabellen, zoals Lynx. In deze browsers wordt de inhoud van de cellen nu gecentreerd weergegeven, en dat is niet de bedoeling. Om dit te voorkomen kun je de inhoud van de cellen in <P ALIGN=left>
of <DIV ALIGN=left>
plaatsen, afhankelijk van de hoeveelheid tekst in de cel.
Je kunt <TABLE ALIGN="right">
gebruiken om een tabel rechts te laten zweven. (Gebruik ALIGN="left"
om aan de linkerkant te zweven.) Alle inhoud die na de afsluitende </TABLE>
-tag verschijnt, zal rond de tabel stromen. Gebruik <BR CLEAR="right">
of <BR CLEAR="all">
om het einde aan te geven van de tekst die rond te tabel moet stromen, zoals getoond in dit voorbeeld:
<TABLE ALIGN="right">...</TABLE>
De tabel zal aan de rechterkant zweven.
Deze tekxt zal links links van de tabel verschijnen.
<BR CLEAR="right">
Deze tekst zal onder de tabel verschijnen,
zelfs als er geboeg ruimte over is links naast de tabel.
De HTML 3.2 en HTML 4.0 specificaties staan alleen maar gehele getallen (die een aantal pixels aangeven) toe als waarden voor het WIDTH-attribuut van het TD-element. De HTML 4.0 DTD staat echter wel percentages (en andere niet gehele getallen) toe als waarde, dus een HTML-validator zal niet klagen over <TD WIDTH="xx%">
.
Het moet worden opgemerkt dat Netscape's en Microsoft's browsers percentages voor <TD WIDTH=...> afwijkend interpreteren. Hun interpretaties (en die van andere table-herkennende browsers) zijn echter hetzelfde wanneer ze worden gecombineerd met <TABLE WIDTH="100%">. In zo'n situatie kunnen percentages als waarden tamelijk veilig gebruikt worden, ook al zijn ze niet toegestaan volgens de openbare specificaties.
Grafische browsers laten een smalle marge open tussen de rand van het weergavegebied en de inhoud. Zie het antwoord op de vraag "Hoe verwijder ik de marges rondom mijn pagina?" voor informatie over het zo instellen van de browser, dat deze de marges verwijdert.
Merk ook op dat Navigator altijd ruimte aan de rechterkant overlaat voor een schuifbalk, maar deze schuifbalk alleen maar tekent als het document zo lang is dat schuiven nodig is. Als het document geen schuiven nodig heeft, blijft er een rechter-"marge" over, die niet verwijderd kan worden.
Dit wordt vaak veroorzaakt door een ongeldige HTML-syntax. Met name losse inhoud binnen een tabel (bijv. inhoud die niet binnen een TD- of TH-element valt). Er is geen standaardmanier om losse inhoud in een tabel te behandelen. Sommige browsers geven alle losse inhoud voor of na de tabel weer. Als de losse inhoud alleen meerdere regelomlopen of lege alinea's bevat, zullen deze browsers al deze lege ruimte voor of na de tabel zelf weergeven.
De oplossing is het repareren van de HTML-syntaxfouten. Alle inhoud in een tabel moet binnen een TD- of TH-element vallen.
In de huidige browsers moet de gehele tabel worden binnengehaald en moeten de afmetingen van alles in de tabel bekend zijn voordat de tabel kan worden opgebouwd. Dit kan het weergeven van uw inhoud vertragen, vooral als uw tabel veel afbeeldingen zonder HEIGHT- of WIDTH-attributen bevat.
Als een van de elementen binnen een tabel te breed is voor de beschikbare weergaveruimte, dan zal de tabel uitgerekt worden om de te grote inhoud te kunnen omvatten. De rest van de inhoud past zich dan aan om in de uitgerekte tabel te passen, in plaats van zich aan te passen aan de beschikbare weergaveruimte. Hierdoor kunnen uw bezoekers gedwongen worden om horizontaal te schuiven om de inhoud te kunnen lezen, of kunnen afgedrukte versies worden afgekapt.
Bij lezers die een een smaller weergavegebied hebben dan de auteur verwachtte, veroorzaken tabellen met een vaste breedte dezelfde problemen als andere uitgerekte tabellen. Bij lezers die een weeragvegebied hebben dat groter is dan de auteur verwachtte, veroorzaken tabellen met een vaste breedte extreem brede marges, wat verspilling is van het weergavegebied. Voor lezers die grotere lettertypes nodig hebben, kunnen tabellen met een vaste breedte er voor zorgen dat de inhoud in korte afgebroken regels met slechts een paar woorden wordt weergegeven.
Veel browsers zijn erg gevoelig voor ongeldige syntax waar het tabellen betreft. Goede syntax is een kritische factor. Zie het antwoord op "Hoe controleer ik op fouten?". Zelfs met goede syntax kunnen genestte tabellen mogelijk verkeerd worden weergegeven in Netscape. Zie het antwoord op "Kan ik een tabel in een tabel plaatsen (nesten)?" voor oplossingen hiervoor.
Sommige browsers negeren tabellen, of kunnen worden ingesteld om tabellen te negeren. Deze browsers zullen de hele layout die u met tabellen heeft gemaakt negeren. Ook zoekmachines negeren tabellen. Sommige zoekmachines gebruiken de tekst aan het begin van een document voor een samenvatting bij het weergeven van zoekresultaten, sommigen indexeren enkel de eerste n bytes van een document. Als tabellen worden gebruikt voor layout, zal het begin van een document meestal veel navigatie-links bevatten die verschijnen voor de eigenlijke inhoud.
Veel versies van Navigator hebben problemen met het verwijzen naar benoemde ankers als deze zich in een tabel bevinden, die gebruikt maakt van het ALIGN-attribuut. Deze browsers lijken het benoemde anker te verbinden met de bovenkant van de tabel, in oplaats van met de inhoud van het anker. U kunt dit probleem vermijden door het ALIGN-attribuut niet met uw tabellen te gebruiken.
Als je tabellen voor layout gebruikt, kun je toch de hiermee samenhangende problemen beperken door zorgvuldige markup. Vermijd het plaatsen van brede afbeeldingen, PRE-elementen met lange lijnen, lange URL's, of andere brede inhoud in tabellen. Gebruik in plaats van één enkele layout-tabel voor de hele pagina, meerdere zelfstandige tabellen. u kunt bijvoorbeeld een tabel gebruiken om een navigatiebalk boven of onder aan een pagina op te maken, en het hoofddeel geheel buiten een layout-tabel laten.
Het gebruik van tabellen voor opmaak wordt uitgebreid onderzocht in <URL:http://www.dantobias.com/webtips/tables.html>.
De basissyntax voor een formulier is: <FORM ACTION="[URL]">...</FORM>
Als een formulier wordt ingezonden ('submitted'), worden de formuliergegevens verzonden naar de URL die is opgegeven in het ACTION
-attribuut. Deze URL moet verwijzen naar een programma op de server (bijv. een CGI-programma) die de formuliergegevens zal verwerken. Het formulier zelf moet bevatten
<INPUT TYPE="submit" ...>
-element),Een uitgebreidere uitleg van het gebruik van formulieren is te vinden op <URL:http://www.hut.fi/u/jkorpela/forms/>. Als je CGI-programma's op je server wilt installeren, zijn dit nuttige bronnen:
De enige betrouwbare methode voor het verwerken van formulierinzendingen is een programma op de server (bijv. een CGI-programma). Om formuliergegevens naar jezelf toegemaild te krijgen, moet je een server-side programma gebruiken dat de formulierinzendingen verwerkt en de gegevens naar jouw email-adres toestuurt.
Web-dienstverleners (ISP's) hebben vaak standaard form-to-email programma's beschikbaar voor hun klanten. Vraag je eigen ISP naar de details.
Als je CGI-programma op je eigen server kan installeren, kijk dan bij het antwoord op de vorige vraag voor een lijst met nuttige hulpmiddelen.
Als je geen CGI-programma's op je eigen server mag draaien, kun je een op afstand beheerde form-to-email dienst gebruiken. Een lijst met zulke dienstverleners is te vinden op <URL:http://www.cgi-resources.com/Programs_and_Scripts/Remotely_Hosted/Form_Processing/>. Merk op dat de aanbieder van een op afstand beheerde dienst toegang zal hebben tot alle gegevens die met de dienst worden ingezonden.
Formulieren die gebruikmaken van ACTION="mailto:..."
zijn onbetrouwbaar. Mogelijk werken ze voor sommige van je gebruikers, maar ze mislukken voor anderen die afwijkende software configuraties hebben.
Kleine formulieren worden soms binnen een TD-element in een tabel gezet. Dit kan nuttig zijn voor het plaatsen van een formulier ten opzichte van andere inhoud, maar het helpt niet bij plaatsen van de formulier-items ten opzichte van elkaar.
Om formulieren-items ten opzichte van elkaar te plaatsen, moet de gehele tabel zich binnen het formulier bevinden. Je kunt niet een formulier beginnen in het ene TH- of TD-element en eindigen in een andere. Je kunt geen formulier in een tabel plaatsen zonder het binnen een TH- of TD-element te zetten. Je kunt wel de tabel binnen in het formulier zetten, en dan de tabel gebruiken om de INPUT-, TEXTAREA-, SELECT- en andere formulier-items te plaatsen, zoals in het volgende voorbeeld wordt getoond.
<FORM ACTION="[URL]">
<TABLE BORDER="0">
<TR>
<TH>Account:</TH>
<TD><INPUT TYPE="text" NAME="account"></TD>
</TR>
<TR>
<TH>Password:</TH>
<TD><INPUT TYPE="password" NAME="wachtwoord"></TD>
</TR>
<TR>
<TD> </TD>
<TD><INPUT TYPE="submit" NAME="Inloggen"></TD>
</TR>
</TABLE>
</FORM>
Het korte antwoord is dat het formulier maar één <INPUT TYPE=TEXT>
en geen TEXTAREA
moet hebben, alhoewel het wel andere formulier-elementen zoals aankruisvakjes en keuzeknoppen kan hebben. Voor een gedetailleerder antwoord, zie <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/www/formquestion.html>.
Dat kun je niet met HTML doen. Maar je kunt na het formulier een script plaatsen , dat de focus op het gewenste veld plaatst, zoals dit:
<FORM ID="mijnform" NAME="mijnform" ACTION=...>
<INPUT TYPE="text" ID="mijninput" NAME="mijninput" ...>
</FORM>
<script type="text/javascript"><!--
document.mijnform.mijninput.focus();
//--></script>
Een soortgelijke aanpak om de focus te plaatsen is mogelijk met behulp van <BODY ONLOAD=...>
, maar sommige browsers lijken de ONLOAD-gebeurtenis uit te voeren nog voordat het gehele document (met bijv. het deel dat het formulier bevat) is geladen.
In plaats van de normale submit-knop (<INPUT TYPE=submit ...>
), kun je een afbeelding gebruiken voor een aangepaste submit knop. Gebruik <INPUT NAME=Send TYPE=image SRC="http://url.to/image.gif" ALT="Zend" VALUE="Zend">
. De meeste browsers sturen daarnaast ook de x en y coördinaten van de locatie waar de gebruiker klikte op de afbeelding naar de server. Deze zijn beschikbaar als "Zend.x=000&Zend.y=000" in de CGI input. Zie voor meer informatie <URL:http://ppewww.ph.gla.ac.uk/%7eflavell/www/trysub.html>.
Voor de 'reset'-knop zou je <BUTTON TYPE=reset ...>
, JavaScript, en/of stylesheets kunnen gebruiken, alhoewel geen van deze methodes altijd n overal werkt. Zie voor meer informatie <URL:http://www.hut.fi/u/jkorpela/forms/imagereset.html>.
Zeker. Dit maakt deel uit van HTML 2.0 Formulier-ondersteuning (sommige vroege browsers ondersteunden het niet, maar het browserbereik is nu uitstekend).
Je zult je 'Submit'-knoppen een 'Name'-attribuut moeten geven, en, optioneel, een 'value'-attribuut. Om erachter te komen komen welke knop wordt gebruikt, zul je onderscheidende 'Name's of 'Value's willen gebruiken, of allebei. Naast dat het wordt verzonden naar de server, geven browsers het 'Value'-attribuut ook weer in het formulier, dus kies iets dat zinvol is voor de gebruiker, zoals in dit voorbeeld:
<INPUT TYPE=SUBMIT NAME=deelnemen VALUE="Ik wil nu deelnemen">
-of-
<INPUT TYPE=SUBMIT NAME=info VALUE="Stuur meer informatie aub">
Merk op dat als je afbeeldings-verzendknoppen gebruikt, dat deze ook van verschillende 'Value'-attributen moeten worden voorzien.
Als je niet zeker weet welke resultaten je krijgt als je het formulier verzend, heeft Tipjar een standaard script dat je kunt gebruiken. Codeer dit, bijvoorbeeld (uitgaande van de methode "post"):
<form method="post" action="http://www.tipjar.com/cgi-bin/test">
en voer dan de handelingen uit om je formulier te verzenden. De Tipjar-server decodeert de formulier-gegevens, en geeft het resultaat voor je weer.
Nee. Een formulier moet precies één 'action' hebben. Maar het server-side programma (bijv. CGI), dat de formulierinzendingen verwerkt, kan meerdere taken uitvoeren (bijv. een database bijwerken, e-mail versturen, een transactie opslaan) naar aanleiding van één enkele formulierinzending.
Ja. Zorg ervoor, dat het server-side programma (bijv. CGI) dat de formulierinzendingen verwerkt, een foutbericht stuurt als het veld niet goed is ingevuld. Het is het mooiste als dit foutbericht een exemplaar van het originele formulier bevat met de oorspronkelijk (incompleet) opgegeven gegevens al van te voren ingevuld.
Daar bovenop kun je JavaScript gebruiken in het ONSUBMIT-attribuut van het formulier om te formulier te controleren voor degenen die JavaScript hebben ingeschakeld. Laat de ONSUBMIT-gebeurtenisafhandeling de gebruiker op de hoogte stellen van het probleem als het formulier niet compleet is, en dan 'false' teruggeven. Merk op dat het server-side programma niet afhankelijk moet zijn van het controlewerk van het client-side script.
Ten eerste: de RFC hiervoor is te vinden op <URL:http://www.ics.uci.edu/pub/ietf/html/rfc1867.txt>.
Bestand-upload wordt verzorgd door de CGI.pm Perl5 library beschikbaar op <URL:http://stein.cshl.org/WWW/software/CGI/cgi_docs.html>. The most recent versions of the cgi-lib.pl library also support file upload.
Deze zaken zijn noodzakelijk voor uploads vanaf een website:
<form method="POST" enctype="multipart/form-data" action="fup.cgi">
Bestand te uploaden: <input type=file name=upfile><br>
Aantekeningen m.b.t. het bestand: <input type=text name=note><br>
<input type=submit value=Druk> om het bestand te uploaden!
</form>
Niet alle browsers ondersteunen bestand-upload op basis van formulieren, dus probeer waar mogelijk alternatieven te geven. Als je bestands-upload nodig hebt in combinatie met formulier-naar-email, kan het Perl pakket MIME::Lite e-mail-bijlagen verwerken.
Dit kan niet met alleen HTML; iets anders moet het formulier verwerken. Verwerking met JavaScript werkt alleen maar met lezers die een JavaScript-geschikte browser hebben. CGI en andere server-side verwerking is betrouwbaar voor menselijke lezers, maar zoekmachines hebben problemen met het volgen van elke navigatie die op formulieren is gebaseerd.
Kijk op <http://www.hut.fi/u/jkorpela/forms/navmenu.html>, waar wordt uitgelegd hoe uitklapmenu's kunnen worden gemaakt, naast enkele betere navigatie-alternatieven.
Met behulp van frames kan een auteur een browservenster verdelen in meerdere (rechthoekige) vlakken. Meerdere documenten kunnen, ieder in hun eigen frame (kader), worden weergegeven in één venster. In grafische browsers kan in deze frames zelfstandig worden geschoven (ge'scroll'd), en links kunnen het in een frame weergegeven document verversen, zonder de andere documenten te beïnvloeden.
Een frameset is een bepaalde samenstelling van frames. Om frames te gebruiken, moet een document een frameset definiëren, zodat andere documenten in de frames kunnen worden weergegeven. Dit document wordt het frameset-document genoemd. Het frameset-document dient ook alternatieve niet geframede inhoud te bevatten in een <NOFRAMES>
-element.
Het HTML 4-frames model heeft belangrijke ontwerpfouten die toegankelijkheidsproblemen voor webgebruikers veroorzaken. Frames dienen alleen met grote zorgvuldigheid te worden gebruikt. De 'Guide to frames' <http://www.htmlhelp.com/design/frames/> van de Web Design Group bevat richtlijnen voor het juiste gebruik van frames, naast een beschrijving van de benodigde HTML-syntax.
Zorg ervoor dat in het frameset-document (het HTML-document dat de <FRAMESET>
en <FRAME>
elementen bevat), de individuele frames een naam hebben gekregen met behulp van het NAME
-attribuut. Het volgende voorbeeld maakt een bovenframe genaamd "navigatie" en een onderframe genaamd "tekst":
<FRAMESET ROWS="*,3*">
<FRAME NAME="navigatie" SRC="navigatie.html">
<FRAME NAME="tekst" SRC="tekst.html">
<NOFRAMES><BODY>
<!-- Alternatieve geen-frames-versie -->
</BODY></NOFRAMES>
</FRAMESET>
In het document met de link gebruik je vervolgens het TARGET
-attribuut om het frame aan te geven, dat moet worden gebruikt om de link in weer te geven. (De waarde van het TARGET
-attribuut moet overeen komen met de waarde van het NAME
-attribuut van het doelframe.) Je kunt het doel aangeven voor een link (bijv. <A TARGET="tekst" HREF=...>
) of voor een formulier (bijv. <FORM TARGET="tekst" ACTION=...>
). Verder kun je <BASE TARGET=...>
gebruiken om het standaard doelframe te veranderen voor het gehele document (normaal is de standaardwaarde voor het doelframe "_self", het huidige frame).
Als er nog geen frame bestaat met de naam die je gebruikt voor het TARGET
-attribuut, zal er een nieuw browservenster worden geopend, en zal dit venster de gebruikte naam krijgen toegewezen. Verder zal ook TARGET="_blank"
een nieuw, onbenoemd browservenster openen.
In HTML 4.0 is de TARGET
attribuutwaarde ongevoelig voor hoofdletters en kleine letters, dus abc
en ABC
verwijzen beide naar hetzelfde frame/venster, en _top
en _TOP
hebben beide dezelfde betekenis. De meeste browsers behandelen de TARGET
attribuutwaarde echter als hoofdlettergevoelig en herkennen ABC
niet als zijnde hetzelfde als abc
, of _TOP
als zijnde het speciale geval _top
.
Verder bevatten sommige browsers een beveiligingsfunctie, die voorkomt dat documenten worden gekaapt door framesets van derden. Als de link in een document als doel een frame heeft, dat is gedefinieerd door een frameset-document dat op een andere server is geplaatst dan het document zelf, dan openen deze browsers de link in een nieuw venster.
Er zijn twee basistechnieken om meerdere frames gelijktijdig bij te werken met een enkele link: De op HTML gebaseerde techniek linkt naar een nieuw frameset-document dat de nieuwe combinatie van frames opgeeft. De op JavaScript gebaseerde oplossing gebruikt het onClick
-attribuut van een link om het extra frame (of frames) bij te werken.
De op HTML gebaseerde techniek kan met TARGET="_top"
naar een nieuw frameset-document linken (de gehele frameset wordt vervangen), maar er is een alternatief als de te vervangen frames onderdeel zijn van een genestte frameset. Gebruik een tweede frameset-document binnen het initiële frameset-document, om de genestte frameset in te stellen. Bijvoorbeeld:
<FRAMESET COLS="*,3*">
<FRAME SRC="tekst.html" NAME="Tekst">
<FRAME SRC="frameset2.html" NAME="Weergeven">
</FRAMESET>
Een link kan nu de code TARGET="Weergeven"
gebruiken om alle frames die worden gedefinieerd door frameset2.html
, tegelijk te vervangen.
De op JavaScript gebaseerde oplossing gebruikt het onClick
-attribuut van een link om de tweede update uit te voeren. Bijvoorbeeld:
<A HREF="URL1" TARGET="Frame1"
onClick="top.Frame2.location='URL2';">Frames bijwerken</A>
Deze link zal Frame1
normaal bijwerken met URL1
. Als de browser van de lezer JavaScript ondersteund (en het heeft ingeschakeld), dan zal Frame2
ook worden bijgewerkt (met URL2
).
Als je de auteur bent is dat heel makkelijk. Je hoeft alleen maar het TARGET
-attribuut toe te voegen aan de link die de lezers naar het bedoelde 'buiten'-document brengt. Geef het de waarde _top
.
In veel van de huidige browsers is het niet mogelijk om een frame in het volledige venster weer te geven, het is in ieder geval niet erg gemakkelijk. De lezer zou de URL van het gewenste frame moeten kopiëren, en deze URL dan handmatig moeten opvragen.
Ik zou willen aanbevelen dat auteurs, die deze optie aan hun lezers willen aanbieden, een link naar het document toevoegen onderaan in het document zelf, met het TARGET
-attribuut ingesteld op _top
, zodat het document in het volledige venster wordt weergegeven als de link wordt gevolgd.
Als de subdocumenten van een frameset-instantie direct worden benaderd, verschijnen ze zonder de context van de bovenliggende frameset.
Als de browser van de lezer JavaScript-ondersteuning heeft ingeschakeld, zal het volgende script de frameset herstellen:
<SCRIPT TYPE="text/javascript">
<!--
if (parent.location.href == self.location.href) {
if (window.location.replace)
window.location.replace('frameset.html');
else
// veroorzaakt wat problemen met de terug-knop, maar het werkt
window.location.href = 'frameset.html';
}
// -->
</SCRIPT>
Een meer algemene aanpak is een "herstel frames" link:
<A HREF="frameset.html" TARGET="_top">Herstel Frames</A>
Merk op dat je in beide gevallen een apart frameset-document nodig heeft voor elk inhoud-document. Als je naar de standaard frameset-document linkt, krijgt de lezer ook het standaard inhoud-document, in plaats van het inhoud-document dat hij/zij probeerde te bereiken. Deze frameset-documenten zouden automatisch gegenereerd moeten worden, om het gedoe en de foutkans te voorkomen bij het met de hand maken.
Merk op dat je het probleem met het 'bookmarken' van frameset-instanties kunt voorkomen, door naar deze aparte frameset-documenten te linken met gebruik van het TARGET="_top"
-attribuut, in plaats van te linken naar de aparte inhoud-documenten.
"Geframed worden" heeft te maken met de weergave van je documenten binnen de frameset van iemand anders, zonder jouw toestemming. Dit kan per ongeluk gebeuren (de auteur van de frameset vergat om TARGET="_top"
te gebruiken bij het linken naar jouw document) of met opzet (de auteur van de frameset wilde jouw inhoud weergeven met zijn/haar eigen navigatie- of reclame-frames).
Om het "framen" van andermans documenten te voorkomen, moet je TARGET="_top"
toevoegen aan alle links, die leiden naar documenten buiten de bedoelde omgeving.
Er is helaas geen betrouwbare manier om vast te leggen, dat een bepaald document moet worden weergegeven in het volledige browservenster, in plaats van in het huidige frame. Als je jouw server kunt instellen om de niet-standaard header Window-Target: _top
te versturen in de HTTP response, zullen Netscape browsers jouw document weergegeven in het volledige browservenster. Andere browsers negeren deze header echter, en het werkt niet om <META HTTP-EQUIV="Window-target" CONTENT="_top">
in het document zelf te gebruiken om de HTTP response na te doen.
Een andere oplossing is het gebruik van <BASE TARGET="_top">
in het document, maar dit geeft alleen maar het standaard doelframe voor links in het huidige document aan, niet voor het document zelf.
Als JavaScript is ingeschakeld in de browser van de lezer, verwijderd het volgende script automatisch alle bestaande framesets:
<SCRIPT TYPE="text/javascript">
<!--
if (top.frames.length!=0)
top.location=self.document.location;
// -->
</SCRIPT>
Een alternatief script is
<SCRIPT TYPE="text/javascript">
<!--
function breakOut() {
if (self != top)
window.open("my URL","_top","");
}
// -->
</SCRIPT>
</HEAD>
<BODY onLoad="breakOut()">
Dit is helaas niet mogelijk. Tijdens het navigeren door een site waar frames worden gebruikt, zal de URL niet veranderen als de documenten in de individuele frames veranderen. Dit betekent dat er geen methode is om een de combinatie van documenten aan te geven, die in de huidige instantie van de frameset voorkomen.
De auteur kan een link aanbieden naar meerdere frameset-documenten, een voor elke combinatie van frame-inhoud. Deze frameset-documenten kunnen automatisch aangemaakt worden, mogelijk zelfs à al minute met een CGI-programma. In plaats van te linken naar de afzonderlijke inhoudsdocumenten, kan de auteur ook linken naar deze aparte frameset-documenten met behulp van TARGET="_top"
. Op die manier zal de URL van het huidige frameset-document altijd die combinatie van frames aangeven, die wordt weergegeven op dat moment. Zo kunnen links, bladwijzers, enz. normaal werken.
Het verwijderen van de rand om frames gebeurt door zowel de frame-randen niet te tekenen als het verwijderen van de ruimte tussen de frames. De twee belangrijkste frames-herkennende browsers gebruiken verschillende niet-standaard attributen om dit voor elkaar te krijgen.
Netscape herkent het BORDER
-attribuut in FRAMESET
. Dit kan op 0 worden gezet, waardoor de rand niet zal worden getoond, en de tussenruimte zal op nul worden gezet.
Microsoft Internet Explorer herkent de FRAMEBORDER
- en FRAMESPACING
-attributen in FRAMESET
, maar in sommige versies ook in FRAME
voor individuele frames. Beide attributen moeten op 0 worden gezet.
De best ondersteunde methode om randloze frames weer te geven is dus <FRAMESET ... BORDER=0 FRAMEBORDER=0 FRAMESPACING=0>
.
Merk op dat deze attributen niet-standaard zijn, en geen deel uitmaken van de HTML 4 specificaties. Ook maakt het verwijderen van de rand om een frame het onmogelijk om het van grootte te veranderen, aangezien deze rand in de meeste GUI's wordt gebruikt om de afmeting van het venster te veranderen.
De enige manier waarmee je een een frame krijgt met wel een vertikale, maar geen horizontale schuifbalk, is door het frame te definiëren met SCROLLING="auto"
(de standaardwaarde), met inhoud die geen horizontaal verschuiven vereist. Er bestaat geen manier om een frame in te stellen met wel de ene maar niet de andere schuifbalk. Het gebruik van SCROLLING="yes"
dwingt schuifbalken in beide richtingen af (zelfs wanneer ze niet nodig zijn), en het gebruik van SCROLLING="no"
voorkomt alle schuifbalken (zelfs wanneer verschuiven nodig is de inhoud van het frame te bereiken). Er zijn geen andere waardes voor het SCROLLING
attribuut.
De titel die wordt weergegeven is de titel van het frameset-document, in plaats van de titels van een van de pagina's in de frames. Link naar een nieuw frameset-document met behulp van TARGET="_top"
om de weergegeven titel te wijzigen (hiermee de gehele frameset vervangend).
Netscape Navigator schijnt met pixels vastgelegde frame-afmetingen af te ronden naar het dichtstbijzijnde gehele percentage, en deze op percentages gebaseerde afmetingen te gebruiken bij het opmaken van de frames. Dus zullen frames met in pixels opgegeven afmetingen, met een iets andere grootte worden afgebeeld dan opgegeven in het frameset-document. Er bestaat geen methode om dit gedrag te voorkomen, en de afrondingsmarge zal afhangen van de exacte afmetingen van het browservenster.
Om dit op te vangen, zou je jouw site zodanig moeten ontwerpen, dat deze zich aanpast aan variaties in de browser's weergave. Dat is altijd al een goed idee, maar zeker in dit geval.
Het fundamentele probleem met het systeem van frames is, dat framesets instanties in de browser aanmaken, die niet adresseerbaar zijn. Zodra een van de frames binnen een frameset niet meer zijn oorspronkelijke inhoud heeft, is er geen manier meer de huidige instantie van de frameset te adresseren. Zo'n frameset instantie is moeilijk om te 'bookmarken' - en onmogelijk om te linken of te indexeren. Het is onmogelijk om te verwijzen naar zo'n frameset instantie in andere media. Als de sub-documenten van zo'n frameset instantie direct worden benaderd, verschijnen ze zonder de context (omgeving) van de bovenliggende frameset. Basisfuncties van de browser (bijv. afdrukken, terug/vooruit navigeren in de browser's geschiedenis) gedragen zich anders met framesets.
Verder richten frames zich op lay-out in plaats van op informatie-structuur, en veel auteurs van geframede sites verwaarlozen het aanbieden van bruikbare alternatieve inhoud in het <NOFRAMES>
-element. Deze twee factoren veroorzaken toegankelijkheidsproblemen voor browsers die significant afwijken van de verwachtingen van de auteur, en voor zoekmachines.
Zie voor verdere discussie <URL:http://www.htmlhelp.com/design/frames/whatswrong.html>
Zoekmachines kunnen rechtstreeks verwijzen naar in frames opgenomen inhoudelijke documenten, maar ze kunnen niet verwijzen naar de combinaties van frames waarvoor deze inhoudelijke documenten zijn ontworpen. Dit is het gevolg van een fundamenteel gebrek in het ontwerp van frames.
Zoekmachines proberen hun gebruikers te voorzien van links naar nuttige documenten. Veel in frames opgenomen inhoudelijke documenten zijn moeilijk te gebruiken als ze direct benaderd worden (buiten de frameset die voor hen bedoeld is), dus is er weinig voordeel als zoekmachines links aanbieden naar zulke documenten. Daarom negeren veel zoekmachines frames helemaal, en gaan ze verder met het indexeren van meer nuttige (niet-geframede) documenten.
Zoekmachines indexeren wel uw <NOFRAMES>
-inhoud, en alle inhoudelijke documenten die bereikbaar zijn via uw <NOFRAMES>
-inhoud. Zulke inhoudelijke documenten zouden nuttig moeten zijn indien ze direct benaderd worden vanaf een zoekmachine-link.
Neem voor aanvullingen op of gebreken van deze FAQ contact op met <darin@htmlhelp.com> (in het Engels a.u.b.).
Alle hierin opgenomen informatie is oorspronkelijk samengesteld door door leden van de Web Design Group, met name Arnoud "Galactus" Engelfriet, John Pozadzides, en Darin McGrew. De Nederlandse vertaling van deze FAQ is gemaakt door Rijk van Geijtenbeek.
Aanvullende gegevens werden verstrekt door Boris Ammerlaan, Martin Atkins, Lori Atwater, Alex Bell, Stan Brown, Roger Carbol, Alex Chapman, Jan Roland Eriksson, Jon Erlandson, Mark Evans, Peter Evans, Alan Flavell, Rijk van Geijtenbeek, Lucie Gelinas, Bjoern Hoehrmann, Tina Marie Holmboe, Cliff Howard, Thomas Jespersen, Peter Jones, Nick Kew, Jukka Korpela, Simon Lee, Nick Lilavois, Neal McBurnett, Glen McDonald, Dan McGarry, Ken O'Brien, Timothy Prodin, Steve Pugh, Liam Quinn, Colin Reynolds, Kai Schätzl, Doug Sheppard, Sue Sims, Toby Speight, Warren Steel, Ian Storms, Peter Thomson, Daniel Tobias, en Diane Wilson.
Bedankt iedereen!
Home, Reference, FAQs, Tools, Design, Feature Article, BBS, Links
Copyright © 1996-2000. Alle rechten voorbehouden.