Gilles Vandenoostende

Hi, I'm Gilles Vandenoostende - designer, illustrator and digital busybody with a love of language, based in Ghent, Belgium.

Archive for the ‘Develop’ Category

On Vendor Prefixes

Remy Sharp weighs in on the same issue as the post I linked to earlier:

We do like vendor prefixes. They give us access to bleeding edge CSS properties, and make our sites look cool. But there’s a serious problem: non-webkit vendors are giving serious consideration to implementing the -webkit prefix to a number of CSS properties.

This is bat shit crazy, but where the web has arrived to. This is one developer’s opinion, but you need to voice your opinion now, and if you’re agreement that this is madness, you need to act now. Make your voice hear, blog about it, tweet about it: make a lot of noise.

The entire point of vendor prefixes was to allow browsers to implement experimental features without breaking things. Since browsers are clever enough to ignore any CSS they don’t understand, it’s a clean, effective and safe way for front-end developers to focus on delivering modern, cutting-edge sites without compromising the site’s content or functionality for people using other browsers.

Provided the HTML of your site is 100% standards compliant you can feel safe adding certain effects using vendor prefixes, since it could never break browsers that do not support them*. It’s the embodiment of the progressive enhancement principle! You also have perfect granular control over  your styles: having different values is easy with prefixes, should there be any cross-browser issues. Compare and contrast that to all the havoc the box-model caused because one browser interpreted the standard a little differently from the rest…

By considering to support -webkit prefixes, Mozilla, Opera and Microsoft risk breaking the web. What if Internet Explorer’s implementation of -webkit-box-shadow causes problems, for example? Then we couldn’t use that feature anywhere anymore! Our options would be reduced to either:

  1. Sniffing the user’s browser or device to serve separate styles to each – BAD
  2. Figuring out new CSS Hacks, and turning our beautiful code into something resembling a Regular Expression – BAD
  3. Going back to only using stuff that’s 100% standard and universal – BORING

So, not good then. So what can be done to prevent this?

  1. Us web-developers have to take more care in implementing all prefixes, and not just the most popular ones, provided it makes sense for the project.
  2. The CSS Working Groups could speed things up and just standardize the stable parts of the spec. What’s the stable part? How about the part browser vendors are willing to implement, even at the cost of their own pride?


* And noone really cares about CSS validation, now do they?

The problem with CSS pre-processors

Miller Medeiros:

I will try to explain the most common problems I see every time someone shows a code sample or I see a project written using any of these languages/pre-processors.

I’ve documented my love for LESS on this very blog many times, but it’s good to see someone pointing out the potential dangers of using them: excessive code duplication and the performance hit associated with over-specific selectors[1]. Be sure to read the full article first, then come back if you want.

Done? Good. Now I’ll ask you: are these problems with pre-processors, or with how people are using them?

If your only programming experience lies with CSS or HTML, then by all means do yourself a favor and stay away from pre-compilers. I know from experience how easy it is to get carried away with a new language. If you’re not careful you could quickly end up shooting yourself in the foot by overcomplicating things.

But if you have a good grasp of plain CSS, you know some object-oriented programming and you understand how your LESS/SASS code will compile to CSS… Why the hell not? You should never see potential abuses by some as a reason to dismiss an entire concept for everyone. Pre-compilers don’t write bad CSS, bad programmers do!


[1] Although unless you’re writing the next Google, Facebook or some other mammoth web-app, I don’t think over-specificity means all that much for performance unless you’re desperate to eek out a precious few milliseconds, of course. It has its effects certainly, but I see it more as a problem hindering efficient code re-use, than with performance. If you find it helps you organize your code so you can more easily find your way, I think it’s a fair trade-off: After all, CPUs will only become faster, while programmer’s brains are pretty much stuck at where they are now. You can always optimize and refactor afterwards, if need be.

My new portfolio

After spending the best part of the last year experimenting with (and evangelizing the use of) responsive webdesign I decided to scrap my existing portfolio and completely redo it, practicing what I preach – so to speak.

Here it is.

I’ve actually been agonizing over the next version of my site since… well, since the last version went live. Because I had decided to use WordPress as a CMS I had to compromise on a lot of areas I feel very strongly about (markup, efficiency, etc…), which left a bit of a bad taste in my mouth. But the version you’re seeing now is the result of just a few weekends’ – and late evenings’ – work.

Of course, there’s always the chance that some things got screwed in the transition from WordPress to a customized PHP solution, so if you notice any dead links or browser rendering issues, don’t hesitate to contact me.

Next up: to apply the new styleguide to this blog (and my tumblr, which I’m planning to expand upon), but that will be for this weekend.

Sensible mediaqueries

Or “A perfect blend of best practices and developer comfort, using LESS CSS”

Mediaqueries are the new black. They really are, I checked. Ever since A List Apart’s article on Responsive Web Design it seems like every man and his dog are jumping on the CSS3 mediaqueries bandwagon. But as with all bandwagon jumping, enthusiasm can quickly get in the way of efficiency and common sense.

Mediaqueries are awesome, but come with a lot of gotcha’s.

Using mediaqueries doesn’t guarantee your site is optimized for mobile.

Optimization is more than just changing the layout. Mobile users have a high probability of having a slower than broadband connection, and so it isn’t a good idea to have them download images made to be viewed at resolutions far higher than their current device.

… but if you look at most sites displaying responsive layouts today, that’s exactly what they’re doing. The first layout they finalize is the standard desktop version, optimized for 1024×768, and they then use mediaqueries to twist and distort their desktop version into a mobile frame. Not only does this result in a coding nightmare where you’re constantly having to reset your own CSS rules, but it also misses the point of having a mobile site by having their users first download all the desktop-resolution art assets, and then download the smaller images on top of that.

So the best practice for making mobile sites is to build for the smallest screen size first, and then using mediaqueries to create ever bigger layouts as the screen-size goes up (Andy Clarke’s 320andUp boilerplate modification emphasizes and encourages this practice). Working like this means that the mobile browser won’t download any of the bigger images that you define in the higher-res mediaqueries. So the mobile version of a site won’t download the 1600×1200 background image you use in the desktop version, for example.

However, this technique, while being the best practice, is impractical for those of us living in the real world where not everyone (who’s not on a mobile device) uses Google Chrome on a Macbook Air in a trendy coffeeshop. I’m talking of course about the dreaded Internet Explorer.

Mediaqueries break in older browsers.

And by “older browsers” I mean of course IE6, IE7 and IE8. No other browser-manufacturer has upgrade schemes that are as broken as IE’s which means that we have to continue to support browsers that are literally *years* out of date. (Note: when’s the last time someone asked you to fix a browser issue with Firefox 2? Exactly my point.)

So anyway, IE right up until version 8 has absolutely no support whatsoever for mediaqueries. The above mentioned 320andUp uses the excellent respond.js script to force IE to recognize and respond to mediaqueries as a workaround to this issue, but I have several reservations against using this.

The first is that it doesn’t really improve IE users’ experience with the site. Instead of getting a responsive website, they’re constantly treated to a page that first looks broken, than flashes a bit and then looks okay. Not exactly the shining example of responsive webdesign we’re looking to serve these people.

Then there’s the fact that if Javascript is disabled, they’ll still be stuck with only the lowest-level mobile layout of the site. For IE6 I have no qualms whatsoever about this happening, as it’s really not that different from just serving them a universal IE6 stylesheet. IE7 and IE8 on the other hand are still shafted though, by having their already suboptimal experience becoming even more crippled.

And then the final reason for using respond.js being a bad idea is that, as a front-end developer on a strict deadline, having not just one, but 2, 3 or even 4 different layouts to debug in Internet Explorer isn’t exactly a fun thing to look forward to.

And it’d be mostly wasted effort as well, since most people using IE won’t expect (or need) to view your site in many different resolutions.

So why give yourself the extra stress? Click on to read my solution.


The Eldritch Freshmaker (soft)-launched!

The Eldritch Freshmaker 2.0

As some of my closer friends might know, about 3 years ago in 2008 I started a webcomic called the Eldritch Freshmaker to collect some of my sketches and drawings. But as with most side-projects, work, social obligations, other interests and a lot of good videogames soon got in the way and it sadly fell into oblivion.

Recently I got the urge again to draw some more comics, but then I looked at the site as it was and just couldn’t live with it, being the nit-picking web-designer that I am. So it was back to the drawing board and lots of sketching, coding and designing later, the Freshmaker has a brand-new custom WordPress theme that’ll hopefully keep me creatively stimulated enough for another bout of comics.

In the mean time, while I get to work inking and colouring the latest batch of comics I’ve sketched out you can all do me a real favour if you’d just scoot on over to and give it a little test drive to make sure I haven’t left any nasty bugs in there.

If you do chance upon a bug, please let me know via twitter (@gillesv or @fresheldritch) or e-mail ([email protected]) and I shall be eternally grateful. (unless you’re on IE6: I’ve deliberately chosen not to support you lot, as you’re holding back progress on the internet)

Jason Santa Maria: A real webdesign application

Screenshot: Jason Santa Maria - A Real Web Design Application

Jason Santa Maria - A Real Web Design Application

Prominent webdesigner Jason Santa Maria wrote an interesting article the other day about the pro’s & cons of current webdesign tools (such as Photoshop, Fireworks, etc…) and what a true webdesign application (if it were created today) would need. It’s an interesting read, so check it out at:

The author raises a lot of valid points, notably the huge disconnect between designing static pixels in Photoshop & co. and the crafting of HTML markup, CSS styles and how to resolve cross-browser inconsistencies. Jeffrey Zeldman wrote a similar article a while back and makes the point that hand-coding HTML/CSS isn’t going anywhere anytime soon. I’m of a similar opinion.


Quick Actionscript snippet: The Konami Code!

Veteran gamers and all-round nerds all know the infamous Konami code by heart. If you ever want to hide a clever easter egg to your Actionscript projects, here’s how you can detect users entering said code:

Clever coders should be able to easily expand this code to allow for more cheatcodes to be detected (“iddqd” or “idkfa” anyone?)


Selling progressive enhancement to conservative clients

Indulge me, if you will, in a little hypothetical. Consider the following scenario: you’re asked to design and develop a website for a big client. It’s a large company, with probably thousands of employees. A bank, for example, or a large pharmaceutical company. Or maybe it’s a government contract, or a big public sector player, like public transport or the electric or gas company.

What all of these clients have in common, is that 9 times out of 10 they’ll all be lorded over by a restrictive and overly protective IT department, who only updates their software and hardware every other decade. Which means the client will be looking at your work through the shit-tinted goggles of IE6. (more…)

.NET webdeveloper? Want to work at Proximity BBDO? DON'T do these

  1. Show us all your pretty Microsoft Certifications! They’re like official and stuff and require you to sit through a written exam and everything! This one here says I can use MS Office, and this one says I’m an Microsoft Certified Webservice Developer! Just because I’ve never actually ever written a webservice doesn’t mean the certificate’s meaningless right?
  2. Who wants to write code when you can drag & drop? It’s so easy! What do you mean, it breaks the designer’s perfectly valid, cross-browser html layout and makes the site slow down to a crawl? Fuck you, I wanna be home by 5’o clock!
  3. Develop for IE6 first, then hack for FF/Safari/etc… Hey! It comes standard with windows, that’s the only standard you need right?
  4. Only have experience developing intranet applications. It’s not easy making buggy web-interfaces that are only marginally more usable than hand-writing SQL statements.
  5. Don’t ever actually spend any time on the internet. Who reads blogs when you’ve got sports & sitcoms on TV? Also never google for .NET related questions. If you don’t know how to do something, it’s impossible and can’t be done, ever. What do you mean, you just did?
  6. CSS? That’s just 1337-speak for using divs instead of tables. Inline styles FTW!
  7. Learn any language other than C# (or even VB.NET). Where’s my Visual Studio at? PHP is for filthy hackers anyway.
  8. Don’t use open source software. It’s free, so there’s got to be a catch right (like AIDS!)? I’ll just stick to Microsoft sanctioned libraries or expensive third-party components that are IE-only, thank you very much.
  9. Design patterns? I’m a developer, not some pansy-ass designer! Excuse me while I code the entire business logic in this single VB file.
  10. Ajax? SiFR? DOM scripting? Stop speaking gibberish you ape. I only care about things if they start with “Microsoft” and have a year in the title somewhere.

Do these sound familiar to you? Then by all means, please don’t go to .

MCSE is to computers as McDonalds Certified Chef is to fine cuisine

Learning rails - updating to 2.2

One of my New Years resolutions is to learn Ruby On Rails, the hip young web development framework popularized by sites and applications such as Basecamp or Twitter. Being on a mac, installing and running rails is dead easy, just a few terminal commands. I’d toyed around with it a few months ago, but didn’t get too far.But now, with the new 2.2 version out I decided to give it another go.I tried updating to the latest version with the terminal command:

sudo gem update –system

to get the RubyGems to update to 1.3.1. However, the command simply returned:

nothing to update

But checks revealed it was still at v.1.2, so there clearly WAS still something to update. A couple of google searches later, and I’d found the solution to properly update RubyGems to the correct version:

sudo gem install rubygems-updatesudo update_rubygems

Now, if you’ll excuse me, I’ve got a train to catch! *groan*

Back to top