De volgende vragen zijn verplaatst naar een ander deel van de FAQ.
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.