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[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
<![CDATA[proportional responsive/a third alternative]]>

Earlier this year I wrote a post on proportional responsive css, detailing two techniques in order to create proportionally responsive elements. The third option I'll be detailing here is little more than an expansion on the padding solution, but one that will save you the need for an extra structural wrapper at the cost of out of the box browser compatibility.

The padding technique is based on the fact that top/bottom padding is relative to the width of its parent. Exploiting this behavior, you can easily create a rectangle that grows and shrinks proportionally. Once you have the proportional box you can span (position:absolute and all sides set to 0) a deeper nested box across the parent box. For this technique you need two extra wrappers though. One to set the padding (as it only works on the width of its parent), one to span the content across the box.

/* html */ <section class="list"> <div class="atom"> <div class="content"> ... </div> </div> <div class="atom">...</div> </section>

The .atom elements are our proportional blocks, the .content elements are the spanned elements that contain the actual content of the block. Now for the css:

/* css */ .list {overflow:hidden;} .atom {width:25%; float:left; position:relative;} .atom:before {content:""; display:block; padding-top:100%;} .atom .content {position:absolute; left:0; right:0; top:0; bottom:0;}

The trick is actually pretty simple. We simply use a pseudo-element to trigger the padding magic, which means we don't need the extra structural wrapper in the html. The pseudo-element is set to display:block so it acts like a regular structural element, then it's given a padding depending on the ratio you want to support (100% makes a square).

The problem with pseudo-elements is that they are not supported in IE7. Javascript fallbacks are easy to do (just insert a div with js and apply the exact same styling), but ideal it is not. Then again, if you don't need to support IE7 this third technique makes things a lot easier.

Thu, 10 Oct 2013 13:53:13 +0200
<![CDATA[ios7 safari lazy repaint bug/android stock browser had a baby]]>

Last week iOS7 finally saw the light of day. For Apple it was an important step away from their original mobile design paradigms, I on the other hand was looking forward to the new Safari (which always comes bundled with major iOS updates), at least until I actually took it for a spin. Apart from some dreadful UI problems that are sure to haunt us in the coming months, I saw some rendering bugs I really wish I hadn't.

It's not entirely unnatural for stuff to break with a new browser update, yet one problem in particular stood out as quite perplexing. For some reason the main navigation flyout on my smallest responsive view had stopped working. Rather than fail completely, the entire flyout just wouldn't appear unless you started to scroll a little, after which it reappeared where it was supposed to be. The thing that got me worried is that the code I used to make this flyout work is incredibly basic.

body #site {right:-17em; width:17em; position:fixed;} body.showSite #site {right:0;}

Of course I have some extra css on there to make everything transition more smoothly between states, but even with that bit of code gone it just wouldn't work. It didn't take me very long to remember a similar bug I once encountered though. A nifty little bug on the Android Stock Browser I often use as an anecdote to illustrate what a crap browser that really is.

What happens is that browsers are getting a little too lazy for their own good. When a class is set (or removed) using javascript (and especially when it is set as high up the dom tree as the body element), they pretty much have to run through the entire page to check whether one or more elements are impacted on css level (the extra class might trigger some extra selectors). In order to save time, some browsers are attempting an educated guess. Some attempts fail, painfully, which happens to be the case on Safari for iOS7.

There are basically two ways to fix this. Either make sure the class is set on the element that is affected (you might even gain a minor performance boost), as the browser knows it should at least re-evaluate the element that received the extra class. Not too difficult, but not always possible when multiple elements on a page are affected by a single state change.

body #site.showSite {...}

The other fix is to force a repaint on the element with javascript. On Android Stock Browser you could fix things by applying zoom:1; (which felt rather appropriate), on the latest Safari for iOS z-index seems to do the trick.

$("#site").css("z-index", "5");

It's a bit worrisome to see such bugs introduced in the latest update of what is one of the oldest browsers on mobile. I understand the pressure they face to improve performance with each new iteration of their browser, but this clearly shouldn't go at the expense of faulty rendering/lazy repaints. This really is basic css that shouldn't be allowed to break, sadly I don't expect to see a fix for it any time soon.

Wed, 25 Sep 2013 13:37:42 +0200
<![CDATA[scrset arrives in webkit/hardware-dependent html]]>

Last year I already wrote at length about the proposition to include a standardized (or was it bastardized) solution for responsive images in html. Well, earlier this week webkit incorporated the srcset attribute, which hopes to fix the retina/HD part of the equation. It hard not to feel disappointed.

One of the toughest things about defining web standards is that we have to be backwards compatible. Most people assume this just means that new changes shouldn't break older code, but it's actually a little trickier than that. Being backwards compatible also means that any new additions will determine what we can (and can't) do with future code. If we add a half-arsed solution now (and it is adopted widely), we're probably stuck with it for the next 10 years (if not longer). So it's of utmost importance to think twice before adding something to the spec.

In short, the problem of burdening html with responsive content images is that the solution simply doesn't belong there. Because different available options need to be hard-coded in the html for each image separately this means a major set of html changes whenever a new form factor or resolution needs to be added. Every single image (including all content images uploaded in CMSes) needs to be updated to reflect this change, which just plain sucks. There's never been a link between html and hardware before and it would be best to keep it that way, as it opens a door that's best kept shut.

Even worse, the srcset attribute only takes care of resolution and screen size, and not the actual available size for the image, meaning we still haven't learned a thing from the media queries mistake we made before. The days that phone/tablet screen sizes matched the available space are already behind us, so I don't really get why we're still stuck with that paradigm.

Everything points at the fact that srcset is a quick fix for a tough problem we can't solve right away. The problem with quick fixes is that they tend to linger and that five or ten years down the line we'll find ourselves cursing at the people who thought it wise to include them. It's happened before and it'll happen again, it's just a shame when you see it happening and you can do very little about it. Let's hope other rendering engine developers will act wiser, but I doubt it.

Thu, 22 Aug 2013 13:43:07 +0200