29106 items (19255 unread) in 36 feeds
Familie
(584 unread)
NetlashCollegas
(2062 unread)
NetlashStagiairs
(303 unread)
Fun
(12286 unread)
NetlashCollegas (100 unread)
Ik heb m’n Google Geocoding class geüpdated en verhuist naar Github. Vanaf nu vind je dus de class met voorbeelden op http://github.com/Dextro/Google-Geocoding-Class
Carnegie Mellon University Professor, Jesse Schell, dives into a world of game development which will emerge from the popular “Facebook Games” era.
De video vind u hier. Een interessante visie, ergens leuk, ergens ook heel erg droevig.
Ik ben geen goede verkoper. Ik ben daar, denk ik, een beetje te eerlijk voor. Ik kan geen onwaarheden (of eerder: halve waarheden) vertellen. Ik moet altijd de beide kanten van het verhaal illustreren. Wellicht ook de kant die me financieel minder uit komt.
Als een klant een formulier vraagt, dan zeg ik dat hij dat in Google Docs kan zetten, en dan kan embedden op de website. Alle resultaten komen live binnen in een Google Docs spreadsheet. Waar je dan met één eenvoudige klik nog eens grafieken van kan trekken ook. Die je dan met een klik verder kan embedden op een website, of de link krijgen om te delen met andere geïnteresseerden. Super.
Het is wellicht voordeliger voor mij om te zeggen dat ik een formulier kan bouwen. En daar dan een aantal uur werk voor aanrekenen. En zitten knoeien met validatie van velden, databases en andere dingen die al duizend keer gedaan zijn, en telkens weer opnieuw worden gedaan. Het wiel heruitvinden meneer. Dat doen we zo graag, als developers, ook al knikken we instemmend als het gaat over codeherbruikbaarheid en data portability.
Wel, mijn beste, dat Google Docs formulier trek je met gemak naar een CSV, dan hoef je weer geen exportfunctionaliteit meer te schrijven, en als er een extra veldje bijmoet in een bestaand formulier, dat is ook geen probleem. Alleszins geen probleem waar weer veel tijd en euro’s aan moeten verspild worden.
Maar pas op: hoe mooi en hoe goed de functionaliteiten van de Google docs form zijn, deze form werkt op 1 manier en niet op een andere. Je kan zo’n embedded form voor een heel aantal zaken gebruiken, maar vanaf je ook maar iets buiten de lijntjes wil kleuren, ben je eraan voor de moeite.
Bijvoorbeeld, je wilt niet dat er staat ‘powered by Google Docs’. Je wil de kleur en de stijl helemaal zelf kunnen bepalen. Je wil een formulier in 3 talen waar de output wel naar dezelfde spreadsheet gaat. Je wil een wekelijkse mail ontvangen met nieuwe data. Of je wil die data gebruiken om te koppelen aan andere data.
Al die zaken vereisen maatwerk. Maatwerk door een vakman. En dan moet je beginnen prullen. Dan moet je je vaardigheden als webdesigner -en developer uit de kast halen en ervoor zorgen dat het werkt, op sommige vlakken iets minder goed als die Google Docs, op andere vlakken dan weer veel beter. Maar wel exact wat de klant wil. Mooi ingepast in de website, in het systeem, in de workflow in kwestie.
Maar hoe maak je dan duidelijk dat dit gekke formulier 7 uur werk in beslag neemt, terwijl je daarvoor op een half uurtje een docs formulier had gemaakt? Voor een niet zo technische klant is een formulier van Google Docs of een custom formulier hetzelfde. Tot die uitzondering moet gebeuren. Dan zit jij vast met je Google Docs formulier; maar de vakman met zijn maatwerk kan nog alle kanten uit.
Ik vind het persoonlijk moeilijk om dat uit te leggen. Dat je een geprefabriceerd systeem kan gebruiken en snel resultaten kan hebben. Of dat je het zelf kan maken, en dat dat even gaat duren, en dat dat wel wat geld gaat kosten. De voor- en de nadelen.
Maar ik vind wel dat je dat moet communiceren. Eerlijk en geduldig. Dat duurt het langst. Maar het is wellicht ook het beste voor iedereen.
Collega Bert wees me vandaag op deze goede Git GUI tool: GitX. Op mijn Flickr een screenshot van de Compass repository.
T’is al van een paar weken geleden, maar moest je het gemist hebben, deze code swarm video is zeker de moeite. De moeite… voor nerds die veel te veel met version control bezig zijn!
Ik probeer een artikel van Paul Graham te lezen. Het is een lang artikel, een vlotte 8 pagina’s lang als je het zou uitprinten.
Zijn website staat links uitgelijnd. Ik zit echter in het midden voor mijn scherm. En na een tijdje begint mijn nek pijn te doen door het in een hoogst onnatuurlijke positie te lezen.
Ter illustratie, een wazige donkere GSM-foto:

Ik ga nog eens twee keer nadenken voor ik ooit nog een links website uitlijn. Wellicht is dit ook wel een beetje een luxeprobleem. Wreed content van dat scherm.
Open Safari en kijk eens naar SublimeVideo. En met de laatste Webkit nightlies heb je zelfs fullscreen video. Met op de planning Firefox-ondersteuning. Performante HD video. Mooi zo.
Hopelijk komen Apple, Google en Mozilla binnenkort overeen welke codec er nu gebruikt gaat worden (ref.). En dan moeten we ons binnenkort niets meer aantrekken van al die blue boxes.
O ja, er is ook nog Internet Explorer. Fuck.
Ik ging iets slim schrijven over dat iPad. En ik ging referreren naar de post van Alex Payne; en de goeie ideeën oplijsten zoals de iPad gebruiken op een stand om gitaartabs op te tonen; of in de keuken als receptenboek. Jeremy Keith heeft die post ondertussen al geschreven.
Hoe meer ik erover nadenk, hoe genialer dat ding gaat zijn. En niet alleen voor mijn moeder.
Een goede video om kennis te maken met de nieuwe UI-paradigma’s van de iPad.
Het situatie-afhankelijk keyboard vind ik een zeer interessant gegeven. Ik spendeer zelf heel veel tijd met het memoriseren van keyboard shortcuts om sneller te kunnen werken. Ik vraag me af hoe een custom keyboard voor Photoshop eruit zou zien.
Leuk om te weten is dat als je één van de nieuwe HTML5 input types gebruikt in je websites, bvb. <input type="email" />, je software keyboard lichtjes verandert als je dat veld invult. Op de iPhone verschijnt er bvb. een @-teken op het eerste toetsenbordscherm. Ik veronderstel dat dit ook zo gaat zijn op de iPad.
Deze blog somt een beetje mijn gevoelens op bij al het social media-geweld. Eentje over een concert dat iedereen lijkt te bekijken door een kleine lens. En een privémoment dat je eigenlijk gewoon niét deelt en voor jezelf houdt.
tinymce.get(0).$('body').html('Hello world'); and $('#textareaid').tinymce().selection.setContent('Hello world!'); has landed upon us! Wow!
With the release of Aptana 2.0 the Aptana developers decided to drop their excellent plugin in favor of PDT. The reason behind this move can only be reduced down to huge amounts of alcohol and/or illegal drugs because – one must admit – the PDT plugin is a pure joke. Luckely there is a way to install the old Aptana PHP Plugin into Aptana 2.0
Saddened by the move to PDT many of the now unhappy users, such as Adam Patterson who has a good blogpost on the subject, have been looking into an alternative yet have found none — at least none which is free. Yes, Zend Studio is a great alternative but that baby will cost you about an arm and a leg; 399 euro worth of arm and leg to be precise. I myself have no problem into buying it myself as it is a great tool, but the technical university I’m teaching at cannot justify total the cost of coughing up the money for the 100 needed licenses as they will only be used for about 3 hours per week during only 1 semester nor can I enforce my students to buy it themselves.

Image by Smashing Magazine
Having sought other free alternatives I ended up most happy with the new Netbeans 6.8. However, it’s not perfect: Netbeans 6.8 clearly has some work to do in order to catch up with the original Aptana PHP plugin, yet I found it better than PDT in terms of use (the ease of creating a new project for example) and features/support (Intellisense/autocompletion and PHPDoc support that work). The – to me – missing feature in Netbeans 6.8 is the lack of an internal debugger. Nearly every time I showcase a bit of code to my students I run it through a debug session. I know, Netbeans 6.8 supports XDebug, but that plugin is a bit too good to the beginning PHP developers: one notice will inject a truckload of HTML with stacktrace and everything related to it — that’s not needed for the newbies as they need to learn to code and debug PHP on a plain PHP install.
Back to Aptana, I’ve used a few Google Coupons and found a way to install the original Aptana PHP plugin into Aptana 2.0. It’s pretty easy actually:
Help → Install New Software...Add button and add a new entry named Aptana PHP Update Site with http://update.aptana.com/install/php as Location. Click OK to add itAptana PHP Update Site from the dropdown and expand PHP Plugin Builds in the listAptana PHP 1.1 Development Environment from the list and press NextFinish in the next screen and restart Aptana when askedThe method above however is not bulletproof: once the original update site goes down we won’t be able to install the plugin anymore. To counter that we’d need to have a local copy of Aptana PHP 1.1 Development Environment and be able to install that copy. Luckely for us, that all is possible.
Having played around a bit I noticed that the update URL http://update.aptana.com/install/php redirects to http://update15.aptana.org/php/25753/index.html. Typing that URL in your browser gives you a nice page stating you must enter that URL into Aptana in order install the offered package. The page also states that you can download the offered package and install it from your local disk … wow, that’s just what we needed!
Here’s the updated instructions (I have a local copy of the package myself and will post it here if the update site were ever to go down):
Help → Install New Software...Add button and then click the Archive... button, and select the file saved in step 1.Aptana PHP 1.1 Development Environment from the list and press NextFinish in the next screen and restart Aptana when askedFor now this will help us out. Now, let’s hope that the developers of the Aptana PHP Plugin will push their goodness towards PDT and transform PDT into what the Aptana PHP Plugin once was: a rock solid, (nearly) feature complete and free alternative to Zend Studio. Strange though, that the better product folded in favor of the lesser competitor.
Bijvoorbeeld, voor een <div> met een achtergrond die zwart is en 70% opacity heeft:
/* Background */
background: rgba(0,0,0,0.7);
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#70000000,endColorstr=#70000000);
De syntax voor de filter vind u op MSDN. Lees zeker ook de syntax van de colorStrings.
T’is maar dat u het weet, maar alle zaken waar nu zo wauw over gedaan wordt in de moderne browsers zitten al 8 jaar in Internet Explorer. Soms op een brakke manier (zie: de shadow filter; font rendering), soms met een relatief goede implementatie.
Een kleine waarschuwing: over het algemeen worden filters afgeraden wegens performanceredenen. Dus een beetje opletten dat het de bedoel niet vertraagt. Situationeel een handigheidje dus.
Geniet nog van uw namiddag.
Vorig jaar schreef ik 2008 in Review – ik beschreef het als een experiment in magazinestijl-ontwerp voor het web. Daar is nu een opvolger voor: 2009 in review.
Voor mij is dit een leuke manier om terug te blikken op het voorbije jaar. Ik kan me eens volledig uitleven op ontwerpvlak; en het is een uitgelezen kans om technisch eens een aantal dingen te proberen die anders niet aan bod komen. De webmensen onder u zijn wellicht geïnteresseerd in de technische notes:
# 2009_REVIEW technical notes
## SCREEN VERSION
2009 in review uses:
* jQuery 1.4
* jQuery color, a plugin for jQuery for color transitions
* jQuery easing, a plugin for jQuery that adds easing
functions to the jQuery animate object
* jQuery sound, a plugin for jQuery that adds an easy API for playing sounds
The CSS is written in Sass, using Compass 0.10
* It includes modified files from Winston as a base.
* Any grids are built off Blueprint, included in Compass by default.
* Using the compressed output style, it automatically gets minified
### MOBILE VERSION
A check is done to see if the client is a mobile device.
This is accomplished using browser.php to check for user agent string.
If the client is a mobile device, custom stylesheets controlled by mobile.sass,
are loaded accordingly.
### LINKS
* Sass: http://sass-lang.com/
* Compass: http://github.com/chriseppstein/compass
* jQuery sound: http://bit.ly/5opkil
* jQuery easing: http://gsgd.co.uk/sandbox/jquery/easing/
* jQuery color: http://plugins.jquery.com/project/color
* Browser PHP class: http://tinyurl.com/crs4ah
* Winston: http://winston.wolfslittlestore.be
Thanks for your interest!
-W.
Moest u de link bovenaan gemist hebben: lees 2009 in Review hier. Reacties zijn meer dan welkom hieronder. Veel leesplezier!

Ik zoek illustraties in deze vintage, line drawing, 60s stijl. Wie kent er goede resources? Stuur me een mailtje als je er kent!
Aha, het jQuery team heeft een nieuwe versie uitgebracht. Nettuts+ legt in jQuery 1.4 Released: The 15 New Features you Must Know uit wat je moet weten.
Voor ontwerpers die af en toe een beetje javascriptanimaties schrijven zijn Per Property-easing (4) en Delay an Animation Queue (7) geweldige nieuwe features. Hoera voor het jQuery team!
De officiële info vind u hier.
Gisteren schreef ik een artikel over onderhoudbaarheid en performantie in CSS. Dit onderwerp ligt me nauw aan het hart, dus vandaag: het vervolg!
Dus. Waar waren we? CSS is van nature een ongestructureerde taal.
Gelukkig is HTML van nature wél een gestructureerde taal.
Neem nu volgend stukje HTML:
<div id="navigation">
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">Over Wolf's Little Store</a></li>
<li><a href="#">Freelance</a></li>
</ul>
</div>
Hier zit een duidelijke structuur in: een <div> met id="sidebar", die een ongeordende lijst bevat. Elk lijstitem bevat dan weer eens een link. Stel dat we dit eruit willen laten zien als een simpele navigatie door middel van CSS. Je zou waarschijnlijk iets schrijven dat lijkt op:
#navigation {
padding: 20px;
}
#navigation ul {
background: #EEE;
}
#navigation li {
border: 1px solid #DDD:
}
#navigation a {
display: block;
padding: 5px 10px;
}
Deze CSS kan je nog uitbreiden met vanalles, maar ik hou bewust het voorbeeld simpel. Quizvraag! Wat is er hetzelfde in elke regel?
Antwoord: elke regel is een declaratie die van toepassing is op #navigation. Een goeie truuk om je CSS te structureren, die ik van Bramus geleerd heb, is het volgende:
#navigation {
padding: 20px;
}
#navigation ul {
background: #EEE;
}
#navigation li {
border: 1px solid #DDD:
}
#navigation a {
display: block;
padding: 5px 10px;
color: red;
}
Door de indentatie maken we de structuur duidelijk: #navigation, met daarin een <ul>, met daarin <li>, en dan <a>.
Stel dat we nu een nieuw stukje aan onze website bouwen, het contentvlak. We breiden onze HTML uit:
<div id="navigation">
<ul>
<li><a href="#">Home</a></li>
<li><a href="#">Over Wolf's Little Store</a></li>
<li><a href="#">Freelance</a></li>
</ul>
</div>
<div id="content">
<h1 id="titel_artikel">Titel artikel</h1>
<p>Inhoud lorem ipsum dolor <a href="#">sit</a> amet...</p>
</div>
En dus ook onze CSS:
#navigation {
padding: 20px;
}
#navigation ul {
background: #EEE;
}
#navigation li {
border: 1px solid #DDD:
}
#navigation a {
display: block;
padding: 5px 10px;
}
#content {
padding: 20px;
}
#content ul {
background: #EEE;
}
#content h1 {
font-family: Helvetica, Arial, sans-serif;
}
#content a {
color: black;
}
Door de techniek van indentatie kan je op het zicht zien: er zijn 2 hoofdblokken, #navigation en #content. Beide hebben specifieke regels.
Wat belangrijk is, is dat als ik iets aanpas in #content, dat dat geen invloed heeft op #navigation. Een principe dat programmeurs toepassen in objectgeoriënteerd programmeren.
De oplettende lezer ziet hier al meteen een optimalisatie. Zoals ik gisteren zei: er zijn eigenlijk twee factoren die het verschil maken tussen goede CSS en een rommeltje.
Er is de ene kant, die noem ik onderhoudbaar:
En de andere kant noem ik performant:
De performance kant is de kant die we kunnen optimaliseren. We kunnen deze CSS namelijk kleiner maken:
#navigation,
#content {
padding: 20px;
}
#navigation ul,
#content ul {
background: #EEE;
}
#navigation li {
border: 1px solid #DDD:
}
#navigation a {
display: block;
padding: 5px 10px;
}
#content h2 {
font-family: Helvetica, Arial, sans-serif;
}
#content a {
color: black;
}
In theorie is dit juist, echter is dit weer zwaar in strijd met de onderhoudbaarheid. Dat #navigation en #content allebei een padding van 20 pixels is louter toevallig.
Ja maar Wolf, je hebt gisteren gezegd, als je dezelfde waardes op 2 plaatsen moet aanpassen, is dat niet goed.
Klopt. Maar deze situatie is anders: er is geen relatie tussen #content en #navigation. Als het ontwerp van de website verandert, ga je voor #content moeten bekijken of de padding nog klopt. En je gaat voor #navigation moeten kijken of de padding nog klopt.
Dit is geen goed idee. Voor je het weet heb je een CSS file waar regel 4 verwijst naar iets dat invloed heeft op regel 921.
En als je dan nog eens browser-specifieke code schrijft in verschillende files wordt het helemaal leuk. En dan loop je tegen een deadline aan, en krijg je opeens een paar bug reports binnen. Van een site die nota bene live staat. Van een site waar toevallig die dag een grote budgetteringsvergadering over is. Oeps.
Mijn held in software is Joel. Joel heeft ooit voor Microsoft gewerkt en heeft al zoveel slimme dingen op het internet gezet dat ik uiteindelijk zijn boek heb gekocht. En het op enkele nachten heb uitgelezen.
Maak niet de fout dat dit een boek voor programmeurs is! Iedereen die voor een bedrijf werkt dat websites en/of webapplicaties maakt zou dit moeten lezen. Zelfs als je project manager bent, of informatiearchitect.
Dat terzijde. Eén van de bekendste artikelen, en meteen ook het beste artikel in het hele boek, is The Joel Test: 12 Steps to Better Code.
Stap vijf om betere code te schrijven is: Do you fix bugs before writing new code?
Er zijn verschillende soorten oorzaken van bugs. Voor het gedeelte waar we het nu over hebben, een degelijke frontend schrijven, zijn de meest voorkomende oorzaken:
Er zijn ongetwijfeld nog andere oorzaken van bugs. Maar, ik weet niet of het je opvalt, 3 van de 4 soorten oorzaken zijn de oorzaak van diegene die de code geschreven heeft.
Veel beter dan een bug oplossen is een bug voorkomen.
Hoe voorkom je deze bugs?
Rendering engine bugsHa. Hier heb je meteen al pech. Je kan deze bugs niet voorkomen. De rendering bug is er, en als je deze perfect normale CSS regel schrijft:
#sidebar {
float: left;
width: 200px;
margin-left: 20px;
}
Dan trigger je de double margin bug. Ik weet het, ik val in herhaling: ik heb deze bug gisteren al aangehaald. Waarom dit voorbeeld? Het is de gemakkelijkste IE bug.
Wat ik zeg klopt eigenlijk niet. Dit soort bugs kan je wél voorkomen. Maar dit soort bugs voorkomen verreist een uitgebreide kennis van alle rendering engines, hoe ze werken, wat er ondersteund wordt en wat niet, en alle quirks en speciale gevallen.
En dat kan je alleen maar leren door heel veel websites te maken en die bugs tegen te komen, en ze dan eigenhandig op te lossen. Eventueel met de hulp van het internet. Bijvoorbeeld door een vraag te stellen op Stack OverflowB, waar er meer dan genoeg mensen zitten die met plezier de allersimpelste CSS vragen voor jou beantwoorden.
Moet ik mijn websites dan bewust heel simpel vormgeven? Het antwoord is, zoals met zovele dingen in het leven, ja en nee. Je moet een balans vinden tussen de complexiteit van je vormgeving en de uiteindelijke uitvoering in HTML en CSS.
Een tabel om mijn punt te maken:
| # | Taak | Moeilijkheidsgraad |
|---|---|---|
| 1 | Slagschaduw op een vast beeld | Gemakkelijk |
| 2 | Slagschaduw op een <div> met vaste hoogte en breedte | Moeilijker dan 1 |
| 3 | Slagschaduw met 1-kanaalstransparantie (gif) op een <div> met vaste hoogte en breedte | Moeilijker dan 2 |
| 4 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met vaste hoogte en breedte | Moeilijker dan 3 |
| 5 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met dynamische hoogte en vaste breedte | Moeilijker dan 4 |
| 6 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met dynamische hoogte en breedte | Moeilijker dan 5 |
| 7 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met dynamische hoogte en breedte die potentieel dynamisch van hoogte en breedte kan veranderen via een Javascript animatie | Moeilijker dan 6 |
| 8 | Slagschaduw met 24-kanaalstransparentie (png24) op een <div> met dynamische hoogte en breedte die potentieel dynamisch van hoogte en breedte kan veranderen via een Javascript animatie, en van opacity moet veranderen | Moeilijker dan 7 |
Moest je aan deze tabel nog een kolom Browser support toevoegen, en in elke cel zetten Werkt correct in A-grade browsers, dan wordt alles nog een graadje moeilijker. Moest je zeggen: werkt in Webkit based browsers, wordt alles opeens heel gemakkelijk.
De eerste methode om een slagschaduw te maken: je slaat een beeld op, geeft het beeld weer, en klaar is kees. Maar deze methode is in strijd met de onderhoudbaarheid, en ook met de performantie. Zeker als je meerdere beelden met telkens dezelfde schaduw hebt.
Opdracht 2 is ook gemakkelijk: je gebruikt het beeld als achtergrond. Ik ga niet in detail uitleggen wat je allemaal moet doen om 8 werkende te krijgen, maar als je daar geraakt, ben je volgende problemen teggengekomen, afhankelijk van welke oplossing je kiest:
Terug naar de vraagstelling: moet ik mijn websites dan bewust heel simpel vormgeven? Nee, als je weet wat je doet. Als je weet dat je binnen het budget en de tijd van een project oplossing 8 kunt uitvoeren, dan kan je met een gerust hart 8 zo vormgeven.
Dat veronderstelt natuurlijk wel dat jij het ontwerp gemaakt hebt dat je aan het coden bent. Dit is niet voor iedereen het geval. Dus tik die designer op zijn vingers als hij zaken doet die niet realistisch zijn.
Oplossing 8 is niet onmogelijk. Het kan. Maar een project heeft een budget. En een project heeft een deadline. Ik heb eens tegen een relatief technisch onderlegde klant volgende vraag gesteld: heb je graag dat ik een dag spendeer aan coole feature X of dat ik er vandaag voor zorg dat die fucking slagschaduw werkt in Internet Explorer 6?
Het antwoord was, uiteraard, werk aan coole feature X. Geluk kan soms toch in simpele dingen zitten.
Wrong referenceEen tigtal paragrafen terug gaf ik dit voorbeeld voor wrong reference-type bugs:
CSS code verwijst naar #lollipop, en in de HTML staat er #lollyPop
Phil Karlton, in de jaren stillekes van browserland verantwoordelijkvoor de architectuur achter wijlen Netscape, zei:
There are only two hard things in Computer Science: cache invalidation and naming things.
Over die cache invalidation kan ik niet meespreken — ik ben er zeker van dat er nu een paar programmeurs luidop aan het zuchten zijn, en zich een situatie herinneren waar cache invalidation hen uuuuren werk heeft gekost — maar wat betreft het naming gedeelte: een volmondige JA.
Soms is het duidelijk wat voor naam je iets moet geven. De inhoud gaat in #content. En de navigatie in #navigation. Dit zijn conventies die vele mensen gebruiken, die al jaren meegaan, die algemeen begrepen worden.
Meestal moet je rond de #content en de #navigation nog een wrapper steken om layoutredenen. Hier komt het naamgevingprobleem naar boven. Mijn wrappers van de hoofdinhoud heten meestal #main.
Wat voor een kutnaam is #main
Dat is een beetje als een stukje van je software “extras” noemen. Wie weet er nu waar je het over hebt als je #main gebruikt?
Wel. Er is geen oplossing voor het benoemen van dingen. Wat je wel kan doen om zoveel mogelijk misverstanden te vermijden, en zo dus bugs (of liever de oorzaak van bugs) te voorkomen is duidelijk afspreken binnen je team wat voor namen je gaat gebruiken.
Dit heb ik even gepikt van onze bedrijfswiki. Ik heb het zelf geschreven, en de basis is gelegd door meneer Dextro, dus dat mag.
Gebruik logische Engelstalige namen voor classes en id’s.
Vermijd zoveel mogelijk benamingen zoals #left en #right, deze hebben de neiging te veranderen en dan niet meer te kloppen achteraf e.g. #right staat dan links, en het geheel wordt verwarrend
Actieve elementen worden aangeduid met ‘selected’ op het li-element. Maak gebruik van descendant selectors in je CSS om deze aan te duiden (e.g.: #navigation li.selected, #subnavigation li.selected ).
Alle classes en ids in camelCase, de eerste letter een kleine letter
Als iedereen deze regels netjes volgt, dan komen er minder problemen voor. Natuurlijk gaat het gebeuren dat je een plugin gebruikt die geen camelCase classes en IDs gebruikt. En iemand gaat het nodig vinden zich totaal niet aan de regels te houden.
Maar! Hoe meer mensen deze regels volgen, hoe minder bugs. Hoe meer je team samenwerkt, hoe beter je op elkaar afgestemd geraakt. T’is een beetje zoals een voetbalploeg.
Syntax errorsOver syntax errors kan ik kort zijn: valideer je HTML en CSS regelmatig op syntax errors, zeker als je een groot stuk code hebt geschreven.
Over de HTML validator kan ik nog een uurtje doorgaan, maar dat leg ik even buiten de scope van dit artikel.
SpecifitySpecifity is één van die dingen in CSS waarvan je denkt dat iedereen weet hoe het werkt, en als je dan eens een vraag erover stelt, weet eigenlijk niemand hoe het werkt.
Als je specifity begrijptD, begrijp je ook waarom:
* { margin: 0; padding: 0; } E!important gebruiken als het niet nodig is een slecht idee isIk ga nog eens iets herhalen:
Er zijn ongetwijfeld nog andere oorzaken van bugs. Maar, ik weet niet of het je opvalt, 3 van de 4 soorten oorzaken zijn de oorzaak van diegene die de code geschreven heeft.
Ik zie je gedachten al verdwalen naar de slechtste CSS’er die je gekend hebt in je carrière.
Het is gemakkelijk om andere mensen de schuld te geven voor slechte code. Echter: verbeter de wereld, begin bij jezelf.
Met een deadline in het achterhoofd is het soms moeilijk om het grote plaatje in het oog te houden. Maar je schiet jezelf in de voet door geen nette code te schrijven, de regels van gestructureerde CSS conveniently even te vergeten.
Ik weet het, want ik heb genoeg projecten waar ik dagelijks inkom waar ik nu van denk: what the fuck were you thinking?. En dat zijn dan nog projecten waar ik helemaal alleen de CSS van geschreven heb.
(Ik spendeer zo nu en dan een uurtje aan het herschrijven van de CSS van grotere sites, en categoriseer mijn tijdsregistratie dan onder “IE6 bug”, maar niet tegen mijn baas vertellen hé.)
Misschien moet ik maar eens dieper ingaan op Sass/Compass, een CSS framework dat eigenhandig allerlei structurele CSS problemen oplost door CSS te beschouwen als een programmeertaal. Misschien.
Voetnota’s
Als je ooit al eens een grote site hebt onderhouden, ken je het volgende probleem wellicht: na een tijdje wordt je CSS file zo groot dat er niet veel structuur meer in zit. Ik onderhoud enkele grote sites waar 5000 lijnen CSS code geen uitzondering zijn. In dit artikel: tips om je CSS te structureren op een onderhoudbare manier, zonder de performantie van je websites uit het oog te verliezen.
Ik hoor de claims al: “5000 lijnen zegt u? Gek! Dat is toch veel te veel? Ik kan dat op minder hoor.” Die line counts zeggen natuurlijk niet echt veel, zeker als je coding style in achting neemt. Het hoe en waarom wordt in dit artikel uitgelegd. Volg even mee.
Sommige mensen schrijven hun code zo (inclusief mezelf):
#globalWarning {
background: #B5121B;
color: #FFF;
position: fixed;
top: 0;
left: 0;
font-weight: 700;
z-index: 3000;
}
Andere zo:
#globalWarning {
background: #B5121B; color: #FFF; position: fixed; top: 0; left: 0; font-weight: 700; z-index: 3000;
}
Of zelfs zo:
#globalWarning { background: #B5121B; color: #FFF; position: fixed; top: 0; left: 0; font-weight: 700; z-index: 3000; }
Als je elke regel op één lijn schrijft kom je uiteraard bij minder lijnen uit. Maar dat doet niet veel goeds aan de leesbaarheid van de code. Ook kan je de CSS file niet meer gemakkelijk naast je HTML file op hetzelfde scherm. Deze coding style heeft natuurlijk 1 groot voordeel: je CSS is kleiner omdat er minder bytes verspild worden aan whitespace characters. Hier komen we later in het artikel nog op terug (minifyen)
Er zijn eigenlijk twee factoren die het verschil maken tussen goede CSS en een rommeltje:
Dan is er de performance kant van de zaak:
Die performance kant van de zaak maakt op zich weinig uit als je een klein blogje draait waar je vrienden lezen wat je te schrijven hebt over je kat. Maar hoe groter je site, of hoe meer bezoekers je hebt, begint dit wel van belang te zijn. Waarom moet je hier tijd in steken? De redenen liggen voor de hand:
Naar het schijnt scoor je ook een beetje hoger in Google, maar daar zijn nog geen cijfers over C. Deze performance kant clasht met de zaken die je wil van je CSS: onderhoudbaarheid, structuur. Laat ik beginnen met een voorbeeld. Dit is de layout CSS voor een sidebar:
#sidebar {
width: 200px;
float: left;
margin-left: 20px;
}
De oplettende lezer die veel over browserbugs weet denkt bij het lezen van vorig stukje code “Jaja, double margin bug.”. Inderdaad beste lezer, deze code triggert naar alle waarschijnlijk de IE6 double margin bug D. Om deze op te lossen doen we zo:
#sidebar {
width: 200px;
float: left;
margin-left: 20px;
_margin-left: 10px;
}
Opgelost!
Of toch niet? Wat is er allemaal mis met bovenstaande code?
Deze code beter maken in enkele stappen:
#sidebar {
width: 200px;
float: left;
margin-left: 20px;
_display: inline;
}
Nu zijn we al af van (1) 2 values moeten aanpassen als de marge verandert. Nu probleem 2 nog… we maken gebruik van een fout in de CSS parser. Wat is hier fout aan? Stel dat er morgen een browser uitkomt die dezelfde fout in de CSS parser heeft, namelijk regels die beginnen met een underscore toch uitlezen, maar die de double margin bug niet heeft, dan klopt de marge niet meer.
Voor wie er nog is, het wordt interessanter dan dit. Ik wil je intelligentie niet beledigen; natuurlijk weet je wat de double margin bug is. En dat CSS hacks niet kosjer zijn. Dat je je Internet Explorer specifieke code in conditional comments moet zetten.
Dus laten we dat doen:
/* Code contents of file 1: screen.css (every browser) */
#sidebar {
width: 200px;
float: left;
margin-left: 20px;
}
/* File2: ie6.css (IE6 only) */
#sidebar {
display: inline;
}
Proper zo! Maar… met dit te doen, verliezen we een stukje van de onderhoudbaarheid. Neem nu volgende code:
#shazam {
opacity: 0.4;
}
Quizvraag: in welke browsers gaat dit werken? Het antwoord staat in de volgende paragraaf in witte tekst. Selecteren dus om het antwoord te zien.
A: Safari vanaf Safari 3, Firefox vanaf Firefox 2, Opera vanaf Opera 9
Opacity is eigenlijk een zeer goed voorbeeld om mijn punt verder uit te leggen. Er zijn heel veel verschillende manieren om opacity te verkrijgen en elke browser heeft zo wel zijn eigen manieren. De syntax voor opacity verschilt zelfs tussen IE7 en IE8. Meteen ook een reden om deze timesaver E te gebruiken.
Dit moet je schrijven voor cross browser opacity:
#shazam {
opacity: .75; /* Standard: FF gt 1.5, Opera, Safari */
filter: alpha(opacity=75); /* IE lt 8 */
-ms-filter: "alpha(opacity=75)"; /* IE 8 */
-khtml-opacity: .75; /* Safari 1.x */
-moz-opacity: .75; /* FF lt 1.5, Netscape */
}
Ja. Waar zijn die mensen die hun hand opstaken toen ze zeiden dat je IE specifieke CSS in je conditional comments moet steken?
Heb je dan ook specifieke stylesheets voor Firefox 1, Firefox 1.5, Netscape, Opera 7, Opera 8, enzovoort?
Ik heb deze opacity-regel van Snipplr F geplukt. De websites die ik maak bij Netlash en ook binnen mijn eigen bedrijfje, worden getest in alle A-grade browsersG. Laten we deze regel even herschrijven met A-grade support in het achterhoofd:
/* Code contents of file 1: screen.css (every browser) */
#shazam {
opacity: 0.75; /* Standard: FF gt 1.5, Opera, Safari */
}
/* Code contents of file 2: ie6.css (IE6) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
/* Code contents of file 3: ie7.css (IE7) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
/* Code contents of file 4: ie8.css (IE8) */
#shazam {
-ms-filter: "alpha(opacity=75)"; /* IE 8 */
}
4 declaraties over 4 verschillende files? Dat is niet meteen onderhoudbaar. Dat moet beter.
We kunnen al 1 van de files weghalen door onze timesaver te gebruiken. We verwijderen ie8.css, en we zorgen we dat de in de <head>-sectie van onze website het volgende staat:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
Goed. nog 3 files over:
/* Code contents of file 1: screen.css (every browser) */
#shazam {
opacity: 0.75; /* Standard: FF gt 1.5, Opera, Safari */
}
/* Code contents of file 2: ie6.css (IE6) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
/* Code contents of file 3: ie7.css (IE7) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
In deze code komt weer hetzelfde probleem als bij de eerste oplossing voor de double margin bug: we moeten 2 waarden aanpassen als er iets wijzigt. Als er beslist wordt de opacity te verhogen of te verlagen, moet iemand er aan denken dat dit deze regel herhaald wordt in ie6.css en ie7.css. Je mag nooit veronderstellen dat jij de enige bent die de code van een project gaat onderhouden (binnen de context van een commercieel project voor een klant in een team).
Als je ooit eens een paar uur bezig geweest met een bug uit andermans code te halen, om dan tot de conclusie te komen dat het geen bug was maar een stukje IE specifieke CSS dat niet geüpdatet is met een verandering, dan lijkt volgende code niet eens zo slecht:
#shazam {
opacity: 0.75;
_filter: alpha(opacity=75); /* IE6 */
:filter: alpha(opacity=75); /* IE7 */
}
De “underscore” hackH heeft ook een variant voor IE7: de “colon hack” I. Om IE6 en IE7 tegelijk te targeten kan je dan ook nog eens dit gebruiken:
#shazam {
opacity: 0.75;
*filter: alpha(opacity=75); /* IE6 and IE7 */
}
Maar zoals eerder gezegd: niet doen! Nog eens: stel dat er morgen een browser uitkomt die dezelfde fout in de CSS parser heeft, gaat die deze regels lezen. En dan ga je onvoorspelbare code krijgen. En als er iets is wat je niet wil in web development, is onvoorspelbare code.
Wat is er wél zeer goed aan bovenstaande notatie? Er is context. Je kan onmogelijk de value van opacity veranderen zonder te merken dat er onder de value ook nog een IE specifieke value staat. Of je bent echt aan het slapen. Hoe combineren we context met voorspelbare code? Ik doe het als volgt:
/* Code contents of file 1: screen.css (every browser) */
#shazam {
opacity: 0.75;
/* @see ie6.css and ie7.css for browser specific CSS for this rule */
}
/* Code contents of file 2: ie6.css (IE6) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
/* Code contents of file 2: ie7.css (IE7) */
#shazam {
filter: alpha(opacity=75); /* IE lt 8 */
}
Deze methode zorgt ervoor dat je CSS doet wat de initiële voorwaarden waren:
Echter, deze methode clasht met:
Dit is de commentaar bij de CSS van de verschillende knoppen in tagger.fm:
/*
Winston 0.3 buttons - for irregular background use
--------------------------------------------------
There are a three kinds of main buttons in this project:
To create a button use:
The standard markup is as follows:
***
EXAMPLE <a href="#" class="button">
<i> </i>
<span>Button text here</span>
<b> </b>
</a>
***
Silver gradient background, blue link text = .button
ICONS AVAILABLE:
With play icon on the right hand side
= .button .buttonIconLeft .buttonIconPlay
Silver gradient background, with dropdown icon
= .button .buttonIconRight .buttonIconDropdown
These buttons work on any background.
PNGs are substituted by GIFs in IE6
***
All of the button images are in a single sprite.
The graphics shown are defined via background positioning.
***
To position the buttons, use the button holders
EXAMPLE <div class="buttonHolder">
<a href="#" class="button">
<i> </i>
<span>Button text here</span>
<b> </b>
</a>
</div>
***
Default buttons will float to the left in a button holder.
To make them float to the right, substitute the holder class for buttonHolderRight
EXAMPLE <div class="buttonHolderRight">
<a href="#" class="button">
<i> </i>
<span>Button text here</span>
<b> </b>
</a>
</div>
***
The <b> and <i> elements are used to:
a) provide a hook for icons on the left hand side (b) and the right hand side (i)
b) prevent transparent graphics overlaying each other when using standard sliding doors
c) to easily adjust the side paddings
This example will produce a "play" button:
EXAMPLE <div class="buttonHolderRight buttonIconRight buttonIconPlay">
<a href="#" class="button">
<i> </i>
<span>Button text here</span>
<b> </b>
</a>
</div>
***
*/
Woeps. 1930 bytes ofte 1,8 kilobyte aan comments.
Ik moet nu wel zeggen dat dit mijn meest extreme voorbeeld van commentaar is. Maar dit dient om mijn punt te illustreren; onderhoudbaarheid clasht met performance.
Dat probleem valt ook op te lossen. Maar het is ingewikkelder. Zoals Yahoo dat zegt: je moet je CSS minifyen. Eén manier om dat te doen is met regular expressions. Een andere manier is je CSS door een compressor draaien, zoals de YUI compressor. Uiteindelijk zijn dat ook maar een hoop regular expressions.
Hoe je dit juist doet en hoe die regular expressions werken is buiten de scope van dit artikel.
Je maakt dus 2 versies van je CSS files: een werkversie, en een minified versie. Laad de minified versie in op de live website. Als je verderwerkt aan de website, werk je verder in de werkversie. En als je klaar bent, draai je je scripts, en zet je de files live. Klaar is kees.
Euhm. Niet echt. Als ik serieus aan één van mijn grotere projecten op het werk aan het werken ben dan zijn hier een aantal problemen:
Gelukkig is hier óók een oplossing voor.
Proficiat aan diegenen die al hier geraakt zijn in het artikel. We zijn er bijna.
Als je het live zetten van je sites automatiseert, kan je zorgen dat dit een stap is in het proces van een site live zetten.
De old school manier om veranderingen live te zetten is naar je FTP client gaan, naar de juiste map gaan, en de bestanden overschrijven.
(Ik veronderstel in alles dat je je website lokaalt ontwikkelt, via een lokale webserver, en een lokale database. En dat je version control gebruikt. Als je beide niet doet ben je slecht bezig. Niet enkel volgens mij, maar ook volgens Joel J.)
De betere manier is zorgen dat je je website live kan zetten met een druk op de knop. In de praktijk betekent dit: een script draaien dat:
En dat laatste bestaat nog niet in ons huidig proces. Stap 2 van de Joel test is “Can you make a build in one step?”. Het antwoord is voorlopig nee. Een tool zoals CapistranoK kan helpen met dit proces. En dat is een verbeterpunt dat ik zo snel mogelijk wil doorvoeren voor de grote sites die ik onderhoud.
Voor mijn privéprojecten gebruik ik Compass L en SassM. Compass bevat een compiler met opties. Voor je een site live zet kan je de opties in je compiler veranderen naar “compressed CSS”. Die haalt automatisch de comments en whitespace weg. In een ideale wereld kan ik Compass gebruiken voor al mijn werk.
Maar: hier komt weer regel 2 naar boven: “Je CSS is duidelijk en goed gedocumenteerd, zodat anderen die hierin werken niet verloren lopen en kunnen werken”. Helaas heeft Compass een stijle leercurve. En als er een stagair binnenkomt op Netlash moet die ook in mijn code kunnen werken. Al mijn collega’s moeten mijn code begrijpen en kunnen aanpassen. Ik kan geen 14 mensen verplichten een nieuwe taal te leren omdat dat mijn leven gemakkelijker maakt.
Zoals de mensen van pinboard.in dat zo mooi zeggenN: “A rule of thumb that has worked well for me is that if I’m excited to play around with something, it probably doesn’t belong in production.”
Dat was het voor vandaag. Proficiat aan diegenen die hier zijn geraakt, en deel zeker jullie maintenance ervaringen in de reacties. Over and out!
Voetnota’s
In Illustrator kan je makkelijk meerdere strokes toevoegen, in Photoshop kan je dit faken via deze techniek. Past wel bij ontwerp van het soort Pimp my Ride:

Ik linkte al eens naar Alex Payne, en de mens heeft ondertussen nog meer dingen geschreven waarvan ik vind dat u ze moet lezen: Don’t be hero, Criticism, Cheerleading and Negativity. Telkens een heldere uitleg.
En voor de TextMate gebruikers is er How I use TextMate.
De telefoon van Google, gepresenteerd via een Flash website die nog eens goed gemaakt is ook. Voor de interface ben ik niet helemaal gewonnen (vergeleken met de iPhone) en helemaal gewonnen (vergeleken met Windows Mobile). Helaas niet verkrijgbaar in België.

Vandaag ontdekt: een elegante kleine applicatie om te rekenen. Vul links iets in en rechts komt er en resultaat uit. Je kan gemakkelijk meerdere lijnen berekenen en de resultaten laten staan (zoals op uw goede oude Texas Instruments rekentoestel). En eigen formules ingeven om uw belastingen te berekenen. Of de gulden snede.
Er is natuurlijk Numbers en Excel, maar dit is zo eentje om op je tweede scherm open te laten staan. Sweet. Een trialversie downloaden kan bij de mensen van Acqualia.
Lieve mensen, je kan me nog altijd bereiken op allerlei manieren, maar niet meer via direct messages, @replies en dergelijke op Twitter. Prettige feestdagen!
Dankzij Birthday exporter, die je alle verjaardagen van je feestboekvriendjes teruggeeft in iCal formaat. Kan tegenvallen bij overdreven veel “vrienden” op Facebook. YMMV.