Advies Overheid.nl adviseert 'next generation' websites

Advies Overheid.nl brengt op zijn site een advies uit aan de overheid over de wijze waarop haar sites opgebouwd zouden moeten worden. Het programmabureau achter Overheid.nl zegt dat het gebruik van zogenaamde 'next generation' websites vele voordelen biedt boven de huidige wat oudere pagina's. Een site van de nieuwe generatie is volledig gebaseerd op de geldende webstandaarden en kenmerkt zich door een scheiding van inhoud en presentatie met XHTML Strict en CSS en markup die uitsluitend gebruikt wordt voor 'intended purpose'.

Als voorbeeld noemt men de site van de Polizei Nordrhein-Westfalen, die onlangs de Duitse Biene-Award heeft gewonnen. Deze nieuwe websites hebben een aantal voordelen boven de oudere varianten, zo lezen we op de site van Advies Overheid. Zo zijn de 'next generation' websites goedkoper in onderhoud, kleiner van formaat en dus sneller te laden, hebben ze een betere compatibiliteit met zowel oudere als nieuwere browsers en is de continuïteit van de vormgeving op deze manier beter te waarborgen:

• Compatibiliteit met nieuwe (versies van) browsers is beter gewaarborgd, maar ook de bruikbaarheid in oudere browsers;
  
• De werkwijze is veel toekomstvaster dan de huidige;
  
• Het maakt de toepassing van 'shared services' eenvoudiger;
  
• Door de strikte scheiding van inhoud en presentatie is consistentie van de vormgeving eenvoudiger te waarborgen.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (70)

Allemaal erg leuk, en in vind het een positive ontwikkeling.
Ik ben mijn site nu volledig XHTML/CSS aan het maken, en het is veel fijner coderen.

Ik vraag me alleen af in hoeverre Internet Explorer deze websites ondersteund. Ik heb nu al 'on the edge' zaken gevonden die niet in IE werken.

Als je bijvoorbeeld deze site in zowel Mozilla als IE bekijkt snap je wat ik bedoel: http://www.meyerweb.com/eric/css/edge/ Vooral de popup menu's zonder JavaScript zijn erg mooi, en de spiral-achtergrond waar de inhoud transparant overheen beweegt.

Ik snap niet dat een bedrijf als Microsoft niet in staat is om een browser te maken die fatsoenlijk CSS ondersteunt.

Kijk eens wat Apple met Safari binnen één jaar heeft bereikt! Kwa CSS ondersteuning is die bijna gelijkwaardig zo niet beter dan Mozilla.

Get off your lazy ass Microsoft!!!

Ze zijn er wel toe in staat, maar ze WILLEN het niet...

Bovendien ontwikkelen veel webmasters alleen voor Internet Explorer, proberen het DAAR goed eruit te laten zien, en testen dan niet meer in Mozilla/Opera. Dat heeft als gevolg dat die websites er in IE goed uitzien, maar in de anderen mogelijk niet... hoppa, extra voordeel voor IE.

Microsoft gebruikt graag hun eigen standaarden....
Veelal zijn dat variaties op bestaande maar net niet compatible

Kijk eens wat Apple met Safari binnen één jaar heeft bereikt! Kwa CSS ondersteuning is die bijna gelijkwaardig zo niet beter dan Mozilla.

Safari gebruikt dan ook de rendering engine van Konqueror genaamd Khtml. En Khtml zit nog lang niet op het niveau van Gecko. Langzaam aan begint Khtml de dingen te ondersteunen die Gecko ondersteund.

Ik weet dat Safari KHTML gebruikt.
Met name door de inspanningen van Apple (m.n. Dave Hyatt) is KHTML enorm verbeterd.

De volgende versie van Safari gaat nog veel verder wat de ondersteuning van CSS betreft:

http://weblogs.mozillazine.org/hyatt/archives/2003_12.html

Tijd voor een Safari port naar windows?

en hun eigen site:

http://validator.w3.org/check?uri=http://www.advies.overheid.nl/page.j sp?pageid=39204

Ik vind het wel kenmerkend voor allerlei grote instanties die anderen vertellen hoe websites moeten worden gemaakt, maar zich er zelf niets van aantrekken.

Hetzelfde is het geval bij drempelsweg.nl, iedereen vertellen hoe een website moet worden gemaakt maar zelf het niet doen met als excuus "geldgebrek". (dat was hun reactie op mijn vraag daarover, inmiddels al weer een hele tijd geleden)

Daar gaat je geloofwaardigheid

"Geldgebrek"?

Een site maken die wel valideert bij w3c kost zelfs minder geld.

Je moest eens weten hoeveel tijd er verspilt wordt met de trial en error aanpak die sommige webdesigners erop nahouden.

Het echte probleem is dat veel van die zogenaamde webdesigners geen idee hebben waar ze mee bezig zijn.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.advies.overheid.nl% 2Fpage.jsp%3Fpageid%3D39204&charset=utf-8+%28Unicode%2C+worldwide%29&d octype=XHTML+1.0+Strict

ook wel grappig

Nog erger: http://redirect.spider007.net/?id=42
(even een redirect om de layout niet te verneuken)

Ze zeggen zelf dat er XHTML Strict moet worden gebruik... dan krijg je alleen nog maar meer fouten dan wanneer je het als HTML 4.01 laat validaten

dat er meer fouten met xhtml strickt komen is simpel uit te leggen.
bij xhtml moet bijna alles afgesloten worden voorbeeld <html&gt ;(html) <html /&gt ;(xhtml).
en dat hebben ze niet gedaan. het is gewoon een html pagina met het doc van xhtml.

Tis nog altijd </html> hoor, ik denk dat je bedoeld dat je sommige tags in 1 defenitie Kan afsluiten zoals:

<br />
<p />
<img alt="" src="bl@@t.jpg" />

het was ook als voorbeeld bedoelt. en je kan ze afsluiten is fout je moet ze afsluiten volgens het w3c

Pak dan meteen XHTML 1.0 strict

't Is dan ook wel triest gesteld met sommige websites. Ik zie het zooooo vaak dat die kleine rotbedrijfjes, die -- met alle respect -- een slecht product neerzetten, een opdracht krijgen alleen omdat ze goedkoop zijn.

Da's erg frustrerend. Vooral omdat je al weer van tevoren dat dit laatste bedrijf de deadline niet gaat halen, een slecht ontwerp neerzet, alles in Dreamweaver of Frontpage zit te "programmeren", een "administratie panel" hebben wat eigenlijk gewoon PHP Nuke is (een standaard php content-pruts-management-systeempje)...

Zonde van de tijd en het geld wat zo'n potentiële klant hier dan instopt.

Nogmaals, niet kwaad bedoeld. Vergelijk het met een 3e-hands autoverkoper die jouw een "klassieke Ferrari" verkoopt voor 200 Euro's, en een Ferrari Dealer die je er een voor 40.000 Euro's probeert te verkopen, inclusief service, garantie, etc.

Ach.. gelukkig zijn de ècht grote klanten veel serieuzer bezig, die ook kwaliteit zien als ze het gepresenteerd krijgen met een mooie beamer

Alsof alle kleine bedrijven maar wat aanrommelen!

Ik kan hezelfde zeggen over de grote bedrijven, duur, personeel met laag kennisniveau en uitermate inflexibel en niet klant/oplossings gericht.

Het zijn juist de grotere bedrijven die hun uber junior personeel het werk wat jij beschrijft laten uitvoeren (zonder supervisie en on site). Tegen bijna vol tarief natuurlijk en met de 'marketing' support van het hele bedrijf erachter.

Ik denk dan ook dat je je post beter achterwege had kunen laten.

't Is dan ook wel triest gesteld met sommige websites. Ik zie het zooooo vaak dat die kleine rotbedrijfjes, die -- met alle respect -- een slecht product neerzetten, een opdracht krijgen alleen omdat ze goedkoop zijn.

(knip rest van de onzin)

Wat leuk dat ik als een werknemer van een klein bedrijf zoiets moet horen over mijn eigen produkten. Even voor jou, knul: er is geen direct verband tussen de grootte van een bedrjf en de kwaliteit van de webpagina's die ze afleveren. Anders zou ik de mijne waarschijnlijk in Word afleveren.

Lekker zeg, door een of ander VB-pikkie vergeleken worden met een derderangs autoverkoper. Nou ja, de beste stuurlui staan aan wal, zoals het Oud-Hollandsche spreekwoord zegt.

Een belangrijk voordeel zou ook de 'accessability' kunnen zijn. Immers zijn websites waarvan de content en presentatie netjes gescheiden zijn over het algemeen makkelijker te interpreteren door screenreaders e.d.

(Bovendien kan allerlei info voor die specifieke devices in de style sheets opgenomen worden)

(edit)In het artikel staat nog de volgende tekst:

Een site stelt eisen aan browser en/of schermresolutie
U kent vast wel de opmerking 'deze site kan het best worden bekeken met [brower X] bij een beeldschermresolutie van 1024x768 pixels'. Een ander voorbeeld is het gebruik van scripts die de browser of schermresolutie proberen vast te stellen. Een dergelijke werkwijze houdt geen rekening met het feit dat gebruikers met andere browsers en beeldschermen (of apparaten als brailleleesregels) óók recht hebben op toegang tot informatie op een overheidswebsite.

(/edit)

Het advies is een beetje onzin. Content en layout scheidt je al veel eerder - maar daar wordt met geen woord over gerept. Daarbij komt dat CSS2 en vooral CSS3 nog niet door alle browsers volledig ondersteund wordt (Neen, ook niet door Mozilla).

Het gaat hier typisch om een stelletje kneuzen die niets beters te doen hebben dan de volledige website van het W3C te lezen en zich vervolgens handenwrijvend voor de PC zetten om in Wordstar even een leuk document te gaan kloppen over hetgeen ze gelezen hebben, daarbij niet gehinderd door enige praktische kennis.

Het scheiden van content en layout is meer een kreet dan wat anders. The CSS Garden of Zen heeft trouwens wel heel netjes bewezen dat het a) kan en b) het alles een stuk MINDER onderhoudbaar maakt. Als je namelijk wat in de layout wil wijzigen OF er is tekst die plotseling wat groter c.q. kleiner wordt dan zit je met de puur css-driven websites onmiddellijk in de knoei en kan je zo een paar dagdelen besteden om je volledige layout te herstellen. Overigens geven ze op de Garden ook wel toe dat het allemaal beperkingen heeft gezien elke browser zijn eigen interpretatie van CSS heeft.

"Het advies is een beetje onzin."

Het advies is zeker geen onzin.
Veel webdesigners maken de fout door HTML als een paginaopmaak taal te zien.
HTML is een markup taal en dat is heel wat anders.

"Content en layout scheidt je al veel eerder - maar daar wordt met geen woord over gerept"

Dat is alleen het geval als je HTML/CSS puur als een paginaopmaak taal gebruikt.

"Er is tekst die plotseling wat groter c.q. kleiner wordt dan zit je met de puur css-driven websites onmiddellijk in de knoei en kan je zo een paar dagdelen besteden om je volledige layout te herstellen"

En daar geef je meteen een prachtig voorbeeld van wat ik bedoel. Als je de paginaopmaak benadering loslaat dan is een dergelijke wijziging met CSS een eitje.

Als webdesigner moet je niet van vaste fontsizes uitgaan, de gebruiker bepaald welke fontsize hij wil gebruiken, maw als webdesigner heb je daar geen controle over.

advies is geen onzin misschien , maar wel een beetje 'laat' en onnozel in die zin dat men het hier doet voorkomen dat er een enoooooooorme verbetering plaats kan vinden, terwijl de meeste webdesigners/programmeurs al lang dit soort technieken/methodieken toepassen... beetje mosterd na de maaltijd, waar weer veel tijd in gestoken is...

Daarnaast zijn juist die programmeurs die dit al tijdje doen (ikke dus) er al achter gekomen dat generalisatie en wat men noemt CMS (content management system) niet heilig is, en zeker z'n beperkingen heeft. Oa dus op beheer. Beheer moet je nl. ook integreren in 'tooltjes', anders ga je de mist in.
Verder zijn uitbreidingen en wijzigingen lastiger omdat alles 'ingebakken' zit in mallen/standaarden ed.. dat shared services klinkt bijv. leuk, maar houdt wel in dat als je daar wilt wijzigen , dat impacked heeft door de hele applicatie!! Dat weet men al heel lang in OO-land met DLL's....

Jou beeld van webdesigners is wel wat kort door de bocht trouwens, klinkt nogal wat minachting uit, ... je kunt nl. niet echt 'fouten' maken zeker niet als een site gewoon draait en precies doet wat ie moet doen. Interesseert het dan iemand dat het niet precies volgens de 'standaard' gedaan is? .. zeker gezien de huidige 'markup' browsers, is de term 'standaard' een lachtertje.... Ik heb nog nooit zoveel standaarden zo snel gewijzigd zien worden.

HTML is wel degelijk een paginaopmaak, ik zie jou statement ff niet. As je het letterlijk neemt heb je gelijk (hyper linked.. ja dan wel), maar gezien alle HTML tags (tables, font, br, etc zijn wel degelijk opmaak structuren).... tag FONT is wel degelijk HTML en heeft niets van doen met 'markup' , maar met de 'opmaak'....

[edit] laat ik het anders formuleren gezien de reacties hieronder... het is niet opgezet als paginaopmaak, maar daar is het wel naar getransformeerd. En daarbij, wat doet dat er toe?
Ik kan wel degelijk momenteel met FONT de opmaak bepalen, grappigerwijze al voor browsers met nog geen nummering.... Daarbij gaan 'goeie' browsers in de automaat als lettertype niet bestaat, pakt dan z'n default. dus...

En me dunkt dat er 'slechte' webdesigners zijn, ik irriteer me mateloos aan al die 'hippe' sites met de wereld aan Javascriptjes die het bij vlagen totaal laten afweten (tweakers is geen uitzondering, komt hier ook nog wel 's voor...).
Das trouwens ook een nadeel van die 'content sites' ofwel 'automated content' opzet, meestal gaat het Javascript gedeelte gruwelijk de mist in .. . soms simpelweg omdat bepaalde componenten de ene keer wel, maar de andere keer niet aanwezig zijn....
Probeer dan maar's een helpdesk te informeren hierover, ze geloven je nooit en never niet! Ligt aan m'n browser, m'n computer, etc... maar aan't systeem? Nee dah kan nie meneer. Het geen mij altijd wel deugt doet, voel ik mij weer heeeeel speciaal, ik ben de enige die dat krijgt ... hehehe.

@GruttePier:
Ik zou van jou wel heel graag willen horen wanneer W3C een levende standaard voor het laatst heeft aangepast.

Er zijn nieuwe versies van gekomen, maar als jij een HTML4 document hebt zal die over 5 jaar (Wanneer MS bijv. eindelijk een nieuwe browser uitbrengt ) er nog steeds hetzelfde uitzien.

Jij ziet zijn statement inderdaad niet. Tables zijn nooit bedoeld als opmaak-tool, font-tags zijn deprecated (xhtml) en met br's was ook wat aan de hand, maar dat staat mijn geheugen mij momenteel niet toe te herinneren (viva la feestdagen).

'Je kunt geen fouten maken als een site gewoon draait'. Hij draait misschien in jouw browser, maar hoe zit het met mensen die jouw browser niet kunnen of willen gebruiken? Die hebben maar pech gehad?
Daarvoor zijn juist standaarden.

@TheCodeForce:
Jij hebt het over DHTML als zijnde een standaard (zo komt het iig over). DHTML is echter niets meer dan Javascript die de DOM aanspreekt, wat op zijn beurt niets anders is dan de opbouw van een (X)HTML document.

Overigens betwijfel ik jouw statement over dat de meeste pagina's applicaties zijn die in een browser draaien.

Voor de redenen die jij noemt kan je beter een echte applicatie bouwen.

Dat de meeste mensen de complexiteit van een webapplicatie onderschatten of de aard ervan verkeerd begrijpen staat vast.

Das ongeveer de enige statement uit je post waar ik het mee eens ben, al is de rest van je tekst wel een goede onderbouwing ervan

Ik ben ervan overtuigd dat als het meerendeel van het internet correct gebruik maakt van xhtml het een stuk interessanter zou zijn. Als je html semantisch correct is, wordt het voor een zoekmachine ook een stuk makkelijker om te bepalen welke delen van jouw tekst belangrijk zijn.
Maar ik geloof dat ik nu grotendeels de heren Zeldman en Meyer aan het herhalen ben...

"Jou beeld van webdesigners is wel wat kort door de bocht trouwens klinkt nogal wat minachting uit"

Helaas heb teveel sites gezien die niet goed werken met andere browsers als gevolg van knullige fouten.

"je kunt nl. niet echt 'fouten' maken zeker niet als een site gewoon draait en precies doet wat ie moet doen. "

Het mag misschien werken op de browser die de webdesigner heeft gebruikt om te testen, maar dat wil niet zeggen dat de site ook goed werkt met andere browsers omdat de foutafhandeling daar anders geregeld is.
Dat soort ellende kun je voorkomen door de HTML te valideren ofwel je te houden aan de 'standaard'

"Interesseert het dan iemand dat het niet precies volgens de 'standaard' gedaan is?"

Een volmondig ja, als men door het volgen van de 'standaard' dergelijke problemen kan voorkomen.

HTML is wel degelijk een paginaopmaak, ik zie jou statement ff niet. As je het letterlijk neemt heb je gelijk (hyper linked.. ja dan wel), maar gezien alle HTML tags (tables, font, br, etc zijn wel degelijk opmaak structuren).... tag FONT is wel degelijk HTML en heeft niets van doen met 'markup' , maar met de 'opmaak'....

En wat als het font niet aanwezig is of als de gebruiker zelf een stylesheet heeft gekozen?

Die tags zijn slechts een hint voor de browser, je kunt er niets mee afdwingen.

@Loempia

Alle bekende sites en forums zijn 100% zeker webapplicaties, geen twijfel over mogelijk. De homepages van Miep op de hoek en zo zijn dat beslist niet. Zodra de HTML gegenereerd wordt (realtime of semi-realtime), en niet d.m.v. een editor of het exact inkloppen door een gebruiker is er sprake van een applicatie omdat het statische er af is.

DHTML is inderdaad geen 'standaard' , maar is iets meer als jij doet voorkomen. Om het te laten werken zijn de HTML elementen ook identificeerbaar gemaakt in HTML4.0 door een ID tag! Anders kun je er met javascript nog niets zinnigs mee!

Ik weet overigens niet of jou opmerking waar je het met eens bent sarcastich bedoeld is of niet, maar voor de lol van discuseren ga ik daar maar ff van uit.

Je komt bij mij een beetje over als een dromer of een puur theoretisch iemand. Jij zou dus perfect passen in de groep van mensen die de praktijk onderschatten.

Wat ik nogal naief vindt, en daar ben jij zeker niet de enige in, is die crampachtige houvast aan een 'standaard' die er niet is. Echt die illusie alleen al is om te gillen!

Standaarden die niet afgedwongen worden of kunnen worden zijn eigenlijk niet meer dan een marketing instrument. Je geeft mensen aan wie je een produkt wil verkopen de illusie van betrouwbaarheid en toekomstzekerheid.

Er zijn namelijk altijd meerdere standaarden, en als een standaard niet is afgedwongen, is het niet meer dan een definitie van dit doen we zo. Het zecht dus niets over hoeveel een standaard in de praktijk toegepast wordt en al helemaal niet of deze correct toegepast wordt.

Een standaard staat dus alleen maar garand voor enige uitwisselbaarheid binnen die standaard zelf. Zo zijn er meerdere en ze worden niet allemaal evenveel gebruikt, en je hebt geen controle over de standaard die je op de computer van de gebruiker tegenkomt.

Vanuit de ontwikkelaar en ontwerper gezien is er dus helemaal geen standaard zoals zo velen die term interpreteren!

Het is dus een grote farce die niet afgedrongen 'standaarden'. Het gebruiken als argument in een discussie om gelijk te krijgen getuigd dan ook van totale ontwetendheid en/of wereldvreemdheid. Hiermee ondergraaf je eigenlijk je credietwaardigheid in deze discussie!

doei!

@TheCodeForce:

Er zijn namelijk altijd meerdere standaarden, en als een standaard niet is afgedwongen, is het niet meer dan een definitie van dit doen we zo. Het zecht dus niets over hoeveel een standaard in de praktijk toegepast wordt en al helemaal niet of deze correct toegepast wordt.

Een standaard staat dus alleen maar garand voor enige uitwisselbaarheid binnen die standaard zelf. Zo zijn er meerdere en ze worden niet allemaal evenveel gebruikt, en je hebt geen controle over de standaard die je op de computer van de gebruiker tegenkomt.

Een ander voorbeeld van zo'n niet-afdwingbare standaard is onze Nederlandse taal - maar daar trek jij je ook weinig van aan blijkbaar.

Voor mij moet de standaard niet altijd gevolgd worden, maar het resultaat moet in elke standaard-ondersteunende browser goed weergegeven worden. En laat dat nou net zijn waarvoor een standaard dient. OK, er zijn waarschijnlijk wel fouten die door vele browsers door de vingers gezien worden, en dan mogen die gerust gebruikt worden wat mij betreft (maar wie ben ik...), maar van introducties als 'best viewed with IE5.5 or higher' krijg ik het op mijn heupen.

Dan maar liever standaarden.

Zl.
PS in verband met theoretische, niet-toepasbare kennis, moet jij niet onderdoen voor de persoon die je dit verwijt me dunkt...

Bij applicatie dacht ik meer aan iets wat door de eindgebruiker bediend word, - de dynamiek wordt pas in de browser toegepast. Maar voor beiden visies is wat te zeggen natuurlijk.

DHTML is inderdaad geen 'standaard' , maar is iets meer als jij doet voorkomen. Om het te laten werken zijn de HTML elementen ook identificeerbaar gemaakt in HTML4.0 door een ID tag! Anders kun je er met javascript nog niets zinnigs mee!

Wat dus weer verwijst naar de HTML standaard. Mijn beschrijving was inderdaad ietwat kort door de bocht.

@de rest van je verhaal.
Er is een standaard opgesteld door het W3C, zij zijn de 'uitvinders' van HTML. Sitebouwers dienen pagina's zo te bouwen, en browsers dienen die zo te interpreteren.
Nu is het geval dat er browsers zijn die er eigen interpretaties aan geven, en elementen gaan toevoegen.
Jij noemt dit nieuwe standaarden, ik noem het breken van de standaard.

Om een lang verhaal kort te maken; jij ziet het als ideaal dat de browserfabrikant met het grootste marktaandeel de standaard bepaalt en dat de concurrentie zich daar maar op aan moet passen?

Ik zelf zie liever een onpartijdige groep die zegt 'zo hoort het' en dat vervolgens iedereen die standaard gebruikt. Zolang die groep iig blijft innoveren (en dat doen ze wel aardig, die leute bij W3C) vind ik dat de mooiste oplossing.

Carbon, je hebt gelijk wat betreft dat HTML van oorsprong een markup language is. Het lijkt mij tevens overduidelijk dat die doelstelling al snel na de eerste releases volledig losgelaten is.

Door toevoeging van allerlij opmaak elementen en later CSS met nog meer opmaak mogelijkheden is praktisch gezien de taal getransformeerd naar een opmaak taal. Precies zoals vrijwel iedereen het tegenwoordig toepast. Voor puur markup gebruik je tegenwoordig XML, wat daar veel meer geschikt voor is en bovendien veel flexibeler. HTML is wat markup betreft stenen tijdperk!

HTML als opmaak- en opbouwtaal voor visuale weergave in combinatie met CSS voor detailopmaak en positionering is echter springlevend. Het scheiden van content en opmaak gebeurd tegenwoordig door de informatie (content) in een XML document te plaatsen (realtime) en daarna te transformeren (met XSLT) naar een opmaak taal (HTML+CSS) en alle daarbij behorende client side code.

Voor echt flexibele websites met slimme interfaces zal een website ook veel javascript gebruiken, ongeacht wat voor geile CSS-versie die W3C professors nu weer als opmaak gaan verzinnen om maar te bewijzen dat je alles met opmaak kan. Waar ze ook mee komen, ze slaan altijd de plank mis omdat ze 1 standaard oplossing proberen te maken voor alle mogelijke problemen (welke ze zelf nooit ondervinden of kunnen voorzien). De enige manier om vrijwel alle problemen te tackelen is programeerbaarheid d.m.v. javascript of andere client taal toe te passen op het moment dat een probleem bekend is.

De huidige manier van veel sites om data gestructureerd als XML op te slaan en daarna te transformeren naar DHTML + CSS + javascript is IMHO dus volledig correct. Het is wel zo dat door de breede kennis van de diverse talen die nodig is, de implementatie van veel sites te wensen over laat.

Je moet HTML, CSS, XML, XSLT, javascript, de browser object modellen, en die van de webserver en mogelijk ook SQL en dan nog de script taal op de server (PHP of zo) beheersen. En ook nog eens weten wat de efecten van HTML zijn op diverse browsers, da's een recept voor foutgevoeligheid indien in onervaren handen. Mensen die dus een beetje HTML kennen en een script taal hebben het dus maar moeilijk, er wordt echt veel meer van een ontwikkelaar verlangt!

Roepen dat iets standaard is (niet persoonlijk), terwijl de praktijk uitwijst dat dit niet het geval is, is mijn inziens een beetje dom . En toch is dit precies wat ik veel mensen bij deze onderwerpen zie doen op dit forum. Ik durf te wedden dat een groot gedeelte daarvan het slechts uit gemak of onwetendheid roept.

En dan nu de vraag:

Waarom gaan ontwerpers uit van vaste schermafmeteing, en fontsizes?

De meeste wesites zijn gewoon applicaties met een DHTML interface. Dit zijn dus niet het type informatie presentatie sites waar HTML oorspronkelijk voor bedacht is en waar de W3C nog steeds mee in gedachten loopt. Je zou eens moeten weten wat er niet aan applicaties gemaakt wordt met de browser als interface.

Mijn punt is dat we eisen en wensen voor applicaties wezenlijk verschillen van die van tektuele informatie presentatie sites. Zo moeten ze met de opbouw dynamish zijn en alles op een zo vast mogelijke plaats weergeven, wat vriendelijker is voor de dagelijkse gebruiker. De casual bezieker is hieraan dus echt ondergeschikt, er is een DOELGROEP!

Ook is er veel interactie op de schermen en je wilt niet dat hierdoor continue de server en het netwerk belast worden. Veel javascript en DHTML dus en om alles overzichtelijk te houden en om niet voor teveel schermopbouw verassingen te komen staan, worden vast fontsizes en absolute positionering (of tabellen) gebruikt en heel veel vaste afmetingen!

Dat de meeste mensen de complexiteit van een webapplicatie onderschatten of de aard ervan verkeerd begrijpen staat vast. HTML is tegenwoordig gewoon geen markup taal meer, maar een opmaaktaal en dient dus ook als zodanig benaderd te worden. Bovendien is dat deel wat je uiteindelijk zie, maar een klein deel van de gehele applicatie en de content op de schermen kan sterk varieren, waardoor zekelheidjes als vaste afmetingen noodzijkelijk blijken.

Als je als doorsnee gebruiker een beetje HTML kan maken en je kijkt met die kennis naar een webapplicatie, dan krijg je een totaal verkeerde indruk. Je overschat jezelf met het idee, dat je dat scherpje ook maken in HTML met je editor en denkt: Dit kost me slechts een dag, dus waarom doen die beroepslui daar weken over?

Ignorance is bliss!!!

Dus helaas voor de HTML puristen....maar gelukkig voor ons allemaal is HTML een opmaak taal .

Je kunt met CSS inderdaad pixelperfect sites bouwen.
Maar daarmee is het nog steeds geen echte pagina opmaaktaal zoals Postscript.

De meeste 'opmaak' tags zijn slechts hints voor de browser.

Pixel-perfect websites leveren kwa onderhoud niets dan problemen op, het zijn exact dezelfde problemen die optreden tijdens bv het lokaliseren van een desktop applicatie, tekst past niet, font niet aanwezig etc.
Een HTML layout engine is veel slimmer dan de win32 dialogmanager, er is geen enkele reden om je al die layout ellende op de hals te halen.
Door geen vaste fontsizes tablewidth etc te kiezen kan de HTML engine dat soort problemen zelf oplossen.

Webaplicaties zijn niet puur textuele informatie sites. De sterke punten van HTML zoals word wrap, dynamische tabel en kolom afmetingen en dergelijke worden wel degelijk gebruikt in webapplicaties, ook welke 'pixel perfect' zijn. Dit is zelfs een van de redenen om voor een webapplicatie boven een windows applicatie te verkiezen.

Maar als je de renderer volledige vrijheid geeft, en erg zuinig ben met het geven van exacte sturende informatie zoals afmetingen, dan krijg je een vaak een zootje. Niet alles is altijd optimale inhoud en zal daardoon niet altijd passen, maar de beste manier om content providers garantie te geven dat het er werkbaar uit komt is het toepassen van restricties in de rendering. Dan volgt er een voorspelbaar gedrag en daar kan een ontwerper tenminste rekening mee houden. Zoiets als 'word wrap' en het concept van vertikaal scrollen boven horizontaal scrollen zijn goede voorbeelden van voorspelbaar gedrag waar je als ontwerper op an bouwen.

In een interface komen vaak kleine plaatjes voor in een vaste vlakverdelingen en specifieke posities. Dit maakt absolute positionering en gebruik van veel vaste afmetingen noodzakelijk. Ditzelfde is het geval voor de fonts, en als je een font 1.5 keer zo groot maakt als de bedoeling is, ziet menig wesite waaring enige functionaliteit zit verwerkt er echt niet meer uit. Dit is niet de fout van de site of applicatie, maar is het gevolg van iets willen waarvoor het niet ontwopen en/of gemaakt is.

Als iemand dan echt een groter font nodig heeft om te lezen zijn er echt praktischere oplossingen. Zoals een 17 or 19 inch monitor op een lagere resolutie zetten, is nog veel mooier ook omdat de plaatjes en de interface zoals bedoeld allemaal evenveel vergroot worden en zonder vervorming. Hier wordt dan ook rekening mee gehouden door te ontwerpen voor een lagere resolutie dan de meesten hebben. Ik maak nog steeds applicaties voor een 800x600 resolutie bijvoorbeeld. Iemand met een echt hi-res display dat voor bepaald werk noodzakelijk is, kan dan op een lagere resolutie ook de applicatie nornaal gebruiken. Het scalen van een font om hetzelfde te berijken werkt niet zoals velen nogal naief aannemen. Vergeet tekst.....het is slecht een onderdeel van wat je ziet en gebruikt!

Je moet het ook niet moeilijker willen maken dan het is he? Voor de mensen die in pure content willen zoeken, zonder opmaak en daarom graag sites zien met kale HTML.......die snappen niet dat je daar juist een vorm van XML service voor moet hebben. Content heeft geen interactie, een website wel, en daar zit het gote verschil.

Zolang de transformatie van content naar een pagina opmaak niet volledig en universeel op de client kan plaatsvinden, zullen ontwikkelaard dit op de server side blijven doen en die schijding dus niet voor eindgebruikers zichtbaar zijn.

En waar het echt belangrijk is dat beide vormen aangeboden worden, daar kan ment gewoon twee sites maken. Een kale en een functionele, niets mis mee!

Volledig mee eens. Het lijkt alsof er weer een doelloos adviesorgaan van 50+-ers aan het werk is geweest en vele Eurootjes heeft gespendeerd aan het uitbrengen van een doelloos advies. Alsof een website zonder XHTML en CSS per definitie niet onderhoudbaar is.

Soms is meer beter en helderder dan iets koste wat kost in 1 mal te proppen, wat ze hier voorstellen. Denk aan Normaliseren-Denormaliseren. De schrijvers van dit stuk hebben nog nooit van dit laatste gehoord.

En onderstaande quote zegt voldoende IMO:

Bij Advies Overheid.nl zijn nog geen voorbeelden bekend van Nederlandse overheidswebsites die zondermeer tot 'the Next Generation' kunnen worden gerekend.

Ze kunnen het beter "The Never Generation" noemen

Persoonlijk maakt het me niet uit hoe (HTML/XHTML/CSS) een website gebouwd is.
Wat wel belangrijk is dat de HTML valideert.

Als iets wel lijkt te werken met niet validerende HTML dan maak je gebruik van de "quirks" mode van de browser m.a.w. een neveneffect van de HTML parser.

Een ander voordeel is dat validerende HTML een heel stuk sneller geparsed wordt dan niet validerende HTML

klopt.

Ik dacht dat dit soort luchtfietserij bij instorten van IT wereldje ook wel verdwenen zou zijn, maar blijkbaar steekt het nog steeds de kop op...

Met welke 'oude' pagina's vergelijkt men dit eigenlijk? Meeste sites zijn al data-driven en zitten al vol met CSS tooling. Shared Services? Fantastisch! Is precies zo'n kreet waarbij niemand precies kan vertellen wat dat dan precies inhoudt...
haha... shared services.... tsjonge jonge... 'intended purpose'... 'consistente inhoud'... hahaahaha.... in de categorie 'interieur verzorger', zullen we maar zeggen....

Klinkt mij een beetje als het wiel nog's uitvinden dit... veel blaat, weinig wol.

ohw ja als je wilt weten wat xhtml is, kijk dan hier even: http://www.w3schools.com/xhtml/xhtml_intro.asp

Je haalt hier twee dingen door elkaar. PHP is (zoals ennan al zegt) een serverside scriptingtaal, waarvan de PHP code wordt geparsed door de webserver zodra jij die PHPpagina opvraagt. Zo kan je dus met PHP een dynamische website maken, zoals een nieuwssite met admin paneel waarmee je makkelijk de content van je pagina's wijzigt, of een forum, etc etc.
Zo wordt <?php phpinfo(); ?> omgezet in een pagina waarmee PHP laat zien hoe 'ie is ingesteld enzo. Om geparste PHP te kijken moet je de PHP pagina inderdaad opvragen via een webserver met PHP module, anders krijg je de broncode ervan te zien.

XHTML is daarintegen gewoon het nieuwe HTML standaard wat je browser meestal aangeboden krijgt als je over het web surft.

Met PHP kan je dus dynamische pagina's maken, welke (X)HTML kunnen uitspugen. Staat dus vrij los vanelkaar, ik zou ook een PHP script kunnen maken wat een zwik queries doet op een MySQL database, maar niets in mijn browser laat zien

php en mysql zijn server side, de bezoeker heeft hier verder niks mee te maken, het gaat hier over client side scripting zoals (x)html, css etc

php heeft ook geen mysql nodig, het is alleen een toevoeging, net zoals html geen css nodig heeft

dat je het op school niet kunt bekijken zal ik niet over beginnen, dat is gewoon een oerstomme opmerking, laat wel zien dat je geen idee hebt waar je over praat

ff ontopic, het is allemaal leuk en aardig maar browsers zoals mozilla ed zijn niet helemaal xhtml en strict css2 compatible, bijv de "height"-property werkt niet 100%

vooralsnog lijkt xhtml me overbodig, het levert wel een beter overzichtelijk geheel op als je naar de code kijkt, maar dat is onbelangrijk als een site niet crossbrowser compatible is

Grappig dat je juist Mozilla aanhaalt als browser die niet helemaal met de standaarden zou werken. Juist Mozilla is een van de betere browsers om XHTML/CSS websites mee te bekijken. Internet Explorer daarentegen heeft vaak de CSS regels onjuist geinterpreteerd, waardoor dingen niet of anders werken. Natuurlijk is ook Mozilla nog niet perfect, maar daar wordt tenminste nog aan gewerkt.

Verder is het onzin om te beweren dat XHTML voor problemen zou zorgen. Alle browsers (incl. de stenen tijdperk browsers NS4 en IE4) hebben geen enkele moeite met een XHTML pagina. Sterker nog, een goede XHTML pagina kan met elke willekeurige browser (dus ook PDA browsers of textbrowsers) goed bekeken worden.

Vaak wordt er negatief gereageerd op CSS omdat het totaal anders werkt dan layouts met tabellen. Ik weet echter uit ervaring dat het mogelijk is om 95% van de table layouts om te zetten in CSS layouts die in alle huidige browsers prima werken.

ik bouw professioneel websites, ik weet echt wel waar ik het over heb.
anyways... met xhtml is IE een van de weinige browsers die 100% compatible is

het klopt dat IE een ramp is als het om stanaarden gaat, maar dat houdt niet in dat ik ongelijk heb, ik weet echt wel waar ik het over heb, en ga geen onzin lopen te verkondigen hier

dit is ook meteen @ Chevalric, en daar komt nog bij:

Verder is het onzin om te beweren dat XHTML voor problemen zou zorgen. Alle browsers (incl. de stenen tijdperk browsers NS4 en IE4) hebben geen enkele moeite met een XHTML pagina. Sterker nog, een goede XHTML pagina kan met elke willekeurige browser (dus ook PDA browsers of textbrowsers) goed bekeken worden.

dat klopt, maar zodra je het gaat gebruiken met css, krijg je problemen met oa mozilla ivm de height css2 property

het klopt dat IE een ramp is als het om stanaarden gaat, maar dat houdt niet in dat ik ongelijk heb, ik weet echt wel waar ik het over heb, en ga geen onzin lopen te verkondigen hier

Kan je dan ook eens aangeven wat je denkt dat er misgaat met de css2 height property? Kan je daarnaast ook aangeven waar in de standaard staat dat Mozilla het fout zou hebben?

Mozilla heeft een verschil met de line height in standards mode vs quirks mode / almost standards mode. Mozilla geeft de pagina wel volgens de standaard weer, maar veel mensen verwachten iets anders (alle andere browsers geven ook iets anders weer). Daarom is, naast quirks mode, de almost standards mode geïntroduceerd, zodat Mozilla de huidige pagina's kan weergeven zoals verwacht.

Alle browsers hebben hun nukken of het nou Mozilla, IE of Opera is, dat maakt niet uit. Ik maak zelf ook veel websites en ben er achter dat bijvoorbeeld een height van 100% voor een tabel die een hele pagina moet bedekken niet altijd werkt in Mozilla. In IE wel, maar in IE werkt :hover weer niet op alle elementen en zo ben je wel een jaar bezig met al die gebreken.
Voordeel van Mozilla is echter dat het nog altijd continu in ontwikkeling is. Iets wat je van IE absoluut niet kunt zeggen

@denblom: php geef je niet weer in een browser: die wordt; door de server omgezet in leesbare taal, die je theoretisch dus ook direct in had kunnen tikken: dus je kan met PHP nog steeds valid (of invalid) XHTML maken...

php is dus een manier om zo'n site in elkaar te zetten... Dus php/mysql is iets anders dan wat er uiteindelijk naar je browser komt, wat ook in het geval van php/mysql (en dit vergeten mensen te vaak) moet je valideren :-)

Ben ik de enige die je verhaal niet snapt?

Verder is het voor bedrijven altijd handig om in ieder geval een leidraad te hebben. Ik kan de splitsing code/opmaak alleen maar toejuichen!

Het wordt hier weer allemaal heel mooi voorgesteld ja. Er zijn standaarden ja maar hoeveel procent van de surfers heeft een browser die die standaarden ook compleet ondersteunen ? Antwoord: 5 à 10%. Dit is geen post tegen standaarden maar zoals de situatie nu is met IE5 en IE6 die belangrijke stukken ( zoals min-width / max-width, om maar iets te noemen ) niet ondersteunen is designen volgens standaarden in heel veel gevallen gewoon niet mogelijk.

Er zijn standaarden ja maar hoeveel procent van de surfers heeft een browser die die standaarden ook compleet ondersteunen ? Antwoord: 5 à 10%.

Ik zal dit alleen maar een goed verkoopargument vinden voor Mozilla ..of in ieder geval standaard compatible websites, websites die overal werken.. Met overal bedoel ik ook PDA's, en textbrowsers voor blinden.

Hiermee dwing je Microsoft toch om ook meer volgens de regels van het web te werken, en niet zelf aparte extenties te ontwerpen, puur voor eigenbelang,

Volledig mee akkoord om zo MS te dwingen standaarden te volgen. Maar hoeveel bedrijven willen zo een statement maken als hun bedrijfsactiviteit er onder gaat lijden omdat hun website niet deftig functioneert voor het merendeel van de bezoekers ?
Dat zullen er niet al teveel zijn denk ik.

Het mag duidelijk zijn dat ik het niet over blogs en prive websites heb ... maar again voor veel bedrijven zijn standaardcompliant websites momenteel niet haalbaar.

edit: paar zinnen duidelijker geschreven

Had het stukje wat beter gelezen, dan had je ook ''...hebben ze een betere compatibiliteit met zowel oudere als nieuwere browsers" opgepikt.

Een oudere browser, of dat nou een IE, netscape is of Lynx zou er ook nog wat van moeten bakken.

Waarschijnlijk met wat minder toeters en bellen, en geen transparency effects en dynamische menu's. Maar zolang 'opa met zijn 486' de informatie nog kan vinden lijkt het doel me bereikt.

Ik vind het heel bizar dat er een adviesbureau nodig is om uit te leggen dat je het beste gebruik kunt maken van standaards. Dat lijkt me nogal triviaal. Het zou toch prettig zijn als mensen die websites bouwen zelf een beetje over de techniek na zouden denken, maar als er een adviesbuereau nodig is om de standaards onder de aandacht te brengen, dan zal de vorm wel weer belangrijker zijn dat de correcte werking van de website.

Ik hoop dat dit advies door alle website bouwers wordt overgenomen, maar ik moet het eerst nog zien.

Malthus ik moet je voor een deel gelijk geven dat het de verantwoordelijkheid is van de mensen die de websites bouwen en bijhouden. Helaas in het bij een aantal gemeente in Nederland nog zo dat de website gemaakt is door een kennis van "iemand".

Een aantal jaren terug heeft iemand in Den Haag geroepen dat elke gemeente een eigen website moet hebben. Dat doel is nu bijna bereikt als ik het goed heb. Maar het probleem is dat het internet voor veel gemeente iets compleet nieuws is. Vaak ondergebracht bij een communicatie afdeling en geloof mij maar die mensen weten niet wat HTML of CSS laat staan XHTML en Crossbrowser. Laat staan dat de mensen die over het geld gaan voor dit soort projecten weten wat ze willen. Voor dit soort mensen kan advies.overheid.nl wel handig zijn.

Ik ben zelf nu al ruim 2 jaar webmaster bij de een van de 10 grootste gemeente in Nederland... je wil gewoon niet weten wie zich allemaal loopt de bemoeien met internet zaken. Alleen een richtlijn een hoe een plaatje online moet met een correcte ALT-tag kost je al 3 weken. Moet je je voorstellen hoeveel tijd het kost om een website te bouwen die voldoet aan de accessibilty guidelines van de W3C.

Een advies over de standaarden die gebruikt moeten worden, is interessant en zal de overheid naar bepaalde webteams leiden. Dus tot zover is het plaatje positief. Bepaalde standaarden gebruiken is natuurlijk maar een begin, de inhoud en opbouw van de website zijn een ander verhaal. Als de structuur niet duidelijk is, het taalgebruik niet consistent of aangepast aan het web (webwriting - inverted pyramid style - highlighted keywords - chunking and linking - ...), enz., dan zal de website haar doel natuurlijk nog steeds missen. Ik kreeg even de indruk dat dit advies "al de wijsheid" verkondigde, vandaar mijn reactie.

Wat ik alleen niet snap is dat ze met "slechts" een advies komen! Ik neem aan dat je dit soort dingen binnen de overheid toch vrij eenvoudig kan afdwingen! (Zal wel een enorm politiek steek-spel gaan opbrengen, maar goed).
Bedoel, diegene die betaalt bepaalt wat er uiteindelijk wordt ontwikkeld.. toch?

Lijkt me een goede organisatie hoor.
Zij zorgen ervoor dat overheids instanties meer aan de slag gaat met het internet en regelen als het kan ook subsidies hiervoor. Niets mis mee.
Die standaarden discussie lijkt me wel leuk maar zolang je HTML houdt blijf je dingen tegenkomen die niet goed gaan. (blijft mensenwerk) Een document moet gewoon te parsen zijn en dan scheelt het aantal fouten al aanzienlijk.
En als ik zie dat er allerlei bedrijven de diverse overheidsinstanties bedienen van diensten en wat ze afleveren dan lijkt me dit soort iniatieven alleen maar goed. Alle koppen een kant op lukt toch niet maar elke site die verbeterd wordt is er weer een.

En goede websites maken is en blijft een vak.