Webmaster - 2.3 HTML standaard RGD

Sectie [ Webmaster , 2 - Richtlijnen voor het aanleveren van pagina's ] Sectie Volgende

Sectie 2.3 - HTML standaard RGD

1 Samenvatting
2 Inleiding
3 Checklist
- 3.1 Inhoudelijk
- 3.2 Trefwoorden
- 3.3 Algemeen
- 3.4 Grafische kenmerken
- 3.5 HTML files en directories
- 3.6 HTML syntax
- 3.7 HTML stijl
4 Voorbeeld pagina's
5 Literatuur

Top van dit scherm document.

1 Samenvatting

Noot (1999-11-11): tegenwoordig heeft PNG de voorkeur vanwege patentproblemen met GIF (Unisys).

HTML (HyperText Markup Language) is de opmaaktaal voor documenten op het World Wide Web (WWW). In september 1995 was er een zgn. Internet Draft [1] die een stabiele HTML standaard bleek te zijn (versie 2.0). Het Abstract hieruit geeft duidelijk weer wat HTML is:

The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic Semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.
HTML has been in use by the World Wide Web (WWW) global information initiative since 1990. This specification roughly corresponds to the capabilities of HTML in common use prior to June 1994. HTML is an application of ISO Standard 8879:1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).
The `text/html' Internet Media Type (RFC 1590) and MIME Content Type (RFC 1521) is defined by this specification.

RGD HTML documenten zullen voor het grootste gedeelte deze standaard volgen, maar ook enkele zgn. Netscape extensies [4] gebruiken, die alle terug zijn te vinden in de HTML versie 3.2 draft [2] ("Wilbur").
Raadpleeg de WWW server van het W3 consortium voor de laatste versie van HTML specificaties.
HTML is trouwens helemaal niet zo moeilijk en eng als het hierboven klinkt ;-).

Netscape is een zgn. WWW browser: een browser is een WWW client applicatie waarmee WWW documenten, afkomstig van een zgn. WWW server, gelezen kunnen worden. Netscape is de meest populaire browser. Volgens schattingen gebruikt zo'n 75% van de Internet surfers Netscape.
De zorgvuldige keuze van een aantal toegestane extensies is gedaan om enerzijds fraai vormgegeven documenten te kunnen maken en anderszijds toch in redelijke mate te voldoen aan de standaard. Dit laatste is natuurlijk wenselijk i.v.m. goede onderhoudbaarheid van de documenten en de leesbaarheid door andere WWW browsers als Netscape.
Hierbij zijn nog de volgende feiten van belang:

De 2.0 draft suggereert een duidelijk afhandeling (nl. negering) door browsers van onbekende tags en attributen; bepaalde Netscape extensies kunnen daarom veilig gebruikt worden
Tabellen en text-wrapping (nieuw in 3.0) worden in de meeste huidige browsers (waaronder ook Mosaic) ondersteund en de syntax voor deze elementen lijkt stabiel

Op grond van het bovenstaande is een zorgvuldige RGD HTML standaard geformuleerd.

2 Inleiding

HTML pagina's ontwikkeld op de RGD zullen grotendeels aan de 2.0 standaard voldoen [1]. Uitzonderingen worden hier beschreven en de rationale daarvan.

Alle huidige WWW browsers ondersteunen HTML 2.0, ook Netscape 1.1 (en hoger). Netscape wordt de WWW browser voor de RGD. HTML 2.0 ontbeert echter vele presentatie elementen die wel in versie 3.2 [2] zijn te vinden en m.n. voor de vormgeving van WWW pagina's belangrijk zijn.
Een aantal elementen, maar zeker niet alle, uit 3.0 werden reeds in Netscape ondersteund (hoewel soms anders). Bovendien heeft Netscape eigen toevoegingen aan HTML die door andere browsers, zoals het nog steeds veelgebruikte Mosaic of Lynx (karaktergeörienteerd) in het gunstigste geval genegeerd worden maar soms ook tot vervelende resultaten kunnen leiden in de presentatie van een WWW document.

HTML is nog erg in beweging, tot grote frustatie van fabrikanten als Netscape (initiator overigens van een aantal veranderingen) die nieuwe markup's implementeren die dan weer in een nieuwe versie van de specificatie veranderd zijn of zelfs verdwenen. Dit geeft ook het dilemma aan voor de RGD: aan de ene kant willen we WWW documenten volgens "standaard" HTML (onderhoudbaarheid pagina's, brede toegankelijkheid publiek), aan de andere kant willen we dat ze, mede door mooie vormgeving, opvallen (gebruikersvriendelijkheid, klantbinding). Referentie [3] geeft goede achtergrond informatie over het "HTML-standaard dilemma".

Omdat de 2.0 draft echter duidelijke aanwijzingen geeft hoe 2.0 browsers moeten omgaan met onbekende markup elementen en attributen (bv. 3.2 of Netscape specifieke) valt toch een duidelijke voorlopige RGD HTML standaard vast te stellen. die wordt in de volgende paragraaf beschreven aan de hand van een checklist.

In het zeer goede en complete Internet Handboek ([5]) van Jeroen Vanheste wordt in hoofdstuk 17 ook uitgebreid ingegaan op "correcte HTML". Zogenaamde HTML validatoren worden in de Checklist (2.3.3) genoemd.

3 Checklist

In deze paragraaf wordt een volledige checklist gegeven van punten waaraan de HTML pagina's op de RGD WWW server dienen te voldoen. Ze zijn verdeeld in een aantal secties. De sectie "Inhoudelijk" is vooral van belang voor de webeditor, de overige gelden meer voor de webdesigner.

3.1 Inhoudelijk

De eindverantwoordelijke (webeditor, webeditor@rgd.nl) dient bij accordering op de volgende punten te letten. De HTML documenten bevatten:

Verwijzing naar de copyright en legal disclaimer pagina.
Correct taalgebruik (groene boekje) en in het algemeen geen inhoud die voor (groepen van) individuen kwetsend is.
Adequate, volledige en correcte informatie.
Geen confidentiële informatie (embargo).

3.2 Trefwoorden

Bij de keuze van geschikte sleutelwoorden kan de analogie met de publicatie van een artikel in een wetenschappelijk tijdschrift gemaakt worden, waar men immers onder de Summary vaak Keywords ziet.
De gebruiker dient in overleg met de bibliotheek (bibliotheek@rgd.nl) sleutelwoorden op te nemen in het HTML document. De bibliotheek heeft een thesaurus van sleutelwoorden.

Sleutelwoorden worden bv. onder de titel of samenvatting gezet ("Sleutelwoorden: ...") en gescheiden door komma's.
Aantal sleutelwoorden: 2-5.
Sleutelwoorden mogen uit meerdere woorden bestaan, bv. "quarternary geology".
Sleutelwoorden moeten volledig in lower case (kleine letters), tenzij het een term betreft waarbij het onderscheid tussen hoofd- en kleine letters cruciaal is.
Niet te algemeen: "geology" is te algemeen (behalve in de Home page van de WWW server!), maar bv. "quarternary geology" niet.
Nederlandstalige sleutelwoorden indien de pagina in de /dutch tree staat, engelstalig indien in de /english tree.
Ga na welke sleutelwoorden reeds gebruikt zijn in vergelijkbare pagina's zodat er een overall consistentie gehandhaafd blijft. Dit uiteraard in overleg met de bibliotheek.

3.3 Algemeen

Er worden hier enkele browsers (Netscape, Mosaic en Lynx) en tools (weblint) genoemd: zie de paragraaf Hulpmiddelen (3.4) in het volgende hoofdstuk.

Ga uit van de algemene template: zie de Voorbeeld pagina's (2.3.4).
Het aanmaken van nieuwe directories in de document tree moet eerst overlegd worden met de webmaster.
Het gebruiken van symbolic links, bv. om kortere URL's te krijgen, moet ook overlegd worden met de webmaster.
Conformering aan de HTML 2.0 standaard [1]. De volgende extensies en situaties zijn toegestaan:
1. Text wrapping/flowing van <IMG>'s met ALIGN=LEFT of RIGHT.
2. Netscape extensies, zoals voor- en achtergrond kleuren of bitmaps, zijn toegestaan mits ze:
  - niet leiden tot vreemd gedrag in de presentatie bij Mosaic en Lynx
  - een equivalent missen in HTML (ongeacht de versie)
  - in HTML 3.2 [2] beschreven zijn (evt. alleen functioneel) en dus redelijk toekomstvast verondersteld mogen worden
  Dit betekent dat niet toegestaan is:
  - <CENTER>
    Hier is een "net" HTML equivalent voor, dat ook door de andere browsers ondersteund wordt, nl. het ALIGN=CENTER attribuut.
  - <TABLE>
    Deze zijn niet nodig voor de toolbar en kunnen verder altijd met een <PRE> sectie gerealiseerd worden.
De HTML syntax wordt routinematig geverifieerd met weblint, dat ook via het Web kan, dankzij het zeer gebruikersvriendelijke weblint frontend van James Carpenter.
Een finale check vind plaats met de HTML Validation Service van HALSoft (gebruik de dichterbijzijnde HTML Validation Service mirror in Oostenrijk), of de uitstekende Kinder, Gentler HTML Validator van Gerald Oskoboiny.
In het algemeen zullen in de volgende constructies fouten geven: <BODY> met attributen, CENTER, LEFT en RIGHT alignments en <IMG> met BORDER=0.
De presentatie moet altijd geverifieerd worden met de Referentie browsers:
- Netscape (>= 1.1)
- Mosaic (Windows PC versie 2.0 final beta)
- Lynx (Unix versie 2.6)
Merk op dat character based weergave dus expliciet ondersteund wordt (Lynx)!
De presentatie wordt van tijd tot tijd ook bekeken met de volgende Optionele browsers:
- Unix Mosaic (2.6.3)
- InternetWorks (v.70, Windows)
- Web Explorer 1.03 (OS/2)
- Internet Explorer 2.0 (Windows95) en 1.5 (Windows 3.1x)
Er wordt naar gestreefd om de pagina's minstens presentabel te maken voor deze browsers, maar het is geen must.
Bereikbaarheid van hyperlinks (<A>) wordt handmatig gecontroleerd, door het document te laden en alle links na te lopen.

3.4 Grafische kenmerken

De Ontwerp uitgangspunten (sectie 3.3) voor de RGD WWW site hebben geleid tot de volgende grafische kenmerken van de HTML pagina's. Zie ook sectie 3.3 voor de gebruikte hulpmiddelen om het onderstaande te realiseren en testen:

Plaatjes moeten altijd het GIF format hebben, omdat dit universeel ondersteund is (denk ook aan clickable maps), hoewel in-line JPEG images door steeds meer browsers ondersteund worden. In uitzonderingsgevallen kunnen foto's e.d. in JPEG opgenomen worden (alleen als in-line image, niet bij clickable maps).
Uitgangspunt voor schermresolutie is 800 x 600 met 256 kleuren (8-bit). Dit is een redelijke eis is voor de huidige generatie van PC's (SVGA) en workstations. Ook wordt de weergave op 1024 x 768 schermen (met evt. meer kleuren) geverifieerd.
Bij monochrome weergave of VGA 16 kleur, dient een gebruiker met een grafische browser "image loading" op "off" te zetten (text only dus, merk op dat Lynx expliciet ondersteund wordt!).
Maximaal 32 kleuren per afbeelding of plaatje (bij uitzondering maximaal 216) uit het Netscape 216 kleurpalet.
Maximaal 10, maar liefst <= 5 (of geen!) plaatjes per HTML pagina.
Combineer plaatjes waar mogelijk maar gebruik geen clickable maps (Lynx). Als toch clickable maps gebruikt worden, moet een text alternatief gegeven worden met uitputtende inhoudsopgave.
Plaatjes moeten klein zijn: hooguit 70 x 70. Grotere afbeeldingen nooit direct in een document zetten, maar via een zgn. thumbnail: een "postzegel-formaat" uitvoering van de afbeelding, bv. 50 x 50, waar op geklikt kan worden en dan de werkelijke afbeelding laat zien.
Maximale downloadtijd van een pagina moet 25 seconden zijn en deze wordt als volgt berekend:
- Alle images in een html file en de html file zelf, elk op 1 Kb afronden en sommeren.
- Eén (1) seconde "straf" per gifje (vanwege TCP overhead).
- Veronderstelde snelheid is 1 Kb/seconde.
  Dit is een redelijke maat voor een 64 Kb lijn met matig belaste server en 14k4 client.
Voorbeeld: een HTML file van 3200 bytes met 3 gifjes van 1200, 1400 en 2000 bytes.
Berekening: 2 + 2 + 2 + 4 + 3x1 = 13 Kb. Is < 25, dus ok!

3.5 HTML files en directories

HTML bestanden zijn ASCII files. Plaatjes zullen i.h.a. het GIF format hebben en zijn binair.

Naamgeving van HTML en gif files en van directories.
De volgende eigenschappen zijn bedoeld om bondige, informatieve en tikfout-ongevoelige bestandsnamen te verkrijgen:
1. volledig lower-case
2. geen onderliggende streepjes ("_", engels: "underscore"), maar altijd gewone streepjes ("-") indien nodig (spaarzaam gebruiken)
3. informatief
4. niet te lang
5. niet te kort of cryptisch, dus bv. geen (DOS) 8.3 beperking
6. extensie is ".html" (HTML) en ".gif" (gif)
Eén file naam
Alle pagina's, behalve die in /people, hebben éen naam. De nederlandstalige versie staat in de /dutch tak van de document tree, de engelstalige in de /english tak.
https://maryniak.home.xs4all.nl/images
Alle afbeeldingen, zoals GIF bestanden, bevinden zich in directory https://maryniak.home.xs4all.nl/images.
/people
Hier staan de persoonlijke Home pages van RGD medewerkers in. Voor deze pagina's geldt:
1. De naam is altijd: welcome.html. Dit is ook een default naam op de server, zodat met de URL van het directory waar de pagina zich bevind volstaan kan worden
2. De home pagina's van mensen bevinden zich in het directory /people/e-mail-adres-van-persoon/. Het "e-mail-adres-van-persoon" volgt het vaste e-mail naamschema van de RGD.
  De URL "http://www.rgd.nl/e.maryniak/" geeft dus de home pagina van "e.maryniak@rgd.nl" aan. Het is niet nodig de volledige naam te gebruiken (http://www.rgd.nl/e.maryniak/welcome.html).
3. Home pagina's van programma's en projecten zijn volgens hetzelfde stramien opgebouwd als die van mensen, behalve dan dat ze in twee takken voorkomen (/dutch en /english).
/wwwforms
Invulformulieren (<FORM>'s), die via e-mail naar een RGD adres gestuurd worden, staan alle in dit directory. Binnen dit directory en voor deze documenten geldt steeds een algemene opzet.
Als voorbeeld nemen we het feedback formulier (feedback.html):
1. Het formulier zelf staat in (nederlands, resp. engels):
  /wwwforms/dutch/feedback.html
  /wwwforms/english/feedback.html
  Dit zijn dus de files die de <FORM> bevatten.
  Merk op dat de tweetaligheid binnen /wwwforms doorgevoerd wordt, analoog aan de document root.
2. De <FORM> in feedback.html heeft de volgende vorm (nederlands, resp. engels):
    <FORM METHOD="POST"
     ACTION="/cgi-bin/feedback?/wwwforms/dutch/reply/feedback.html">
    <FORM METHOD="POST"
     ACTION="/cgi-bin/feedback?/wwwforms/english/reply/feedback.html">
  Merk op dat het cgi-bin programma en het reply (antwoord) document dezelfde naam hebben als het formulier zelf.
3. Het reply (antwoord) document staat in het subdirectory reply en bevat de volgende string om aan te geven naar wie het ingevulde formulier moet worden verzonden:
  
  In dit voorbeeld is dat webmaster@rgd.nl, wat ook overigens de default is als het reply document of deze string er niet is.
4. Als niet alle velden zijn ingevuld, wordt als volgt een error (fout) melding document gepresenteerd (nederlands, resp. engels):
    <INPUT TYPE=HIDDEN NAME="errorcheck" VALUE="1">
    <INPUT TYPE=HIDDEN NAME="errorform"
     VALUE="https://maryniak.home.xs4all.nl/wwwforms/dutch/error/feedback.html">
    <INPUT TYPE=HIDDEN NAME="errorcheck" VALUE="1">
    <INPUT TYPE=HIDDEN NAME="errorform"
     VALUE="https://maryniak.home.xs4all.nl/wwwforms/english/error/feedback.html">
  Het document met de foutmelding staat dus in het subdirectory error en heeft weer dezelfde naam als het formulier zelf. Elke VALUE ongelijk 1 heeft tot gevolg dat er niet gecheck wordt of alle velden zijn ingevuld. Dit is ook het geval als het error document niet bestaat. De twee hidden fields kunnen bv. direct onder de <FORM> worden gezet.
5. Met sommige WWW server/client combinaties is er een probleem met het ontvangen van de laatste byte van het laatste veld van een <FORM>. Dit kan gefixed worden door het volgende dummy hidden field op te nemen aan het einde van de <FORM>, dus vlak boven </FORM>:
  <INPUT TYPE=HIDDEN NAME="dummy" VALUE="dummy">
  Met dank aan Leo Willems (leo@tunix.kun.nl) voor deze tip!
Document structuur.
1. HTML pages moeten bij voorkeur <= 5 schermbladzijden zijn (op basis van 800 x 600) en absoluut <= 10.
2. Grote documenten, zoals boeken, rapporten en catalogi, volgen de drie-laags indeling zoals beschreven in het artikel van Steven Pemberton How Do You Make an Electronic Journal Readable? [6].
Layout ASCII.
1. De lengte van regels in de HTML ascii source zoveel mogelijk <= 80 houden. Dit bevordert leesbaarheid bij een View document source en de onderhoudbaarheid van de pagina's.
2. Gebruik zoveel mogelijk indentatie en zet start en sluit tags zoveel mogelijk alleen op regels. Uitzondering: images, zie bij HTML syntax (hieronder).

3.6 HTML syntax

In dit deel van de checklist volgen de harige details over welke HTML syntax constructies wel en niet mogen.

Syntax algemeen.
1. Documenten dienen gebruik te maken van de SGML karakteristieken van HTML voor wat betreft structurele en logische markup. Hiermee wordt bedoeld dat naast de verplichte tags als <HTML>, <HEAD>, <BODY> en <TITLE>; ook de volgende tags gebruikt moeten worden indien van toepassing:
  1. <H1> .. <Hn> en <P> voor documenten met hoofdstuk en paragraaf indeling: het is dus expliciet niet de bedoeling dat (titels van) secties met vormgevings truken als <FONT SIZE=> en images geregeld worden. Dit is om later incorporatie van de logische elementen van tekst documenten in de relationele database mogelijk te maken en voor goede indexering. Immers, SGML (en daarmee HTML) is voor documenten wat SQL voor relationele databases is en dus moet de HTML markup wel juist gebruikt worden.
  2. <ADDRESS> voor adressen en andere contact informatie
  3. <OL>, <UL> en <DL> voor lijst elementen ofwel enumeraties ofwel opsommingen. Gebruik ze adequaat! Dus voor resp. geordende (genummerde) lijsten, ongeordende lijsten ("ge-bullete") en beschrijvende (definitie) lijsten. Gebruik niet meer als éen (1) <DD> in een <DT> van een <DL>.
  4. <PRE>, <CODE>, <SAMP>, <VAR> en <KBD> bij listings van code en beschrijvingen van invoer.
2. Sla geen header nivo's over, dus bv. niet van <H1> naar <H3>.
3. Gebruik liever <EM>, <STRONG> en <CODE> ipv. <I>, <B> en <TT> tenzij echt typografische aanwijzingen nodig zijn.
4. Markup elementen (tags) en attributen van tags moeten ALTIJD UPPERCASE. Vooral ook bij CGI programma's, waar een METHOD=POST in lower-case niet door de server begrepen wordt. Dit bevordert de leesbaarheid en onderhoudbaarheid, omdat de scheiding broodtekst/markup duidelijk is. Daarnaast zijn er een aantal server scripts in ontwikkeling (oa. keyword indexers) die ervan afhankelijk zijn dat de HTML tags en attributen upper-case zijn.
5. Gebruik geen lege of "rare" tags, zoals: <>, <!> en </>.
Meta informatie.
1. Auteurs (X-RGD-CreatedBy en X-RGD-LastModBy) vermelden met volledige naam en e-mail adres (tussen haakjes).
2. Data (X-RGD-CreatedOn en X-RGD-LastModOn) zijn in ISO 8601:1988 formaat (yyyy-mm-dd). Indien tijden worden vermeld, volgen deze ook ISO 8601:1988 formaat (hh:mm:ss), waarbij de uren (hh) van 0 tot 24 lopen. Dus bv.: 20:42:05.
3. De <TITLE> en X-RGD-Contents moeten identiek zijn. Een <TITLE> moet een duidelijke, context onafhankelijke, inhoud hebben, dus bv: Introduction research program Marine Geology en niet alleen Introduction.
Images (<IMG>)
1. Gebruik de ALT tag tbv. Lynx gebruikers en als "image loading off" staat bij grafische browsers. Indien geen ALT nodig is, laat dan [IMAGE] toch verdwijnen door een ALT=" " te geven; de spatie tussen de quotes is belangrijk!
2. Een rij buttons wordt aangegeven met ALT="{button text}", dus "{}" om een button aan te geven.
3. Geef als eerste tag altijd de SRC, dus: <IMG SRC="..." ALT="..."> en dan pas andere attributen.
4. Indien een image en direct daaropvolgende tekst hetzelfde anchor hebben, dan moeten ze samen in 1 anchor worden genomen. De image krijgt dan een ALT=" ", omdat er geen tekst voor de image nodig vanwege is omdat er ook anchored tekst is.
5. Het gebruik van (te grote) images moet zoveel mogelijk vermeden worden ivm. lange download tijden voor clients. Houd er rekening mee dat veel gebruikers een 14K4 modem hebben en veel universiteiten (zeker aan de andere kant van de oceaan) effectief op dezelfde snelheid uitkomen als het Internet druk is.
6. Indien de <BODY> sectie een BACKGROUND tag heeft (achtergrond), dan moet een BGCOLOR tag met zwart (000000), worden toegevoegd. Dit forceert een grafische flush. Sommige PC's vertonen met Netscape anders witte vlakjes op een donkere achtergrond. Zie voor een voorbeeld de startpagina in de sectie over Voorbeeld pagina's (2.3.4).
7. Er moet géen regel overgang zijn (of andere spaties) bij <IMG>'s die anchored zijn (<A>) en naast elkaar moeten staan. Anders ontstaat er een klein stukje hyperlinked spatie rechts van image, wat niet mooi is. Dit betekent meestal ervoor zorgen dat er na de sluittag </A> geen spatie of regelovergang voorkomt.
Special characters.
1. Een special character begint altijd met '&' en eindigt met ';'. Dus '<' voor het '<' teken, dat anders in HTML een bijzondere betekenis heeft. Het komt regelmatig voor bij source weergave (<PRE> en <CODE>), dat men special characters zo moet weergeven, maar ook in gewone tekst komt het voor.
  De tekst tussen '&' en ';' moet altijd lower-case zijn, dus geen '&GT;'.
2. Gebruik altijd symbolische referenties (de zgn. "mnemonic") voor special characters, zoals vermeld in appendix B van [1]. Hier volgt een lijstje van veel gebruikte special characters en hun mnemonic:
```
Special character          Mnemonic code
        &                  &amp;    
        <                  &lt;     
        >                  &gt;     
  harde spatie             &nbsp;   
        ©                  &copy;   
        ®                  &reg;    
        à                  &agrave; 
        á                  &aacute; 
        ä                  &auml;   
        è                  &egrave; 
        É                  &Eacute; 
        é                  &eacute; 
        ë                  &euml;   
        ï                  &iuml;   
        ö                  &ouml;   
        ü                  &uuml;   
```
3. Gebruik in de HTML source geen tekens boven ascii code 127 (met de ALT toets). Gebruik voor speciale characters een mnemonic, zoals in de bovenstaande tabel gegeven. Ook het TAB character en control characters, zoals ^F, mogen niet voorkomen.
Specifieke tags.
1. <CENTER> was Netscape specifiek en is toegestaan in 3.2, maar is niet nodig. Zowel headers (<H1> etc.) als paragraphs (<P>) hebben een ALIGN=CENTER attribuut die door alle browsers verstaan wordt en beter is.
2. Paragrafen in de <BODY> altijd beginnen met <P>. Een <P> geeft het begin van een paragraph aan, het is niet een paragraph separator of "sterke" newline!
3. <BR> dient als newline binnen een paragraph <P> en niet om kunstmatig vertical space te krijgen. Doe dit evt. met een (leeg) <PRE>-blokje, of een paragraph met enkele harde spatie.
4. <PRE>-formatted tekst.
  Gebruik geen structure tags, zoals <P> en <H3>, in preformatted tekst, daar dit tot vreemde effecten kan leiden. Alleen hyperlinks (<A>) en special characters zullen evt. kunnen voorkomen in preformatted tekst.
  Stop nooit zomaar een stuk ascii tekst in een <PRE>-blok! Let erop dat van '&', '<', '>' e.d. special characters gemaakt worden.
5. .
  Commentaarregels, ook al staan ze onder elkaar, moeten elk afzonderlijk aangegeven worden tussen , itt. wat men bij veel free format programmeertalen gewend is.
6. Vergeet in hyperlinks (<A>) niet de "URL" tussen quotes te zetten. Vooral afsluitquote wordt nogal eens vergeten en kan tot vreemd browser gedrag leiden. Dus: <A HREF="URL">.

3.7 HTML stijl

Het lezen van documenten van een scherm en het karakter van HTML (hypertext) vragen om een speciale benadering van het "HTML-ificeren" van documenten. Het artikel van Steven Pemberton [6] is een goed uitgangspunt voor het bepalen van een optimale "human computer interface" van documenten.

Verder kan men letten op:

Zeg niet "Klik op dit of dat".
Dit is browser specifiek: met een command-line browser, zoals Lynx, kan er niet geklikt worden op hypertext links.
Zeg niet "Klik hier" of "Selecteer dit".
Dit is ten eerste browser specifiek en verder zegt "hier" in een index, die op <A>-hypertext gebaseerd is, niets!
Zeg niet "Terug naar de Home Page."
Als de lezer direct naar de pagina is gegaan, is het woord Terug niet van toepassing.
Zeg niet "Home Page".
Welke "Home Page"? Geef de context aan, zodat de lezer weet waar deze zich bevindt! Dus bv. "RGD Home Page".

Deze lijst is niet volledig.
Zie verder goede boeken over HTML, zoals die van Laura Lemay [7].

4 Voorbeeld pagina's

Afgezien van de top home page en de Nederlandse en Engelse "sub" home page, zijn er twee soorten documenten op de RGD WWW server:

Navigatie documenten, bv. de info pagina.
Feitelijke documenten, bv. dit RGD webmaster handboek of het rapport CCCEE - Climate Change and Coastal Evolution in Europe

De "feitelijke" documenten volgen de drie-laags indeling zoals beschreven in het artikel van Steven Pemberton How Do You Make an Electronic Journal Readable? [6]. Het raamwerk van deze documenten wordt automatisch gegenereerd met een door Eric Maryniak snel in elkaar gehackt Perl script, pemberton.pl. Bij kleine documenten zijn de drie lagen tot één HTML file gecombineerd.

Gebruik de "View source" faciliteit om te kijken hoe de source van deze HTML files eruit ziet!

5 Literatuur

[1] Hypertext Markup Language - 2.0.: T. Berners-Lee & D. Connolly.
MIT/W3C. September 22, 1995.
URL: http://www.w3.org/hypertext/WWW/MarkUp/html-spec/html-spec_toc.html
[2] HyperText Markup Language Specification Version 3.2 (W3C, draft): D. Raggett.
W3C. September 9, 1996.
URL: http://www.w3.org/pub/WWW/MarkUp/Wilbur/
[3] Appendix B: Netscape/HTML 3.0. [uit een HTML gids]: Case Western Reserve University.
URL: http://www.cwru.edu/help/introHTML/AppB.html
[4] Netscape's extensions to HTML 2.0 en Netscape's commitment to open standards: Netscape Communications
URL: http://home.netscape.com/assist/net_sites/html_extensions.html en
URL: http://home.netscape.com/newsref/std/standards_qa.html
[5] Het Internet Handboek (Nederlands): Jeroen Vanheste
Addison-Wesley. 1995.
URL: http://www.tunix.kun.nl/handboek.html
[6] How Do You Make an Electronic Journal Readable?: Steven Pemberton
URL: Publishing on the World Wide Web. Conference book. Autumn 1995.
URL: SIGCHI Bulletin (online from januari 1996)
[7] Diverse boeken over HTML van Laura Lemay: Laura Lemay
URL: Laura's Web Zone.

Zoeken in dit handboek

Sectie [ Webmaster , 2 - Richtlijnen voor het aanleveren van pagina's ] Sectie Volgende