work blog - My work blog is dedicated to articles about my job and the web in general. Read about XHTML, CSS, semantics and dig into my insane theoretic mumblings. en-us (Niels Matthijs) <![CDATA[september 2014 updates/more movies and small design tweaks]]>

The past few weeks I've been tinkering with my design again. The most obvious change is the switch from a black site menu bar to a white one. It's the first time in the 7+ years I'm running this site that I've opted for a dark on light design for my site menu. The reason is mostly due to a growing irritation with the scrolling center part of the site. With a fixed left/right column and only the middle part scrolling, the effect became a little too claustrophobic, hopefully that's a bit better now. I've also removed the pictures from the article list on the blog section, making the page quicker to load and less cluttered.

The movie section has undergone some small updates too. Unreviewed films are now "censored", making it just a tad more exciting to complete the list. I've also added 10 new films, so the list has now grown to 200 movies in total. A nice round number that will take me well into November/December to complete. With 6 more films to review, it might even be the final update to the list this year. Finally some small changes were made to the informative part of each film, making for a tighter design.

Small changes, but hopefully they make the site a bit lighter and less cluttered. The updated movie list is at its usual spot, so check it out!

Wed, 10 Sep 2014 11:54:20 +0200
<![CDATA[The Checkbox Parable/Logical Order Vs Visual Order]]>

Even though a lot has changed (both good and bad) since I started working as a front-end developer, there have been a few constants in my line of work that have persisted no matter how much I wrote or talked about them. I'm not a quitter though, so I've prepared yet another article in an attempt to try and bare the core of what makes an html developer tick. What exactly it is that makes us choose one particular html structure over another.

visual order vs logical order

At first glance there might be a strong bond between visual and logical order, but upon closer inspection you'll find that our eyes behave very differently from our brains. Our eyes don't always follow a logical path (top left to bottom right for us Westerners) when scanning for information and they often manage to skip ahead based on what attracts them or what they have learned from previous experiences.

For example, when browsing through a site our eyes will start to skip the site header after a while because they know from previous pages that they're not going to find anything of interest there, instead the eyes skip immediately to the content section of a new page. Then there are also color and alignment impulses that help our eyes to focus, whereas a logical order might dictate a different structure.

These alignment impulses is what I'm going to talk about here, as they perfectly illustrate the way we deal with checkboxes (or radio buttons is you want) on our websites. It's a perfect example of how the mind of someone who writes html works (or should work).

the checkbox

Checkboxes don't pose a big challenge these days, not for developers nor for designers. Just line up the checkboxes to the left, then add the labels to the right and when a label spans multiple lines make sure it doesn't wrap around the checkbox. It's easy as can be.

At least, that's how our eyes interpret it. By lining up the checkbox elements to the left they are a lot easier to spot (useful for quickly checking which ones are active). If we'd put the checkbox elements behind the labels they would be a lot harder to find, so to the left they go. But from a logical perspective, putting the checkbox first makes no sense at all.

Instead of thinking like a blind user (who probably has a screenreader that couples the label to the input element for him), just imagine going through the html code from top to bottom. If you'd match the html to the visual structure, you'd be putting the checkbox first in the html structure. So basically, you'd get a checkbox without the slightest idea of what its label is going to be. There is no context at all that tells you what this checkbox is about. Only when continuing you'd get to read the label. Should you then want to activate the checkbox, you'd be required to hop back before you could check the checkbox. It's like asking someone to reply "yes" or "no" without posing the question first. Silly, no?

So from a logical point of view, the label comes first, followed by the checkbox. And in short, that's what I try to take into account when I write html code. It's css that's supposed to bridge the gap between logical and visual structures, where html makes sure everything is presented in a logical order. As for the practical side, a position absolute and some padding will do the trick, or you can be all modern and flexbox both elements in the right visual order, but that's a css thing, not a html thing.


Don't get me wrong, I fully understand that this is quite the purist example. If you put the label after the checkbox, nobody will die and your site won't be much harder to use by the people visiting it, but to me this example perfectly illustrates the difference between what you see in a design and what you code in html. Other popular examples include "see all" links laid out next to the heading of a list or "back to top" links laid out in the same spot. Share buttons above an article or images that appear above headings are other popular examples.

Sticking to logical html structures can put some extra stress on the css and unless you're confident enough I wouldn't recommend going all the way, all the time, but it's good to keep things like this in mind whenever you're writing html code. Just read it from top to bottom and consider whether it makes sense without a visual design, because that's what html is all about.

Wed, 20 Aug 2014 12:45:47 +0200
<![CDATA[On messing up/and missing deadlines]]>

Last week an interesting question was launched on the Smashing Magazine's Twitter account: "What's the biggest mistake you've done in design/web development or your career so far?". The perfect trigger for some soul searching that ignited a little (yet stubborn) nibble I've been wanting to blog about for some time now, so here goes.

don't worry, be happy

Everybody makes mistakes, that's only natural. As anyone with a basic level of life experience will tell you, don't get too worked up when it happens to you, just look at it as an opportunity to learn from your mistakes. And front-end being the cesspool that it is, opportunities will be creeping up on you all the time.

I've made mistakes that nobody ever noticed. I've also made mistakes that reared their ugly heads on a level 5 page with a total page view count of 10 that some content editor published without double checking. Then I've made mistakes that cost a lot of money to fix. Even some mistakes that persisted throughout the project and made every new change tougher than it needed to be. I have a million options to choose from really, but singling out one single action didn't feel like it would adequately answer the question

the big picture

Looking at all the projects I've worked on over the years, big or small, there's been one nasty constant. A mistake that creeps up on you at least once a project and puts an indelible mark on all future work. And it has everything to do with not sticking to the optimal workflow. Once you start to compromise on workflow, you start to compromise on quality and that's usually the beginning of the end.

A website requires a lot of planning. Strategy, architecture, design, front-end, copy and back-end all cross each other's path. Things are bound to go wrong at some point, deadlines are bound to be missed. We don't like to admit it, certainly not up front, but whatever timing you make, you can be certain you're going to miss at least one deadline.


Deadlines are important. I am one of those people who appreciate the pressure a deadline puts on a project. Missing a deadline is generally not okay and people should do their utmost best to make their deadlines, but putting everything at risk to meet a deadline is quite possible the worst thing you can do. And that's where it often goes wrong. Rather than inform a client that a deadline cannot be met, "solutions" are proposed to try and get a project on track again.

My advice: if those solutions impact the ability to do your job well in any way, fight it as hard as you can. Intermediary deliveries, reduced development time, extra features without extended deadlines, mid-development change requests, parallel development that isn't feasible ... do everything in your might to avoid these situations. If you don't you'll end up cursing them afterwards. Situations like these are sure to result in shortcuts and quick fixes, unfinished work or lack in detail, jeopardizing the project as a whole.


Deadlines are rarely 'hard', even when everyone (including the client) is pretending they are. I've been in so many situations where we were failing to meet a deadline, changed things around to make it work, fucked it up and had the deadline moved when it turned out we weren't going to make it either way. It's usually a lot safer to push the deadline back a little or go for reduced functionality (and fix it post-launch) than to take the gamble.

When making a website, there's little or no option for "turning back" or "refactoring" once the website is live (of course there is in theory, but it never happens). That means that whatever you fuck up during the process remains that way until after 4 years your client decides it's time for an entirely new website. Many of the "solutions" proposed to meet a deadline will turn out to be more costly in the long run and will end up decreasing the quality to often unacceptable levels. You can't always stop it (people are stubborn), but being part of the development team means you have the obligation to fight these decisions and to warn people of the dangers. It's often an uphill battle, but even if you only win a few it will make your job a lot nicer along the way.

Tue, 05 Aug 2014 11:20:32 +0200
<![CDATA[movie list updated/180]]>

As predicted, it took a while before I got around to adding the next batch of films. But slow and steady progress is progress too and almost three months after the last update I'm happy to announce 10 new films to add to my list of all-time film favorites, making for a total of 180 films.

It's pretty much an Asia exclusive this time around, the two European film that made the cut are Leconte's La Fille sur le Pont and Tarek's Metropia. Apart from that we have three re-entries (Mah Nakorn, Gangu Shurya and Oretachi no Sekai), two animes and some interesting horror additions. In total 4 new films are waiting to be reviewed, while the first review should be ready by next week. So the next update shouldn't be too far ahead.

The updated list is at its usual spot, so check it out!

Thu, 15 May 2014 12:03:57 +0200
<![CDATA[rip comments/the end of an era]]>

Yesterday I took one of the hardest decisions in my six years running this blog. Even though I'm a big supporter of commenting and I still stand by every word I wrote back then, I killed off my comment system. Here's why.

The problems arose a few months back. Due to a changes in Mollom's API (a system to block spam messages) there was a sudden increase in spam comments that were slipping through my filters. The spam bots picked it up right away and they started to target my blog. This resulted in some server trouble, which prompted the server admins to disable comments on their side of the fence.

We invested a little time in the problem but weren't able to solve it right away. I would've been glad to put in some extra effort but there's also another reality I had to face. I don't mind the 1000 spam comments fired at my blog every day, most are stopped by the spam filters anyway, the real problem is the lack of actual comments being made.

Unless you implement systems like Facebook comments or Disqus, people are less inclined to comment nowadays. And even then you need a pretty popular site to generate even a little buzz in the comment section. I could've given it a try, but I'd rather not have these crappy systems on my blog. So that left me with only one option: remove the comment section.

I went for the cold turkey option and removed all traces of comments on my blog, even on older articles. While they still live in the database (so they could be revived at a later time), I chose to remove them everywhere to improve page load and general performance (less css, less html, less database calls).

I would like to give a final thanks to all the people who commented here over the years. It's sad to see this functionality go as I still consider interaction to be one of the most important cornerstones of the web, but you can't fight reality forever. At least I'm still here on my own blog platform (another thing that's dying quickly these days), something I plan to keep on doing for a long time to come.

Thu, 27 Mar 2014 11:26:21 +0100
<![CDATA[component complexity pt2/html variants]]>

After last week's short introduction on component complexity, it's time to get down to business. First off, I'll give a quick run-down of the example I'll be using throughout the rest of the series, after that I'll be looking at the way html can vary within the scope of a single component. To keep things sane I'll try to keep my examples as clear and concise as possible, though I'll be hinting at some additional real-world variations that will only add to the complexity.

example component: the article

I'm going to make it easy on myself and just refer to the Smashing Magazine article I've written back in 2012. It gives a perfect run-down of the component we'll be using here. In short: the article component is a typical (and common) content type, used for displaying articles, blog posts, news items and whatnot. Typical for content types is that they appear in several different guises. Usually there's a detail page with the full article, but you'll also find smaller teasers throughout the website linking through to the detail page. From an html perspective it's all the same component though.

html variants

There is no straight mapping between a single html component and its html output. All variations of an html component will be built from the same html structure, but actual html output may differ depending on several factors. These variations are important as they will impact design, css and possibly even javascript, so it's important to be aware of all the different possibilities.

Just imagine a pager. Some pagers feature prev/next links, some feature first/last links, others feature no extra navigation links at all. All these instances are variations of the same component, but the html output will different (the first/prev/next/last links will no doubt feature different classes and the html will either be there or will be completely absent). Some other examples include headings (ranging from h1 to h6), navigation lists (either marked up with the nav or div element) or input fields (with or without informative text), but the list is virtually endless.

Not all changes in the html output are html variations though. When the difference is an additional (existing) html structure initiated by content (just think of an extra item in a navigation list) this does nothing to change the structure of the output. It simply represents a loop of a specific html structure within the component.

Html variations are pretty common and you should expect each component to have at least a couple of them.

html variations for article

Two main variations exist. First of all you have the views. On the detail page you'll find the full view of the article, but on higher-level pages you'll find various teaser views. These views can range from heading-only to semi-expanded views with a teaser image and abstract. For this article's sake, we'll stick to two views only (detail and teaser).

/* detail view */ <article class="article detail"> <header> <h1>article heading</h1> <div class="meta">...</div> </header> <div class="main">...</div> <footer> <div class="share">...</div> </footer> </article> /* teaser view */ <article class="article teaser"> <header> <h1>article heading</h1> <div class="meta">...</div> <div class="abstract">...</div> </header> </article>

The detail view has a main and footer section for body text and sharing options, the teaser view obviously lacks these elements, but features an abstract text section in the header of the component. But that's not all, the teaser view as it is written now lacks a link (as that's its sole purpose of existence: linking through to the detail view).

There are two options there, either we use a block level link (so the entire teaser is linked), or we just link the heading of the view. Both options yield different html

/* block-linked teaser */ <article class="article teaser"> <a href="#"> <header>...</header> </a> </article> /* heading-linked teaser*/ <article class="article teaser"> <header> <h1><a href="#">article heading</a></h1> ... </header> </article>

so why is this important

The problem with these structural html changes is that they impact css and javascript work and they might even carry some design impact too (in case of the different link options). A block-linked view has different hover and focus states compared to the heading-linked view, the block-linked view impacts the use of child selectors and the styling of the different base views might be wildly different, so all these different variations will impact the work needed to style and design them.

Looking back, this gives us three different variations: one detail view, one block-linked teaser view and one heading-linked teaser view.


In real life, there are usually four to five different views per content type (one detail and three or four teaser views). Combined with the link options this can lead to up to nine different variations already, and we've just started this series. It's important to limit the views to an acceptable minimum and pick one single link method from the start. Leaving the option open will have a disastrous impact on the amount of use cases you'll have to cater for in a later stadium.

Next up: the visual and functional variations of components.

Thu, 20 Mar 2014 12:26:20 +0100
<![CDATA[component complexity pt1/an introduction]]>

The past 3 or 4 years everyone has been racking their brain to break through the responsive web design wall, I've been worrying about something else. To be honest, from an html point of view responsive design isn't even all that interesting. Shuffle some structural elements around so the css guy has less trouble positioning everything and that's about it. Instead I've been tinkering with component-based html concepts, something I've written about extensively in the past.

Component-based html makes sense when working on large (multi-site) projects and easily extends to the entire workflow, from architecture and design to css, javascript and back-end. Once you decide to go the html components route, everyone has to go along with it. One thing I didn't predict up front was that the biggest problem I was going to hit had everything to do with its main selling point: the perceived simplicity of (html) components. A component is little more than a small(ish) piece of html code that looks cute and manageable from afar, but in reality even the tiniest block of code can become an unmanageable beast in less than a blink of an eye.

from page to components

Once you decide to go down the component route you can't permit yourself to do a half-arsed job. If you work with components, your delivery is exactly that: components. Pages are pretty much demoted to an afterthought in the process, a reality check to verify whether your components continue to work when put together. So instead of wireframing and designing pages, you wireframe and design components. You css and javascript these components, you cross-check them by building a few standard pages and when everything is in order you deliver the components to the back-end developer.

This is absolutely essential, as working with pages will never allow you to incorporate all the different variations. Give a page wireframe to a designer and he'll design the page. Give it to the csser and he'll css that same page. Send it in for a quality check and the page will be checked. The components may have disappeared from view, but they still exist at html and back-end level. At first you might not be too worried, until the customer starts to play around with his set of components, enabling and disabling all kinds of variables and inserting some bits and pieces of content in the most unexpected places. That's when the trouble starts.

five types of variation

Because I think this subject deserves some in-depth writing I decided to make a little series out of it. Instead of just listing all the possible types of variations and tack on a quick conclusion, I'll run through all the variations individually, working with a real-world example to try and prove my point. At the end of this series I'll dedicate a separate article to the conclusion, hopefully illustrating how a simple component turned into a downright monster.

In total I found five different (yet very common) types of variations. Ways to alter a single component that could result in problems later on (which means they should be checked through all levels of the process, from wireframe to back-end implementation). If you don't keep an eye out, you'll end up with an exponential growth that results in 30-300 variations in no-time. Many of those will look and behave similarly, but when these variations are hidden from view you'll be sure to miss some, resulting in more bug reports and more after-project care than your sanity can handle.


So there we go. I'm still deciding on which component to work with (though I suppose I'll take something similar to the story component that I detailed in the Smashing Magazine article, as that is an easy component to understand and one that turns sour real quick if not handled correctly), but expect new entries in this series to pop up at regular intervals.

Next up: html variations.

Mon, 03 Mar 2014 12:21:29 +0100
<![CDATA[movie list updated/170]]>

Just two weeks ago I expanded my list of favorite films to 160, with the Braindead review already behind me I can add another 10 films. This time though I will have a lot more work getting everything reviewed as there are quite a few previously unreviewed films entering the list.

In total six older gems (all yearning to be reviewed) are making their way into my list of favorite films. There are two re-entries in the form of About Love and [rec] and two previously reviewed films that finally made the list (Frontière[s] and Cheuat Gon Chim). There's also a bigger variety in nationalities as Japan only delivers two films (Kurenai no Buta and Daiteiden no Yoru Ni) this time around. More than enough reason to check it out I think.

The updated list is waiting for you. Enjoy!

Thu, 13 Feb 2014 11:46:25 +0100
<![CDATA[movie list updated/160]]>

It's that time again! Ten new films were added to my list of all-time favourite, largely dominated by older entries that failed to make the cut after one of my yearly updates. That made it an easy update for me as most of the review and entry work had already been done. It also means that the next batch of 10 is right around the corner and can be expected within a month or so.

Shamo and Himizu are new to the list, though I already reviewed both films on this blog before. The only missing review is that of Braindead. While it popped up in my list at the end of last year, the big New Year shuffle prevented me from actually watching it. So there you go, another step towards a list of 200 favorites (which is a rough goal for the end of 2014).

You can check the updated list here. Enjoy!

Fri, 31 Jan 2014 11:46:32 +0100
<![CDATA[design theory vs reality/a plea]]>

Should you still doubt it, I'm not the graphical designer. type. I can manage html and css, some basic javascript if needed, but don't present me with a blank canvas because I'll choke. Still, as an everyday (an avid) user of the web I can comment on design choices and even challenge design theories, so that's what I'm going to do here. At the same time, this article will be a plea to my designer colleagues to get their act together.

In my opinion 2013 has not been a very good year, design-wise. More then ever I've been bothered by design decisions that actively hinder the speed and comfort at which I can consume a website. And when design becomes a hurdle, I think it's fair to call it bad design. While I read up on the theory behind such choices (and can understand why they are applied), it's clear that there exists a large gap between theory and reality that's being ignored by some of these designers.

1. custom fonts

Custom fonts are probably the worst thing that could happen to the current web. At least, in their current state and implementation. Not only do they present extra page weight that I personally don't care about, most of the custom fonts I've encountered actually hinder legibility.

As a Windows user, it's actually quite easy to see which designers work on Macs and which use Windows. Font rendering between the two OSes is wildly different and most fonts are ill-equipped to deal with those differences. You know all those thin fonts that look so damn sexy on Macs? They look like famished stick figures on Windows. They are blocky and ugly, some characters looking more like torn-up war victims than actual readable characters.

Font theory sure is interesting to read, but it is based on an assumption that a font renders a certain (exact) way. I've often compared font rendering between Windows and Mac and the differences can be staggering. Even browsers have a different way to render fonts. I know everyone is tired of Arial and Helvetica, but picking fonts that look cool on a Mac and leaving 90% of the desktop market looking at massacred text is definitely not a good alternative. If you're opting to use custom fonts, make sure to test them cross-OS and cross-browser first.

2. huge type

Mike Anderson (sorry for singling you out) wrote a pretty in-depth article outlining the reasons why he prefers huge type. It has almost become a de facto standard for blogs these days to use 16-18px as base font size. While his reasons make sense (and contain some long-standing design principles), I feel many of his arguments are based on wrong analogies and optimal situations.

Mike starts off by stating that he wants his site to be read like a book. While that's a fair goal, the web is so vastly different from print that it's a pretty impossible analogy to make. With a book your eyes move from top to bottom, from page to page. On a website your eyes go from left to right, but the upwards/downwards motion is often handled by mouse/touch input. Maybe it's just me, but I never read to the bottom of my screen before I scroll to the next part of an article, instead I scroll almost continuously, keeping my eyes centred on the screen.

Now, this isn't too big a problem if you somehow have smooth scrolling enabled. But I don't. I use a scroll wheel to scroll. When I scroll text jump X amounts of pixels, which is far from easy on the eyes. So even though line lengths, line heights and huge fonts may all contribute to easy reading in books, it doesn't necessarily amount to the same results on the web. The bigger the fonts and the more they breathe, the more I have to scroll. Hence the small type on my blog as it doesn't take more than one or two scrolls to read the entire article on a desktop.

It's not only that though, once you scroll a few times you end up looking at a sea of white, showing hardly two full paragraphs at once on a screen. I often feel dwarfed and lost reading blog posts like that, as if I'm sitting too close to a TV screen to see the full picture. I also miss the context of where I am in the article. Books have pages and physical attributes to help you with that, but online, there's only a scrollbar and that's only if your browser still displays those.


My conclusion is pretty simple: design for your audience. Designing in a browser solves a few issues, but people use many different devices, browsers and OSes. Design theories are good (and necessary), but when they don't match other people's situation they are actually quite worthless, sometimes even counter-productive.

If you design on Mac, please check how your designs look and behave on a Windows machine. Check out how they work on Android and WP. You may look down upon these OSes, but they still present the majority of the users out there, and if you're not careful you're giving them a horrible experience. Which, in returns, reflects directly upon your skills as a graphical web designer.

Thu, 09 Jan 2014 13:18:42 +0100
<![CDATA[the film shuffle/a yearly update]]>

And so the year is coming to an end. Not just a moment to look back and filter the best films I watched this past year, but also a time to rethink what I consider the best films ever made. I've updated my top list of favorite movies accordingly. A total of 20 new films made the cut, which means another 20 fell off the bottom. No worries though, I'll keep expanding my list in 2014 so I'm pretty sure they'll pop up again.

Below is a list of the new entries and their respective victims. I'm still missing two reviews (Primer and Renaissance), so those will get top priority. After that it's back to expanding the list.

The full list of 150 entries can be found at its usual spot.

Heruta Sukeruta (013) [Helter Skelter] Eraserhead (067)
Petaru Dansu (042) [Pedaldance] Takeshis' (072)
Yi Dai Zong Shi (044) [The Grandmasters] Oretachi no Sekai (097) [This World Of Ours]
Gravity (068) Rubber's Lover (108)
Luan Qing Chun (073) [Beautiful Crazy] 964 Pinocchio (113)
Boku to Tsuma no 1778 no Monogatari (093) [1778 Stories Of Me And My Wife] Mah Nakorn (114) [Citizen Dog]
Ikiterumono wa Inainoka (095) [Isn't Anyone Alive?] Tian Bian Yi Duo Yun (119) [The Wayward Cloud]
Sumagura: Omae no Mirai o Hakobe (098) [Smuggler] Sennen Joyu (120) [Millennium Actress]
Sekai de Ichiban Utsukushii Yoru (099) [The Most Beautiful Night In The World] Yokai Daisenso (125) [The Big Spook War]
Autoreiji (111) [Outrage] Gerry (130)
Monsutazu Kurabu (115) [Monster's Club] Gangu Shuriya (132) [Toy Reanimator]
Kotonoha no Niwa (117) [The Garden Of Words] [Rec] (133)
Kantoku: Banzai! (126) [Glory To The Filmmaker!] About Love (134)
Upstream Color (130) Haze (138)
My Blueberry Nights (137) Kimyo na Sakasu (140) [Strange Circus]
Renaissance (no review)(139) Tokyo Ken (141) [Tokyo Fist]
Primer (no review) (142) Braindead (no review) (147)
District 9 (145) Balada Triste de Trompeta (148) [The Last Circus]
Where the Wild Things Are (148) Gau Ngao Gau (149) [Dog Bite Dog]
Memorizu (150) [Memories] Akiresu to Kame (150) [Achilles and the Tortoise]

Tue, 31 Dec 2013 12:29:42 +0100
<![CDATA[ie7 support dropped/it's official]]>

Time flies, though sometimes it should be allowed to fly a bit faster. It's about two years ago that I officially dropped support for IE6. Back then I figured IE7 would be quick to follow. I guess I figured wrong though. It took the damn brat two years to finally disappear from my browser stats radar, but now it is finally gone for good.

Should you be one of the very few still visiting this site with IE7, you probably already know that support has been very limited since the last redesign. This sites basically "works" in IE7, that's just about as much effort I put into it. From now on though, I won't even check in the old browser of yonder when I make changes to the design or structure of the site.

So who's up next? Why IE8 of course. Still jumping between 0.5% and 3% (check the new graph on the homepage), I can only hope it will go down faster as IE7. The outlook is rather grim though, as IE8 is the top IE version on XP (which, for some insane reason, is still a popular OS), which means people on XP can't upgrade to a more recent IE. Then again, there's always Firefox, Opera and Chrome.

If you're still using IE8 (or you know people who do), please redeem yourself and help me win my quest. The world will be a better place (and my site will be that little bit leaner for everyone).

Mon, 30 Dec 2013 11:40:08 +0100
<![CDATA[mobile-first vs mobile-second/a nuance]]>

After a surprisingly short transition period, the mobile-first css approach has become the de facto way of implementing responsive designs. Unless you're retrofitting a responsive design on an existing site, there really is no question about how to structure your css. But lingering underneath the reassuring cloak of best practise comfort there is a little nuance that is lost on some. There are basically two ways to approach a mobile-first css setup and only one of them is sane.

why mobile-first

Mobile-first css development is good a way to reduce performance issues on mobile. Instead of coding the desktop (largest view) design first and overriding the necessary properties for smaller viewports, you start with the smallest viewport and go from there. Mobile browsers are capable of ignoring all css that isn't necessary for them (as long as it's contained by a proper media query), so they get a significantly smaller set of css rules to apply and reapply (when javascript is doing its dom magic).

The result is a smaller css file, less code overhead and better performance on machines that only need a small chuck of the entire set of css rules to render their design (even though the css file is still loaded in its entirety, less rules need to evaluated).

mobile-first to the letter

When going the strict mobile-first route, you start by looking at the smallest viewport design and implement that outside of the scope of media queries. Then for each responsive change, you create a media query and add the necessary code to get to the new design. The result looks something like this:

/* mobile-first */ .class {border:1px solid #000;} @media (min-width:960px) { .class {border:none} }

It sure beats a desktop-first approach where the mobile browser would have to evaluate two rules instead of one, but what irks me about this setup is the fact that we need to reset the border to its default state on desktop. Even though the desktop styling needs no border styling rules at all, we've written two to make the design work on desktop. That's pretty silly.

Not only does it feel like overkill, it also impacts the readability of the code.


It's actually quite easy to fix this. Rather then look at the mobile design first, why not look at all the design variants at the same time and filter out the common elements. These are the rules that may exist outside the scope of any media query. Then add the custom styles for each responsive view in a second stage, beginning from the smallest view. The example above would look like this:

/* option 2 */ @media (max-width:959px) { .class {border:1px solid #000;} }

As the smallest viewport design is the only one who needs a border, we just apply it to this viewport in the mobile view and leave the desktop be.


The problem with the mobile-first approach is most apparent when smaller viewport designs apply styles that have to be reverted to the default (browser) styles on larger viewports. It creates ugly overhead that hinders overall readability of the css.

You can be more lenient in cases where different viewports need explicit stylings (instead of no border at all, imagine a red border on the desktop view in the first example), especially if this saves you extra media query declarations, but that doesn't change the fact that it's better to start with looking at common stylings instead of staring blindly at the smallest viewport design first.

small disclaimer: whenever I'm talking about "mobile" and "desktop" views in this article, I'm referring to the smallest/biggest viewport designs available, not necessarily to the device on which a site is rendered. These terms are remnants of the days when mobile = 320px and desktop = 1024px. Sadly they have become somewhat of an industry standard, but at least people understand them (and they limit the use of overly verbose descriptions like "smallest responsive view"). It's a semantic discussion that's probably better suited for a different article.

Wed, 27 Nov 2013 14:10:34 +0100
<![CDATA[performance is the new seo/use it wisely]]>

Being a front-ender is more than just flashing some fancy html5, css3 and javascript magic in people's faces. A small but important part of our job is to steer a project in such a direction that the resulting front-end code stays maintainable and up to par, quality-wise. Design, information architecture and back-end limitations are all hurdles in our path to deliver lean, clean and spotless front-end code. The following article discloses three tricks to help you on your way, but use them wisely because their reach is limited.

Actually influencing the course of a project is pretty difficult for a front-ender. It's not that our work is seen as invaluable, but people usually expect us to just fix things. Jumble some css and javascript together so the wanted design emerges, while doing it in such a way that it can be easily incorporated into the cms. Making requests as a front-ender is difficult, often because we lack quantifiable data to illustrate the problems and risks of certain unfavourable decisions. Luckily there are other means to defend ourselves from harm.

1. the classic: seo

When the internet finally reached the big masses, getting your site noticed became increasingly difficult on an ever expanding web. Around the same time semantics came into play after years of abusing html for whatever designers asked us to make. Seemingly unrelated at first, those two concepts would find each other in a rather unlikely marriage.

Semantics made things a lot more difficult though. Writing html became a skill that actually required knowledge of the language. Then again, it benefited css, accessibility and machines alike, but sadly those three arguments were hardly convincing. Especially when implementing these new html structures lead to back-end development issues (which it always did, as all of sudden the default cms code wasn't good enough any more).

But then seo came along and thanks to Google seo became the perfect wave for us html guys to latch onto. Correct use of headings, paragraphs and tables ... they were all taken into account when determining the position of a site in the search results. This opened up a path that forced people to take notice of our html. It was a lever we used to force our own html in a project so that not just css and accessibility would benefit, but that we were finally able to deliver some properly structured html code.

2. updating the classic: responsive

Nowadays cmses churn our pretty acceptable html, at least from an seo perspective. Most of them are still pretty html5-agnostic, but the seo-argument has definitely lost some of its weight. That doesn't mean we just have to comply with the default html of popular cms systems though. Our new lever: responsive web design.

While many cmses got a good grasp of the most important semantic rules by now, most of them still lack structural sanity. That's a real problem when having to deal with responsive needs, because that very structural sanity allows us to easily jumble elements around. Without it, we have to revert to nasty javascript hacks and insane css constructions.

Position:absolute; and box:flex; are our life savers here. They require specific structures that are often lacking in default cms code, meaning custom html code is actually required to make everything work in a way that doesn't break a page whenever it appears in a different viewport.

3. the new kid on the block: performance

But what about css and javascript you ask? Well, since a year or two "performance" is all the rage. Providing a decent mobile experience nowadays is key for a well-functioning website, sadly (hah!) the current state of smartphones doesn't allow for too many fancy bells and whistles.

Techniques for responsive images and reworking responsive layouts alone require too much of our time already, with functional demands often reaching for the sky. This is where performance comes into play, because all those fancy solutions are often highly dependent on complex javascript and css. A dependence that doesn't really comply with most smartphone specs, resulting in hot, lagging phones and draining batteries.

Performance is our lever when we want to scale down the functional complexities. Recently a lot of tools have appeared to help us determine the exact impact of certain techniques on the overall performance of a web page, which is a great help when trying to block those exact functional demands from being implemented.

a word of warning

Just remember though: while the three arguments above are all valid, they are not holy. If you go around yelling at everyone they can't have X or Y because of performance and they need to implement Z because of responsive needs without solid arguments to back up your claims, you're not going to working on the project very long.

Use the above arguments in valid cases, but when such a case present itself you can try to use it as a lever, sneaking in some extra bits and pieces that will improve the overall quality of the front-end code. Trust me, everyone else is doing this already (designers, information architects, back-end developers), so don't feel too bad about it. Just don't be too obvious when you're doing it.

Wed, 13 Nov 2013 13:09:04 +0100
<![CDATA[movie list updated/150]]>

It took me a little longer than expected, but I was finally able to add another 10 films to my list of all-time favourites. In part this was due to a welcome vacation and the sudden availability of Yawarakai Seikatsu, but also due to a hefty dose of laziness on my part.

Tokyo-Ken finally reappears in the list, the rest of the films are mostly Asian entries with 2 European films and 1 New-Zeeland film to fill in the remaining gaps. I only need to review 4 films this time around, so I suspect I should be ready before the end of the year, right in time for an entire refresh of the current rankings. Something to look forward to.

You can check the updated list here. Enjoy!

Thu, 24 Oct 2013 11:08:15 +0200