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: , ,

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.

Technorati op WordPress.com

WordPress full-version kent allerhande Technorati plug-ins. Omdat het op WordPress.com behelpen is, werken deze hier geen van allen… Gelukkig bestaat er een handige bookmarklet om aan dit ongerief enigszins tegemoet te komen: Oddiophile’s Technorati Tags Bookmarklet. Als je bij Oddiophile je tags invult genereert het een stukje JavaScript met jouw tags en de bijbehorende links naar Technorati. Die code moet je vervolgens in je post pasten. Niet ideaal, maar beter dan niks.

Tags: , ,

Maintainable JavaScript

In de drietrapsraket van onderhoudbare HTML, onderhoudbare CSS en onderhoudbare JavaScript zijn we met de eerste goed op weg, maar valt er bij de laatste twee nog veel te winnen. Regelmatig zie ik een unobtrusive JavaScriptmenuutje uitgroeien tot een codemonster van 200 regels, omdat je én Dean Edward’s window.onload wilt toepassen, rekening wilt houden met memory leakage en ook nog toevallig sIFR van stal gehaald hebt. Alles geheel en al tot brei verwerkt.

Chris Heilmann doet een goede voorzet om met The Importance of Maintainable JavaScript licht in de duisternis te werpen:

So here’s an eight step plan to show you what can be done to make your scripts easier for the maintainer.

Hij geeft 8 soms voor de hand liggende, maar desalniettemin niet te verontachtzamen tips.

Tags: , ,

Front-end code reviews

In het Digital Web Magazine spreekt Garrett Dimon over front-end code reviews. Hij heeft helemaal gelijk dat een review op HTML- of CSS-code een ondergeschoven kindje is. Hij vindt dat ook projectteamleden die niet direct met de HTML te maken hebben een review zouden moeten doen en ziet de volgende voordelen van front-end code reviews:

  • Verschillende disciplines binnen één team raken betrokkener bij elkaars werk;
  • Het verhoogt de consistentie van de code;
  • De code wordt beter, omdat meer mensen er een blik op geworpen hebben;
  • Het is een evidente manier om van elkaar te leren.

Vervolgens bespreekt hij een grondige aanpak voor code-reviews, die mijns inziens wat ver gaat, maar zijn punt is gemaakt. Garrett, ik zal er harder aan gaan trekken om dit voor elkaar te krijgen, want ik ben het met je eens dat de volgende drie gevolgen van code reviews erg belangrijk voor kwalitatief betere code: educatie, consistentie en vroegtijdige foutopsporing.

Tags: , , , , ,

Waarom WordPress?

De afgelopen week heb ik voor mijn broer een weblog van Blogger in zijn website gehangen. Dit ging zo snel en eenvoudig, dat ik dacht: “Hm, dit is toch wel een stukje beter dan TomCMS…” Helaas heeft Blogger ook nadelen. Je posts worden bijvoorbeeld niet opgeslagen in een database en dat geeft mij een onzeker gevoel voor de toekomst, mocht ik ooit het heft in eigen handen willen nemen. Daarom zou ik voor mijn eigen blog niet direct voor Blogger kiezen.

Voor open.info.nl gebruiken we WordPress. Daar ben ik zeer te spreken over. Er hangt een grote community achter en voor iedere wens bestaat een uitbreiding. Maar toen ik voor CSSGreut een gratis weblog aanmaakte bij WordPress.com, bleek het hier wel om een erg uitgeklede versie van WordPress te gaan. Je kunt geen tags aan een post toevoegen (althans, niet eenvoudig) en je kunt niet aan de HTML van de template komen. Beroerd! Toch houd ik voorlopig aan WordPress vast, omdat je altijd kunt upgraden en dan wel al die mogelijkheden hebt.

Maar goed, ik ben niet van plan te upgraden voordat ik 100 feedreaders heb.

Tags: , ,