HTML: the good, the bad and the ugly

Wie zei het ook al weer? The user interface ís the system. De gewone eindgebruiker heeft geen flauw benul van de interne werking van een willekeurige software-applicatie. Hij ziet enkel de User Interface (UI), en oordeelt over de kwaliteit enkel en alleen op basis van de interactie met die UI. We willen dus dat de eindgebruiker zo weinig mogelijk fouten veroorzaakt, zelf geen fouten maakt en het bovendien leuk vindt om met de applicatie te werken. Daarom moet er zorg gedragen worden voor de UI code, want deze is minstens zo belangrijk als de programmalogica.

Wie zei het ook al weer? The user interface ís the system. De gewone eindgebruiker heeft geen flauw benul van de interne werking van een willekeurige software-applicatie. Hij ziet enkel de User Interface (UI), en oordeelt over de kwaliteit enkel en alleen op basis van de interactie met die UI. We willen dus dat de eindgebruiker zo weinig mogelijk fouten veroorzaakt, zelf geen fouten maakt en het bovendien leuk vindt om met de applicatie te werken.

Daarom moet er zorg gedragen worden voor de UI code, want deze is minstens zo belangrijk als de programmalogica en de back-end. Jammer genoeg wordt ze vandaag vaak ad hoc geprogrammeerd, zonder duidelijke richtlijnen, zonder vooraf bepaalde kwaliteitsnormen.

HTML is code

De basistechnologie voor Web User Interfaces is HTML. Ze kan als statische pagina’s worden opgeslagen, of dynamisch worden opgebouwd met JSP, ASP, XSL, Javascript, enz. Maar in principe rendert elke browser HTML.

HTML is source code, en net zoals bij andere talen kun je ofwel “spaghetticode” schrijven ofwel kwaliteitscode. Helaas overheerst vandaag vooral spaghetticode. Toch zijn er duidelijke voordelen aan een consistente, gestructureerde en doordachte aanpak. Je kan je afvragen waarom dan niet iedereen gebruik maakt van kwaliteitscode?

Wat zijn de eigenschappen van kwaliteitscode?

Readability: goede code is leesbaar (voor iemand die de syntax begrijpt) en consistent, en dus snel te doorgronden wanneer je code van anderen leest, of code die je zelf lang geleden hebt geschreven. Daardoor is ze sneller en makkelijker te onderhouden.
Reusability/extensibility: goede code is flexibel, en kan eenvoudig aangepast, uitgebreid en hergebruikt worden. In HTML doen we dit bijvoorbeeld door inhoud los te koppelen van presentatie.
Performance: goede code bevat minder fouten, vermijdt dubieuze interpretaties en is sneller/performanter.
Usability: goede code draagt bij tot de gebruiksvriendelijkheid van het systeem voor de eindgebruiker.

Eén van de basisregels voor source code is dat ze aan strikte syntaxregels moet voldoen. Wanneer je code niet valideert, dan krijg je een syntax error tijdens de compilatie of uitvoering ervan. Iedere ontwikkelaar met een half brein beseft ook wel waarom dat zo is, en wat hiervan de voordelen zijn.

HTML had tot versie 4 geen strenge syntaxregels. Met alle gevolgen van dien:

Onleesbare spaghetticode die vaak regelrechte fouten bevat en gemakkelijk nog meer fouten veroorzaakt wanneer ze gewijzigd of “gecopy-paste” moet worden.
Starre code die onnodig veel tijd vraagt om te onderhouden en onmogelijk te hergebruiken valt, door bijvoorbeeld veelgebruikte stukken niet te isoleren. Of code die enkel werkt op IE, omdat cross-platform tweaken economisch niet langer haalbaar is.
Code die ontwikkeld wordt via trial-and-error, zonder goed te beseffen waarom iets werkt of niet, maakt het onmogelijk om vooraf kwaliteitsnormen en test-mechanismen in te bouwen.
Gevolg: meer ongemakken voor de eindgebruiker.

Toch kan het ook anders. Door HTML op te bouwen volgens strikte standaarden verkrijg je alle voordelen die andere syntactische programmeertalen reeds lang bieden. Zo meteen ga ik dieper in op de vraag waarom dat zo is.

Hoe is het zover kunnen komen?

In den beginne was er HTML. HTML, een subset van het rigide SGML, was een mark-up taal met een bewust losse syntax. De ambities voor HTML reikten oorspronkelijk niet verder dan het vrijblijvend opmarkeren van platte tekst, genre RTF. De oorspronkelijke bedenkers hadden hierbij geen content-sites met duizenden pagina’s, database gedreven E-commerce van ordegrootte Amazon, B2B, P2P en andere complexe constructies in gedachten.

Niettemin werd HTML razend populair (juist omdát het zo eenvoudig te leren was), en het Web bloeide… Iedereen kon opeens HTML schrijven, en dat leidde tot code-wandaden van amateurs zonder enig technisch inzicht in de onderliggende processen.

Gelukkig waren browsers zeer vergevingsgezind, en interpreteerden/corrigeerden eventuele fouten, helaas elk op hun eigen manier. Dit leidde al van in het begin tot de gewoonte om gemakkelijkheidshalve zeer ongestructureerde, zelfs foutieve code te schrijven. Er was wel een standaard, die langzaam evolueerde naar HTML 2 en later naar HTML 3.2, maar die was eerder vrijblijvend, niemand volgde ze echt tot op de letter. De WYSIWYG editors waren (en sommige zijn dat nog steeds) van ronduit abominabele kwaliteit en werkten deze wantoestanden in de hand.

Bovendien vulden de browser-producenten de standaard HTML tag-set aan met eigen tags waarvan ze vonden dat die nuttig waren. Dit, gecombineerd met de vrije interpretatie van standaard tags, leidde tot grote verschillen tussen browsers onderling. Zowat om het jaar kwamen de belangrijkste browsers met een nieuwe versie op de markt, en telkens waren er verschillen in wat ze ondersteunden, en hoe ze HTML renderden. Er moest dus in principe met steeds meer browsers rekening gehouden worden bij het schrijven van HTML.

Tegen 1998 was HTML code schrijven een living hell geworden. De bekende browseroorlog was volop aan de gang. Netscape en Microsoft hadden beiden zowat 50% marktaandeel, dus HTML moest op allebei even goed werken op. Vaak werd meer dan de helft van de ontwikkeltijd (voorzien voor HTML) besteed aan het cross-platform, cross-browser doen werken van de code.

Naarmate webapplicaties complexer werden, begon dit voor problemen te zorgen. Telkens wanneer er browserversies bijkwamen groeiden de verschillen. Toen Microsoft definitief marktleider werd gaven veel ontwerpers de strijd op, en gingen enkel voor IE (voor Windows) coderen, omdat de code aanpassen voor die steeds kleiner wordende groep Netscape-gebruikers economisch niet langer haalbaar was. Ook Mac- en Unixgebruikers vielen uit de boot.

Naarmate NN marktaandeel verloor, richtte de ontwikkeling zich per default op IE. Geholpen door dit momentum werd IE dominant, waardoor je heden ten dage kan stellen dat je zeker 95% van de gebruikers accommodeert als je enkel voor IE4+ ontwikkelt.

Accessibility

Designers en programmeurs die bleven volharden (HTML designers zaten zelf vaak op afwijkende systemen, meestal Mac en NN) kloegen steen en been en kregen hulp uit onverwachte hoek. Enerzijds klaagden steeds meer consumenten over slechte gebruikerservaringen omwille van slecht ondersteunde browsers en gebruiksonvriendelijke websites. Anderzijds was er het probleem van de accessibility.

Het is belangrijk om bij het schrijven van HTML rekening te houden met de toegankelijkheid voor mindervalide gebruikers. Blinden, slechtzienden en kleurenblinden zijn de grootste en bekendste groep internetgebruikers met accessibility-problemen. Daarnaast er zijn ook de motorisch gehandicapten die moeite hebben om de muis op veel te kleine labeltjes te mikken, en de cognitief gehandicapten, die bijvoorbeeld meer moeite hebben om navigatie te begrijpen.

Bovendien is accessibility niet alleen voor fysisch of psychisch mindervaliden. Ook mensen die geen optimaal systeem gebruiken (kleine schermen met weinig kleuren, trage inbelverbindingen, enz.) kunnen tijdelijk of permanent technisch “mindervalide” zijn en hinder ondervinden van veeleisende HTML. En dan zijn er nog de andere user-agents, die geen mensen zijn, zoals spider programma’s van zoekmachines. Ook die interpreteren HTML op hun eigen manier, en doen er iets nuttig mee.

Drie factoren werkten de accessibility-problemen in de hand.

De gebreken inherent aan HTML
De nadruk van designers op het vormgevende aspect
De tekortkomingen van browsers

Het belangrijkste probleem inherent aan HTML (3.2) is de vermenging van structurele en vormgevende mark-up. Bepaalde tags, zoals B, I, FONT, enz. en een groot deel van de attributen slaan uitdrukkelijk op de vorm van de tekst, en niet op de betekenis. Ze zijn met andere woorden niet relevant voor user-agents die geen visuele voorstelling maken van de inhoud. Textuele browsers voor blinden, maar bijvoorbeeld ook zoekmachine-spiders. Structurele tags, zoals P en TABLE, zijn dat wel.

Dit is onrechtstreeks gekoppeld aan het tweede grote nadeel, namelijk de aard waarop code word geschreven. HTML pagina’s worden dikwijls ontworpen door designers met mega-grote schermen, breedbandconnecties en jeugdige ogen. Soms uit onwil, maar meestal uit onwetendheid ontwerpen die mensen pagina’s die er goed uitzien voor henzelf, op hun eigen systeem. Wat veel ontwerpers niet echt beseffen is dat niet iedereen surft met de laatste browser en een Telenetverbinding. Dit leidt tot ontoegankelijke code, te zwaar in KB’s (door bijvoorbeeld overdadig gebruik van beelden), die van het scherm valt op alles kleiner dan een 800×600.

Een ander probleem van HTML zijn de beperkingen qua vormgeving op een beeldscherm, vergeleken met bijvoorbeeld print. Je kunt niet zomaar de elementen gaan positioneren op het scherm, omdat HTML nogal lineair geïnterpreteerd en uitgevoerd (gerendered) wordt. Dit leidde bijvoorbeeld tot het oneigenlijk gebruik van TABLE tags, namelijk voor het fixeren van de layout, waarvoor ze uiteraard niet bedoeld zijn. En het zijn opnieuw de non-visuele user-agents die zich hierin verslikken.

Omwille van de vorm-inhoud vermenging in HTML is de structuur van de inhoud niet expliciet aanwezig in de structuur van de code. Er zijn wel structurele tags (zoals SPAN en DIV), maar deze worden zelden gebruikt wegens niet relevant voor valide gebruikers (de ontwerper zelf). Er zijn ook een resem attributen die mening en structuur aan de vorm kunnen geven, maar ook die worden niet gebruikt, om dezelfde reden.

Commerciële browsers droegen bij tot de problemen:

Door browser-specifieke tags en plug-ins creëerden ze lock-in van developers. HTML development ging zich richten op slechts twee browsers, NN en IE. Zo vielen sommige eindgebruikers volledig uit de boot, zoals blinden die surfen via “primitieve” text-based browsers zoals JAWS en Lynx, of UNIX gebruikers met een andere exotische browser.
Sommige tags (zoals de gehate FRAME tag) werden gebrekkig geïmplementeerd en zorgen nog altijd voor grote usability-problemen.

We kunnen nog wel een eindje doorgaan over accessibility, maar we eindigen met de opmerking dat het binnenkort wel eens een verplichting zou kunnen worden om websites hierop te voorzien.

In de VS is reeds de beruchte sectie 508 van de Rehabilitation Act van kracht, die alle websites van de federale overheid verplicht toegankelijk te zijn voor mindervaliden, die vaak obscure browsersystemen hebben. Net zoals elk publiek gebouw een verplichte ingang voor rolstoelen heeft. We kunnen de komende jaren ook in onze contreien hierover meer wetgeving verwachten, mogelijk vanuit Europa.

HTML als verliespost

Tenslotte werden er serieuze vragen gesteld bij de toekomst van HTML in de groeiende en steeds complexer wordende webindustrie.

We hebben reeds aangehaald hoe het cross-browser, cross-platform laten werken van HTML een enorme kost inhield. Op het eerste gezicht was de oplossing eenvoudig (al was ze dan niet politiek correct), namelijk enkel voor IE op Windows werken, aangezien dat zowat iedereen (een dikke 90%, meer als je de B2B-markt bekijkt) is. Maar daarmee lossen we onze accessibility-problemen niet op. Gelukkig gaat het vaak om kleine groepen, meestal met weinig economische impact. Dit is niet onze mening, maar het lijkt soms de huidige attitude. Er zijn sites die mensen die niet via IE browsen simpelweg de deur wijzen. En begrijp me niet verkeerd, dit is niet de schuld van IE, maar van kortzichtige ontwikkelaars.

HTML 3.2 had echter ook technische en grammaticale beperkingen.

Door de steeds groter wordende websites, en het hergebruiken van dezelfde inhoud in verschillende media (bijvoorbeeld Web én krant én TV), wordt de vraag naar professioneel content management groter.

Van hetzelfde document moeten vaak verschillende versies bestaan (HTML, HTML printversie, PDF, XML, SGML, WML, enz.), dus de inhoud moet worden losgemaakt van de presentatie.
Meer en meer HTML code wordt dynamisch gegenereerd door bijvoorbeeld ASP of XSLT, en meestal door automatische processen. Maar dergelijke programma’s hebben behoefte aan een strikte syntax en gemeenschappelijke formaten, zodat programma’s met elkaar kunnen communiceren in talen die ze allebei begrijpen, en om fouten te vermijden.
Bepaalde zaken die inherent zijn aan content management zitten niet per default in HTML, bijvoorbeeld versiebeheer, workflow (status) en metadata.

Er was ook behoefte aan nieuwe technieken om bestaande problemen over het Internet op te lossen, zoals Remote Procedure Calls (RPC). De industrie had veel geleerd van pogingen om COM en CORBA algemeen verspreid te krijgen, maar steeds belandden de verschillende producenten in belangenconflicten. Er was behoefte aan universele interoperabiliteit, oplossingen waarin iedereen zich kon in vinden.

Het belang van standaarden

De oplossing werd gevonden in open standaarden, of tenminste in het uitpuren en vernieuwen van de bestaande standaarden. Het open-zijn is belangrijk, om lock-in door één of enkele firma’s te vermijden. HTML wordt onderhouden door het W3C. Deze onafhankelijke en non-profit organisatie werd door Tim Berners-Lee (de “uitvinder” van het Internet) en enkele anderen opgericht juist om dergelijke standaarden te bewaken. W3C heeft als twee voornaamste taken:

Gebruik van standaarden aanmoedigen, actief promoten, met de steun van de grote spelers binnen de software business.
De standaarden technisch verbeteren.

In de hierboven beschreven tijdgeest was intussen XML ontstaan. De bedoeling van XML was oorspronkelijk om tegemoet te komen aan de technische beperkingen van HTML. Al snel werd echter duidelijk dat je niet zomaar van HTML naar XML kon overstappen. Wat moest er gebeuren met de miljoenen HTML pagina’s die reeds bestonden? En er zou altijd behoefte zijn aan een HTML-achtige mark-up taal omwille van zijn eenvoud en bruikbaarheid in presentatie-op-scherm. Bovendien bleek XML zoveel meer te zijn dan een verbeterde HTML, en de rest is geschiedenis.

HTML werd parallel verder ontwikkeld, maar moest voortaan enkel structuur geven aan inhoud, en werd ontdaan van alle tags en attributen die enkel stijl op het oog hadden, typografie, kleur, enz. (zoals de FONT tag), en voor dat doel werd de Cascading Style Sheets (CSS) standaard ontwikkeld. De vernieuwde HTML heette HTML 4.01.

Om de interoperabiliteit tussen XML en HTML nog te vergroten werd HTML 4.01 herschreven als “well-formed” en gevalideerde XML. Deze standaard werd XHTML gedoopt. XHTML is de logische next step van de HTML evolutie en uiteindelijk zal de oorspronkelijke HTML verdwijnen.

En hoe moet het nu verder?

Advocaten van standaarden vonden uiteindelijk gehoor bij de browser-producenten. Moderne browsers ondersteunen deze quasi volledig, en bovendien kunnen ze verschillende varianten van elkaar onderscheiden. Oude HTML presenteren ze in quirks mode, en nieuwe pagina’s (herkenbaar aan hun DOCTYPE) worden in strict mode gepresenteerd.

De browser-oorlog Netscape Navigator vs. Internet Explorer is gelukkig voorbij. De versie 4 van beide schoten in allerlei opzichten tekort, toch schrijven we nog altijd HTML code als was het voor de IE4.0. Dit maakt de problemen met iedere nieuwe browserversie die op de markt komt groter, lost geen accessibility- en cross-whatever problemen op en biedt dus geen lange-termijn oplossing.

IE5 is ondertussen 3 jaar oud, IE6 1 jaar en beiden hebben uitstekende support voor HTML 4.01 en CSS 1. Waarom niet de HTML code volledig richten op dergelijke standards-compliant browsers en er tegelijk voor zorgen dat individuen met oudere versies of zonder IE geen echte functionaliteit (≠ style) verliezen? Pure HTML 4.01, gecombineerd met doorgedreven gebruik van CSS, belooft dit. En je ondersteunt automatisch alle andere browsers die standards-compliant zijn (zoals Mozilla 1.0, Netscape 6, Opera 6, etc. op zowel Windows als Mac als Unix) zonder dat het extra moeite kost.

We komen stilaan in een situatie waarbij mensen die geen CSS ondersteunende browser gebruiken, daar een goede reden voor hebben. Van anderen kunnen we verwachten dat ze upgraden. Deze tactiek van forced-upgrade wordt overal toegepast, omdat de kosten om oude systemen te ondersteunen te hoog oplopen.

Nu gevalideerde (X)HTML schrijven garandeert dat ook binnen vijf jaar alle browsers de code nog gaan interpreteren op de manier waarop wij ze nu bedoeld hebben. Als je de korte geschiedenis van HTML code kent, dan weet je welk een enorm voordeel dit is. Straks gaan we nog dieper in op de échte voordelen van HTML/CSS.
Er is trouwens geen enkele garantie dat IE over nog eens vijf jaar even dominant zal zijn als vandaag. Er zijn opnieuw een paar zeer sterke concurrenten op komst die het belang van IE by default wel eens in vraag zouden kunnen stellen. AOL, misschien wel de belangrijkste ISP op de Amerikaanse markt en eigenaar van Netscape, experimenteert openlijk met de Mozilla code. Dit kan een nieuwe browseroorlog uitlokken.

Het blijft natuurlijk koffiedik kijken, en voorlopig blijft IE dé referentie.

Mogelijk wordt het belang van de klassieke browser ook kleiner. Er wordt nu reeds gesurft via PDA’s zoals de iPac en de Palm Pilot. Het is een trend die zich ongetwijfeld zal blijven voortzetten in de toekomst. Nokia wil gebruikers laten surfen via GSM, en denkt hierbij aan de Opera browser. Kleinere schermen dus en nieuwe browserversies (ook van IE): een mooie toekomst.

De voordelen van standards-compliant HTML 4.01 en CSS code

HTML 4.01 + CSS draait rond het volledig gescheiden houden van stijl en inhoud. In HTML steek je enkel en alleen structuur, inhoud (de functionaliteit) en metadata over de inhoud. Wanneer je de pagina oproept zonder stylesheet krijg je de ruwe, niet opgemaakte vorm te zien, maar toch hoort de betekenis duidelijk te zijn.

In CSS steek je enkel en alleen opmaak. CSS bepaalt in feite hoe de user-agent (meestal de browser) de code gaat visualiseren. Dit betekent dat browsers die geen CSS ondersteunen de opmaak missen, maar toch van de volledige functionaliteit gebruik kunnen maken. Je moet met CSS niet meer ontwikkelen naar de kleinste gemene deler, tags die niet worden begrepen worden gewoon genegeerd en kunnen dus niet tot fouten leiden. Zelfs IE3 en NN4 ondersteunden reeds CSS, zij het in beperkte mate.

Standaard HTML 4.01:

is dé open industriestandaard voor WUI (Web User Interface) code.En wordt als dusdanig gepromoot. Moderne browsers (IE vanaf versie 5) ondersteunen ze 100%. HTML 3.2 of ouder schrijven is niet alleen démodé, het wordt ten stelligste afgeraden, en kan in de toekomst grote problemen opleveren.
maakt het resultaat voorspelbaar. Striktere syntaxregels zorgen voor een meer uniforme source code en maken duidelijke afspraken mogelijk over hoe deze gehanteerd en geïnterpreteerd dient te worden. Rond de interpretatie van HTML bestaan nauwkeurige specificaties, zodat je vrij goed kunt weten hoe de code er op het scherm (of enig ander medium) uit zal zien, zonder dit vooraf echt te hebben getest. Dit leidt in de praktijk ook tot een betere kennis bij de programmeur van hoe de browser met de code omgaat en waarom.
is leesbaarder, wordt gemakkelijker begrepen en geïnterpreteerd. De praktijk van steeds complexer wordende software met steeds meer en andere programmeurs op hetzelfde project heeft het belang aangetoond van begrijpelijke en goed gedocumenteerde code. Niks is frustrerender dan oude rommelcode gaan debuggen of uitbreiden. Het leidt ook al te vaak tot de introductie van nieuwe fouten. Code met een duidelijke en consistente structuur zorgt ervoor dat ze veel sneller begrepen wordt door een menselijke lezer.
kan automatisch gevalideerd worden. Validatie is belangrijk, en niet in het minst bij niet-gecompileerde code. Het is de beste manier om fouten op te sporen, en het creëert een zekere discipline en routine.
is consistenter. Consistentie zit in het gebruik van dezelfde tags op dezelfde manier, dezelfde methode van pagina’s opbouwen, het gebruik van de juiste attributen, enz. Het kan er bijvoorbeeld voor zorgen dat wijzigingen over veel pagina’s heen veel sneller kunnen gebeuren, omdat je vooraf weet waar alles zal staan. Het helpt opnieuw bij de toegankelijkheid van code die je zelf niet hebt geschreven. En als alle HTML consistent is wordt het ook gemakkelijk om bepaalde stukken elders te gaan hergebruiken zonder opnieuw teveel te moeten tweaken.
helpt onderhoudstaken te automatiseren. Een strikte syntax en een consistente structuur zorgen ervoor dat bepaalde handelingen niet meer manueel hoeven te gebeuren. Regular Expressions gebruiken om tekstwijzigingen over meerdere pagina’s tegelijk uit te voeren zijn hiervan een goed voorbeeld, of het manipuleren van de code via de DOM (nog eenvoudiger als je XHTML gebruikt).
is goed gedocumenteerd. HTML is door het W3C tot in de kleinste details gedocumenteerd. Browsers proberen deze specificaties rigoureus te volgen. Wanneer er dus een probleem optreedt, kan er gemakkelijker worden uitgezocht wat er precies foutloopt en waarom. Zo kun je gericht werken en vermijd je trial-and-error gedoe.
maakt ontwikkeling sneller/goedkoper. Beter leesbare, sneller te onderhouden code kort de ontwikkelingstijd drastisch in en verhoogt de productiviteit in dezelfde tijdspanne. Er hangt dus een (jammer genoeg vaak moeilijk meetbare) kostenbesparing aan vast.
wordt sneller gerenderd door browsers omdat er minder “vrije interpretatie” van de browser vereist is.
vergroot de kans op interoperability tussen diverse systemen. Code die volgens een strikte syntax wordt geschreven garandeert up-front dat alle tools/programma’s/software die de standaard ondersteunen ook overweg kunnen met die code, en ze exact op dezelfde manier zullen interpreteren. Je hoeft dus niet langer zelf moeite te doen om andere systemen te ondersteunen.
verkleint de kans op fouten. Omwille van alle bovenstaande redenen. De kwaliteit van het eindproduct verbetert, en da’s altijd mooi meegenomen.
vergroot de gebruiksvriendelijkheid voor ontwikkelaar én eindgebruiker. Pagina’s met minder fouten, die performanter zijn, leiden tot minder frustraties bij iedereen die het systeem gaat gebruiken. Gebruiksvriendelijkheid gaat natuurlijk veel verder dan de code, maar de code is wel het fundament.
is een Unique Selling Proposition (USP). Een gebruiksvriendelijk product van hoge kwaliteit, en flexibel in interoperability en extensibility, is beter te verkopen.
is platform-onafhankelijk en browser-onafhankelijk. We hoeven ons niet langer zorgen te maken over de enkelingen met Netscape of IE op Mac. De interpretatie van HTML 4.01 is bij alle standards-compliant browsers identiek. De verschillen die er wel nog zijn in het eindresultaat zitten in de CSS, niet in de HTML.
schrijven is leerzaam. Voor wie ook geïnteresseerd is in het waarom van de dingen. En het vereist discipline en routine van de programmeur.

CSS (1 en 2):

is een open industriestandaard van het W3C voor WUI look-and-feel.
De ondersteuning is niet overal gelijk, maar alles zit in één file, dus er is heel wat minder tijd nodig om te tweaken. CSS 1 wordt door alle moderne browsers zowat 100% ondersteund.
is de beste optie om valide HTML vorm te geven. Daarnaast is het ook de meest ondersteunde en misschien wel enig redelijke methode.
maakt HTML code onderhouden sneller, véél sneller. Door alle stijl-gerelateerde informatie te centraliseren in één of enkele files kun je duizenden HTML pagina’s “wijzigen” door een paar regels CSS code aan te passen.
maakt HTML code korter, je doet hetzelfde met minder KB’s. HTML files worden kleiner en hanteerbaarder omdat veel informatie “ontdubbeld” wordt en gecentraliseerd in één CSS file. Dit vergroot de efficiëntie op zowat alle niveaus, snellere download- en rendertijd client-side, efficiëntere caching, minder server-load, noem maar op.
maakt HTML code onderhouden gemakkelijker en leuker. Heel wat repetitieve taakjes kunnen worden vermeden of geautomatiseerd. Je werkt met minder verschillende files. Je hebt sneller resultaat.
maakt HTML code flexibeler, gemakkelijker te hergebruiken, ook op andere dragers (bv. GSM, PDA, enz.). Dit kan belangrijk zijn naar de toekomst toe.
draagt bij tot de accessibility door de inhoud van de vorm te scheiden. Accessibility zal altijd een issue blijven. Mindervalide gebruikers gaan accommoderen zonder extra moeite te moeten doen is een aardige plus.

XHTML 1.0:

is gevalideerde HTML én XML in één (best of both worlds). XHTML neemt alle voordelen van XML over, en het heeft nog steeds de eenvoud van HTML.
wordt aangeraden door W3C (status: “recommendation”). Ten koste van de gewone HTML.
maakt XSL transformaties eenvoudig. XHTML maakt het eenvoudig om zowel als input en als output te dienen van XSLT. Het genereren van HTML uit XML en XSL is reeds enige tijd in gebruik. XSL is ondertussen geëvolueerd naar XSLT (XSL Transformaties) waarbij het resultaat óók XML is, en XSL-FO (formatting objects) waarbij de output print-gericht (PDF, Word, enz.) is. De verwachte “well-formed” XML als output van XSLT gaat hand in hand met het gebruik van XHTML. En de XHTML kan daarna opnieuw getransformeerd worden, iets wat met klassieke HTML niet zomaar mogelijk is.
is 100% backwards compatible. Iedere browser die ooit werd gemaakt voor het Internet begrijpt deels of volledig HTML. XHTML wordt door al deze browsers als HTML herkend (de root-tag blijft immers HTML), en zal er dus een vorm aan geven. Dit wil niet zeggen dat al deze browsers ook hetzelfde zullen tonen, de visualisatie hangt immers af van de CSS.
is forwards compatible, biedt goede vooruitzichten voor de toekomst. XHTML is de gedoodverfde vervanger van HTML, het is ook een logische evolutie, omdat toekomstige browsers zich volledig op XML zullen richten. XHTML zal dus zeker nog zeer lang meegaan, langer dan “regular” HTML.
wordt gecombineerd met andere XML standaarden (RDF, SMIL, SVG, XForms). Als we even in de toekomst kijken, en zien welke nuttige XML-gebaseerde standaarden er langzaam aan het evolueren zijn (nuttig in de zin dat ze extra functonaliteit mogelijk maken, en nog meer taken kunnen automatiseren), dan wordt de echte kracht van XHTML duidelijk. XHTML wordt immers voorzien als de lijm tussen verschillende andere XML namespaces. De basis hiervan werd geformaliseerd in XHTML 1.1.
is op een uur geleerd, op voorwaarde dat je HTML en wat XML kent. Het verschil tussen HTML 4.01 en XHTML 1.0 zit in syntactische details.
maakt extensie met eigen tags mogelijk. Deze zijn niet noodzakelijk zichtbaar voor de eindgebruiker, maar kunnen de ontwikkeling op veel gebieden vergemakkelijken.

Toch is het niet allemaal rozengeur en maneschijn.

De huidige kennis bij programmeurs van HTML is beperkt. Iedere programmeur weet ongeveer wat er werkt, en in de praktijk zijn er geen onoverkomelijke problemen, dus is geen drang om cutting-edge te werken. Het blijft een trage evolutie.

De leercurve is steiler dan spaghetticode HTML. Er wordt motivatie en discipline vereist van de programmeur. Bepaalde gewoontes moeten aangeleerd, en evenveel moeten afgeleerd worden.

Sommige problemen verdwijnen niet. User Interface Design problemen worden niet opgelost omdat de code ineens uit gevalideerde XHTML bestaat. Er ligt nog altijd een grote verantwoordelijheid bij de programmeur zelf, en anderen, want bijvoorbeeld usability problemen op gebied van layout en interaction design zijn in feite veel belangrijker dan de code problemen.

Een weak-point vandaag is vast en zeker het gebrek aan degelijke editors. Nu advocaten van web standaarden de editor-makers onder druk zetten om gevalideerde code af te leveren, kunnen we verwachten dat toekomstige versie van populaire editors zoals Dreamweaver XHTML en CSS gaan produceren. Maar even belangrijk is dat IDE’s zoals Visual Studio .NET goede code produceren, want veel HTML code wordt geproduceerd door niet-gespecialiseerde software engineers.

Herschrijven is zelden de oplossing, je gaat in de praktijk deze principes enkel bij nieuwe applicaties toepassen.

Wat kun je concreet doen

Grote veranderingen in aanpak moeten er niet gebeuren. De syntactische verschillen tussen losse en strikte code zijn beperkt. Een ééndaagse opleiding is voldoende voor iemand die praktijkervaring heeft in het schrijven van HTML en/of XML. Belangrijker is de verandering in mentaliteit die nodig is. Vooraf nadenken over hoe je de pagina zult opbouwen, de inhoud gaat structureren,…

Je kunt heel wat regels gaan opleggen, maar als ze het development proces onnodig verzwaren hebben ze geen echte meerwaarde.

Bepaalde dingen zijn belangrijker dan anderen. We trachten hier vooral de nadruk te leggen op goede code, niet zozeer op het al dan niet gebruiken van HTML 4.01 of XHTML 1.0, Strict of Transitional. In al deze varianten kun je goede en slechte code schrijven.

Belangrijker is bijvoorbeeld het consistent gebruiken van CSS voor álle look-and-feel. Het niet langer gebruik maken van attributen zoals MARGIN, ALIGN en BGCOLOR, het vermijden van tables om een layout te fixeren. Elke toepassing zal in principe ook zijn eigen .css file hebben (desnoods enkele), of één gemeenschappelijke voor kleinere applicaties.

HTML code valideren is eenvoudig, en kan gratis via de W3C HTML validator. Je kunt zelfs tijdens de ontwikkelingsfase files uploaden en die zo laten checken. Doe de test zelf eens met webpagina’s die je eerder schreef, zeer leerrijk.

Interessante links

Tools en tutorials voor diegenen die hun technische kennis over de hier beschreven technologieën willen vergroten.

Veel succes!

20.09.2002 2:18 pm : Code :