Archive for webstandaarden

Betere HTML in 37 stappen

Een paar weken geleden publiceerde Tommy Olsson zijn artikel “Bulletproof HTML: 37 Steps to Perfect Markup“. Het is een leerzaam verhaal dat soms een belerend toontje heeft, maar desalniettemin voor velen de basiskennis van HTML kan vergroten. Een aantal dingen viel mij op.

Onder standardista’s is het nogal cool om geen XHTML, maar HTML te schrijven. Belangrijkste argument is doorgaans dat je XHTML als “text/html” en niet als XML mag serveren (omdat Internet Explorer daar geen raad mee weet). So what? zou je zeggen. Tommy Olsson: “We cannot use any of the features of XHTML when serving it this way, because we are not really using XHTML at all — we’re only pretending to.” Dan zou ik wel graag willen weten wat die ‘features’ zijn. Missen we echt iets? En over missen gesproken: mis je iets als je XHTML gebruikt in plaats van HTML? Ik vermoed van niet.

Wat ik niet wist was de betekenis van de opbouw van de DOCTYPE-declaratie (als <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">). Wat doet de ‘EN’ daar bijvoorbeeld? “Note that it doesn’t say anything about the language of the web page itself; it is the language of the DTD that is specified here.” Het eerste deel van de identifier heet de ‘public identifier’ en het tweede deel de ‘system identifier’. “If the system identifier is missing, or if there is no DOCTYPE declaration at all, browsers assume that this is an old document and render it in ‘quirks mode’.” (Hé, zou Anne bewust ‘quirks mode’ triggeren?)

Ook over character encoding is Olsson verhelderend. Ik wist bijvoorbeeld niet dat de character set die je in je HTML-pagina opneemt (bijvoorbeeld “<meta http-equiv="Content-Type" content="text/html; charset=utf-8">“) overruled wordt door de HTTP header die je mogelijk via de server verstuurt.

Over het address-element zegt Olsson dat “A common misconception is that address is meant to be used to mark up only postal addresses, but that is not the case.” Ook telefoonnummers en andere contactinformatie kan met het address-element opgemaakt worden. Hij vergeet evenwel te vermelden dat het bij het address-element gaat om de contactinformatie die van toepassing is op de informatie die een bepaalde pagina geeft. Een adresboek bestaat dus nietuit een lange reeks address-elementen.Alleen de contactgegevens van de maker van het adresboek zou je in een address-element mogen verwachten.

Olsson licht nog een paar HTML-elementen toe die we nooit gebruiken omdat geen CMS ze ondersteunt. Maar toch is het handig om te weten dat “A certain term should only be marked up with dfn once in a document (where it is first used and explained)” en dat “A common misconception is that var should be used for marking up variables in programming code samples”.

Over het alt attribute kan nooit genoeg gezegd worden: “This text equivalent should not describe the image; it should convey the equivalent information”. Olsson geeft ook een helder voorbeeld om deze stelling toe te lichten (zie step 33).

Tot slot beweert Olsson dat de waarde van een id, name and class attribute altijd moet beginnen met een letter. Ik dacht evenwel dat het ook een underscore mocht zijn?

Een aantal van dit soort artikel tesamen zou een prachtig boek kunnen vormen over de basis en de achtergrond van HTML; verplichte kost voor iedereen die al langer dan vijf jaar met HTML zit te knoeien.

Tags: , ,

Comments (5)

Het W3C is geen godheid

Er is de laatste tijd een hoop heibel binnen en rondom het W3C. Gaat het niet om accessibility (WCAG 2 – bevrijding uit een keurslijf?) dan wel om een SVG specificatie. Bekende namen verlaten het W3C en gerenommeerde bloggers nemen de ‘opstellers van onze standaarden’ ongenadig onder vuur.

David Baron, een Mozilla developer die ook in de W3C’s CSS working group zit, licht in zijn artikel More W3C Controversy toe hoe besluitvorming binnen het W3C werkt. Zijn uitvoerige verhaal komt in feite neer op de wens van het W3C om het web voor de pc en het mobiele web aan één standaard te laten voldoen en de weigering van vooral de vertegenwoordigers van het mobiele spectrum hier aan te voldoen:

The problem is that they don’t have much incentive to choose behavior that’s compatible with the content on the Web.

Het vastleggen van standaarden lijkt vervolgens neer te komen op een wedloop wie het eerst zijn regels op papier heeft neergekalkt om op die manier de tegenpartij voor het blok te zetten.

Baron komt ook met een oplossing. Misschien moeten we de W3C-soep niet zo heet eten als ze wordt opgediend:

No members of the W3C should be obliged to implement any specifications, or criticized for failing to do so simply because the specification they do not implement is a W3C Recommendation. Instead, specifications should compete on their own merits among implementors, authors, and users.

Baron is van mening dat bijvoorbeeld Microsoft de CSS2-standaarden in IE7 niet heeft geimplementeerd omdat het W3C-standaarden zijn, maar omdat Microsoft dacht dat dat voor hun product de beste keuze was.

Dat hoeft helemaal geen probleem te zijn, vindt Baron, zeker niet als de interne strijd binnen het W3C de developer of de gebruiker met onmogelijke of onbelangrijke regels opzadelt:

We should work on, and implement, the standards that we think are appropriate for Web browsers, and ignore the rest.

Het gevaar van deze benadering is natuurlijk dat iedereen op eigen houtje een standaard kan gaan implementeren en dat we terugvallen naar de reuzeverschillen tussen IE4 en NN4. Hopelijk is de webcommunity sterk en eensgezind genoeg om in elk geval over de belangrijke regels overeenstemming af te dwingen.

Tags: , , , , ,

Geef een reactie

Happy clog

Happy Clog laat weer van zich horen. Martin Reurings heeft een steen in de stille vijver gegooid om te achterhalen of er nog leven in de klomp zit: hij is de Google Group Happy Clog gestart.

Achter Happy Clog zit een aantal jonge (en een enkele iets minder jonge), ervaren en enthousiaste webontwikkelaars. Hun idee was het promoten van webstandaarden in Nederland, maar hun eerste acties leken voor de buitenstaander vooral neer te komen op het drinken van bier en het opscheppen daarover tegen hun Engelse brothers in crime.

Het meest vruchtbare idee kwam van Faruk, die – analoog aan @media – een Nederlandse front-end webconferentie wilde organiseren. Helaas is het daar nog niet van gekomen.

Een paar tips daarom voor een succesvolle Happy Clog:

  • Bijt je niet vast in procedures. Wat maakt het uit of happyclog.nl een wiki is? Is het per se nodig om van tevoren af te spreken om eens in de zoveel maanden bij elkaar te komen?
  • Probeer de groep open te houden voor buitenstaanders. Een ouwejongen-krentebroodsfeer kan potentieel geinteresseerden buiten de deur houden. En daar kunnen juist de mensen tussen zitten die je wilt overtuigen.
  • Wees niet bang de dialoog aan te gaan met de grote internetbureaus in Nederland. Daar zitten immers de jongens (en meisjes) die de meeste Nederlandse sites bouwen, met niet altijd even bewonderenswaardige uitgangspunten als het om client-side code gaat.
  • Het idee van een conferentie blijft aantrekkelijk. Ik zou echter niet puur op eigen houtje opereren. Kennis van webstandaarden is één, maar voor het organiseren van een conferentie moet je ook uit een ander vaatje kunnen tappen. Jullie zijn niet de enigen in Nederland die het belang van webstandaarden onderkennen. Is het mogelijk om hulp te verkrijgen van bijvoorbeeld Accessibility of een ministerie? Ook zou ik me voor kunnen stellen dat een groot internetbedrijf graag zijn naam verbindt aan een dergelijk initiatief. En wellicht is het mogelijk om als subonderdeel onder een bestaande conferentie te opereren?

Tags: ,

Geef een reactie

Webrichtlijnentoets

Als je benieuwd bent in hoeverre je code voldoet aan de webrichtlijnen van de overheid kun je je site door de Webrichtlijnentoets heenhalen. De punten van de richtlijnen die automatisch te controleren zijn, worden dan getoetst. Raph heeft er ook een handige bookmarklet bij gemaakt.

Tags: , ,

Comments (1)

Webrichtlijnen van de overheid voor dummies

Hé, wat een leuke post weer op open.info.nl: Webrichtlijnen van de overheid voor dummies.

Tags: , ,

Geef een reactie

Delta Lloyd

Twee weken geleden is de nieuwe website van Delta Lloyd live gegaan. Een voor mij belangwekkende gebeurtenis, aangezien alle client-side code van mijn hand is. Delta Lloyd was een prettige klant om mee samen te werken, omdat ze op alle fronten hoge eisen stelden aan de website. Zo moest de site voldoen aan prioriteit 1 van de W3C richtlijnen en was SEO een belangrijk uitgangspunt.

Mijn HTML-templates valideren altijd als XHTML 1.0 Strict en het is goed om te zien dat – na door de mangel van een CMS gehaald te zijn – het meeste nog overeind staat op de livesite. Er waren wat omgevingsvariabelen die bepaalde zaken (met name formulieren) wat lastiger maakten. Tevens was het jammer dat het visueel design nog aan veranderingen onderhevig was, terwijl ik al lang met de HTML bezig was. De code is inmiddels bijna een jaar oud, en bepaalde zaken zou ik nu zeker anders doen, maar toch ben ik trots op wat er nu staat!

Comments (1)

Stijlgids.overheid.nl

Veel klussen voor de overheid doe ik (nog?) niet, maar het is goed in de gaten te houden wat zij als potentiële opdrachtgever allemaal uitvreet. Een handig weblog dat een kijkje in de keuken geeft, is stijlgids.overheid.nl.

Dit blog publiceert met regelmatig lijstjes als Top-10-Tips voor Opdrachtgevers met als tip nr. 1:

Neem de Webrichtlijnen Optimale Set (en W3C WCAG1.0 prioriteit 1 & 2) als harde eis op in de opdracht aan webbouwers.

Ook mooi is de Top-10-Tips voor Webbouwers:

  1. gebruik ‘HTML 4.01 Strict’ of ‘XHTML 1.0 Strict’ als doctype op elke pagina
  2. laat alle (X)HTML & CSS valideren conform de W3C validator
  3. start bij voorkeur met echte content in de code en plaats de navigatie-elementen onder deze content
  4. gebruik geen (i)frames
  5. gebruik nooit tabellen voor het opmaken van pagina’s, alleen voor het weergeven van rijen en kolommen data
  6. regel alle opmaak van de website via stylesheets
  7. gebruik geen client side script (zoals Javascript) voor onmisbare functies (zoals menu’s, links of uitleg)
  8. gebruik UTF-8 via de HTTP-response headers en via het meta-element
  9. gebruik H1 t/m H6 consequent en zonder niveaus over te slaan
  10. gebruik ‘list’ elementen voor het aangeven van lijsten

Tot slot pleit stijlgids.overheid.nl voor “omgekeerde bewijslast”:

Laat de opdrachtnemer het bewijs leveren dat de website voldoet aan de eisen met betrekking tot toegankelijkheid en bouwkwaliteit.

Tags: , ,

Comments (2)

Webstandaarden verkeerd begrepen

Verdedigers van webstandaarden houden ervan om hun blik op het web in handige lijstjes te gieten. Het grote nadeel van deze lijstjes is dat ze regelmatig een zwart-wit stelling poneren en iedere nuance missen. Al eerder had ik ruzie met een Zweed die het geldige HTML-element noscript wilde afschaffen. Nu stuit op een andere wannabee-goeroe die met zijn 9 Ways to Misunderstand Web Standards de bocht te fel afsnijdt. Drie van zijn negen opmerkingen behoeven ernstige nuancering:

Misunderstanding #1: “We Need Separate Print Pages”

Philipp Lenssen betoogt hier dat we de mogelijkheid van CSS van een aparte print stylesheet moeten benutten. Gelul, IMHO. Veel gebruikers verwachten dat – als ze op print drukken – de pagina zoals zij die zien, uit de printer komt rollen. Ik pleit er daarom voor om juist geen aparte print stylesheet op te nemen. Gebruikt de bezoeker de print button van de browser dan krijgt hij gewoon de pagina zoals hij die ziet. Gebruikt hij de custom print button in de website, dan krijgt hij een aparte, geoptimaliseerde printpagina.

Misunderstanding #2: “We Need an Alternative Mobile Web on Top of the Existing Desktop Web”

Hier gaat Lenssen te eenvoudig aan het feit voorbij dat de gemiddelde downloadsnelheid van een mobieltje aanzienlijk langzamer is dan die van de PC thuis. Natuurlijk is het een mooi ideaal om dezelfde content op te sturen onafhankelijk van het device, maar als ik een HTML-pagina naar een mobieltje stuur, wil ik die zo compact mogelijk en geoptimaliseerd hebben.

Misunderstanding #9: “CSS Hacks Are Always Superior”

Natuurlijk heeft Lenssen gelijk dat je voorzichtig met CSS-hacks moet omspringen, maar waarom hij alleen ‘gewone’ hacks laat zien en conditional comments (die enkele van zijn argumenten onderuit halen) negeert, is mij onduidelijk.

Mocht je in 2006 nog nooit van webstandaarden gehoord hebben, dan kan 9 Ways to Misunderstand Web Standards wellicht een eye-opener voor je zijn. Maar een beetje serieuze ontwikkelaar mist in dit artikel de genuanceerde en afstandelijke blik die Andy Budd bijvoorbeeld liet zien in zijn superieure presentatie over standaarden.

Geef een reactie

d.Construct

d.Construct registration succeeded

De server lag er een kwartier uit, maar uiteindelijk kwam ik er door: 8 september zit ik in Brighton bij d.Construct (Andy, zet de background-color van de body even op #fff). Jur, ben je er ook?

Tags: , ,

Geef een reactie

Who cares about standards?

Andy Budd heeft weer een prachtige presentatie gemaakt. Aan de hand van de geschiedenis van de schroef gaat hij de betekenis van standaarden na: Who cares abou standards? Schitterende slides.

Tags: ,

Comments (1)

Volg

Ontvang elk nieuw bericht direct in je inbox.