like thieves in the night

This is not a new problem of course, there is plenty of software our there today that crawls specific sites and pages in order to harvest data. As long as websites do not provide an API to access their data, this is the only way feasible to accomplish certain tasks. For example, a site like icheckmovies.com provides a service where users can import their IMDb votes, but IMDb does not offer other sites a way to access this particular data. So icheckmovies asks you for the page url containing your votes and crawls the page looking for the data it needs. As long as the html source does not change, this is a pretty reliable way to extract data online. When IMDb does change the source html (like they did a couple of weeks ago), the service breaks and has to be adapted to match the new html structure.

I'm not sure about the specifics, but legally speaking this is somewhat of a gray area. When the data is public it can be used by others. On the other hand, you can't just copy a whole database of information from another site. That's why big sites like IMDb (or any other database-fueled data site) introduce known errors into their data (Google Maps has a couple of non-existing towns for example). If these errors make it onto other sites, they know they've been robbed of their hard work.

the new google

Search engines like Google Search also crawl your site for data. This is not really a problem because if all goes well they will direct people to your site based on the search criteria they entered. It uses your data simply to produce a search result snippet so users can make some kind of initial decision before they click through to your site. Google generates traffic for our websites, so nobody minds.

But what if Google was going to use the data on your site for other things beside generating links to your site? According to an article published on HBR Google is aiming to produce immediate answers for direct answers, effectively bypassing the sites where it got its information. It's nothing more than an extension on what they are doing with exchange rate calculation and simple math problems, but because Google has access to an almost unlimited amount of data, it can actually start aggregating and analyzing that data to predict the answer to more complex questions. In the end, it's not even stealing your data, but simply using it to predict the correct answer.

google and microdata

Semantics (more specifically microdata) are crucial in this process. It allows machines to understand data that would otherwise be captured in language-dependent full sentences. Google isn't guessing anymore, it knows. And because it knows, it will answer you directly rather than point to a source that might hold the answer to your question. For users of Google, this is superb as this saves a few clicks and they still get the information they were looking for. Other services too will have a much easier time figuring out your data. A site author can change the html all he wants, as long as the microdata implementation remains the same (which in theory it should), services that crawl your pages don't need to be rewritten every time you change something in the source.

As content authors though, we could feel a bit cheated by this. External services are using our carefully marked up data for their own benefits. Google does provide extra links to its sources, but only in a collapsed view which is likely to be ignored by people just looking for the answer. What this means is that we are doing all the hard work while Google is taking all the credit.

Blogs like mine might (at least for some time) escape the first few blows because we offer opinions and contextual articles, not so much single answers to direct questions. Then again, I believe it's probably just a matter of time before we're going to feel the consequences of this. Google could just as well roll out a list of film reviews (with some source links in the footer that nobody is going to click anyway), reliably harvesting its information from sites that use the movie and review microdata formats. That way it shows our reviews without giving us the proper credit for writing them.

conclusion

What bothers me the most is that content authors gain very little by going the extra step to mark up our data with microdata, we may even lose a part of our audience that way. Sure the people we lose are probably just looking for a simple answer and may not be particularly interested in the rest of our site, but branding works in mysterious ways. Currently there is no way to protect ourselves from this and we are at the mercy of Google and other search engines to provide visible source links and quotes so we are at least given the proper credit for our work.

If search engine developers play this right both engines and content authors could benefit from the semantic web, but if they're going to claim all the credit for the data we are providing, many people are going to be discouraged to keep writing for the web. Not only that, it could hurt the success of the semantic web itself, setting us back several steps in the process to make more sense out of this enormous cluster of information we call the internet.

10. writing about front-end

I should probably repost this article once a year, if only to remind myself how important it is to provide the proper context when writing about web development. When writing for the web we often forget our target audience, kidding ourselves that we're writing for professionals only. The reality is a bit different and in order to make sure people don't walk away with the wrong ideas after reading our articles, it's good to keep providing the proper warnings and to keep explaining best practices and why they matter, even when they seems trivial to ourselves.

09. ux design: the u-deception

At first I didn't feel too comfortable writing about ux design as it's not really my usual territory, but as a regular web user I believed I could still add something valuable to the discussion. The bottom line of this rant is don't overdo it. Don't make me feel like you're trying to engage me. Don't think you're smart with your analogies and witty humor. Just get me to the information or service I was looking for as quickly as possible. Then I'll think about engaging myself with your site.

08. html-man

This year I've been concentrating a lot on writing html. I haven't done too much css work this past year and I don't feel to bad about that. Tying in with my article on the death of the one-man-show web developer, this article explores the depth and range of what it means to write html and how this could very well turn into a full-blown job description. Complexity brings specialization and we're definitely heading in that direction.

07. graceful degradation pitfalls

As web developers we're always working with the latest tech. Graceful degradation is a valuable concept but providing others with a down-graded experience while we're getting the entire package certainly leads to a couple of interesting pitfalls. It's easy to ditch functionality and graphical detail if you yourself don't need to look at it all day, which is why it might be better to start adopting the progressive enhancement paradigm, ensuring the base experience is strong enough and working your way up from there.

06. form mark-up

Ah yes, what html to use for an entire form and how to tie it to data sheet mark-up. With more time to think about how to write quality html code, this is one of the crazy things that came out of it. Semantics, structure and consistency all wrapped together to create the mothercode of all forms. A bit verbose of course (that's html flexibility for you), but I'm quite happy with the resulting html structures. Worth a read if you're like me and you like to ponder on semantics, structure and reusable html code.

05. the adverse effects of social

Social is big, but the bigger it gets, the hollower the experiences it provides. Social these days is all about simple interactions, not so much about communication, and because of that we lost a very valuable function of the web. Discussion is moving away from the web once again, which is a real shame as what remains is random numbers of likes, shares and +1s that try to make up a binary web profile of our offline personas. Not a rosy future if you ask me.

04. html5 articles for content types

Choosing between the article and section element may be one of the most fuzzy areas of html5, so I took the time to figure out why the spec made a separation between these two element. I also came up with a better analogy, instead of matching the article tag to syndicated content (resulting in an ongoing discussion of what content could be syndicated and what not), it's a lot easier if you match the article element to what most CMSs call "content types".

03. in defense of semantic value

One of the articles that spawned the most front-related discussion this year was a rant on the (minimal) value of html semantics. My article was a direct reaction to that, coming from someone who just spent a year specializing in html and semantics. Needless to say I didn't quite agree with the original statement and needed to vent a little. The result is a pretty strong vote in defense of html semantics.

02. the design axiom

While html does a pretty good job of keeping up with the needs for the modern web, css has a lot more issues to deal with. My design axiom states that whenever css catches up with design, design moves away from css again, simply to stand out from the rest. We know that a lot of work is spent on bringing css up to par to current web design standards, but the very ideology of this is flawed at its core. And it's just something we'll have to live with.

01. dry htmling

My personal favorite of the year is an article on what I've been doing the most: dry htmling. I don't know too many other who (can) do this and it's quite a challenge at first, but it really does teach you a thing or two about html. The idea is to write html for a set of wireframes that is given to you without any hints of design or design input. Just write html for what you see on the wireframes and worry about the css later. If you do it right, you'll notice that your html should be strong enough to incorporate most design decisions (unless they are structural of course). A very neat challenge.

microdata reservations

The way I see it, there are three main problems with the current microdata spec. First of all the syntax is just too verbose. You need at least three new properties (itemscope, itemtype and itemprop) to get anything useful out of your marked-up elements, two of them requiring custom attribute values (itemtype and itemprop). That's a lot of extra data for something microformats fixed with just a few (extra) classes.

The second thing that worries me is the obvious correlation between microdata and class names. I know they are two different things with different goals and purposes, but there's an undeniable link between the two of them. Different semantic elements require different styling (if not now, then maybe in the future so if you're into future-proof coding this is a fact rather than a possibility). When using microdata you're pretty much doing the same work twice: naming elements with semantics in mind and naming elements with styling in mind. Not very efficient if you ask me.

And finally, getting your hard work implemented will prove to be an additional challenge. It's hard enough to get the CMS to throw up the classes and tags you requested, if you're going to bother back-end developers with a stack of semantic hocus pocus things might end up a true battlefield. While this sounds like the least important issue we're dealing with (as it is not ideological in nature), it's actually the one that has the biggest impact on the success rate of the whole operation.

here and now

So why bother with microdata? Well, because Google bothers. If you implement known microdata vocabulary in your site today Google can and will pick it up (to test it, you can use the Google's Rich Snippets Testing Tool. While this data is currently not used for page ranking purposes, it can be used to enhance your search result snippets (I think the most visible example today is when Google ads review ratings to the search results).

If you want known vocabularies (which is way more interesting than inventing your own and ending up with microdata definitions no machine can read) you can check sites like schema.org which give you a proper overview of the most common vocabularies out there. It takes some time to get used to the site and to find what you're looking for (some extra examples would've come in handy) but once you get a feel for it (and you see some results in the Google testing tool) I assure you things will go smoothly from there on.

basic usage

<article itemscope="itemscope" itemtype="http://schema.org/Person"> <h1 itemprop="name">(person name)</h1> </article>

The example above illustrates the most basic use of microdata. Each base tag of an object is marked with the itemscope attribute (I'm using the xml serialization syntax here), the nature of the object is given through the itemtype property (which is a working url to the page containing the vocabulary syntax). The attributes of the object are defined through the itemprop property which can be set on all nested elements.

The entire microdata syntax is a bit more versatile, allowing you to add not-nested data to an object, uniquely identify objects and to define multiple properties for one single value, but I'll just direct you to the w3 microdata page as they explain it in much more detail than I ever could.

conclusion

Safe its over-verbose syntax and repetitive nature, html5 microdata is cool because it works today. Add it to your pages and watch how Google picks it up, using it to enrich its search results. Hopefully it will at one time influence page ranking (as Google can now properly interpret your data), but I assume that for the time being they're not allowing it in an attempt to counter blackhat seo tactics (in other words, microdata abuse to increase page ranking).

So if you feel any affinity with semantics, now is the time to get really started. Check the microdata syntax, bookmark the vocabularies and you're good to go. Exciting times indeed!

viewport vs resolution

One important thing to note is that the viewport size of the browser doesn't matter much when talking responsive html, it's the device resolution that matters. You should always send enough html to fully display the site on the current maximum resolution of the device, otherwise you could end up with too little html when someone is loading a site in a small browser window, only to remain like that when the window is enlarged. That's not very responsive now is it? So if we want to filter our html based on the clients' context, it should definitely be based on the device resolution instead of browser viewport size.

The first problem we face is trying to find out the client's resolution. This is easy when working client-side, but since we want to limit the html we are sending to the client based on the clients resolution, we should know about it beforehand. As far as I heard, it's not exactly impossible to do this (using redirects or other nasty solution), but there's no real clean way to get what we want before we start generating our html code. Setting a cookie after the first pageload is an option, but this is not ideal either. Maybe browsers could include this information in the request they are sending (no idea if any security risks are linked to sending this kind of info), but clearly that isn't happening yet.

A much dirtier way is to sniff for browser identification strings and make a base assumption about resolution on that, but that too is hardly an option worth pursuing I think. So for now, cookies are probably the best I can come up with.

direct filter or post-filter

The most efficient way to filter unneeded html is to filter it within the CMS (or whatever system you are using to generate your html). That way we can save server execution time as the back-end will only generate the necessary html the device resolution can handle. The downside is that you will need to support an endless list of CMSs, frameworks and languages and each implementation is custom development. Not a very global and/or centralized solution.

There is a much easier way to filter our html (though not as efficient). Rather than dive into the back-end html generation code, we could just wait until the html is ready for distribution, hijack it, filter it and send the filtered output to the client. This way we could write the application once and use it everywhere (as long as it is able to run on the server). Downside is that you're not only wasting time generating useless html, you're also wasting extra time filtering it afterwards.

Still, the second option sounds like the preferred solution to me. It's clean and straight-forward, it's centralized and maintainable.

filtering

The actual filtering shouldn't be too hard I think. If you look at how easy it is to manipulate the dom on client-side with javascript, a similar thing should definitely be possible on the back-end. If you write decent html your html code should be sufficient to define tasks based on dom queries (through css selectors or whatever). Imagine the following rule for small resolutions:

#page > #main > aside {display:none}

Now imagine your filter just deleting the nodes that match the above selector from the html. Easy right? Not everything should be about deletion though, this would also be the perfect place and time to switch image resolutions for smaller resolutions, making the hacks described on 24ways.org obsolete.

conclusion

You might have noticed that this article is very much focused on theory instead of suggesting any practical solutions. The reason for that is actually quite simple: my knowledge of server-side implementation is staggeringly insufficient.

Still, I'm quite certain that a stand-alone html filter like this should make things very easy to brew responsive html versions of your site based on device resolution (and ideally also on available bandwidth, as this is an even more decisive factor). You would only need to focus on developing one application that could be used independently of the way a html page is generated and is easily configurable to mess about with the html.

I'm sure I missed some huge pitfalls in the process, if so tell me about them. If not, please build this thing as quickly as possible :)

communication vs interaction

Before I had an internet connection there was one main reason why I wanted to get online. It was not for buying stuff off the web, not for downloading emulated SNES roms or for browsing online anime galleries. The single idea that pulled me towards the web was the possibility to sit down behind my computer and talk to some complete stranger in the USA about things that interested us both. This line of communication opened up a completely new world, one that allowed me to look beyond the borders of my hometown, province, country and even continent.

When social boomed this idea still lived on in me, even though by then I'd learned that talking to some dude in Kansas isn't all that different from talking to your next-door neighbor. The charm of online communication had somehow faded, but the ideal wasn't dead at all. What I failed to see back then was that social wasn't really about communication, the big players had something different in mind. Rather than communicate, the social experience was hollowed out and brought back to interaction in its most simple form.

meta-usability

No worries, meta-usability isn't going to be a trending topic in 2012, I'm sure there are better words out there already, but for lack of knowing them I'm just going to roll with it.

Usability for me is taking a certain task and making it as simple as humanly possible to perform, without losing any meaning in the process (= essential). It art of usability spans many disciplines in web design, from conceptual design to wireframing to visual design and copywriting and received much attention these past couple of years. People ran with the concept and went a little overboard though.

What I mean with meta-usability is not related to the art of simplifying tasks, rather picking the easiest task to meet an (application's) goal. This is something all the big social networks understood very early on. Rather than make the act of communication as simple as possible, they looked at the goal of their application (connecting people) and picked the easiest task to accomplish this. And they did a good job too, as they managed to reduce the basic interaction to the single most basic action on the web anyone can make: 1 click.

If you like something on Facebook: 1 click. +1 something on Google+: 1 click. Retweet something on twitter? 1 click. These days this is the very basics of social. Interaction between people is reduced to one single click. No follow-up reactions, no actual communication needed. This fueled the success of platforms like Facebook and Twitter and the choice of this particular path more than helped them in meeting their personal goals.

What many fail to see it that the actual users pay the price, because when applying this type of usability meaning and value are definitely getting lost in the process of simplifying things. People are lazy by nature and if you give them the choice for feedback with one single click they'll gladly take it. At the same time, these functionalities are actively killing incentive to really discuss and communicate.

on hippies and lack of nuance

The thing I like the most about Google+ is that it dropped the concept of "friends". Most of my connections are just that, people I know or would like to follow. They are not my friends, some of them I never even talked to. So Google introduced circles and provided a way to follow someone without the hassle of fake friendships. At least this is some kind of useful progress.

But this rosy, hippie mentality made popular by Facebook runs a little deeper. For ages people have been bugging the Facebook team for a dislike button but it's still not available. Google+ doesn't offer any solutions either. From the point of view of these platforms, omitting this option is quite logical. They want happy people on their sites, reducing all kind of fights leading people away to different networks. After all, a happy customer is a returning customer.

Everyone knows that a good value scale is made up out of three basic reference point. Good, medium and bad. Our social networks lack these scales. There is only "like" and "no comment". No comment can mean anything from "I didn't see it", to "I didn't think it was worth sharing", to "man, that sucked balls". And yet these social networks are making assumptions based on what we like (and more importantly, don't like). At the same time the word "like" underwent a serious devaluation from "happy state" to "acknowledge you put it there", so even when someone likes something, I'm still not sure they actually like it.

Social networks are reducing people to binary equations. To Facebook and Google I'm a collection of likes and no comments. Everything I like, I like equally. There is no difference between "okay" and "best thing I've seen all year", no difference between "that's a great video" or "good you finally found what you were looking for". Just a collection of 1s and 0s. Quite frankly, I'm not happy to be reduced to such a lacking binary equation as systems won't be making any good choices based on that info. Proof of this? Amazon's recommendation lists are damn awful, and I'm not surprised if I think about how they try to build these recommendations. It's pains me to think Facebook is doing the same when it's compiling my stream of updates.

line length

The perfect example of why best practices are not always absolute truths. Maybe you've read about this discussion before, but for years people have been looking for the ideal line length in text. Readability is the prime motivator for this quest. I don't know if there's a real consensus by now, but last time I checked the ideal line length was set around 80-90 character or roughly 12 words per line.

This may very well be true for readability, but if you try to encourage conversation on the web the line length problem gets a whole new dimension. Once again, look at Facebook or Google+. When I comment, a single full sentence looks like half an article of opinion spam. Line length is so limited on these social platforms that you feel bad posting anything longer than a single paragraph of text. Even I, someone who looks around for discussion and conversation, feels the daunting pressure to skip long Facebook comments just because they look too impressive to delve into.

Think back of the old days, when we used to live and talk in fora. After three complete sentences you had roughly one line of output. I'd often go back to a previous post to flesh it out, trying to document my opinions more thoroughly and provide extra context for the people who were intending to read and reply to what I wrote. Longer line lengths promoted more meaningful and wholesome discussions, something that got lost when we kept a narrow focus on readability.

And Twitter's 140 character limitation? Still the worst idea ever.

conclusion

Social is turning us into lazy, inanimate, voiceless object who's main interactions consist of acknowledging and sharing. Social is actively preventing (meaningful) discussion in its quest to narrow interaction down to the single most easy task one person can perform. Sometimes I long back to the day of fora and oldstyle web communication, when the term social wasn't in our vocabulary yet but at least the concept actually existed.

When we talk about best practices we talk about meeting our goals, not necessarily about the goals of our users. As long as they believe they're happy, that's good enough for us. In this process we lost of lot of depth on the web, which should be clear to anyone who compares the current situation to that of 5 years ago. It's time to ditch the Twitters, Facebooks and Google+'s, I demand the next social network should provide for communication, not mere interaction.

the problem

<section class="focus"> <header>...</header> <div class="main">...</div> <footer>...</footer> </section> section.focus > header section.focus > footer

I believe a quick recap of the issue I described in my previous article is in order, so here goes. The html setup above sets no extra classes on the header/footer elements, so the best way to style them is through the child combinator. This allows us to style only the header and footer of the focus block and not worry about nested content that might contain its own header and footer elements. Long live the child combinator!

The problem is that extra (sometimes unforeseen) wrappers in between section.focus and header/footer elements will completely destroy our carefully constructed css. Javascript might be inserting extra wrappers, a structural change (block level wrapper link or form) will lead to similar results. While the child combinator is extremely useful, in the end it might be too rigid for the needs of the web as we know it. Only in very controlled circumstances can it be used without worrying of breaking large chunk of css.

call to the w3

So I contacted the css working group once again to revisit this problem, in the hope to find a proper solution to counter this very shortcoming in the future. If you want you can read the entire thread you can, but I'll limit myself to the proposed solutions that were raised in the discussion.

conclusion

I love the idea of scoped css, though it's not really clear to me right now if you can define multiple boundaries for one single component. It's not even certain that this is ever going to make it into the spec or even a proposition, so it's probably best not to get too excited yet.

That said, with ie6 slowly disappearing it's time we start to tackle the problems of the next-gen css (it's sad to call child combinators that, but it's still true I'm afraid). Hopefully the near future will give us something that allows us to finally style a component within the limitations of its own boundaries.

it's all about structure

You can actually witness the problem live on this page (at least for now, I'm planning to change this as soon as possible). Regular visitors won't notice it because it's not a visual issue, but if you dig into the html code you'll soon see that I ran into some serious structural problems here.

If you look for the article component you'll find it nested inside the left column, but if you check the top of the right column you'll find article info and visitor stats there. Currently both elements are connected by a matching background colors, ideally they should be nested within the same component. After all, article info and visitor stats can be considered meta data of the article. The assumed problem lies with the related page data that is placed directly below the article meta data (related article, articles, ...). Somehow I never found a way to layout this structure with the article meta data actually nested inside the article component.

floats to the rescue

<div class="wrap"> <article> <div class="main">...</div> <aside>...</aside> </article> <aside>...</aside> </div>

This is roughly the structure we're going to work with (a small abstraction of my current blog code). The goal is to have the article > .main area to appear to the left and to have both aside elements appear on the right, neatly stacked below each other without and javascript trickery or fixed css heights.

The key to solving this problem (and what I somehow missed completely) is to understand that floats will continue to work as expected even when they are set on different dom levels. My initial reaction to floats is to make sure their wrapping parent always clears the floats. In this case though, the article wrapper is simply a structural/semantical wrapper and its contents should not really be contained by it.

.wrap > article > .main {float:left; width:100px;} .wrap aside {margin-left:100px;}

It's really that simple. The article > .main area is floated left, while both aside elements are pulled to the right with a left margin spanning the width of the left-floated element. As a result they both appear beside the article > .main area, neatly stacked underneath each other.

support and pitfalls

Basic support for this method is superb. It works all the way down to ie6 with no extra fixes required. While this is great, it actually made me feel worse for not knowing about this simple trick.

There are some (rather serious) pitfalls though. You have to make sure that the article element does not clear its content, so no clearfix or overflow:hidden can be applied to this element. Other clearing methods are equally forbidden. Worse though is the fact that you can't apply any clearing within the aside elements as their contents will once again drop below the left-floated main area. This might be a big issue when working with more complex use cases.

.wrap > article > * {float:left; width:100px;}

Finally, you could lose the .main wrapper inside the article element (placing the float and width properties on article > *) if you're a real html purist, but that means you'll end up with a lot of floated elements that won't collapse their margins and will generally behave in unwanted ways, that's why I left the wrapper in there.

conclusion

So there you have it, a simple and browser-proof method to create the proposed layout with the given html structure. Many of you will wonder how this could've escaped me all these years, I don't really have an answer either. I can only assume that this isn't common knowledge, which is why I wrote this little piece.

As for more "modern" methods, I assume it's also possible to fix this layout using the css3 grid layout module, if anyone could point me to an interesting article regarding this subject I would appreciate it a lot.

rant 1: why microformats and html5 microdata (kinda) suck

To understand the current lack of semantics on the web, it's important to know how and why semantics should matter. Currently the goals of semantic value can be summarized into two main selling points: findability and processability.

Findability probably speaks for itself. When I ask google to look for a specific film review, I want google to return actual reviews. I don't want a page featuring the film's title and a greyed-out review link (because no reviews are available). That's exactly the opposite result of what I asked google to find me. So semantics should make it easier for google (and I'm talking all search engines of course) to determine the actual contents of a document/component and provide better search results.

Processability is a little different. It doesn't just stop with finding content, it wants to recognize content and offer a gateway to export it in different formats. That's what the most popular microformat (vCard) is doing right now. It makes sure the hCard spec can be recognized in html documents by external software, which can then automatically import all the data into a different piece of software or export it in a different format. In this case, an automatic way to sync data between two different systems (website and agenda).

One of these tasks is infinitely more difficult than the other. For findability, you need one single marker on the base tag of the component (.review), for processability you have to define all the separate sub components and make sure they can be processed correctly. Looking back at how web design grew up, there has been one big constant: baby steps are the way forward. Start out simple, maximize profits with minimal effort and once you have established popularity, extend and build on that. And that's exactly what initiatives like microformats and microdata failed to see. Implementing findability support is easy and trivial, but by trying to tackle the full picture all at once that step was skipped and forgotten.

Everyone who ever tried to implement a microformat should be aware of its complexity. And not only for us, the front-end guys, it also requires extra effort from the back-end team who has to develop the correct code in whatever cms they are working with. This extra step is often too much to incorporate into the project, so we take the easy route. At the same time we see that very little support exists out there for people who do implement microformats and microdata, so the pay-off to go that extra mile remains small.

For findability, all we would need is a fixed vocabulary for popular content types (.product, .review) that can be added together (.product.review). Add synonyms (.post = .article) and you have just about all the power you need to tell search engines what content you are serving. There is still no way to process this information, but that kind of support can be put back a little until the time we do have enough base support.

The main question of course is who would manage this vocabulary list, but that's a more practical consideration I like to leave for others to decide. I'm sure though that the popularity of semantic thinking would rise exponentially if such (very simple) support existed today.

rant 2: the now-generation of web development

The three quotes above are taken from the posts and comments of the two articles appearing on Smashing Magazine. They are coming from people with considerable weight in the web development community.

The sad thing is that they all talk about the "now". Immediate gain, direct results and measurable effort. Things become worthless or invaluable to pursue if they don't yield immediate results. As our industry grows and matures, it's normal that money (and thus efficiency) is becoming more and more important, but I firmly believe that possible shortcuts should never be preached by those who are (in whatever way) elevated to preach to the masses.

Whether it's worth to go the extra mile to understand semantics that don't "work" today is up to the developer. Making sure that developers understand that increased semantical value will aid us five years from now is up to the preachers. This whole "now"-movement reminds me a lot of why we are still providing ie6 support today, as those sites we also conceived and constructed only with "now" in mind (and they worked damn well in the past "now" too).

People seem to forget about the benefits of theoretical research. My math teacher once told us the story of "i" (the imaginary number). This number was conceived in the 16th century without any possible use for it. Only 300 year later it proved to be incredibly useful research that immediately solved a number of problems people were facing back then (fe. electrical engineering). It's the perfect example of how a theoretical effort can prove to be invaluable in the future, even when you can't even begin to predict the actual benefits.

Couple this with the popular "paving the cowpath" principle of web design and you'll quickly begin to see how important it is to look to the future rather than just think is terms of quick gains and immediate profits. The fact that not everyone realizes this isn't worrying me, but that big names in our industry are actively challenging these ideas is a whole different story.

The web lacks semantics. It's something that's becoming more and more obvious every day, and people telling us to stop pursuing semantic validity unless there's some immediate gain should be countered immediately and effectively, because they aren't helping us forward in our quest to provide a more meaningful web.

conclusion

Semantics matter. If not today, then hopefully tomorrow. And if not tomorrow, you know who to blame.

css transition

css transitions are a special kind of (automated) animation where css will animate between the different values of a single css property, triggered by a change in state of its base element. The most common and obvious use lies with :hover states (or related), applying small animations for hover colors and the like.

These transitions rely on numeric values to work though, which sadly is quite a limiting factor. It's still possible to transition between colors (as they can be presented by hexadecimal values) and the like, but transitioning between different background images is not an option yet. That's a real shame, since I wanted a small color fade effect on the icons in the main navigation of this blog. Lucky for me, there were some other options to explore.

introducing: opacity transitions

Re-using one of the older tricks (changing hmtl images on hover) it's actually quite easy to reach the intended result. The property that's going to help us with that is css opacity.

The idea is to place two layers right on top of each other. On hover, we'll use a css transition of the opacity value of the top layer, so the bottom layer will gradually begin to shine through. When the animation is complete the opacity of the top layer will be 0 and all we'll be able to see is the bottom layer (in other word, the hover state).

two structural elements

.outer {background:(hover-bg); position:relative;} .outer .inner {transition:opacity 0.2s linear; background:(bg); position:absolute; left:0; right:0; top:0; bottom:0;} .outer .inner {position:absolute; left:0; right:0; top:0; bottom:0;} .outer:hover .inner {opacity:0;}

As you can see in the above code, the hover background is set on the lowest plane. The inner element is positioned on top of the outer element so that both backgrounds will match exactly. On hover the opacity of the inner element will be reduced to 0, finally leaving us with the image of the hover background. Mind though that if you have other content nested inside the inner element this will disappear as well, so to be safe it's best to make a self-closing, empty element of .inner. Not very clean (I know), but it does the trick.

This is 2011 though, so it wouldn't be quite alright to not try the :after/:before option for cleaner code.

one structural element

.base {background:(hover-bg); position:relative;} .base:after {transition:opacity 0.2s linear; background:(bg);} .base:after {position:absolute; left:0; right:0; top:0; bottom:0;} .base:hover:after {opacity:0;}

Ain't that lovely, a working example without the need for any extra structural elements. No hover support for ie7 or lower (of course), but a little javascript can easily fix that. Together with ie8 you'll also need the ie transparency filter to make it work (or just use visibility:hidden if you don't care to animate it).

But ... you know this was coming, right? Apparently Webkit (oh yeah, we develop for state of the art browsers now) does not support css transitions on pseudo-elements. There is probably a good reason (and this is not really a Webkit bash, which in turn supports quite a few things other browsers don't), but somehow I can't help but feel a sharp sting of disappointment that after all these years we're still dealing with partial and/or buggy implementations even in the latest browsers. Because let's face it, css transitions have been around for some time and are hardly experimental anymore.

conclusion

So if you're looking at this site through Chrome or Safari, you won't see the color fade in the logos (main navigation navigation). I could've opted to include an extra structural element but was too stubborn to go through that length for something that calls itself a modern, A-grade browsers. So for now Webkit users have a simple hover effect until Webkit fixes its lacking support for css transitions.

For more professional projects I would suggest using the first method though. It may not be very clean using an empty structural element (you can still insert it with javascript if you want), but at least it gets the job done across most modern browsers.

killing ie6

You might have noticed already, but the ie6 graph on my homepage has been consistently showing figures lower than 0.5% for four weeks now. Taking several variables into consideration (fewer works posts these past couple of weeks, gradual ie6 fade-out), I won't suspect it will ever rise above that marker again. That means that even before 2011 comes to an end I will be dropping complete ie6 support. I'm sorry for all of you who are still using ie6 to browse the web, but your group is too small to warrant all the extra work in my spare time.

This is also one of the main triggers to (finally) make the switch to html5 and to rely on more "advanced" css selectors (like the child-selector). Between that and cleaning up the mess that ie6 left behind, I assume it will be quite the chore to get everything back into order. On top of that, I'm also converting my css to less, so the resulting file should be a lot cleaner and easier to manage. For those of you wondering what will happen to the graph on the homepage, expect a new one to pop up the moment I axe the ie6 graph, displaying ie7 user stats of my site. That's the next browser that needs to disappear.

live iterative design

Like last time I will be fixing one component at a time, rather then launch a complete new site all at once. You can already see the result in the header and footer of this site, which have already been converted to html5 and feature some nicer hover effects than before. It's small things like these that will define the redesign.

It's quite impossible to do this without breaking some stuff along the way though. Currently the right column looks a little less styled than it should be due to changing my grid html structure (and finally fixing the ads properly). Small glitches like these will no doubt pop up once in a while, but I'll make sure the content will remain accessible and clean at all times. Just cut me some slack when I'm working on some of the bigger components.

so what is in it for you?

As a regular visitor you probably won't notice much of all these changes as most of them are happening behind the screens. Apart from some smaller visual changes and touch-ups left and right not all that much is planned to change.

Hopefully this site will come out a little leaner and should be a bit more responsive compared to the current one, at least that's what html5 and css3 promises anyway. I hope you'll enjoy the updates, as small as they may be, so here's too a fast and seamless attempt and live iterative design!

1. using two structural elements

.parent {background:();} .parent .child {width:(); margin:0 auto;}

The easy way is to use two structural elements instead of one. The parent will function as a wrapper for the background, the child will be used for horizontal centering using margins and for defining the width of the centered element. Of course it would be much easier if we could center the containing content, but sadly that is not possible yet (unless I missed something vital of course).

This works fine in most cases, but if your code should be flexible enough to allow for visual rows within the page content, things will get a little tricky. Once a container is centered using margins, its children won't be able to break out easily, especially not if they'll need to span the entire width of the browser canvas. On top of that, I wasn't very happy with using two structural elements for such a minor visual detail. So let's ditch this method and look for something smarter.

2. using ::before and ::after

body {overflow:hidden;} .element {position:relative; width:(); margin:0 auto; background:();} /* pseudo-elements */ .element::before {content:" "; position:absolute; right:100%; width:999em; top:0; bottom:0; background:(); z-index:-1} .element::after{content:" "; position:absolute; left:100%; width:999em; top:0; bottom:0; background:(); z-index:-1}

If you lack structural elements, the popular way these days is to abuse your pseudo-elements. And sure enough, with the code above you'll get the intended effect.

The trick is to give the pseudo-elements a large width, pull them on either side of your centered element (using left/right:100%) and cut the remaining parts off using an overflow:hidden on the body (if not, you'll get scrollbars). Mind that the z-index of the pseudo-elements should be set to -1 so they don't overlap the content of your element. Even though they are positioned to the left and right, they might still overlap any drop shadows or other parts sticking out from your content.

The problem with this method is that you'll need to fake the background using three elements. If you want to add an inner shadow to your visual row, you might hit a wall once again. Visual requirements may differ though, and if you need to have different colors for left/right flaps or you need transparency in your centered area then this is definitely the way to go.

On a side note, if you want ie8 to play along, make sure to use the :before and :after syntax, rather than ::before and ::after.

3. using only ::before

body {overflow:hidden;} .element {position:relative; width:(); margin:0 auto; background:();} /* pseudo-element */ .element::before {content:" "; position:absolute; left:-500em; width:999em; top:0; bottom:0; background:(); z-index:-1}

This third and last method uses only one pseudo-element and removes the need for multiple background declarations to fake one single background. Just pull your pseudo-element to the left using a big (negative) left value and make sure it is wide enough as to span the entire browser canvas. It's not a very pretty fix, but it does the trick.

If you want an ie7 fallback, you can always insert one extra structural elements using javascript, applying the same css as used for the pseudo-element in this example. I haven't checked ie6 myself, but when ie6 compatibility is required I assume you might be better off using the second method (inserting two structural elements using javascript), I figure it's quite plausible ie6 won't be liking that negative z-index.

conclusion

Mind that the solutions listed above are not necessarily my own. I remember reading about this some time ago but could not relocate the article, so I'm not sure if it differs much from what was written there (I just remember the pseudo-elements trick).

Even though the above methods work pretty well, they are still hacks (or at least crappy solution to a rather simple problem). It would be a lot nicer if we could leave these pseudo-elements for their intended purpose and simply size and position the inner content of an element using css, but I still haven't found a decent solution to do this.

For now though, the solutions above will be able to help you out where needed and will offer enough flexibility to encounter most common issues.

developing with less

While using less to write css is incredibly easy, using it for development is somewhat of a chore. Either you use the less javascript library, but that has poor support across different browsers (I've only really seen in work well in Firefox), or you can install a server-side parser, but that's a bit over-the-top for local (often static) template development. And then there is of course the command line method, something I won't even begin to discuss.

In theory it shouldn't be all that much trouble to develop in Firefox, then parse the css once and start checking it in other browsers. I clearly say theory, because web design is never that simple. There are always some small changes close to the deadline that need to be processed, or some small bugs popping up that were missed in the first quality check. Before you know it, you're constantly switching from and to less and css files in your static templates. A dreadful job and hardly productive.

poor windows support

What you need is a tool that converts less files to css files the moment you save your less file. That way you can include the css files in your static templates, but keep developing in less. Other platforms (like Mac and Linux) have such tools already, but for some reason they never made it to Windows. That void is finally filled with the new Air Less Parser.

The tool is currently in beta, but has solid project management functionaly, a feedback log and an option to automatically scan and parse folders (and subfolders) whenever files are altered. If you don't want this you can still opt to parse manually. Just fire up the air app, start adding your projects and begin development in less without ever having to worry about the generated css.

what the future brings

The tool is currently in early beta, but should function as advertised. New features are already planned though. Expect to find minification options and growl-like notification messages in the near future. So without further ado:

Air Less Parser

my personal blog through the years

Those of you who've been following my personal blog since the very beginning will probably have noticed that along the line my output changed considerably. At first the personal posts were more diverse, ranging from music reviews, game reviews to other, more personal rants. Nowadays, most of the posts appearing on my personal blog are movie reviews, with only one of two game reviews or vacation pic lists appearing every year.

There are a couple of reasons for this, the most important one that a few years ago I was recruited as a member of twitchfilm.com. Even though they don't actually expect regular input from me (I'm pretty much free to write about what I like, when I like), it gave me plenty of motivation to write more film reviews. On top of that, my interest in discovering new music and games had to make way in favor of watching more movies as I hardly have enough time to do just one of these as passionately as I would want.

introducing: my 100 favorite films

As someone who loves (and I mean loves) lists, I can't get past the fact that I need to make a yearly update of my top 100 films (ever). This year I noticed that many of the films in that list already featured a review on my blog, so slowly an idea began to form. Just a couple of weeks later my permanent top 100 movies section is finished and ready to launch.

The list isn't just a rehash of existing reviews, there is also some new content in there. Each film features a poster, an on-page trailer (safe a few films where I couldn't find a good trailer), some limited movie info and a link to IMDb. On top of that, the review is displayed (if available). For now that means there are little over 40 reviews in there, the others will be added over the course of the coming year (I'm aiming for one review/week). Two birds with one stone, as this is the perfect opportunity to revisit some of my old favorites.

the future

For now the banner to access this new section is featured on top of the homepage and it will stay there for two weeks, after that I'll move it below the blog list to its more permanent spot. I'm planning to make this switch once a year, when I update my list of favorites. I hope you enjoy this new addition to my site, feedback is always welcomed.

check my new top 100 movies section

html brings light into the darkness

html is about structure and semantics. In all these years I've been blogging I found myself repeating this over and over again, but that's just because it's one of the most purest (and actually one of the few) truths in our profession. It's the baseline and starting point of any proper argument you can have on different ways to write html.

What this means is that html should provide as much clarity on the content it describes as well as reduce the chance of any ambiguous assumptions. Both structural and semantic information are important so that humans (less important) and machines (very important) can try to analyze your content and use it for their own specific purposes. This goes from search result optimizations to screen reader software offering your content in well-structured, bite-sized portions.

top-down semantics

When I first started to learn about html (and its semantic value) I was clinging to a very narrow view of what semantics was all about. Trying to find a proper and descriptive name for a component happened with little regard to any relations it had to other existing components. It was really an exercise in "what is the best name to describe this thing" without wondering about "... and how does it fit in with the rest of my page/site".

As you write more and more html code you find yourself making connections between certain components. When I just started out there was a moment when I realized it might be good to somehow group all navigation components together. I started using a prefix (nav) for classes referencing navigation components. Nowadays we have a unique tag for this specific case. The benefit of doing this: screen readers now have an easier job finding site navigation and offering it in modified form to their users.

While experience will teach you these things over time, I feel that bottom-up grouping is not the best way to start off. So let's see what a page looks like from the top, working our way down to the level of individual components.

3 abstract content groups

I found that just about any page out there can be split up in a combination of three different abstract content groups. Note that none of these groups are actually required to build a proper web page. A quick rundown:

just another useless categorization?

What's particularly interesting about this way of categorizing things is that it allows you to separate fluff and noise from the actual content your site is based upon. If you would somehow succeed in getting this categorization in your html code, a program could run through your site and extract all your unique content, skipping navigation, ads, shortlists and other duplicate content.

This is not an alien idea, there are already programs out there (Safari Reader for example) that try to do this. Sadly these programs only base their output on vague assumptions and guesses, not able to guarantee a proper result. This is because they lack the proper hook in html to make valuable assumptions.

conclusion

While these abstracts will probably not be reflected in your final html code anytime soon, they will still reveal some interesting subtleties. Before I used to think that a search box and contact form were closely related components, now I feel that a search box is a clear redirect, meaning it's closer related to the group of navigational components (though I firmly believe a search box doesn't actually belong to the category of navigation).

This article was written from a html perspective, but obviously these categorizations have a much broader impact than html alone. In time they might influence the way you structure you css and javascript (a direct result of restructuring your html), needless to say they are also useful when starting to wireframe a new site. They might help you make better judgments when deciding what elements to remove or switch around when taking a mobile-first, responsive approach, or they might help you balance your pages, making sure you have enough unique content on offer.

All this just because I was planning to write an article on a special category of redirect components, but I'll leave that for next time.

say, what are base variants?

I guess I'll start by explaining what I consider to be base variants. When using class names for semantical purposes, the first thing to do is come up with a name for a particular component and add that as a class attribute. Usually it doesn't end there though. It is not uncommon that (semantical/visual) variants of one particular component exist, so to mark those variants you have to add a second class to the base class, like so:

.focus {} .focus.news {} .focus.topArticle {}

The css excerpt above illustrates the setup I'm talking about. The focus class is used for whatever piece of content on a page that advertises other content on your site (more about that in a future article), the additional classes describe the nature of the content that can be found in the .focus component. The base variant in this example is .focus.

Not all instances need an extra specifying class, so the base variant will appear wherever the component contains nothing more than generic content. Another possible reason for ending up with a setup like this are last-minute changes. Imagine that you implemented one version of a component all over your project, but right before launch they decide to add a (functional or visual) variant of this component. Rather than add a extra class on all base variants (which is usually a rather large cost on the back-end side), you just add a specifying class on the new variant.

the problem

As long as the additional classes only indicate semantical differences or small visual touch-ups you won't have any trouble with this way of working, but sometimes semantically related components can end up with designs that wildly differ from each other, even when they appear on a single page. Now, if you added all your css styling to the base variant you'll be cursing all the way through when you need to reset half of your styles to match the new design.

Even worse it that every design change of the base variant means you'll need to check the impact on the other, visually unrelated variants. Things get messy real fast and what you end up with is bugs, crap code and annoyed customers.

matching base components

1. div[class="focus"] {} 2. div[class~="focus"]> {}

Luckily the attribute selector can help us out here. The first line of code above targets all divs with a single class focus. If you want an alternative for .focus (as we know it in css) you can use the second line. It's a subtle but important difference that helps us to identify base variants. (props go to Jochen Vandendriessche for bringing this to my attention).

Mind that this is not fool-proof though. Browser support is okay (all the way down to ie7 and with a little javascript trickery it's easy enough to duplicate the css on a computed class for ie6) but additional characters (like spaces, tabs, ...) can still mess up your targeting. They should be easy to trim in most cmses but I'm sure there are some exotic cases out there where this could be a major problem. Another issue lies with adding (trivial) extra classes through javascript for whatever reason (think modernizr), which will again mess up your css target.

All of these issues are rather minor though and don't really render this method unusable. Still, be weary that they might still occur, usually when you least expect it.

ignoring a specific component variant

1. div.focus:not([class~="news"]) {}

And while we're at it, here's another little tip. Consider a situation where you have one base variant and 4 other component variants with slight visual touch-ups. Now imagine a fifth one (let's say .focus.news) being added that looks completely different from all the rest. The selector above will help you style all the existing variants while keeping any existing styling away from the .news variant.

conclusion

With ie6 almost out of the picture we can finally start using more powerful css selectors, then again we have to make sure we're fully aware of all the complications towards future-proof coding. The examples above will work quite well in these very specific circumstances, but know that they can easily be overturned by changes later on in the project. Such changes might render your css setup completely obsolete, forcing you to start all over again. As future changes are always difficult to predict better think twice before using these techniques, but they can still come in handy for some quick fixes or in well-defined use cases.

As a final thought, I guess this also illustrates that even though we might have more powerful css selectors available to us now, they're still far from powerful enough to really translate our needs to a matching css selector. At first glance the attribute selector might benefit from logical operators, though that might lead us too far. Or maybe this is just another good argument to stop using classes for semantical purposes. Alternatives are welcomed.

web and net

As a front-end developer I have spent most of my time defining structure and semantics of content on a single page. The past few years I've tried to create consistency in my html components between different pages and even websites, but even then I was still focused on describing content that resided within single documents. There is more to the web than just displaying information though.

The main strength of the internet lies in linking documents together, to create a real web of information. So far we didn't have many means to describe how pages were related to each other, the rel attribute was conceived as a first step to change that. The rel attribute accepts a string of keywords that gives extra information on a specific link, explaining the relation between these documents. While some of its functions are questionable at best (nofollow for example, which clearly doesn't describe a relationship but instead describes an action), it opens up a whole world of interesting possibilities.

prev/next

I probably don't even have to explain what rel="next" and rel="prev" are really for, as "prev" and "next" are common keywords in whatever pagination variant you can think of. rel="prev" indicates a link to a document that belongs to the same sequence and precedes the current document, rel="next" indicates a link to a document that follows the current document. It's as simple as that and that's all there is to it really.

If you follow the whatwg spec the prev/next values can be placed on all types of pagination, ranging from multipage articles, paginated result lists (on both prex/next keywords and the appropriate numerical links) to the next/prev links you'll find at the bottom of this article, used for jumping directly between blog posts.

Implementing this is also as easy as can be, but before I was going to tamper with my blog I looked around one last time, a little weary of the simplicity of this particular spec.

enter google

For years now we've been adding semantics and structure to our documents so automated systems would know what to do with our information. So far not many systems out there use this semantical data, so there has been little feedback on how this would actually work in the real world (I know there are various attempts by Google to match microformats and such, but I consider those implementations to be rather marginal compared to what you would normally describe as common use on the web). We've been so occupied with finding the best way to do this, that we somehow forgot that there would be a possibility for those automated systems to willingly misinterpret this semantical data, or at least interpret it differently as we originally intended.

The quote above is how Google hopes to interpret the prev/next values for its search engine, hinting that it will try to redirect people to the first page of the sequence if it thinks this is appropriate. Looking back at the pagination examples I've given though, this is definitely not what I would consider preferred behavior. Not as a site owner, but also not as a user of the Google search engine. Worst case this would mean that if Google found a match in one of my latest articles, it would throw the person back to the first article I've ever written. Or if it would find a hit in a result list, it would send you back to page 1 of the results. How this is useful is beyond me.

What Google tries to do is catch those instances where one single article is spread across multiple pages, but even then it's a questionable assumption that people would prefer to start at the beginning of the article, rather than get to the bit that matched their search and go from there. It's nice that Google tries to be helpful, but they should take care not to hurt, hamper or hollow out the initial goals of a spec.

conclusion

It's a little scary to think that one company (~85% of the world population searches the web with Google) can make such a trifle assumption and make a simple, clear cut spec like this virtually unusable. Maybe I'm jumping to conclusions here, as Google didn't actually reveal its algorithm for deciding on the automated content jump, but as it stands now I'm not going to implement the prev/next values as I believe this will actually hurt the resulting hits people will receive on my site.

I'm sure the option to jump directly to the first page would be handy (if it isn't already available on the page itself), but when big companies start deciding what content to serve me (hello there Facebook) rather than just offer what is out there, things get a little iffy. I do hope Google retracts its decision to act on the rel="prev/next" spec the way they described above because it's a nice spec with a lot of potential.

hype the hype

The web development community has grown considerably these past few years. While definitively not a bad thing, it introduces a couple of fresh problems that need to be dealt with. One of those problems is visibility. Everyone wants to be noticed and with more and more people competing for attention there has been a surge in boiler plates, mini frameworks, code projects and artificial hypes, ... whatever is necessary to make your work feel big and important. Where you used to just share a bit of code in a blog article, you now need a project on github with a fancy version number and a snappy project name, otherwise people won't pick it up.

All this hyping has lead us to a less critical perception of some of the tools we promote so vehemently. Last week I caught an audio interview between Jeffrey Zeldman and Faruk Ates discussing modernizr. I say "discussing", but what I real mean is promotional talk. They didn't even raise the issue of partial/faulty browser implementations of new features, instead they sold the framework as universally future-proof. I guess you just can't be critical of your own work anymore or people will look elsewhere. Stuff like this bothers me, which is why I think it is time to point at some of the dangers of responsive design. Because even though the concept of responsive design holds a lot of promise, it can go horribly wrong too if you're not careful.

responsive

So what is responsive design? Well, leave out all the subtleties, cut out the buts and ifs and what Joe Average remembers is my site looks different on my phone. In reality though, things are a bit more complex. The idea of responsive (in contrast with adaptive) design is to define a couple of different contexts up front. Think of it as having several cubes with different sizes where your site should be made to fit in. For each cube you need to decide how to reorganize your webpage so it fits as nicely as possible.

To accomplish this we use css media queries. Using a list of possible parameters we define a set of contexts. For each context we (over)write some css rules to change the structure and visualization of certain components. We can even add some fancy javascript if needed to make the transitions between different states a little easier. As you can see, the whole concept of responsive design leans on the flexibility of the css media queries, which at this time is rather poor. You can play around with dimensions, orientation and color depth (yay!), but that's about it.

translating mobile to media queries

So going back to our example of developing a site for mobile devices, where do we start? Well, the "mobile" experience is usually defined by three parameters that differ greatly from the desktop experience. The most visible is screen estate, the second (and equally important) one is performance and the third one is interaction. Looking at the media query options we have though, there's only widths and heights to toy around with.

So targeting "mobile" in responsive design is actually defined by browser/device dimensions. There is no way to decide anything based on connection speed or means of interaction. If you target on device width/height you are somewhat limiting yourself to industry standards (hoping there won't be any exotic variations out there), but if you target on browser width/height you run into the chance of changing the desktop experience too (which can be very bothersom, unnecessary and unwanted).

but that is not all

There are more glaring issue though. Trying to figure out how to define the right amount of different contexts can be quite tricky. I've seen sites that shift layouts every 50 pixels or so, which is damn annoying. But when only defining two separate contexts, you might be limiting yourself a little too much. On top of that, deciding what components to cut and what components to move around is another really tricky issue. Of course these are mostly trademark UI problems, but when done wrong or when handled by people not fully competent to tackle the task, the results can be disastrous for your site.

Another interesting problem revolves around big screen sizes. Nowadays responsive design is mostly targeted at fitting sites in small screen estates, but there's a whole range of possibilities to fill up redundant space on large displays. At least, if such a thing is actually possible without confusing/annoying the hell out of your users with each design transition.

For now I believe it is best to try and match a design per device. This pretty much eliminates the use of browser widths/heights in media queries, but I just don't think it's a good idea to throw around the design of a single site on a single device during a single browser session. When I resize my browser window I'm not hoping to see any structural or visual changes on a webpage, and whenever that does happen I'm usually disappointed with the result.

If we're not careful with this and the current tred continues, I hope they will start introducing browser plugins for ignoring media queries soon.

conclusion

Responsive design is a grave responsibility. You are deciding how and how much of your site a user will see in his current context. It's the first time a designer has to decide on a set of different contexts, where before we just had to deal with the limitations of our tools. This adds a lot of new responsibilities to the task of designing a website and if you get it wrong it can effectively ruin the whole experience of an otherwise good site.

Technically media queries are still very limited and even though the concept of responsive design holds a lot of potential, I'm sure it's way too early to tag it as the new industry standard. For now it works quite well when the use cases lay far apart and are easily distinguishable, but whenever people try to show off more complex stuff the concept falters and the result is nothing more than an impressive tech demo massacring an otherwise decent site.

what changed since last time

A lot has been written about the article element already, but many of these posts are based on an older definition of the html5 article. The definition received a small (yet important) update not too along ago, making it at least a little more relevant for everyday use. Here's the definition I quoted last time (and which can be found in most articles google turns up when searching for html5 article info):

If you check the w3c or whatwg site now though, you'll come across the current version:

The big difference? Well, the article element went from something that is intended for syndication to in principle, syndicatable. It may sound like a minor change in phrasing, but it means that we can now use the article element for content that is not actually being syndicated, but could be (in principle). With the first definition, you'd be (at least, in theory) forced to change the html code of your site if it was suddenly decided a particular piece of code was not syndicatable anymore (as in, we'll stop the rss feed of our event data). Rather that describe content that is syndicated, the article element is now used for content that could be syndicated.

on syndication

I am somewhat bothered though by the introduction of a term like "syndication" in the html spec. Syndication is a description that is neither semantic nor structural, so it feels pretty much out of place in there. Furthermore, as a content owner and believer in the semantic web, I don't really care what part of my content is syndicatable. As long as I am properly quoted, crawlers can pass by and scrape whatever piece of content they want. They want to include my main navigation in their site? Sure, why not. Want to get my rss links? Just take 'em. Building a front-end newsletter form aggregation site? Go ahead, crawl my site and take whatever you see fit.

On top of that, I'm not planning to ask myself whether there is a possible scenario for syndication each and every time I write a div or section. I'd be going insane as most of the time I could probably come up with some obscure reason why someone would still want to syndicate that particular part of his site. Also note that the definition of syndication is broader than "it can appear in an rss feed". It's practically every situation where you as a site owner would like to offer a piece of your code to an external source.

One final (and important) remark about syndication is that it is just cited as an example in the current definition. The e.g. list is not exhaustive, meaning syndication is just one example of many. When talking about the article element people often refer to syndication (and rss feeds) though, but the real focus lies on "independently distributable or reusable".

on self-contained

Note that the current definition also holds two separate requirements for using the article element. Independently distributable or reusable is just one part of the definition, your piece of code should also be self-containing. Again your mileage may vary and people will hold different meanings to this part of the definition.

The most popular example to illustrate this vagueness is the wrapping of a blog comment in a separate article tag. While it is not uncommon to offer comments through an rss feed, the question remains whether a comment is really self-contained. Nobody doubts that a comment can exist by itself and holds all the data to properly define itself, the real question is whether it has any dependable value outside of its immediate context. Distributing a comment without any of the other comments doesn't always make sense, especially when the commenter didn't bother to quote previous comments to which he is reacting. It becomes just another random blob of text, not that much different from a simple paragraph.

Again it's a tricky issue which can probably fuel days of discussion, only leading me to believe that it's probably not all that fit for defining the proper use of the article element.

abstraction: on content types

Taking one step back, let's see if we can figure out why people felt the need to create an article element in the first place. This is just second-guessing of course, but it might help us to get a little closer to the core purpose of this new tag. Syndication probably wasn't the incentive, I think meta data/concepts like that would probably be better fit as an attribute rather than a separate tag. And for sectioning pages the spec already lists the section tag.

Straying away from edge cases and fuzzy definitions for a minute, we'll find some proper and indisputable use for the article element when marking up data like news, events, products, reviews, contacts ... and yeah, even comments. People with a little understanding of CMSes like Drupal will recognize these elements as content types. Content types are a way of describing and entering structured data, displaying that data in different views (shortlist - overview list with filters - detail) all across a site.

If you keep to this perspective, all of a sudden the use cases for the article element become a lot clearer. Content type instances are typically self-contained, make sense as syndicated content and are definitely reusable (on your own site as well as on someone else's). The only difference with the current definition is that you probably lose some obscure edge cases (like a newsletter subscription box) in the process.

conclusion

So even though using the article element for content types might exclude a couple of valid use cases when held against the standing definition, the clarity it brings makes it a lot easier to help you decide whether to use the article tag or just stick with a section/div.

That said, it somehow feels as if the content type approach lies closer to the original intentions of the article tag, which were then somehow clouded by a definition that's way too fuzzy. It could be my personal interpretation of course, but for now I'll stick to using the article element for content type instances exclusively, and suggest you do the same until the next article spec update.

improving your workflow

I used to believe that the input for html was a combination of wireframes and designs. The result was that the html phase in the development process could only start once the designs were finalized. This way of working proved to be rather inefficient though, as there weren't too many options to work parallel to other phases, dragging out the development time considerably. Further proof of this issue could be found in last year's design in your browser hype, where people were trying to merge the design and css phase.

The problem with designing in your browser is that you're basically doing not two but three things at once. You're not only developing a graphic design while writing css, you're also writing mark-up to hook your css to. Separating the priorities of these three tasks is virtually impossible, so ideally you would throw everything away when the design is finished and start the html and css work all over again. If you've ever worked on a real-world project, you already know that's not going to happen. On top of that, you're not really improving your workflow when you work like that.

And so we needed a different approach, one that would allow us to win time on the overall development cycle, but would also allow us to focus on writing quality html.

ditching the design

The solution to our problem was actually quite simple: just ditch the design and use the wireframes as your sole input document for writing html. After all, wireframes are a means of showing "what" goes "where", which happens to be a perfect match for "semantics" and "structure", the two core principles of html. Sure there are times when we have to provide extra hooks for styling, but these are the exceptions, not the norm (especially with css3 and progressive enhancement in mind).

By starting html development as soon as the wireframes were finalized, it became possible to deliver the html version of the templates at about the same time the design was finished. There was only one final check needed to see if and where extra structural elements were needed. Once those were added the html work was finished. Developers could start the implementation while we could begin work on the css and javascript tracks.

so why is it dry?

If you're not used to writing html based on wireframes alone, it can be a little daunting to start for the first time. There's little visual pay-off and there's no real sense of accomplishment. You're basically looking at black and white drawings and translating those to a mesh of tags. The most exciting thing is coming up with good class names. Not exactly rock & roll (or breakcore, if you're not living in the 60s anymore).

That said, there's a lot to be gained from adopting this way of working. For one you lose all the visual clutter that a design offers. Putting it like that may sound a little disrespectful, but even though designs have a clear functional vision, they are also meant to make things more attractive. A focus block on one page can look very different from a focus block on the next page, but at their (html) core they are the still very much the same thing, so the html should match.

Taking a design away makes it easier to see underlying structures and semantics, usually because these elements are still visualized the same in the wireframes. In the end all you have to do is make sure that a component (variant) is either defined by an extra class or by its context. The rest of the work is up to the css guy, who takes the design and matches it to the html code.

one word of warning

Make sure you are prepared to easily change a few things around when the designs are finalized. There's nothing more frustrating than having finished your html and having to add an extra structural element on each and every instance of a component throughout a set of 30+ templates. We developed an inhouse tool that allows us to write a component only once and use that across our entire set of templates, but if you're still hand-coding this might be a bit more problematic.

conclusion

Dry-htmling brings you focus. It helps you in finding the true nature of html, which is not about writing hooks for css and javascript, but about translating components and structure to a logical set of tags and classes. On the other hand, it takes some time to get used to working days on end with very little to show for it. html is not something you can easily showcase, it is not something that looks good in a browser. The key is to make sure others understand the importance of good html while at the same time trying to make it clear that it is all a back-end developer needs to get his work started.

So the next time you get a set of wireframes, rather than wait for a design you may want to start writing html right away. If you think it's boring maybe writing html really isn't your kind of thing, in the other case you might start learning a thing or two about html.

special links

Links are everywhere, which is not all that strange considering they're probably the most elementary concept of the internet. Apart from some nesting issues and some semantic debate (do they have semantic value or do they just describe behavior?), links are pretty straight-forward from a html point of view. They usually appear in navigation or larger text sections, so they need little extra mark-up.

But then there are the solitary links. They could be navigation links that don't necessarily belong to a navigation component (prev/next links, read more links, ..), they could be action links (trigger print, trigger rss, ...) or they could be contextual triggers (expand view, flyout handlers, ...). Usually such a link forms a separate entity within a larger component, so wrapping it in a container to separate it from other subcomponents feels somewhat unnecessary.

Most of these links are accompanied by an icon (or if the design is not known yet, have a high probability of being accompanied by one), so a class is usually needed to identify and style the link. For action links, some javascript is usually required too, so it's always better to have a class ready on these type of links. Better safe than sorry.

putting the class on the link

<a class="more">...</a> <a class="print">...</a> <a class="open">...</a>

So the obvious way to go is just put the class on the link. I used to work like this for a while, but found myself struggling with the css once too often. The biggest problems arise when setting a link to display:block, enlarging the click area to often undesirable dimensions, but positioning these links can be downright annoying too. If you start to float them, expect some margin/overflow crap from neighboring components.

Also, I'm not a big fan of mixing inline and block level elements on a single structural level, nor do I find the idea of putting two inline links next to each other without any kind of structural separation appealing (fe. a next and prev link). Inline content for me is something that works as a single sentence, which in this example is definitely not the case.

Ditching this approach, I tried option 2.

wrapping

<div class="more"><a>...</a></div> <div class="print"><a>...</a></div> <div class="open"><a>...</a></div>

The other option is to wrap each and every one of those links and add the class to the wrapper (illustrated in the example above). This leaves you with a little more flexibility, but once you start adding a lot of these type of links on a page the codebloat becomes obvious real fast.

I've been using this method for quite a while too, but started to feel bad about adding all the wrappers. I usually don't have too much problems with some extra html, but most of the time the wrappers are absolutely useless and really don't help to solve anything at all. They just amount to more code and are often harder to implement.

Of course you can always tailor your html to a specific design, but coming from a component/design pattern background, that's not really what I'm after here. And so I've been alternating between both options through the years, never really feeling satisfied with either option.

conclusion

What I'd love to see is some additional input, critiques, maybe even some interesting alternatives or some extra arguments to support either one of the options above. I know it's a pretty small issue that most people won't even notice either way, but it sure would be good for my own personal peace of mind to find an option that would put me at ease.

It doesn't have to be perfect, just good enough for now.

what's graceful degradation

Like most standing front-end development best practices, there's a certain level of vagueness surrounding the definition of said best practice. In this case, it's the definition of graceful that is not quantifiable, being a judgment that greatly relies on the ideologies of the person passing it. After all, grace is a very subjective quality, quite impossible to capture in a definite measure. And even if you could come up with a scoring system, other people bearing different priorities and ideologies would dismiss it as invaluable right away.

If you look at the practical bottom line though, graceful degradation adapted the meaning of something that still functions and does not look broken in older or less capable browsers. And as we are developers by nature, it also means that less effort equals more grace. It's why automated degradation (think superficial visual effects like drop shadows or rounded corners) are quite popular these days. Without any extra effort they degrade quite well in browsers not supporting these styles. Whether this degradation is actually graceful is an entirely different question.

The concept of graceful degradation is something I happily support, but the current translation makes things a little too easy for us, developers, while safely ignoring the well-being of our visitors. It has become an excuse for rapid development and sub-par global support of our website in older and less available technologies, something the original concept of graceful degradation was actually supposed to counter.

the slippery slope

The hollowing of graceful degradation started when designers began countering the notion that a design should be rendered pixel-perfect across all browsers. Early discussions were mostly purist affairs, explaining why sub-pixel font rendering and such made it inherently impossible to achieve pixel-perfect designs. While I whole-heartedly agree with that, it's a big stretch going from that to some of the degraded designs we see today.

Another obvious factor is the rise of html5 and css3, which provided us with tools to speed up our development and made it less painful to implement some of the more complex designs in modern browsers. Graceful degradation became a common counter for extended IE development as designs would not look broken in IE, just bare-bones. It gave us a quick way out, bypassing the crap IE usually gives us when working on a site. To make it even better, we were adhering to industry standards by doing so.

providing the best possible experience

These days, graceful degradation is not about providing the best possible experience anymore. It's about delivering something that is passable in older browsers so clients won't bitch about bugs and errors reported by IE6 users. It's about designing the best possible solution for the most advanced browser, and breaking it apart from there. While I do believe some people go through the trouble of investigation the client's user base first, many others don't and simply assume that what they're doing is okay for most people. Would they be forced to look at their own designs and implementations all day, they would probably change their mind quite quickly.

The result is that you're developing an optimized version for not even 50% of the web's users, while not bothering to optimize the degraded version for the rest. Sure we are now spending our time on responsive designs, but in the end it's only about 5% of our audience that will ever experience the benefits of that. What about the 50+% IE users who're looking at a bare-bones design of your site every day, or are missing implementable features that just didn't make it because it was too much trouble for you?

In contrast, a concept like progressive enhancement seems to facilitate the optimized experience for all parties much better. It starts from coming up with a solution (be it interaction design, visual design or technical implementation) for all (major) parties, and improving further on that for those who have the capabilities. It might not reach the excellence of a design exclusively made for the most modern technologies available, but it has a much better chance of providing a more pleasurable experience for people all-round.

conclusion

I'm definitely not against graceful degradation. The concept is sound and it provides us with an worthwhile technique to deliver a website that can match modern standards. But the current translation of the concept is a little too easy-going and conflicts with the initial ideas behind the best practice. As (web) developers we live in a sheltered IT world full of fast computers, Apple gear and the most recent updates of our browser, but in the end it's the site stats of a client that counts.

If your target audience consists of 90% smartphone users, go right ahead and ditch those rounded corners, drop shadows and gradients for IE. But if more than 60% is still using IE8 or lower, think why you bothered to introduce these elements into your design, consider the loss of these additions and try to figure out whether you're not just making a crap version of your design simply because you can't be bothered to provide a better experience for users that are not you.

Graceful degradation is no excuse to provide sub-optimal browsing experiences, and if by now the concept is too far gone, maybe it's time to devaluate its meaning to just degradation and start pushing progressive enhancement once again.

the need for ux design

Before the first web bubble burst, simply having a website meant you had a competitive advantage over your peers. People were happy to find your information online and that was that. Over the years this changed to the point where nowadays not having a website (or app, or whatever) puts you in a great disadvantage. It has moved the challenge from simply acquiring an online presence to building on that online presence to distinguish yourself from other competitive businesses in the online environment. Hence the rise of UX.

You need to engage people so they want to visit your website. You have to provide an online experience that puts people at ease, maybe puts them in awe or at least has them leaving your site with a feeling of general contentment. Those are the broader prospects and goals of UX, but somewhere along the way this vision slowly corrupted into something that is vaguely reminiscent of proper UX, but serves a very different need.

u and me

This all sounds very positive for the actual user, but that's not always the case. Even though a lot of effort is put into sculpting a first-class quality experience for your pleasure, it is not necessarily done for your benefit, rather for the benefit of the website/app owner. Sometimes these goals may overlap (make sure you have a happy customer and he will return), but that's more of a welcome side-effect rather than a goal in itself.

Nowadays UX knowledge is often used as a tool to manipulate users into helping the brand/owner to meet his goals. Which is fine if he succeeds, but if these subtle manipulations turn out to be less subtle then anticipated, the online image of a brand of site may actually receive a couple of serious blows. When you as a user suddenly get the feeling you're pulled into a website without any personal benefit, but only for the sake of engaging with a particular brand or site, you start to wonder whether UX isn't just a new tool for marketing minds to trick you into whatever goal they are after. And you might actually be quite close to the truth.

me, the user

Looking at myself, I usually use the web for one of three reasons (and I guess this goes for most people):

• Functionality: a site that offers me something interesting to do. Think social networks, fora, eshops, games, ...
• Information: sites that have info I need right now and want to access as quickly as possible.
• Boredom: sites that give me an opportunity to waste five or ten minutes in between more pressing matters.

And unless I'm really bored, the "experience" of visiting a site is usually some secondary or tertiary priority. If a site offers me a unique functionality then I'll put up with a lot. And if I want information, I don't care about engaging with a website, I want to know what I need to know as quickly as possible and leave just as quickly. Only when I'm bored some elaborate UX nonsense can amuse me enough to persuade me into staying the extra minute.

us, the designers/developers

One of the big(gest) problems in our industry is that we are not your everyday web user. We are often awed by innovation, creativity and/or technical excellence, but most normal users don't really care about that. They want to reach the information or functionalities they are looking for as quickly as possible. People usually don't want to engage with a particular site or brand, nor do they want to invest the time trying to figure our what your brand is all about. They want what they need quickly and they don't want to waste any precious time.

When industry people talk about cool, creative, awesome and inspiring web experiences, they are usually rather tiresome and overly complex constructions that I wouldn't prefer to face when I'm in regular user mode. We have somewhat of an incestuous relationship with the web, which is why it wouldn't hurt to take a couple steps back once in a while, thinking about what we're actually trying to achieve and how this is beneficial to the people visiting our websites.

hands-on: some examples

Here are some nice examples of UX gone wrong (or taken too far). Some sites listed here are actually award-winning sites that received praise throughout our own industry, but look at them from a user perspective and try your best not to get annoyed.

conclusion

I understand the need for companies to engage and tie customers to their brands, but I would prefer it if they could find a way to do this without wasting people's time. Just face it, most of the time you visit a website as a regular user you couldn't care less about actively engaging with the site's owners or brand. You simply want to do what you came to do as quickly as possible and leave again.

I get a little tired when I find yet another site that asks me to put in some time to "discover" them, or that tries to woe me with some elaborate analogy that bores me even before I've read two single lines of text. Seeking user engagement is cool if you have users that are willing to engage themselves in the first place, but most sites these days take that as a given and try to force-feed it into you.

Don't get me wrong, UX is an extremely valuable concept and an essential part of our job building websites. And in its core incarnation, it's actually very beneficial for the end user, if applied properly. And sure, sometimes a site itself can awe its users, but generally speaking I believe that good UX design cannot be experienced directly. It's something more subtle, something that engages users on a more primal level. Abuse is growing quickly though and we as an industry are partly to blame for that, constantly pushing forward creative and innovative sites that just aren't all that great to use.

the form attribute

Sure I've talked about forms before, but never about the real thing. I wrote a piece on tabular forms and a quick css post on styling equal height forms, but the traditional, full-length, expanded form I've tried to avoid so far. The reason is pretty straight-forward: I've never really felt at ease with the code I've been using. That's not to say that the code I will deliver in this article is absolutely perfect, but at least it shows some interesting connections to other popular web components and it serves as a solid starting point for future improvements.

learning from the mistakes of others

It's ironic how glaring mistakes can sometimes uncover core truths about particular problems. If you've been doing front-end development long enough, you might remember the days when back-end developers represented a data sheet (typical lists of label/value pairs on detail pages) as a form with the input fields set to disabled. This particular structure made their work a lot easier as they simply had to remove the disabled attributes from the input fields to put the data sheet in edit mode (creating a regular form).

While all of that sounds pretty silly nowadays, there is still something to be said for their line of reasoning. Both data sheet and form are basically the same semantic entity, a form simply being the edit mode of a data sheet. This semantic link between both elements is very real and obvious, so in all fairness this link should be equally apparent in our html code. After all, semantics and structure is what html is all about.

With that in mind, we can adequately define the challenge ahead: come up with a piece of html code that can handle the specificities of both data sheets and forms while keeping the differences to a minimum. html minimalists beware, the result might be a little too verbose to your liking, but we're not aiming for minimalism here.

cutting options

An old (but popular) way of marking up forms is by using tables. This has actually become somewhat of an accepted practice as most screen reader programs feature specific table-form modes which guides their users through the unsemantic mess. Taking into account the mark-up for data sheets though, tables are simply not a valid option here. We're not going to use tables to mark up label/value pairs, on top of that I'm not very happy with using tables for form mark-up either.

So what's the best way to mark-up label/value pairs then? Well, according to the html5 spec, the dl-dd-dt structure got a recent overhaul to encompass exactly that. It's a reasonably elegant solution for simply data sheets, but if you consider all the extras a regular form needs (user feedback, input hints/help, multiple inputs on a single row) then the drawbacks of the parentless dd-dt pairs become a real pain in the ass. The structure simply doesn't allow us enough flexibility for styling, nor does it provides us with the means of building a logical html structure. Just another reason why I have my reservations about the proposed structure of definition lists.

So all that is left is to build our own data sheet/form structure using divs and some proper classes. Let's give it a shot.

basic setup

<section class="dataSheet (editable)"> (<form id="formID" action="#" method="#">) <header> (heading/form feedback/required indication) </header> <div class="main"> (label/value pairs) </div> <footer> (crud links/options/submit) </footer> (</form>) </section>

What we have here is a very typical (and generic) component setup. The optional .editable class serves as the form mode toggle, apart from that we use a simple base class for our data sheet component. Note that the form tags are added only in .editable mode. If you're a real purist you could argue that the header shouldn't be wrapped inside the form tag (as it should not hold any input elements), but that would take us a little too far. I left the header inside the form tags as it puts it on the same structural level as the main and footer containers, which feels more natural to me.

The header and footer elements are not always necessary, but they come in pretty handy to separate the label/value pairs from action-related components and/or meta data. The header can be used for headings, form feedback (form error overview or general help) and the classic required indicator explanation. The footer can be used for submit buttons and cancel links in form mode, or for the typical crud options in data mode. And if the design/css doesn't permit it, the crud options can always be added to the header instead.

It's a generic setup I use for many components that have unpredictable and varying degrees of complexity. It's nothing much out of the ordinary so far.

label/value groups

<section class="fieldset"> <h1> ... </h1> </section> <fieldset> <legend> ... </legend> </fieldset>

As you can see, the tags change according to their context, but the structure remains the same. For ease of styling you can add an extra wrapper div following the legend/h1 which can be used for better cross-browser padding/margin control (fieldsets are notoriously hard to style). Similarly, you can nest a span inside the legend tag for some cross-browser pos:abs magic, but those are all cosmetic changes and have little to do with semantics and/or structure.

This part is of course optional, if your data sheet/form doesn't have any subdivisions then you won't need fieldsets or extra sectioning elements. To make the implementation easier you can also opt to drop the fieldset syntax and always use the sections, that way no extra work is needed when switching between data and edit mode.

wimpy html concessions

<div class="row"> ... <div class="feedback (error) (confirmation)">...</div> </div>

The html bit above is something I would rather avoid using, but sadly it's a necessary bit of code if you want to build a little flexibility in your form design. I add it to ease the process of fitting multiple label/value pairs (think first/last name or city/postal code) on one single line. Its semantic value is rather vague (sometimes the pairs are linked, sometimes it's just a matter of saving space), but there's still a practical side to web design that has to be taken into account. It's also the easiest way to provide immediate input feedback, which happens on row-level and not on pair-level. I know this is not ideal, but fitting multiple pairs on one line and providing pair-specific feedback is virtually impossible in most setups.

label/value pairs - finally!

<div class="spec (inputtype)"> <div class="label">(<label for="id">)...(</label>)</div> <div class="value">...</div> </div>

And so we finally reach the code for our label/value pairs. Notice the seemingly obsolete div.label element, which is used to allow extra hint/help information to go together with the label. You could of course nest the extra info inside the label element, but that way it is always included for screen readers, which can be a bit much at times. At least this way you have the choice, only adding it where needed.

Within the div.value you can either add the actual data or the input controls + all the extra typical form tidbits (calendar overlays and help flyouts) that go with the input element.

conclusion

Putting all that together, you get a pretty mean piece of html code. From a semantical and structural point of view it's a rock-solid, flexible and reusable code setup, but I'm aware that it brings some overhead and it's rather verbose. If minimalism is your html ideal, this is definitely not for you.

The cool thing though is that it provides a very generic solution to capture the semantics and structure of data sheets and forms with a minimum of impact on the actual code. Not only is it easy to implement, it also makes a lot of sense from a semantical point of view. In its easiest setup the only things that change are the extension class on the root elements, the addition of form tags, the extra label tag and the input elements. To make it a bit more specific there's some extra work to convert fieldsets, but that's about all there is.

Not only will developers be grateful (unless they're using auto-generated CMS form code), it actually makes a lot of semantic sense to work like this. This kind of abstraction always leads to a little overhead, but it's a price I'm willing to pay.

table rows

The requested design wasn't anything special really. It was a simple product list where each product was presented as a horizontal block. Whether this warrants a table structure or not is a discussion I'll try to avoid here, the thing is that the html was already there (and implemented), so everything had to be done using css only. When I first saw the design I figured it wouldn't be too hard to separate the tr elements from each other, but once I tried to implement it cross-browser I lost a lot of time trying out different options. None of them wielded good results.

The design exercise was made a little harder by two extra conditions. First of all it should be possible to add a drop-shadow to each product box, secondly the list should be able to exist on a gradient background. These conditions don't show up on the design above, but the site was set up to be themable to a certain degree, so we had to take those possibilities into account.

Using borders to fake the effect was not really an option, considering the uncertain background color and browser support for older versions of IE. Faking the gap using background-images on the td elements inside was equally unsuccessful, as you ended up screwing the inner td borders. The only way to do this was to create an actual gap between the tr elements. For that we usually define a margin, but margins don't work on tr elements.

A short how-to

table {border-collapse:separate; border-spacing:0 10px;}

The clean way to do this is by using border-spacing. Apparently there are a few subtle nuances between the border-spacing and margin properties, but broadly speaking they create a very similar effect. It's important to note that the border-spacing only kicks in when defining a border-collapse:separate though, so don't forget to do that first.

The line above creates a vertical gap of 10px between the cells, without creating any horizontal gaps (0px). The inner td borders need a little fiddling with (:last-child to the rescue), but the line above pretty much does the trick. Sadly IE8- support is crap. You can add a position:relative; on the td elements for less crappy rendering, but that's about as far as you'll get. Not good enough.

As a side note, you might have noticed that you need to set the border-spacing property to 0 10px, where a margin would be set as 10px 0 to created vertical padding. Heh.

table, tr, td {display:block;} tr {margin:10px 0;}

A dirtier, but ultimately more browser-proof way of doing this is by removing all table-specific display modes from the table elements. Just set everything to block and you can start using your margins on the tr element.

That's fine for creating the needed space between the product blocks, but creating an equal height effect for the td elements becomes a whole lot more difficult than it should be. So while this method is fine by itself, you're probably setting yourself up for some pretty messy css when you start styling the inner elements of the product block.

what this is really about

I understand that display:table-row and display:block are two different display modes. But in the end they both result in a single rectangle form that would (and should) interpret properties like margin just the same. If a tr can handle a drop-shadow, why can't it make a simple margin work (and/or why does it need a specific property that's far more obscure than margin and uses a reverse shorthand?).

There are historical reasons (border-spacing was created to replace the cellspacing attribute on a table), but in the end I still get the feeling that sometimes html and css are a little over-engineered and too focused on backwards compatibility. In the end all these restrictions amount to very little. They might seem logical at first, but five years down the road people still run into use cases where certain restrictions are simply blocking the way to easy development.

conclusion

I must say that things are definitely improving (remember how they lifted restrictions on the footer element), but it would still be nice to see a more self-aware shift in mentality.

I'm all for best practices, but restrictions built into html and css that try to enforce these best practices often turn out to be counter-productive. Blocking margins from tr elements is one of those, ruling out the use of divs in headings is just another random example. At some point these restrictions might've seemed like a good idea, but the web is vast and infinite and there is just no way of foreseeing all use cases. Especially not those five years into the future.

To style the simple design above, I spent way too much time cursing at the restrictions of css, without knowing why they were even there. It's not like I was trying to do something extremely creepy or cutting edge, I just needed a little space between the tr elements in a table.

the form attribute

<form id="form1"></form> <input form="form1"/> As is often the case, the spec explains what the new attribute represents and how it should be implemented, but it fails to give real insights into why it was introduced in the first place. After all, why would you want to put an input element outside the form element it belongs to? As someone who values structural logic, it sounds like a very weird use case to begin with.

I asked the whatwg for an explanation and I must admit they did come up with a pretty good example. As you will already know, html has a couple of fixed tag-structures that cannot be broken or interrupted. There's ul>li, fieldset>legend and table>tbody>tr>td. In most cases this won't present much of a problem as the structure consists of only two elements, allowing you for example to wrap a form inside a li-element if needed.

But structures like table>..>td and dl>dd+dt won't allow you to do such a thing. You cannot provide a form that spans the contents of an entire tr, nor can you provide one that does the same for a dd+dt couple. This is where the form attribute comes in handy, as you can simply put a form in a td (I guess the one that holds the submit button) and link the inputs in other tds to that particular form.

It would've been a lot easier to take the xhtml2 route (remember the proposition to introduce the href attribute on all elements - a similar idea could be raised for forms), sadly backward compatibility restraints prohibit such changes in the html5 spec.

reservations

My main reservation is that this proposition breaks the logical structure of html. In 99% of all cases it is possible to identify one logical (semantical) unit with one single html element (+ combination of classes or whatever extra-semantical method you like using). Very few exceptions exist, and the only one I know of (dd+dt) doesn't exactly enjoy my approval either. But even that example exists only within the confines of its parent dl element.

Now, it's not the first time an html element is allowed to detach itself from the structure it logically belongs to, but it is the first one to actually require this. Other similar pairs (like label-input and img-map) can also be linked through attributes and ids, but a responsible htmler will still make sure that his code remains structurally sound. The form attribute was conceived to counter such sound structures and to allow people to break through these typical structural html limitations. My gut feeling tell me this is not a good thing.

Another big issue is support for screen reader users. Until their software supports these extra form specifications, they will have no clue whatsoever that they missed some form fields in the process of filling in the data. But it's not only screen readers that will suffer, regular users too might be confused what form fields they are actually submitting, as the front-end might be wired completely different that the design suggests. This is of course already possible with css and javascript today, but those technologies do throw up an extra barrier. The form attribute is not a direct attack on accessibility and usability of course, but it does make it easier to break such best practices.

Finally, I'm a little afraid of how easy it will be to abuse this attribute. Similar to the remark above, it's already possible to position a "receive newsletter" checkbox outside the designed form and still have it submitted, but it still requires some dirty work to make it all work. The form attribute actually invites such behavior and makes it just a little too simple for malicious marketeers to fuck around with us.

nested forms

One final advantage of this new attribute is that it will be a lot easier to avoid problems with nested forms, as you can play around with the actual input fields and just link them to their respective form elements using the form attribute. Then again, I would've just preferred native support for nested forms instead of this somewhat hacky and undeniably dirty solution.

conclusion

The form attribute improves on one interesting use case, but it doesn't exactly fix anything that was impossible to accomplish in the past. At the same time, it opens a few doors I'd rather see kept shut. Structural validity and structural logic are two important aspects of writing quality html code, and if a property like this leads to a slippery slope situation than we'll end up with code hell real quick.

I might opt to use it for its intended purpose, namely to generate tr-spanning forms, but aside from that single use case I hope it's not a property that will become widely spread. If people not familiar with the ins and outs of writing html come across a property like this (ie back-end devs writing html code), I predict the end of the world, full apocalypse with lots of fire and blazing horsemen included.

the design axiom

Graphical design is a complex balance of functional and aesthetic requirements that compliment each other to create both a distinctive and pleasant experience. For a graphical web designer, these requirements are often a real burden on their creative freedom, so creativity comes from multi-dimensional rule-bending and playing around with smaller details. After all, from a functional point of view a button should always look like a button and when you're designing for a specific client you need to stick to a strict graphical styleguide, so you can't do much there to really distinguish yourself.

That's why you'll see that many design trends in web design are often focused on smaller visual cues. Just think of rounded corners, vertical stripes, obvious transparency effects, text-shadows, flaps and whatnot. These are all design-hypes of the recent past that defined modern (generic) site designs, up until the point where everyone was using them and designers were forced to find something new to play around with. If you're looking at the near future, expect subtle animations, uneven drop shadows, triangles and similar elements to pop up all around the web.

So recently I was faced with two interesting design challenges in the small freelance project I mentioned earlier. Simple visual tidbits on paper, but once I sat down to put them into practice it quickly became obvious that even with the current css3 propositions it would be quite a challenge to get them to work. Here's what I was supposed to do:

1. 1. make a transparent search box in a full-width header that has a background color. Underneath the header is a (moving) background image which should shine through the transparent part of the search box.
2. 2. create a box with a transparent background which uses the color multiply effect from Photoshop. Again the box lies on a moving background image.

The first challenge is tricky because you can't cut holes in a background, especially not if this needs to be done by a deeper-lying (dom-wise) element (the search box positioned within the header). The second challenge is simply impossible to do in css, though some tricky canvas wizardry might help you out there.

css left in the dust

One key problem is that css development is currently aimed at fixing existing shortcomings. We look at design elements that are hard to accomplish with our current css standards and we try to find solutions to fix those shortcomings. But once these solutions exist, there is only a very short period of time where we can happily use them to make our job easier. At the same time, these very elements are become stale and boring at a frighteningly fast rate.

That's the exact moment when designers set out to find new elements to distinguish themselves from their peers, starting the whole cycle anew. Mind you, it's not that we suddenly lost the need for rounded corners and drop shadows, but these elements simply degraded from actual eye-catchers to common design elements. So even if css design could almost immediately match designer's demands, it still wouldn't fix our problem. It's even impossible to try and outsmart designers by adding new graphical options they haven't been using so far, as the bottom line is always the same: once a design trend picks up, designers will look elsewhere for inspiration and the trend will pass just as quick as it surfaced.

conclusion

The web is here to stay and browser competition is more alive than ever. A couple of years ago development was slow, but these times seem to be officially over. In the coming years we'll see many design hypes as sites and companies will invest more energy in trying to distinguish themselves from the competition. css standards will face the impossible task to keep up with these trends and css developers will still need to enter hacky territory to create that one visual effect that others will find hard or even impossible to accomplish. Until the code is broken of course, and a new design trend is needed.

The bottom line for the front-end developer is clear. Even though the css spec will keep expanding, designers will continue to come up with elements to challenge the reigning design standards, to set their designs apart from the competition. And the harder something is to accomplish, the more exclusive a design will be. It's an interesting realization that offers both job security and a lifelong career of stress and challenge. Hopefully you are ready to face that challenge.

Gone are the days I believed that css development would be made easier by new, upcoming standards. The only thing that changes is the base standard of web designs, which will continue to grow more complex and challenging. It's actually a rather comforting realization, but one that is necessary to keep yourself from getting disappointed by the work people are putting into the css-X spec. They do a great job though, even when they are constantly two or three steps behind the demand.

what and why?

That's what the spec has to say about the data- attribute. Basically it's an attribute (a label/value pair) that holds data which doesn't belong in the html as a text node. This data is not intended for users, it's there to aid scripts in their tasks. Following the "data-" prefix is a string that can be freely chosen (within the boundaries of regular xml constraints), allowing multiple data- attributes with different suffixes to be placed on one single html element.

Before the data- attribute was introduced to the spec we had to be creative when script-only data was needed in our html code. We abused hidden input fields, we hid html elements from view with css, we even used title attributes to stuff our script data and the really adventurous amongst us just made up their own attributes, extending the dtd if validation was a requirement. None of these methods were perfect, some were just plain hacks or failed to work in all circumstances. An standard alternative was needed and so the data- attribute was born.

Use cases

The above explanation has been quite theoretical so far, so let's find some real-life use cases for our attribute. These past months I've been able to distinguish three main use cases where the data- attribute proved to be an invaluable tool. As an example, let's take a run of the mill web shop and see where our data- attribute comes in handy:

internal vs external

If you check the spec again, you will also notice that the data- attribute is only meant for data that is to be used by internal scripts, meaning scripts you have specifically developed to work on the website you're building. A strange limitation that begged for further explanation, but none was given in the spec itself. My first guess was that they included this to prevent abuse of the data- attribute (seo keyword stuffing that would be picked up by search engines) but that felt like a big price to pay for something that cannot be stopped either way.

So I went to the whatwg (irc ftw!) and asked around for more concrete information. It turns out that it's not really an issue of abuse, but of possible conflict. Since there is no governing entity and everyone can freely decide the name of the attribute, collisions might occur. Google might be using data-contentid for one thing, while Amazon might be using the same attribute for something else.

Fair enough, but that doesn't solve our problem when we need to provide extra data for external scripts. I pushed the whatwg for alternatives and even though their first options were all less than satisfactory (using microformats - meaning you still need to add your data as text nodes - or using the itemid property - meaning you're limited to only one property), there is one way to work around the scope limitations of the data- attribute:

<div itemtype="..."> <meta itemprop="productid" content="025652156" /> </div>

Apparently there's an edge case where meta elements can be used outside of the head of a html document. When combined with an itemprop attribute they serve the same purpose as data- attributes, but for data targeted at external scripts. This was the first I ever heard of it, but all in all it's a decent solution that fits the whole microdata implementation worked out in html5.

The only problem of course is that this is way more complex than introducing some or other data- attribute to hold your data, as you need external documentation for your microdata semantics and structure. Figuring this out as a front-end developer is hard enough, getting your back-end developers on board is a completely different challenge. I fear that the cost of microdata is just too high too make this a very workable solution, especially when nothing is holding you back to just use a data- attribute. And if you choose your attribute name wisely (what's the chance of data-amazonproductid ever appearing on some site not intended for amazon?) there shouldn't be much of a problem.

conclusion

Apart from the internal vs external discussion, the data- attribute is ready for use (and has been for quite a while now) and proves a very handy way to conceal script data from agents and users alike. It's an valuable addition to help you clean up your html, remove unnecessary text nodes and hidden inputs where they aren't needed, even helping out in cleaning up your javascript files to make them more robust and less data dependent. Just remember that you might still need some hidden input elements, especially if form-submit fallback is required.

As for the microdata alternative (external scripts), I'm still not too sure. I'd be inclined to ignore it for the time being, hoping that we'll once again face a "pave the cow path" situation in future releases of the html spec.

the setup

A few weeks ago the people of Smashing Magazine launched a pretty interesting question through their Twitter account. They asked themselves (and all their followers) how the skills of a good front-end developer could(/should) best be tested. While the answer to this question seems mostly relevant to team leaders and HR people, the core of the question is something that should speak to every professional front-end developer out there: "What makes a front-end developer a good professional".

It prompted me to write an article on hiring front-end developers, but at the same time I was pretty interested to read what others would consider important qualifications for becoming a good front-end developer. So for the first time in my life I clicked on a Twitter hash tag (just for reference, I'm using Tweet Deck to manage everything Twitter related), quite anxious to dive into this hidden layer of Twitter's social communication platform.

For those of you who don't know the Smashing Magazine Twitter, it's pretty much set up like a direct feed of interesting links on web development. Because of that it garnered a pretty extensive base of followers. Current numbers are flirting with the 400.000 mark, so when they present a question on Twitter it reaches 400.000 people without any form of further social intervention. That's a lot of possible replies, right?

the numbers

I did my reply count a couple of days later, by then not many new replies where added to the list. Since it was the first time I was trying out filtering on hash tags, I really had no idea what the multitude of replies would be, but even then I couldn't have imagined how poor the actual results looked. From a potential audience of roughly 400.000 people, came ... 50 replies.

That's a 0.00125% reply rate, meaning only 1 in 8000 people took the time to write a (133 characters maximum) reply. Now of course not all followers are probably active accounts and Smashing Magazine has a pretty strong focus on design, which probably eliminates a percentage of people who aren't all that interested in front-end, but no matter how you look at it, 1 in 8000 is a pretty sad statistic.

On the upside, speaking in absolute numbers, 50 reactions is still a pretty solid result. But let's not get too excited yet. 20 entries in that list of 50 are mere retweets. I don't know why a program like Tweet Deck doesn't filter these as retweets merely functions as information noise when scrolling through the list of replies, but a good 40% of what you're getting is just other people asking the same question again. An important part of the social Twitter structure no doubt, but not at all interesting to someone like me, who's looking for actual answers. So without those 20 retweets, we still have 30 actual replies left.

on comedy, feminism and other nonsense

This being the web and all, everyone can say and post whatever he wants. There isn't much in the way of moderation possible on Twitter either (at least, as far as I know), so those 30 replies are not necessarily all on-topic. Of course it's the same with comments, though those are a lot easier to moderate. So what did I find among these 30 replies?

Well, we all know the web is full of comedians, and so I found some nonsense on Star Wars and IE6 not worth reading, totaling 4 tweets. Apparently there are also a few active feminists watching the Smashing Magazine Twitter, as there appeared to be some consternation on the usage of the word "he", which obviously needed a swift intervention. Together with retweeting and some sucking up to these remarks, it totaled 5 tweets. One random tweet just listed the hash tag, so that one could be scrapped from our list too. This leaves us with 20 factual replies to the posed question.

It's a tad risky to discuss the quality of the contents of these replies as everyone has his own ideas on front-end development, but I for one don't believe that implementing front-end code in any kind of CMS is part of the basic front-end skill set. If you're looking for people who can do that, you're probably not looking for hardcore front-ender developers but a cross-over profile who's versed in both back-end and front-end development. So to be fair, let's just keep it at 20 replies in total (one of which was my own though).

the bottom line

The stone-cold bottom line: 1 in 20.000 people actually found the time to write an actual reply to the question. That's 20x133 characters, mostly comprised of straight keywords lacking any form of decent argumentation. Only 1 tweet contained a link to a blog post that actually went a bit deeper than listing things like "writing clean code" and "make him do a practical test without internet connection".

Maybe the Smashing Magazine Twitter is a bad representation of the web development community living on Twitter, but considering all the limitations the Twitter format presents to holding a decent discussion (the 140 character limit, hardly enough to fit in a full sentence) and the poor quality output of such a huge community, I'm hardly convinced that Twitter is the right place for us to talk about our work.

I do believe it's the perfect place to share links (though not in any shortened form) and to post funny/thoughtful oneliners, but beyond that it remains a rather poor communication platform. If you take the above figures into consideration, I believe it's hard to contest that conclusion. If I'm missing something though, don't tweet it to me, just list it in the comment section.

so what is front-end development?

This might be a silly thing to say, but first you should fully understand what a front-end guy does. Us front-end people, we limit ourselves to writing html, css and javascript. Flash is already borderline, but asking us to incorporate html code in a CMS system is not really part of our job description, so don't be offended if we give you a funny look. It's a skill that many of us have mastered though, but if you truly expect this from your future employee, it's probably best to list it as one of the main requirements right away.

And if you are specifically looking for a profile to incorporate front-end code in CMSes, make sure to find someone with a good feel for both front- and back-end coding. While many front-end developers have some experience with dropping their code in WordPress or Drupal, it's best to find someone who's had sufficient experience in both areas and willing to focus on this particular skill.

size matters

Not the size of your front-end developer mind, but the size of your own company. Before you start looking for people, consider what kind of profile you need for your company. There's a big difference between looking for a lone developer (who can tackle everything from html to javascript on small projects) compared to a team player (who can focus on one or two aspects of front-end, working on large-scale projects). If you're not interested in building a team of skilled front-end people, you should be looking for overall skills and the ability to balance quality across all three major aspects of front-end development.

If on the other hand you plan on building a team of experts, you should look for people who don't mind specializing a little. As a front-end developer you should definitely know the basics of all three fields, but it's not necessary to be able to execute all three. I for one don't feel very comfortable working on javascript-heavy projects, but I know the basics of good javascript code, being perfectly able to write html and css to go with the javascript. At the least, you should be able to find people who can recognize the quality of the code written in all three areas.

Finally, if you need to assign a team of 3 developers to 3 different projects, it's better to split responsibilities (html, css and javascript) and assign them as a team to all 3 projects, rather than giving them each a project and letting them do all html, css and javascript for a single project.

brainwash vs brainwar

Then there is the question of hiring a junior or senior profile. Both have their advantages and disadvantages and depending on your reason for hiring the outcome of your decision will be different.

Junior profiles are perfect if you are fortifying your team for the future. These profiles are easy to brainwash with your company's guidelines on quality coding and even though they are hardly billable at first, they will adapt quickly to the needs of your company. Junior profiles are best hired before the storm, when there is time to learn them about the tricks of the trade, not overwhelming them with stress and performance pressure. They will learn about that when their skills are sufficiently developed.

Senior profiles are perfect if you need quality output fast, without too much hassle. Sudden bursts in html and css work might require you to hire someone that knows what to do with a minimal amount of briefing and follow-ups. On the flipside, know that his ideals and preferred method of working might clash with your own quality standards. It's good to challenge your own standards once in a while, but make sure that you don't create schisms in your team and that you have one single person who has the power to decide when conflicts don't get resolved.

quality

It's hard to define the quality of someone's work, because we as an industry lack an extensive set of best practices. That's why you could probably use an internal document that lists your company's requirements for quality front-end code. If you don't have that, look for someone who has strong ideals and knows to defend them so he can make you such a document. Whatever the actual quality of your internal guidelines and whatever the critique from outsiders, just make sure you'll be able to stand behind your own ideals.

Also make sure to differentiate between html, css and javascript in this document, regulating just about anything you can regulate. This is easy when new guys join the company, ensuring standardized quality output that can easily be transferred to other developers.

do skills matter?

Well, yeah, of course skills matter, but know that most skills in our trade can be learned through experience. There is not much that cannot be learned through extensive reading and years of coding. You'd do better to look for certain characteristics in a person as this indicates how he can and probably will develop himself to become better at his job. Some of the more important characteristics are:

• Find someone with a clear opinion. Front-end work is quite messy, so if you hire someone who picks up ideas without critical reflection this will be reflected in the overall quality of his work.
• Find someone who writes clean code. This can also be taught through experience, but only to a certain degree. Make sure your front-end guy can stick to his own guidelines.
• Find someone who is willing to live by the general ideals of front-end development. HTML is not hard to learn, but it's much more difficult to understand. Find someone who is willing to invest the time to understand his job.
• Find someone who doesn't like to give up. Cutting corners is very easy in our profession because both clients and visitors will find it difficult to judge the actual quality job you've done, but providing sub-optimal work will no doubt have its revenge later on.
• Find someone who is dependent on his own skills. Don't believe people who'll tell you frameworks can solve everything.

there are no black, female nerds, right?

Finally, you're not hiring a demographic, you're hiring people. As long as they fit the profile, race, gender or any other personal, differentiating characteristic doesn't matter one single bit.

conclusion

If you want a front-end developer, start by deciding what kind of profile you're looking for. There are many people out there, with broad skills ranging from design to information architecture and html, but also front-end developers who like to specialize in a limited set of skills. One is not necessarily better than the other, but depending on the needs of your company it's good to know what kind of profile will fit your position best.

As for skills, examinations and questions are only profitable if you need someone good, fast. If you're looking for a long-term engagement, focus your attention on other things. And if all else fails, just depend on your gut feeling.

focus is key

When I started in the web business I simply "made websites". People gave me a design and I made them a working, fully functional website. ASP development, html and css, javascript, SQL queries, you name it. One thing I learned through all that is that when you have to do all these tasks yourself, it's hard not to compromise on quality. I often adapted back-end code to make the implementation of front-end code easier (and the other way around), but working like that doesn't really help the quality of the overall project. If you do everything by yourself, it's just a lot easier to cut corners without anyone noticing.

Working in a team proposes a different dynamic. First of all you have an obligation to the people who come before you, doing a good job of translating their work into your own deliverables. At the same time, there's an obligation to the people that follow you, making sure they are given proper deliverables to work with. To do that you need focus, doing the best job you can within the field that is assigned to you.

When I started at my current employer my focus was html, css and a little javascript (front-end work in general), which was already quite narrow at the time. But that focus shifted even further over the years, to just plain html work. It's not that I don't write css anymore, but that part of my job is slowly fading and it's being assigned to other people now.

becoming the html dude

There are various reasons and explanations for this change in focus, but ultimately it feels like a very natural shift that comes forth of our growing industry rather than from my own growth.

First of all, writing html and css were more related to each other five years ago. Today we can depend on the power of css3 to do a lot of the dirty work for us, but back then writing html was 50% semantic and structural work and 50% getting your code ready for the css. That is slowly changing nowadays, so we can spend more time on semantic and structural relevance in our code. Taking into account styling limitations is becoming less and less of a problem these days.

Another thing that influenced my job a lot these past months is the arrival of html5. New challenges presented themselves, allowing us to write richer html code, but at the same time making the html job a bit more difficult. Fiddling with sections, articles and only 1 heading level took up quite a lot of my time, which could not be spend on getting the hang of the latest css3 evolutions.

A third thing that changed a lot for me was the development of an inhouse tool to automatically construct static web templates. Rather than making static html pages and spending half of my time copying html from page 1 to page 30, I can now focus on writing a single component once, making it flexible enough to incorporate all instances and variations of this component on a whole set of templates. This part in particular will have a big influence on my job in the future as you really learn to write rock-solid, flexible and expandable html code.

siding with the wireframe guys

If you write static html, consistency is a tricky thing to uphold. It's just too easy to copy a particular piece of code and to make slight adaptations to it, according to the needs of the wireframe you're following. But experience taught me that many of these little inconsistencies are just there by accident, the result of actively working on a big set of wireframes and momentarily losing sight of the bigger picture, or simply by failing to see the connection between certain components on a page or site.

Working with instances of master html components brings these little inconsistencies to the surface, taking the job of the html-guy much closer to the people drawing up the wireframes. So while my "old" job started after the visual designs were finalized and continued from there on as "front-end development" (including html, css and javascript), I can now start work from a preliminary set of wireframes, do my html stuff and start consistency discussions a lot quicker.

The way I see it, html and css will keep growing apart from each other in the future. Which is only natural because the html work that needs to be done is more closely related to the job of wireframing a site anyway, while the css work ties in with the visual design part of building a website. This rupture between html and css will probably mean that people doing html and css at the same time will either be forced to take sides, or to jump ship halfway through a project.

conclusion

For smaller projects nothing much will change in the near future I guess, but more and more sizable companies are willing to invest in tailored html-frameworks to role out on all their sites. This goes beyond looking at a few wireframes and writing html for that, but it will become an essential part of our job to deliver solid, flexible and future-proof html components that can be used in a range of circumstances, most of them not defined beforehand.

This is a very interesting challenge that makes the song we've been singing these last 10 years very tangible and real indeed. If html is all about semantics and structure, then it a single component could and should be only defined once, to be used across multiple sites and projects.

rise of the framework

Over the past years we've seen many frameworks spring to life. Just a few years ago we had one or two javascript frameworks to choose from, now we can also find frameworks for our html and css work. We can even go deeper and download boilerplates to build our own framework, going completely Inception on our everyday job.

Frameworks are usually built for one of two main reasons. Either the job has become too complex and time consuming to learn by heart, or there's a repetition of successive tasks that needs to be executed a lot. Being a professional web developer means you're using the framework for the second reason, saving yourself time to spend on more pressing issues. Sadly though the reason I stated first is one of the prime successes of the frameworks out there today, leaving many people clueless about the finer points of the job.

This ties in with what I explained in my previous post. Back in the days writing html used to be quite simple. You didn't have too many elements to choose from, writing an h1 instead of p class="title" was considered excellent coding and even though people were working hard on the next-gen html, nothing much ever changed. The need for a html5 boilerplate indicates that writing html these days is a bit more complex than it used to be, and so frameworks are created to help people overcome these complexities.

the beast within

I've voiced my concerns about frameworks before and I still believe these concerns are relevant, probably even more so, today. Frameworks can be extremely useful to get started with a language you aren't familiar with, hiding most of its nasty bits, but at the same time they will limit your knowledge and creativity.

Using the jQuery example once again, it's perfectly fine to use this fine library for avoiding the cumbersome task of querying elements on a page. The dom selector engine in jQuery is a real time saver. But even then, actually knowing how to do this cross-browser with regular javascript is definitely necessary is you want to sell yourself as a javascript expert. Once you start fiddling with jQuery UI components though, you're entering the territory of quick and dirty coding. From what I've seen from these components, the html code is crap and most components are far from accessible.

The bigger the task you are trying to capture in your framework, the bigger the chance you will yield sub-optimal results. And if you only know to work with a certain language through a framework, your output as a developer will never rise above the strengths (but more importantly, weaknesses) of said framework. You'll be confined by the limitations of what your framework can do for you, trying to solve problems with the limiting tools you have (or can find online) rather than going for the best possible solution.

conclusion

Frameworks offer many out of the box solutions, but most of the time these solutions are of moderate quality (trying to put it mildly). I have never seen a CMS out there that generates decent html by itself, I haven't seen too many javascript UI components that generate something I would put in my code without a definite sense of shame. Of course most of these out of the box solutions look quite okay when viewed in the browser itself, and if that's the level of quality you're aiming for then that's fine I guess, but I would hope that most modern web developers have higher standards.

Use frameworks when it saves you time on repetitive tasks or when you really lack the resources to get a pro for the job, just don't fall into the trap of relying on frameworks without knowing what it is actually doing in the background. You'll lose the ability to properly judge its output, which will directly reflect the quality of the job you're doing. It may be true that it's easier than ever to built a site all by yourself using frameworks, but the quality of the site will be reflected in this approach and in the end there will only be one person accountable for that.

levels of accessibility

Last week I read an article on html source order by Roger Johansson. I usually tend to agree with the articles he writes, but this particular one seemed to take accessibility concerns just a little too far. The article argues that the source order of a html page should match the visual order of element rather than follow a logical structural flow. The reason: accessibility concerns.

Don't get me wrong, it's good to see articles on accessibility these days (just this morning I found a comprehensive article on modals, completely lacking any kind of accessibility best practices and concerns), but accessibility is still just one of the many things we web developers have to take into account. It's important that our sites and applications are accessible for as many users as possible (I say users as it is broader than just people, it also includes crawlers etc), but it's virtually impossible to give everyone out there the best experience possible.

The difference between both opinions lies with the level of accessibility. It's not that either option will render the information inaccessible to anyone or anything out there, the question is who's given the most priority and who do we want to service best?

the tightrope dance

In the end it's all about balance. Compare what you gain with what you lose and make a decision based on that information. Now looking at Roger's arguments I can't say they are convincing enough to make me change my mind. It's not that I contest the things he says, but confusion between sighted and visually challenged users looking at the same screen seems like a very minor use case indeed. Confusion about focus order is a stronger point as this affects a bigger group of people (everyone using the keyboard to navigate), but as long as we're talking huge blocks of content (and not a single link that's positioned in a completely different area) I don't think this should be a real issue either.

On the other side of the fence lies structural validity (ie, is the order of elements in the source code logical). A popular use case here is sub navigation (usually found in a left sidebar, next to the main content of a page). Sub navigation is only relevant if the content on the current page is insufficient. To know whether the content is insufficient you have to read it first, so the sub navigation should be placed after the main content in the source. For visual users this is a little different, as they can scan really fast to judge whether to continue reading the main content (based on amount or structure) or to check the sub navigation for further drill-down. People relying on screen readers and other assistive tools don't have that luxury though.

We tend to read from left to right, so if you want to match source order to visual order the sub navigation should actually be placed in front of the main content. Now if you ask me, I prefer structural validity to raising the accessibility for a very limited amount of people, but maybe that's just because I put a lot of effort in creating structurally valid html.

conclusion

Accessibility has an important place in our job and currently it's being grossly overlooked. On the other hand, it's just on of the many factors that influence the judgments we make. In the end it's all about balance. Divide all arguments in two distinctive groups and weigh these groups against each other. Personal preference will always have an influence on the outcome as we still lack hard figures to back our arguments (how important is structural relevance compared to the group of visual/screen reader duos? Any numbers?), and maybe that's where experience will help you to make better calls. Just realize that definite answers are really hard to find.

To get back to my original question (how to raise awareness for accessibility once again), I believe its crucial for accessibility concerns to remain level-headed and useful, instead of going head-on against the current trend of neglecting them. We can grind hours about the finer points of accessibility, but for now there are more important issues at hand. Make people think about accessibility when they reach for the canvas element, turn it into an argument for choosing javascript frameworks or incorporate it into the newly emerging best practices. If we turn accessibility into a purist matter now, we will probably alienate people even more of this simple concept, digging our own grave. Just my two cents.

first of all: context

I'm sure this article will not be a very pleasant read for some of you. It's not my intention to offend certain people or firms, but I do believe that what follows needs to be said. Also, it's not that I don't respect the work being done by people out there in the field. On the contrary, I know for a fact the work and hours some of you are investing in your job as front-end developer are far beyond my own capacity. But sometimes reality is unpleasant and yet it needs to be dealt with. So much for the disclaimer.

In less than 20 years time our profession changed a lot. Not only on a technical level, I'm talking more about workflow and social context here. When we first started to build websites we had to battle the amateur site builder, nephews, relatives and friends who could build you a site for half the price professionals charged. At that time these people were necessary for our job to evolve. Everyone wanted a website and there simply wasn't enough professional capacity out there to fulfill that need. But once the web started growing up these same amateurs became a threat to our job. They simply couldn't guarantee the quality that was needed for the web to evolve as a business-minded ecosystem.

A similar shift is coming up once again. For years the middle regions of the web have been ruled by one-man show developers. People who were capable of handling a single project from start (initial meeting with clients) to finish (sometimes this meant front-end only, sometimes it even included back-end). These people really helped the web to grow and to attain a respectable level of maturity, but nowadays you can feel how they will be limiting further growth in the near future. Not because they aren't capable or they aren't putting in enough effort in their job, but simply because the complexity of building a site is rising exponentially.

from conception to front-end delivery

Taking a site from initial conception to a finished (front-end) delivery is still quite possible if you're talking about a website composed of 6 to 10 pages. Simple custom development set up in Wordpress or any other simple CMS is still somewhat doable. But even that is changing, with needs of customers that keep on growing. If you want a quality site these days, you need to think about taxonomy, wireframing, usability, accessibility, semantic and structurally correct html, css and browser compatibility, javascript and frameworks, design (functional and creative), performance, mobile solutions, cms or other autmated systems, copywriting etc etc. And that's just the technical side.

It is possible to do this all by yourself, but it becomes more and more difficult to do a good job in all these fields separately. Keeping track of all knowledge in even one of these fields is pretty much a daytime job, so the more you want to do and the broader you want to develop yourself, the more you'll have to compromise on quality. If you want to distribute these tasks over a team of people, you only need to take into account extra project management.

One-man show developers these days are a bit like those one-man orchestras. I respect them mostly because what they do is technically very difficult indeed, playing multiple instruments at the same time. But I usually don't respect them for the end product, which is never as good as a well-guided and well-educated team of specialists would have accomplished. This is not so much a critique as it is a simple observation, but it's important to realize this.

the way forward

If we want to respond to the ever-more demanding clients, we'll need to start doing things a little different. Solutions coming from people doing one-man show development are actually pointing in the right direction, but will fail if they are executed by one and the same person. Wireframing and designing in html is okay, but not when done by the same person. The subtleties and knowledge for each job is just too much for one single person to handle, and it will only continue to get harder. So there is a definite need for new best practices and better platforms to accommodate the different profiles working together, something that is still strangely lacking today.

As a html-guy I've noticed important changes in my day to day job too. A lot of what I used to do was copy/paste work from one template to another, from one site to another. These days I'm more focused on writing a specific html component once and referencing that component wherever I need it. It allows for maximum consistency, ease of adaptation and a minimum of errors. I can't really go in-depth here, but the steps we are taking to make our job easier are profound and will have a serious impact on the way I work on a daily basis.

conclusion

While many people are looking for ways to combine all the work they do into a simpler workflow, they are fighting for a lost cause. It's time to split responsibilities, specialize (without over-specialization) and see how each member of the team can cooperate as efficiently as possible, reducing the amount of work and overhead.

If you're still trying to do everything yourself, know that in a few years time you'll probably become a liability within your own community, holding others down and delivering sub-optimal websites that won't convince your clients of the full potential our web holds. It's a tough truth alright, but it's right around the corner and waiting to happen.

the inner workings of a browser

Usually you hear people talking about browsers when there are rendering inconsistencies, javascript incompatibilities or features lacking. We love to complain about the tools that output our work, but we do so on a very basic level. We throw input at our browsers, we look at the output and start to grumble when something is not coming out well. That's alright I guess, but if we just keep it at that we'll never really learn to use the browser to our advantage.

In most other professions people are thought about the tools they work with. You can't fly a plane unless you know a couple of things about physics, math and electronics. The more complex the tool, the more important it is to understand it at a core level. That's not to say a front-end developer should understand the finer delicacies of rendering an entire page in every single browser out there, but some general knowledge will definitely come in handy. This broader understanding would form a perfect base for tackling problems, making connections and becoming generally better at what it is we do.

Currently most people know bits and pieces, based on information they just happened to encounter when they felt adventurous enough to actually sit down and read up. Or when they met a particular problem that needed fixing, forcing them to dig deeper into the inner workings of the browser. This is all fine of course, but hardly conform with the future-proof spirit I like to apply in my work. I prefer to prepare for problems when they arise, or try anticipating them so they won't even occur in the first place.

knocking on some doors

If you start looking around for information on browser activities when rendering/redrawing/leaving a page you'll come up with very little. Most of the information is related to specific problems, more often than not we get little more than tepid conclusions based on black box tests. So I took the time to do some extra research on how a browser performs his primary job, starting at the source. I opened up my IRC client and entered the Opera, FF and webkit chats for a little talk with the people who actually work on these browsers. The results were pretty interesting.

The bottom line though is pretty simple: the documentation I was after simply doesn't exist, at least not in any structured form. I asked for books, schemes, online or offline documents, but got nothing substantial from any of the channels. The webkit guys remained awfully quiet (though they seemed pretty busy discussing some bugs), the Opera guys told me they'd rather not reveal too much about their engine, the FF crew informed me that the browser core changes too much to maintain any kind of up to date document. They did say they were available for more direct and concrete questions, which was rather nice of them.

So even if you go through all the trouble to get some idea of how the browser handles our web pages, there isn't much info out there that will help you. Either browser developers don't like to share the exact details, or they simply don't have the resources to keep updated information. That in itself is an interesting find, one which is once again telling for the state of our profession.

meager findings

Along the way I did find an odd resource here and there, so I'm just going to share what I've got so far. It's pretty random and not very focused, but at least it's something:

• FF engine scheme (1999)
• Steve Sounders on script execution (black box testing)
• Google guy digs into webkit
• webpagetest.org: live results of page loads and timing

conclusion

Knowing what exactly happens when you leave or enter a page is crucial if you want to spent time on optimizing web pages or when you happen to encounter timing issues. Sadly this information is not readily available today, nor did I find a source that gathers all the bits and pieces and puts it in one single location.

Finally I'd like to thank the people I bothered with my annoying questions for their time and help, they must've picked up my disbelieve/surprise but they were still nice enough to explain their situation. If I missed some vital resources or you guys have any more links to share, please do so in the comments. The more information I can get my hands on, the better.

nesting selectors

I'll start with the easiest part. I've tried to use the nesting pattern a couple of times, but quickly reached the conclusion that it's just not for me. That said, I don't think it's really worth much discussion as I believe it firmly belongs in the category of personal preference. Depending on your preferred formatting style (1 property/line) I can see how this could be useful to some, but I found it greatly reduced readability when writing 1 full selector/line css.

Additionally, the class names I use are pretty much fixed, even across projects, so the chance that I'll be changing them afterwards is incredibly slim. Even then, A simple double click and a couple of quick copy/pastes are hardly worth the mess it creates. I guess I just miss my visualized dom tree. To each his own.

css variables

While css variables are an interesting concept their actual use is quite limited. Most of the variables I used were targeted at widths (column width, site width, floated blocks) which had to be repeated over multiple selectors. A good example of this is the grid structure I've been using (padding on parent, width and negative margin on column). It's easier to play around with the widths of the columns if you only need to adapt one value. This ties is perfectly with my ideal to eliminate as many duplicate and related values as possible, leaving less room for errors.

I also tried to list my base colors as css variables but found it counter-productive in the long run. It's actually quicker to color-pick a certain color than it is to scroll up to look for the correct variable. Sure, using variables would prove efficient if you had to change the specific color for a certain class of object while not affecting other objects with the same color applied to them, but as I'm not a designer myself (I work with psd deliverables) these calls are impossible to make for me, so this benefit is entirely lost. I also doubt if most designer could actually make that call.

I'm still looking for a nice way to format the variables according to their scope. I identified three basic types of variables: the ones that work across the whole css, the ones that work across a selection of components (like the column width of grids) and the ones that remain within the scope of one component. Coming up with a clean way to separate them from regular css is a little difficult though.

mixins

Mixins can prove to be very useful. Their capability to capture all instances of browser-specific css (border-radius) and feed them the correct parameters is quite lovely indeed. Furthermore, classes like .hidden (position:absolute; left:-999em; top:auto;) are now much easier to apply to random elements, also eliminating the need to add them to the html itself. It does save you quite some time.

Also interesting is the option to capture certain styling combinations that form a design element used on multiple objects that don't have any semantic middle ground (meaning they don't have common classes that can be used for styling). Particular box layouts or two different renderings of headings (font-family, text-transform, font-weight, ...) can now be easily captured in one class to use throughout your css when necessary.

There's still the danger of taking mixins too far, but I haven't felt that urge yet myself.

functions and operations

Probably the most powerful addition of less, but also the most dangerous one. There are some interesting cases where operations can be used (float:left - margin-left setup where the left margins equals the width of the float + the width of the gutter), but I've seen more cases where possible abuse lies right behind the corner.

I've found very few use cases for css operations because I'm used to writing css with as few width declarations as possible. I use margins and paddings where possible and rely on block behavior for elements to fill in the available width. Nothing new you say, but when confronted with other people's css you might be surprised how a left padding on the parent is often substituted for a (width - padding) + float right on the child. Giving people access to an option like this is only going to make that worse, ultimately resulting in overstated and messy css rather than letting the css do all the hard work for you.

So while definitely useful for the experienced csser, I'm afraid what will happen to those just starting out with css. I believe they'll feel more at ease using some simple math instead of figuring out how to fix it using proper css, which is definitely not the way to go.

overall conclusion

I didn't have any difficulties finding the benefits of an extra layer like less, but the gain is actually quite small. Many of its use cases should already be covered by writing decent html and css, only a few edge cases will benefit from using a extra layer like less. On the other hand, it requires minimal effort to include the less layer, so while the gain might be minimal, the effort to work with less isn't all that big either.

My main reservation remains though. I'm pretty sure all the current functionality in less (safe the css nesting, which relies on personal preference) is useful for the seasoned csser, but I also believe it's harmful for those who are just starting out using css. When used wisely it's a powerful addition to your tool set, but it still has the power to turn your css into a complete mess.

For now I'll keep on using the less layer, if only to see what else there is to uncover. If anyone could point me to a quality resource of best practice though, that would be greatly appreciated.

front-end quality

I'm pretty happy I joined the front-end ranks when things were still relatively calm. Sure, not much was happening in terms of technical innovation, but back then (I know I sound old) you had the time to read up on best practices and people were still actively discussing how to improve the general quality of our work. Since then our job has splintered into many different, smaller movements, all of which advance at different speeds and seem to hold to a different set of rules and ideologies.

Nowadays it's difficult to find articles that openly list pros and cons of what they are trying to preach. Blogging on web development is often about selling your idea, hoping nobody will notice the pitfalls and lapses. Some of these ideas go right against solid best practices we've helped to establish years ago, without even showing the guts to counter these ideologies directly. Especially when it comes to increasing site performance people seem to throw away all they know and go against the most basic rules we try to work by. The more vocal and charging your tone of voice, the more chance you have at succeeding. Earlier this year I already warned you about these types of articles, hopefully a live use case might prove more effective.

To illustrate my argument I'll refer to an article written a couple of weeks ago, preaching css efficiency. It's a short, smart and humorous little piece that has the power to convert many, but fails to back its claims with anything substantial.

faster is better

Knowledge is power, so when people write a detailed article about the processes behind interpreting and rendering css I can only applaud such efforts. But then others run off with that information and use it to sell their own ideas. See, they ask you if you would like to have your pages render faster. They tell you that your style of writing css is wrong and slows things down. Why not be cutting edge and improve the user experience by writing fast and efficient css, right? Right?

Nobody will doubt the fact that efficiency is good and should always be taken into account when considering multiple options. That said, it's definitely not the only factor and more often than not there is a price to pay. This is definitely the case when it comes to css selector efficiency. The idea here is to limit the elements within a selector as much as possible and to use the fastest type selectors possible (ids are faster than classes are faster than generic html elements). But no thought at all is spent on code readability, no one cares about future adaptability, no attention is paid to the actual gain of these optimizations.

Believe it or not, but some people don't even question the proposal to just add some extra classes to our html as to make certain css selectors even more efficient. And I'm not even worrying about html efficiency here, I just always figured the whole idea behind html(5) and css3 was to have better separation of style and content. I didn't know we were going to be adding classes to our html so our css would render faster when the time finally came to start using these new technologies.

catch phrases

Ideas like these are often sold on deceptive catch phrases. Faster rendering is better is what sells this particular idea, and by itself this is indeed a valid assumption. But once put into a broader context, listing all the downsides and the middle fingers to solid best practices, you should start wondering if it's really worth the gain.

You might even start to wonder what the actual performance gain is. How many milliseconds of rendering time are we winning by massacring our css files (and possibly our html too)? How much time is spent on rendering css when showing a page, and how is this theoretical gain perceived by the user? It's not because the actual rendering is a tad faster that it will be perceived as faster by the one browsing the page.

Such reservations are completely left to the people reading the article though. If you fail to notice these pitfalls (which is not all that strange if you're just starting out as a front-end developer) your trust is seriously tested by those who try to sell their idea to you.

conclusion

In the end you gain very little by posting articles like the one mentioned above. Sure you can try to form a troop of loyal followers who stand behind your own beliefs, but in the end this takes us just farther away from forming a solid set of best practices people can actually depend on, creating yet another schism within our small little front-end world.

And hey, maybe the author of the article is actually right. The gain might be substantial enough to warrant these optimizations, obliterating all the arguments against this way of working. Then again, if this is the case, you could wonder why he just didn't take the time to properly list all the pros and cons and to come to this conclusion together with his readers, rather than make fun of those who have their reservations.

My conclusion: screw efficient css, I'll rather write solid, readable and easily adaptable css code instead. And unless someone shows me some solid data that end users are effectively harmed by this, I'm not prone to changing my mind. Ridicule or not.

animation on the web

The introduction of Flash on the web caused a pretty big shock. It was a tool specifically built around animation, allowing web developers everywhere to go haywire with this new-found power. The result (as always when new techs arise on the web) was quite horrendous. Ridiculously long loading times, CPU killing websites and zero accessibility. It was obvious that there had to be better ways to provide animation on our little internet.

So we expanded our reach to javascript (and later css). And surely, soon enough people started to create whole javascript libraries offering various nifty little animation effects to use at will. Yay for web standards and all that, we love to battle corporate solutions and take matters in our own hands, coming up with solutions that use free and open languages. Sadly no-one seemed to be interested in the big loser of this particular success story: animation itself.

javascript vs css

Javascript animation has been around for some time now, since a year or two browser vendors and rendering engines have started experimenting with animation in css. Nothing very stable yet, all proprietary stuff that fails to work in any serious cross-browser way, but it's a start alright. Good stuff for the inner geek in us, but where is css animation supposed to be positioning itself compared to the other animation alternatives? It bothers me that css animation is often thought off as a simple alternative for javascript animation, which should not be the case at all.

I could be wrong of course, but I've always thought we were striving for a web development model where content, style and functionality remain as separated as possible. For animation this means that we should differentiate between graphical animation (just some nifty styling effects that don't have any functional merit) and functional animation (content is shown or hidden using expand/collapse, flip boards, state changes...). For graphical animation css is fine (graceful degradation comes naturally too if you plan it well), but functional animation should remain written in javascript. Chances are though that people will pick a solution depending on their own strengths (I'm better at javascript or I'm better at css), rather than picking the appropriate technique for the job.

I guess it would be nice to see some insightful discussion about this topic rather than run into the next browser-dependent showcase of badly animated nonsense. Just a couple of years ago there wasn't moving much in css and html land, but at least people were still interested in best practices.

fluidity and continuity

What bothers me more though is the decline in animation standards. Flash animation was pretty much okay for websites. It was too limited for animated films and such, but stretching, morphing and translating is all done pretty fluidly. It comes at a rather high cost of CPU power, but that's the trade-off you're up against when choosing to incorporate animation. Now, fluidity isn't going to be my biggest concern here. For example, I'm a big lover of claymation, a form of animation that's rather stilted by default, so that's not really the point.

What does matter though is continuity and that's where both javascript and css animation fall flat. Both languages aim for a best-effort implementation, often (pretty much always) resulting in performance spikes completely ruining the intended animation effect. Animations can start of fluid, turn choppy and end up being fluid again. The slower/CPU intensive your computer, the worse it gets. Of course it runs quite great on our beta versions of the next-gen browser when all other programs have shut down, but most people don't get nothing close to the intended effect and so the reason to include animation in the first place becomes moot.

conclusion

Maybe it's because I'm quite fond of animation as an artform, but I guess there's a little more to it than that. Many sites add animation to show off technical skills, but fail to awe with their actual animating skills. Recently people have been talking about the new beercamp site, to me this is the best example that if you can't do something right, it's better to not do it at all. The project is offensive to anyone with even the slightest grasp of the subtleties of animation, turning the whole site into one incoherent, laughable mess. And it's even worse in fall-back mode (but who uses Firefox these days huh).

Javascript and css will never quite succeed at providing quality animation if they keep clinging to best-effort performances. So far I've seen very few examples of animation on the web that work, outside the boundaries of Flash that is. Most developers don't seem to be bothered by this. Animation is equal to going from a to b, no matter how fluid or continuous the resulting animation is. The fact that it moves is all the thrill needed, while the standards of web animation have dropped far below zero as a result. A real shame if you ask me.

css variables, mixins and nestings

For the full specifics and syntax proposals I'm simply going to refer to an article written by Johan Brook. He does a pretty good job of laying down the basics in a very organized and easy to understand manner. To me is article is not about syntax proposals or providing reference material, it's about coming to a conclusion whether to adopt these changes or whether to refute them.

In short, css variables will substitute a single css property value for a variable name. Changing the value (on top of the css file seems like a logical place) will change the values everywhere this variable is used. It sounds quite fancy, but in most cases it's nothing a well-aimed "replace all" couldn't fix. Mixins are a little fancier, bundling a set of css properties which can be used for further reference throughout the stylesheet. Powerful stuff, but potentially quite messy. As for nesting, they are all about reducing selector length and ease of adaptation when a class name is changed in the html code.

While these three techniques are not inherently connected to each other, they seem to be grouped together as one single proposition, so for the time being I'll handle them as such.

css ideals

Just like html, css was conceived to be a simple language. A pick up and play kind of tool that would be promoted to reach a broad audience. The web was meant for everyone and so css should be a language that anyone with a healthy interest would be able to pick up quite rapidly. If you look at the everyday difficulties you're experiencing with css this might provoke some cynical laughter, but know that most of your troubles are due to browser incompatibilities, not because of the spec itself.

Also, just like html, css is meant to be as backwards compatible as possible. We cannot break the web when we introduce new properties and property values, and if we do we should at least have workable fall-backs available. This can be quite infuriating at times, no doubt, but it's a core principle we can't simply ignore. Even if it would make our job a whole lot easier, we'll just have to cope with these basics as they are for the greater good.

Both principles seem to suggest that css variables (and company) aren't really the way forward, question is how relevant these principles still are today. As for the backwards compatibility I'm sure it's safe to say we better not touch that, but is it really feasible to keep css as simple as possible? I wonder.

simplicity and professionalim

Making css a simple, easy to use language was once a very smart and crucial choice. In the early days people coming from all different kinds of backgrounds could put their stuff online, authoring the design of their site themselves. It really gave the web the boost in needed, with amateurs everywhere publishing and posting their knowledge online. We've come a long way since then though and the web has changed a great deal.

Simplicity also brought many freeloaders and slackers to our profession. Since css isn't very hard to pick and everyone and his dog needed a site to represent themselves online, it was easy to call yourself a web developer and get started right away, asking terrifying sums of money for abominable jobs. It's the reason why the current web is in such a lamentable state, void of usable semantics, inflexible as hell and continuously falling apart when new browsers come along.

Where the introduction of css variables will lead us is hard to predict. Either people with insufficient skills will drop out and we can grow as a profession, or we'll just mess up the web even more. Without a set of well-considered best practices the addition of css variables will lead us to an almost mythical mess. Problem is that like most front-end related problems, there is not one single solution and nobody ever seems to agree on one single best practice (think css notations, use of paddings vs margins etc etc). So we'll just make things harder on ourselves.

other brainbits

I can see some good use for the mixins myself, though at the same time there are many situations where they will prove inefficient rather than beneficial. If you change the original declaration halfway through a project it will be pretty difficult to predict the consequences on the existing css. It will become even worse when using mixins within mixins. And what if for some reason only half the current selectors using a specific mixin need to be adapted.

The same goes for variables. What if you've assigned a blue color value to the variable main-blue, but somewhere in the next phase of the project this color needs be changed to red instead? Do you change the variable name too, or do you make sure that your variable names don't reference their styles. A valid option, but this will definitely put a strain on readability of your own code.

As for nestings, I just don't find this type of css very readable. Maybe it's nice for people writing css property/line css, but I prefer to see my dom tree represented in my css files. Something that a good css editor should be able to fix no doubt, but I can see this kind of css notation turning into a horrible mess within mere minutes of development.

conclusions

I'm not really against these propositions. I believe that within the right context and used by capable people, these additions will make our css cleaner, easier to maintain and more flexible altogether. But the chance of that happening seems rather slim compared to the various ways people can fuck up a css file using variables, mixins and nestings. And considering the state our profession is in, this seems rather likely. I for one do not look forward to taking over such a project.

Maybe I should dive into LESS and SASS to work with these improvements first-hand. That said these new additions will be much harder to adopt on a global scale, compared to current css3 additions. Unless every single (popular) browser out there supports them they are virtually unusable as they will completely fail to render in current browser versions, effectively breaking entire designs of a site. I guess that gives us plenty of time to make up our minds, leading me to believe there's no real reason to stop the current development.

For now, I'll just leave you with the above remarks. No doubt more about this in the future.

the problem

The issue at hand is one that popped up on this blog before (check the heading headaches article). Rather than try and find solutions within the current context of css, let's do one better and let's go looking for the reasons behind the trouble some of us have been experiencing when margins clash with em-designs.

The main issue here is that margins (set in ems) on a box are influenced by the font-size defined on that same box. This becomes very annoying when you're playing around with headings and the left and rights margins of the heading box keep changing every time you adapt the font-size of this heading. What you (usually) want is to create a nice vertical grid, but when you need to pull out your calculator to recalculate the correct margin values time after time it becomes tiresome really fast, not even talking about browser-specific pixel value roundings.

Even though the issue itself is slowly dying (because most people stopped making em-designs), I believe the inner workings of the problem are still very much worth checking out.

the box model

The main culprit causing us all this trouble is the css box model. The box model describes the spatial properties that define a css box, including widths, heights, borders, paddings and last but not least, margins. If you see it explained it looks perfectly sane, seemingly providing us with a good model for defining the dimensions of a box and its position based on its context.

To make things as easy as possible, all em-values on the box will be calculated based on the font-size defined on that same box. So if I choose to increase the font-size, widths, paddings and margins will change accordingly. It's an easy rule to remember, but one that does not necessarily match our own mental model of how a box should behave.

real life boxes

So where does the css box model differ from real life boxes then? The answer is simple: a real life box is defined by its borders (sides, walls, whatever). For example, we consider a cardboard box the box itself and everything that is contained within the box. As far as boxes are concerned, you're either outside or inside and everything that's outside the box is not part of you, nor do you care what happens with it. Outside is simply not your responsibility.

The concept of margins doesn't really exist in the simple life of boxes (we do have similar concepts though, like "personal space"). The space outside of the box is part of its context and should be monitored by that same context. If we translate this back to css, this would mean that margins should not be defined by the font-size set on a box itself, but by the font-size set on its context.

Considering the fact that font-sizes are inherited values, this should pose little practical problems to implement. It also fixes our problem with the change in computed margin values. On the other hand, it does complicate the rule set of the css box model, where a small exception should be made for calculating margin values defined in ems.

conclusion

Not that I'm expecting the powers that be to change the css box model, I'm sure there are way too many practical problems (breaking existing implementations) that would stop this from ever happening, but it would've been nice if they'd thought of this a little earlier. It's once again a good example of programmer logic interfering with simple human logic, resulting in easy rule sets but leading to sub-ideal practical implementations.

We could of course add yet another css property to control the behavior of the css box model (just like they did when they introduced the box-sizing property - maybe something like box-calculate), but I'm not sure if that's really worth the trouble. Sure I would be quite happy with it, but I'm not really confident many others are waiting for such a property.

Like I said at the start of this article, not many people are faced with this problem anymore as ems units are getting out of fashion, but that doesn't change the fact that the problem still exists within the core of the css box model. Just something to think about.

w3c, who are you?

In all these years I never quite figured out what or who drives the w3c. I assume it's a non-profit organization, but considering all the work they do it's not unlikely engaged participants are compensated in some way or another. Not that it matters much to me (or is even relevant to this article), but it does indicate that the w3c is no ordinary organization, harboring some mystical dimensions.

Apart from regulating the road map of the technologies we front-end people work with every single day, they also bear a more public function. They are our point of reference when people ask us about the specifics of our job. They host the specs, they round up all the accessibility guidelines, they are the ones that hold the key to all the under-appreciated subtleties of our profession.

Whatever the reason may be, the w3c has always had issues with this public responsibility. Their communicative skills seem quite underdeveloped compared to the guardians of other technologies, resulting in a sub-par website, obtuse communication channels and a general lack of convincing the outside world they know what they are doing.

For years people have told me that accessibility and quality design don't go together simply because they went to check the w3c website and were appalled with what they found there (go figure). Over the past years there have been several attempts to improve this situation, but none of those brought them to a level where we (front-end developers) could actually be proud to point other people to the w3c.

html5 video

With html5 booming they took this opportunity to somewhat overturn their public image. Looking at the site built around the new html5 logo I can only conclude it's like nothing I've ever seen from the w3c before. It's a modern, glossy attempt to construct a community feel around what should be the way of the future. I clearly say "attempt" because the result is as hollow and empty as one could fear from such an undertaking.

Not only is their continuous attempt at humor and lightness a little embarrassing, they made a few very questionable decisions along the way. One of them is to revive the use of technology badges. Their campaign page even features a badge builder (5000 - man I couldn't stop laughing) where you can customize your own badge for use on your site, project or wherever you plan on using it. Why anyone would like to go back to those days is absolutely beyond me.

Worse though is the fact they are pushing css3 as an integral part of html5, apparently Bruce Lawson's ranting hat wasn't quite effective enough. While opinions are divided about commercial parties like Google and Apple abusing the terminology, it's scary to see an organization like the w3c (who should know what they're talking about, they wrote the damn specs) take off with it. It leaves us with very little options to fight the misuse of the html5 label when even the w3c is joining in.

conclusion

How unreasonable is it to demand a certain degree of professionalism from the w3c? All I want is to point people to the w3c when they have any intentions of finding out more about html, css, javascript, accessibility or whatever other front-end related topic, without feeling embarrassed to do so or without putting those people off before they even started?

While this attempt to inject some fresh juice into the pr of the organization is laudable, I don't think it's wise to come off as the next hyped up yet hollow and meaningless technology fling. I thought html5 was supposed to be the future of our profession, not some knock-off hype constructed to feed on emptiness and buzz alone. The html5 logo campaign site looks like website designed for a party organized by boy scouts, not like a serious step in the growth of a more open, semantic and stable web. So dearest people of the w3c, you don't have to be hip and cool, nor square and old-fashioned. Just be solid, decent and quality-minded. Please?

apple and google, sitting in a tree

For some time now Google and Apple have been fighting a somewhat childish battle amongst themselves, which is slowly expanding to every sector they believe they should be dominating. When I say childish I'm talking about the behavior of both parties, because the decisions coming forth of this quarrel are for from playful and are key to determining the future of our web. Apple's rejection of Flash and Google's rejection of h.264 will shape web development in years to come.

Whatever good or bad comes of it, the fact that these decisions are made based on a silly rivalry can only hurt the web in the long run. Both parties claim to reject technologies based on lack of openness, but in the end they're just looking for personal gain, abusing web standards and open formats to reach their respective goals.

Hardly anyone cares about this because both parties have been busy building fanbases. There's Apple fans and Google fans, both sections supporting pretty much everything their "team" does. And if their favored party does something they don't like they simply jump ship and start to root for the other side. It's like an ordinary game of football, sadly there's a lot more at stake here.

html5 video

People rejoiced when html5 video became usable through modern browser support and Flash fallbacks. A win for html5, we all declared! But from the very beginning it was clear html5 video implementations were going to be hampered by codec support. Firefox and Opera weren't ready to support h.264 because of licensing issues (which still exist today), Safari isn't planning on adding WebM support (the proposed web standard supported by the rest, but closely linked to Google itself).

I've already complained about the decline of web professionalism in the past year, if you check the comments on the Chrome blog you can see how clueless those people who've mindlessly jumped on the html5 bandwagon really are. The shocked reactions at encoding every file twice are absolutely telling, while in fact they should have been doing that from the very start. It's a sad reminder that the ideology of the web is quickly abandoned in favor of laziness and monetary gain.

With this decision, Google put the ball in Apple's camp. They are currently the only ones not planning any support for the WebM video format. Apple can still pull the quality card (h.264 currently beats the WebM codec hands down) but whether that's enough to convince the standards community is still unsure at this point. It would be quite a big gamble for Apple and if it goes wrong it's sure to put a serious dent in their shiny armor.

an uncertain future

We can only speculate what this change in Google's attitude might mean for the future of the web. One thing is certain, if they mean business and stop supporting the h.264 format altogether they might even go as far to switch YouTube to WebM encoded files, leaving iOS users feeling abandoned because they can't access any videos on YouTube (only one of the biggest and most popular sites on the web). There is after all no Flash-fallback on iOS (hah, the irony).

If this move blows up in Google's face though, this might affect the hype status html5 is currently enjoying, as people could lose trust in this new html standard. After all, one of its biggest selling points is turning into a complete disaster before it is even properly introduced to the masses. And while that's one reason why we might do well to support Google's move, I'm not all that happy to support the motives behind their decision.

conclusion

The conclusion is simple: it's not even a matter of supporting or disapproving Google's plan, it's more important to recognize the dirty game both companies are playing and the effect their decisions have on our job, our community. While I'm quite happy to see the balance on the h.264 vs WebM codec tilt in favor of WebM, I'm greatly disappointed by the reactions of the community and the obvious motives for this tilt.

The coming weeks and months will shed more light on the road Google is taking with their codec support, it will also be interesting to see whether IE will jump the h.264 ship (though very very(!) unlikely). The conclusion is simple though: once again web development is being dominated by the interest of larger than life companies. Google and Apple are not afraid of showing their true colors anymore, publicly showcasing their identity of corporate monsters who abuse whatever cheap sales talk they can, only now backed up by a large portion of a community who's vowed they wouldn't let things comes this far ever again, jeopardizing everything they so bravely fought for.

the act of blogging

According to ALA's Web Survey 2009 a good 70% of all you guys out there have a blog of your own. According to that same survey a good 95% uses the web (at least to some degree) to stay up to date with the current evolutions in our job. You are probably amongst those 95%, if not you wouldn't be reading this blog in the first place. You'd think that this would put a lot of weight on the shoulders of all us bloggers out there, but the act of blogging completely eclipses this supposed responsibility. With that comes a certain danger.

Writing for the web is quite unique in the sense that the whole world is your audience. Of course not everyone will read what you write, but with a minimum of effort that part of society that has access to the web can reach your article in mere seconds. We all know this, but truly realizing this is something else entirely. If you have stats running on your site, I challenge you to take a look at your demographic and try to image actual people reading your article on their computer in Palau, Kiribati or Gabon. To be honest, before I checked I didn't even know these were actual countries.

Most of us would rather look for our answers on the web instead of flipping through a book. I am definitely one of those people, I never even looked at a book on web development before. If I need info, I turn to Google. And even though I often compare different sources to check the validity of information, I'm fully aware that information found on the web is potentially not as researched or factual as information found in a book or magazine.

Seen from a writer's perspective, if you write for paid press you can somewhat safely assume that the people reading your articles will be dedicated enough to grasp the unwritten implications behind certain techniques and theories. After all, they paid to get to the information so they mean business. But when writing for the web we can't assume anything about our potential audience. Oh sure, we all love to believe we have a hardened clan of followers that still remembers what we wrote 20 posts back, but in the end the majority of people reading our articles will be a less defined mix of amateurs, passers-by and professionals. Assuming they have sound prior knowledge to get the basics of what you're trying to tell them is simply erroneous.

taking responsibility

Recently a lot of new people have been flocking to new standards and technologies like html5 and css3. These are often people with little prior knowledge of concepts that took a long time to finally ground themselves as best practices. It's not that these newcomers are lazy or uninvolved, but if they lack the proper background knowledge they will be making all the same mistakes we made 10 years ago. Graceful degradation, accessibility, separation of content/style and function ... these are all important axioms to make the next 5 years in front-end development work.

That's why it is important to realize the responsibility we have when writing about our profession. We're not just writing for professionals or dedicated enthusiasts but also for an audience that just happened to stumble on our article by accident. These people might be picking up a lot from our articles, but without a proper context they are doomed to fail.

This is not a plea to provide a detailed explanation of each pitfall for each how-to article we write. A simple notion, link or reference to the needed information is more than sufficient to point people into the right direction. What they do with this information is up to them of course, you can't force people to read anything, but by omitting this info you're denying them the chance to catch up on essential knowledge.

conclusion

I'm the first one to admit that planning for the worst when writing an article can get a little tedious. It's a lot easier to suppose people already know all the important bits on which you can build your article. But providing proper information is key to ensuring our profession grows in the right direction. We've fought long and hard to establish the slim base of best practices currently available, it would be a shame to lose them just because there are some new flashy bits peeping around the corner.

10. how webkit loads a webpage

Sometimes you have to go deep, way deep. If you want to fix certain issues (often related to timing and performance) it becomes crucial to know what steps a browser takes to render a page. Concrete information on this topic is often quite hard to find, so when the webkit team released a quick rundown of the process it was quite helpful indeed.

How webkit loads a webpage

09. bbc coding standards

Admit it, we are all a little voyeuristic. When the BBC released their coding standards on the web I went over there immediately to see how our own standards compared. As it turned out, we're probably a bit more strict than the BBC ... which was nice. Want to know how your standards compare? Take a look.

bbc coding standards

08. css parent selectors

People have been asking for parent selectors for a very long time now. The following article explains in detail why this might not be such a good idea. While the concept itself might save us some trouble, the price we have to pay is simply too high. So whenever you feel yourself aching for the parent selector, just come back to this article and reassure yourself it's not worth the trouble.

css parent selectors

07. death to email address re-entry

Together with captchas one of the worst common practices when it comes to data entry on the web. Most people simply copy their email address anyway, so why bother people with this obnoxious extra step. A very nice read indeed.

Death to email address re-entry

06. html5 video

One of the top evolutions on the web this year was html5 video (and the related battle between Apple and Adobe). Several good players became available, most of them featuring Flash fallbacks. If you need a good overview of the strengths and weaknesses of each player, look no further.

html5 video

05. w3c tests html5 compatibility

Internet Explorer is back in the game. The past couple of years they made great leaps to catch up with the competition, now it's finally paying off. Still not quite there yet, but when the news arrived that the w3c crowned IE9 as best html5 compatible browser (at that time) a creepy silence wrapped itself around our community. Fun times.

w3c tests html5 compatibility

04. in defense of comments

One of these appears every year, but with many bloggers still disabling comments or redirecting their readers to Twitter (or related services) it remains a relevant topic. A nice writeup that argues the strengths of in-page comments. I can only support the author's vision.

In defense of comments

03. css positioning 101

Can you imagine an article on basic css positioning appearing on ALA? In 2010? Everyone has their head up high in the html5/css3 cloud and apparently there is still a need for this basic info on one of the leading web development platforms. Sadly, this is the reality we have to deal with and even though the article seems absolutely obsolete, their choice to publish it was completely justified.

css positioning 101

02. yahoo shutting down delicious

With all the hype about "the cloud" and keeping your data centralized on the net, stories like these eat away at the confidence of the end user. Apparently companies can simply pull the plug from leading internet platforms without much hassle. People who invested years in their bookmarking library can export them and find some other place to store them. Just like that. Puts your feet back on the ground, doesn't it?

yahoo shutting down delicious

01. 20 things i learned

A very interesting project illustrating all that's good and bad about the current web. It's an awesome tech demo, uncharacteristically polished for the likes of Google, but the format itself is a complete failure. Made to work on touchscreen devices, it's hell to read on a desktop and almost impossible to finish one or more pages, let alone the whole article. Bad use of real-world analogies killed this one.

20 things I learned

10. equal-height search form

Trying to get an input field and button to align horizontally in each and every browser often seems like an inhuman task. If you want to know what causes this and what can be done about it, the following article might just answer all your questions. No more search form styling headaches from now on.

equal-height search form

09. front-end quality levels

Quality is what separates amateurs from professionals. But there is more to front-end quality than just making a good-looking website in one single browser. Explore the different levels of front-end quality and you're sure to come out a better person on the other side. I'll even vouch for that.

front-end quality levels

08. inline-block vs float

We all hate floats, so when display:inline-block became widely available people flocked towards this new holy grail. But is this really such a good idea? Did we first consider the differences and similarities between both properties, and did we think about the necessary requirements to pick the appropriate property for a particular problem?

inline-block vs float

07. extended semantics

In our quest to deliver quality we sometiles overreach. Proper semantics on the web is a perfect example to demonstrate this. Microformats and html5 microdata are interesting concepts but with not even a hint of a base to start from these concepts are simply too difficult to get off the ground on a global scale. First learn to walk before you want to fly.

extended semantics

06. carousel - graceful degradation

We all know and love graceful degradation, but it is often considered to be a single-road solution to accommodate older browsers. The truth is that there are usually several possibilities when taking the graceful degradation route, each with their own advantages and disadvantages. Sadly this topic is grossly underdeveloped, the following article will start by laying down the complexities of proper graceful degradation.

carousel - graceful degradation

05. over-semantic

html5 brings us many new elements and has redefined a series of existing ones. We are eager to use all of them, but sometimes our eagerness can actually hurt semantics when we try to bend the rules to match our own needs. It's usually better to use more generic elements rather than force the meaning of specific ones. So beware!

over-semantic

04. web design patterns (for front-end)

Web design patterns have been around for a while but they have a hard time harvesting a solid fan base. This is a real shame because they really are the way forward if you want to accomplish cross-site quality. They are the ultimate in standardization and a great way to question your own work. If you haven't started using them, there is no time to lose.

web design patterns (for front-end)

03. cms skinning

A nice reminder of the responsibilities of what a cms is supposed to do and how this conflicts with our everyday reality. It's time for popular cms' to get their act together and to keep their hands clean of our html code. This is pretty much the only way to improve the front-end/back-end developer relationship as I see it.

cms skinning

02. css specificity: lacking proximity

The dangers of porting real-life concepts to human-made programming languages. Find out why css specificity doesn't always act the way we expect it to and where the exact difference lies between real-life and css specificity. Sometimes a good look at the human mind can improve the way we work and we might even learn something valuable in the meantime.

css specificity: lacking proximity

01. when one word is more meaningful than a thousand

The most comprehensive argument I've written this year, no doubt. A plea for simple, standardized and semantic html, all wrapped in one dashing article. I should also thank Smashing Magazine for the opportunity to publish it on their blog and the editing guidance they gave me. Enjoy!

when one word is more meaningful than a thousand

going to the doctor

Earlier this week the brave team of html5 doctors asked themselves (and its reader base) how to mark up the author spec of a comment. They presented their readers with 5 choices and asked for feedback. A great platform for discussion and a perfect opportunity to get acquainted with the obscurer parts of the html5 spec.

There were three basic options (add two variants to make five in total), one using the cite element, another using the address element and one final option using neither of both. The comment section of said article is a true treasury of front-end wizardry, allowing a brief yet enlightening glimpse into the minds of fellow artisans. And while I'm not in the position to claim absolute truth, nor in the position to openly criticize individual opinions, I will argue that these comments illustrate how easily rules are bent and how common sense is often discarded simply in the name of supposed semantics.

the options

I suggest reading the article + comments first before coming back to finish this write-up. I won't be repeating everything said on the html5 doctor's site and I'll be assuming you're up to date on what was being discussed over there. So let's have a quick glance at the available options then.

conclusion

In the comment section there is one opinion stating the option without extra semantic mark up is a semantically light. This is true of course, but lacking better options it still beats adding incorrect or questionable semantics. Doing this is by no means an improvement over the simple solution and should even be considered harmful to the quality of our work.

It's not because we have new elements to toy around with that we have to start bending ourselves in all different kinds of positions just to make sure we use them. When the situation calls for it and you can properly use the address or cite element, go right ahead (though I still object against the current use of address), but if there's no fitting element, just leave it at that. Maybe html6 will fix it for you later on. If not, in five years time we'll be dealing with cow paths that make little or no sense at all.

Disclaimer-wise: this is not meant as personal critique to any of the commenters, nor to the people who wrote the html5 spec. I fully realize how easy it is to get caught up in the semantic spiral. But a word of warning is definitely in place here.

give me an I, give me an E

I'm currently working on a project developed in SharePoint 2010. Apparently this version of SharePoint goes a long way in tinkering the html code, but the dynamic pieces (called webparts) are still happily spewing out table tags. Not too big a deal though, I needed the wrappers anyway since in this particular case graceful degradation was not an option. This led to the following (simplified) css setup.

table, tbody, tr, td, th {display:block;} additional testing code table, tbody, tr, td, th {padding:0.5em;}

No time to beat around the bush, IE (all of them) is one of the main fuck-ups here. The code above is supposed to turn the most common table-related tags into block elements. Following the concept of css defaults these elements should behave like any other simple block element out there. But when applying a padding (and a different background color to each element), you'll notice that both properties won't affect the tbody and tr elements. Worse still, it doesn't even set the table container to a default 100% width.

When going back to ie7 and ie6 you'll see that even the padding on the table element can't be applied. So while you might have expected that the styling of these elements comes straight from css (and should be ease to overwrite), there seem to be some exceptions left and right. Apparently table elements feature some extra fixed clauses that prevent them from acting like regular block elements, even when stated explicitly in css.

Note that position:relative declaration won't work on tbody and tr elements either (when set to display:block), so if you plan on using some absolute positioning tricks, those won't fly either.

Check out the test page for a live example

webkit saying hi

If you think it's just IE being a bitch, think again. Front-ender in crime Mathias Bynens uncovered more issues in Webkit. Apparently the background styles applied on a tr are repeated through all nested tds. The bug is already filed, you can check out the test page for a live example, the bug can be spotted in Safari/Chrome on both Windows and Mac.

Once again, this seems proof that not all visual styles of html elements are solemnly applied through css. It makes you wonder what other hacks, workarounds and shortcuts exist within these rendering engines, doesn't it?

conclusion

Opera and FireFox seem to be handling everything just fine. As for Webkit, let's hope for a quick and simple fix in the near future. The IE legacy is a much bigger problem though, and it's even more alarming that even ie9 doesn't seem to behave like one would expect. Not that I like working with tables and turning them into block elements, but when necessary I do want these things to be possible.

If anything, this is just another lesson that front-end development is never easy, not even the simple parts. Somehow, somewhere, something has to go wrong. It makes are job what it is, so all you can do is sigh, file a bug report and go on to fix the next issue on your way.

html has no style

Probably the most important key element that prevents a better understanding of the separation of style and content concept is css defaults. While these defaults are extremely useful and make our everyday job a lot more enjoyable, they eclipse a small yet important part of our job that leads to a lot of confusion for people not aware of these defaults actually kicking in.

We all know that html is not meant for styling, yet there is a big different between the behavior of a standard div, span or p element in a browser. A div will behave like a block element while a span will behave like an inline element. And a p looks a lot like a div but comes with stardard margins. So even though you might be writing simple html and haven't even started your first line of css, a minimum of styling is already applied to your html document.

Most people go on to assume that this basic styling comes from the html elements themselves. This might sound plausible at first but goes right against our base axiom that demands separation of style and content. Even then you could argue that front-end developers usually prefer breaking rules rather than following them, but in this particular case things are a little different.

css defaults

What happens is that each browser has its own default css file it applies to a html document. These default css files might map quite well between browsers but you cannot assume that each browser will render the same default styling. Hence part of the reason why most people prefer to use some kind of reset css, leveling the standard styling between all (or most) browsers.

If you check Firebug (or most other similar tools) you can see traces of these default css declarations. Just highlight a simple div and see how the browser css applies a display:block style. If you want to be a true adventurer you can even go and change these css files, though there's quite little to be gained there. This should also explain why brand new tags (html5) don't come with standard styling in a browser (if you were wondering about that).

conquer your fears

Some people seem a little scared to start tinkering with these css defaults, especially when it concerns the display property. But even the most basic css rules often changes common css defaults. Simply adapting the color of a link means overwriting the default browser css. Overwriting a display property isn't any different from that and shouldn't be considered a hack at all (which some people seem to suggest).

You might remember the little table-row/table-css hype from a little while ago. Use divs to create your own table layout. This never really took off (for various reasons, but mainly because tables have very limited positioning potential) but the essence of this little trick is still quite important. You might be using simple divs, but you're creating a table layout in css. The perfect example that styling and layout is not inherently connected to html.

You can also go the other way around. Working on some crappy project with table-layouts? Simple set the table, tbody, thead, tfoot, tr and td tags to display:block and they will behave like normal block elements. You can start floating tr elements to turn them into columns, or you can use absolute positioning to allow for more flexibility in your layout changes. And once again, remember this is not a hack, just plain and normal use of css as it was intended.

conclusion

While css defaults are a useful necessity guaranteeing the separation of content and style, you should not be afraid to change them around to better match the layout you need to create. It all starts by realizing that the basic browser styling is just some simple default css hidden away in a separate file. If you get to that point, overwriting it is just the next logical step.

html5 is the new web 2.0

We've come to a point where clients are specifically asking for html5 sites. Not because they have any clue what it is all about, but because it's a new technology and they don't want to lag behind. It's very much like the web 2.0 hype we experienced a couple of years ago. They don't care whether we're actually using html5 or any other new technology, as long as they're seeing the bling these new technologies promise they feel happy and comforted.

It's been interesting to see how this hype developed over time. First it was pushed forward by front-end developers to ease our work, later on the infamous Apple/Adobe/Google feud took a run with html5. And of course browser vendors and rendering engines are continuously bragging about cutting edge support for new features. All of this led to one single conclusion: there's a new web and you need to be part of it unless you want to feel left out.

And much like the web2.0 hype this new web needed a new hype word. That hype word became html5. What a bummer.

hollow words

Somehow html5 became an encompassing term used to hint at all these new technologies available today. It doesn't matter if we're talking about css3 effects, new javascript functionalities, actual html5 elements or even simple oldskool javascript effects to mimic all this new tech, it's all html5 in the eyes of sales people. Even the Apple team ran head-first into this wall when they launched a special section on the Apple site for showcasing their fancy "html5" demos (working in Safari only).

If you'd think the big names of our industry would rise against this semantic abomination you're mostly wrong. Many even seem to embrace this evolution as it brings a lot of positive (note: definitely not always factual) press to the development of html5. And surely, it helped to speed up the acceptance of all these new standards beyond the borders of the front-end slang. But it comes at one important cost: misuse and abuse of the semantic value of html5.

sad semantics

It's not uncommon for a single word to hold several different meanings. Some even completely different and unrelated from each other. To stay close to html, just think of the English word table. A grid-like structure to show tabular data, but at the same time it is also used to describe a piece of furniture. The thing is that depending on context it's always easy to differentiate between these different meanings. Even though such a simple word may bear different semantics, the context will usually clear up any possible confusion.

The case of html5 is not like that. There's a more incestuous relationship going on here as html5 (the spec) is actually a subset of html5 (the new web). If you take html5 and add css3, the javascript upgrades and a few recent design patterns, you get html5 once again. The biggest problem here is that context usually won't provide any resolutions either. Even amongst professionals it's often quite difficult to find out what "html5" they're actually talking about.

I really don't care what kind of hype word they use to indicate the new web, but when it starts to hinder professional conversations there's obviously something wrong with it. Furthermore, as a supporter of the division of content, style and function I really don't think it's a good idea to give newcomers such a muddled impression of the technologies used to create front-end code. Before you know it, 10 years of hard work is flushed down the drain.

conclusion

If you ask me, html5 is all about tags, structure and semantics. Not very exciting stuff to sell to the outside world, but they'll just have to deal with that and find a new buzz word to capture all the cool things. Not that my stubbornness will have any effect on the overall use of web lingo, but I would advise you to think twice the next time you're using "html5" in a conversation. Unless you're talking about the spec, it's better to use a more precise description.

Isn't it just too ironic that a language built around semantics is now being semantically abused? Hype rarely brings about something positive in the long run and I'm sure the hordes of newly converted html5 fans will end up creating a rather big mess unless they are properly introduced to the finer points of our job. And a good place to start would be by using html5 for what it was intended.

why the fuzz?

When the aside element was first introduced it raised discussions left and right. While the need for capturing "sidebar"/related-like content was clear, the exact implementation clearly wasn't.

One issue raised lived purely on a semantic level. The word "aside" is easily linked to visual positioning. It's not quite as bad as "sidebar" but it still seems to suggest the content is positioned next to the main content. After fighting for years against style-based classnames front-end developers weren't too happy to see this trend resurface in an official w3c spec.

But there were more glaring issues to tackle. It turned out the original definition of the aside element didn't even qualify as a container for typical sidebar content. It was only meant to hold content directly related to a main block of content. Usual sidebars often include contextual information related to the side as a whole, not necessarily to the content on the current page (just think latest news block on a calendar detail page or see the contact block to the right on this very page).

And so the first definition didn't actually cater to the needs and wants of the front-end developer community, making the new element only marginally interesting and possibly creating a lot of confusion along the way. Luckily the powers that be were listening and decided to make some changes to the aside element, greatly increasing the sex-appeal of this new html5 elements once again.

the current aside spec

This latest definition opens up many more possibilities but at first glance we might be losing a little specificity compared to the original definition. Upon closer inspection though, there's an elegant solution to giving extra meaning to the aside element based on it's context in the document, so no need to worry (just yet).

so everyone is happy?

Well, almost everyone. Looking at this very page you'll notice that the sidebar content includes actual related article content (the affiliate ads, the article info) but also typical sidebar content (the contact, archive and related section articles blocks). So if I wanted to follow the current spec, the first few sections should be contained by the article, the other sections should structurally be outside the article. Sadly css isn't quite ready for that yet so I'll need to find a way around that. It's more of a design issue though and nothing a better spec could solve (unless you would link content through specific attributes, but that's taking it a little too far).

conclusion

The new aside element is a gallant way to mark up related content. Whether it is directly related or just marginally is dependent on its context, so use it wisely and carefully.

Figuring out what content is related and how related it actually is will probably take some experimenting though. Hopefully we'll stay clear from previous errors (remember when everything was a list) and I'm still in doubt whether the comments on an article belong in a section, article or aside. Like most best practices though, time and testing will help in providing all the answers.

makeovers

Quite a few things changed this past year. The most glaring and obvious one is the complete visual overhaul started by some small css3 experimenting. You might even remember the short period of time dedicated to the live transformation of this blog. An interesting experiment where each component received a visual update spread across a period of a month or two, making the overhaul a lot easier to plan and execute. By now you're probably already quite used to the current design, but looking back at the very first design (png) it's hard to imagine where it all began.

The downside of the live overhaul can be found in the state of my current css files, which are a lot messier than U can accept. Together with cleaning up the css I've been working on the html code of the blog, getting it html5-ready. You won't notice too much of this change, though the blog might be a little faster to load. Hopefully it will be up and running by the time the ie6 graph remains fixed below the designated 0.5% line. So if you're still visiting this blog using ie6 (which will not be a truly pleasant experience I reckon), it's really time to upgrade now!

getting the ads right

Another important update came in the form of advertising. Not that this blog became impossible to manage without it, but toying around with ad systems itself has been a pretty interesting experience. The (small) monetary gain coming from it is a welcome plus but not a goal. Priority one remains to keep the ads as unobtrusive and valuable to the reader as possible.

By now the affiliate ads should be kicking in all over the personal blog, the coming month I will be adding ads on the work blog. These ads are not automatically generated so I can at least keep control over the quality of the ads. At the same time I can use them to link to relevant articles so I'm actually winning on both sides. Don't feel obliged to click on them though, clicks won't generate me any revenue anyway. But if you're interested in buying something, go right ahead!

social stuff

A smaller addition came in the form of a Twitter link (footer of the blog). I'm still not a big social-lover but I believe that shutting people out because of personal preferences is not always the best way to go. If people want to follow me on Twitter and abuse the network as an rss tool, why not. A slight change of mentality that might have some impact on future decisions no doubt.

The past years has also been quite interesting cross-blog like. I've written an article for a respected Dutch blog and even landed one of my articles on Smashing Magazine. The overall gain of regular visitors of such endeavors is quite small but it does get your name out there.

my plans

Besides the technical overhaul I don't have much lined up, apart from continuing what I've been doing all along: writing articles. Things are going well with a steady rise in visitors and overall visibility, so I must be doing something right. Blogging takes quite some perseverance and patience but once you're used to the rhythm of writing several articles each week it's actually not all that stressful.

So I can only hope you keep coming back to read more of what I have to say. Here's to another year of blogging!

buttons and paddings

If you ever had to develop for Internet Explorer you already know it can be a strange little beast. Still, most bugs seem to have some kind of logical background. There are a couple of issues though that seem to defy any kind of human logic and with no fix at hand will drive you mad whenever you run into them. The following issue definitely belong into this latter category.

The left and right padding inside a button (defined by an input[type="submit"] or button tag - doesn't matter) will increase in ie6 and ie7 depending on how much text is entered in the value attribute. So if you put a lot of text in your button, the left and right padding will increase without any possibility of altering this through the regular channels. In simple forms this is usually not much of an issue (except that it looks ugly), but when working with buttons in limited spaces (buy-buttons on e-shop websites) it can quickly turn your css into a true nightmare.

Now, I've always thought this issue was impossible to fix and would only die together with ie6 and ie7. Apparently a fix has been available for quite a few years now, it's almost impossible how I could've missed that considering the pain this particular bug has caused me in the past. The good news is that the fix is easy to integrate into the ie6 css fixer, so rejoice! Your input/padding problems will be fixed from now on!

the fix

I haven't bothered finding out the true source of the fix (sorry!), but Viget Inspire gives a good recap of what needs to be done to get ie6 and ie7 to comply to the standard behavior. I've been doing some testing myself and it seems the width:auto; addition isn't even needed to make the fix work. We'll be leaving it out for now as it can conflict with earlier defined statements. If it still turns out to be essential we'll update our tool as quickly as possible.

input, button {overflow:visible}

Some additional testing revealed that the overflow:visible fix has no negative effects on other input elements, which allows us to simply add this single line to the css output and have it done with. It's a lot quicker than running through the whole stylesheet and the chance of missing certain buttons (if only styled by classname for example) is down to 0. All good!

input[type="submit"], button {overflow:visible}

If you opt to receive the inline ie7 hack we even improved the syntax a little so only the submit inputs are targeted. Sadly ie6 doesn't understand this syntax so this is an ie7 solution only. And that's about it really. A simple fix, one that is actually stylesheet-independent and can even be added to a reset css or something similar. But as this fix is only relevant in ie6 and ie7 it deserves a place in our little tool.

One word of warning though. This is listed as a "safe fix", which it is if you apply it before the actual css debugging. If you add the fix on a site that's already been debugged chances are things will look quite bad (as you probably worked around the extra padding by adapting some other values for ie6/ie7 specifically). For existing sites, use at your own risk or just uncheck the option to include the fix.

Try out v0.95 now if you want to see the improvements.

conclusion

With the rework of this blog we've decided to postpone the 1.0 version just a little longer. The rework might even involve some front-end changes to the ie6 fixer tool so it would be nice to launch all of that together. And as this fix is quite small (and not even stylesheet-dependent) we've opted to raise the version only 0.05 points.

As always, we welcome feedback. Hope you enjoy the new feature!

no more h2-h5

One of the coolest changes in html5 is the way headings are handled. I complained about crappy heading handling of (x)html before, html5 brings forth a new era of headings. From now on we can (and probably should) use only one heading element (h1 - note that you can use it more than once on a page though) and leave the rest of the structuring to the html outline itself. Not minding the SEO implications for a second, this is without a doubt the best way forward from a html/css perspective.

This way of working makes it a lot easier to syndicate content (no more worries about heading hierarchies when a particular component is dropped into a different context) but puts a lot more strain on the html structure itself. You can't simply trust on nesting depth to compute the level of a heading so you need a different mechanism to construct the hierarchy outline of your document. That's where the new section and article elements come in. There are a few additional elements with sectioning powers but their scope is smaller and more tied to semantic meaning rather that structural power, so for now I'll leave them be.

article element

The article element was introduced to wrap content which still make sense on its own when syndicated. Think of a blog post, a latest news list or an event calendar. These components can be taken out of their original context and can freely exist within a different context without losing any of its meaning. Sounds clear enough, but "syndication" remains a somewhat vague indicator. Some people say that a single comment on a blog post could be wrapped in an article element (because some blogs offer rss feeds with separated blog comments), whether you agree with this line of thinking is entirely up to you.

I believe (for now) that content wrapped in an article needs to make sense all by itself. A single comment does not as it is part of a conversation or relates to the article where it was posted. Your mileage may vary though and it's still too early for best practices (not enough practice yet I guess), so it's really up to you to decide the best way to make use of the article element.

section element

According to the specs a section is meant to wrap a generic content part. If you ask me, that's a pretty generic description making it look a lot like a regular div element. But the spec goes on to state that a section will usually contain a natural heading, limiting the scope of the element considerably. It places its use rather on component level rather than molecular level.

So section elements are for wrapping a selection of content that belongs together, can be given a natural heading but does not quality as an element that can be syndicated. If that's the case you're better of using the article element. Note that article elements can be nested inside section elements and section elements can be nested inside article elements. It all depends on whether a particular block of content is viable for syndication, so no real hierarchy exists between these two elements.

document outliner

The theory is relatively easy but when actually sitting down there's a lot of pondering and weighing to do. Trying to find best practices and workable rules takes time, luckily there are a couple of tools that might help you on your way, if only a little. With the html5 spec not finished it's impossible to find anything definite but currently this html5 outliner seems to be considered one of the best ones around.

These outliner tools allow you to upload your html after which an outline of your document is returned. This makes it a lot easier to check whether your document sectioning makes any sense and what areas are up for improvement. Think of it as an automatic table of contents generator for you html document. Without it, you're pretty much left to yourself battling the somewhat cryptic and elaborate rules that currently exist for sectioning html documents.

conclusion

With the addition of the section and article elements the w3c is once again stressing the need and importance of structural relevance of html documents. In short, don't remove html elements ("wrappers") simply because they are not needed for styling or because they don't bring any semantic value to the table. Remember the structural value of html and use it to improve the quality of your online documents.

I'm sure it will take a lot of time and debate to come up with some decent best practices, but at least we're given some useful tools to get started. If all goes well I will implement the new code by the end of this year, though that might be a little bit too optimistic. I'll keep you posted.

to sync or to async?

We at the Internet Architects WebAnalytics department - WAIA in short - are serious about data and data quality. That's why we were all excited about the release of the Google Analytics Asynchronous tracking code snippet in December 2009. The benefits seemed obvious, as stated on Steve Souders' blog:

• Faster page loads and improved uptime: the script now loads without blocking the downloads of other resources.
• More data equals more accurate results as early click-aways will now be measured more accurately compared to the synchronous tracking snippet.

The first benefit seems clear: the asynchronous script call leads to ga.js being downloaded parallel to other resources - a good thing for a functional website script as the tracking code adds no new content to a page. After the script is fully downloaded the page view calls (and other GA methods) will be executed.

So how to verify whether the accuracy of data generated by the asynchronous tracking code is more accurate than the data generated by the synchronous tracking code? The answer is simple: the improved tracking code should track more page views and visits since there is less data loss due to early-click aways from pages.

Below you can find a test, set up to verify this improved data accuracy. After all, in a web analytics environment the data itself is already quite the subject of discussion, so let's try to make sure we don't pollute our messy data even more.

synchronous versus asynchronous tracking code snippet

We performed the test on this very blog. The test was implemented as follows:

• Leave the current tracking code as-is: synchronous and implemented inline before the closing body-container.
• Add the asynchronous tracking code as additional measurement (using a different UA) before the closing head-container, as prescribed by Google Analytics.
• Check results in the GA front-end.

Following the async code's raison d'être we expected the traffic data to be more or less the same, with slightly more traffic measured by the asynchronous tracking code as this version is supposed to have lesser data loss due to early click-aways. The actual results looked like this:

Synchronous: 17305 visits / 31891 pageviews
Asynchronous: 17968 visits / 30203 pageviews

Visits: more data measured with the asynchronous tracking code.
Page views: less data measured with the asynchronous tracking code.

The results for measured visits are in line with the expectations: more visits are recorded by the asynchronous tracking code snippet because early click-aways are recorded more accurately. However we didn't expect to see that more page views would be measured by the synchronous code. Following the same logic as before we would expect to see a rise in page views equal to the higher amount of visits.

So we performed a more detailed check, comparing the results on a day-per-day basis:

In the table above, a green table cell in the delta column indicates an expected result (more data measured by asynchronous code). An orange table cell indicates an unexpected result (more data measured by the synchronous code).

These results are more or less consistent with previous findings, but they still offer little in the way of explanation as we encounter plenty of fluctuations in the delta columns. We had to dig deeper, finding a way to evaluate the performance of the measurements of early click-aways of the GA async code versus the sync tracking code. The closest match was to segment on bounced visits versus not bounced visits within GA:

• Bounced visits segment: Number of page views equals 1.
• Non bounce-visits segment: GA built-in segment.

These are the results summed up in two tables.

The results are stunning:

• The asynchronous tracking code has improved measuring performance for bounced visits: almost 12% more visits measured compared to the synchronous tracking code.
• The asynchronous tracking code's results are worse for multiple page visits: 8,5% less pageviews are measured compared to the synchronous tracking code.

conclusions

The results of these tests lead us to conclude that a website might benefit from the asynchronous tracking code only if it has a high bounce rate. Then again we must consider the merits of measuring more bounced visits: we receive more accurate data on the visitors who click away early, at the same time we lose about 20% data on our other visitors, while the latter category is by far the more interesting group of visits to analyze.

So how is this possible? Why does the async code measure 8,5% less pageviews? For the moment we are assuming (and of course investigating) that there might be a difference in the way the browser handles the async versus the sync script code, causing these differences. You will hear from us again when we have more results to back these assumptions...

content management system

Most sites these days are built using external CMS systems. From small-scale projects using WordPress, middle-sized sites using Drupal to corporate monsters using Tridion. Static sites or sites using custom-made CMS systems are rare these days which is not that surprising considering the complexity of building a quality site. Most CMSes offer lots and lots of out-of-the-box functionalities that make the life of a developer a lot easier.

Content Management Systems these days do way more than simply managing content. The WMS-hype has long since gone, but in fact Web Management System is a much better description for the functions of a modern-day CMSes. These CMS systems are life savers, at the same time they are most often the biggest limiting factor within a project. While coping with all the complexities of setting up a site most CMSes lock themselves down, limiting flexibility in order to assure a working-out-of-the box experience for the layman.

And while I do understand the need for these simplistic solutions, locking out the pros to do a good job is definitely not the way to go. You won't hear me say this is an easy task to accomplish, front-end development doesn't know too many best practices and even those are often contested by different groups of people. The fact remains that if I deliver a set of static templates, your system needs to be able to implement these templates flawlessly. No questions asked.

cannot modify stuff

The truth is that most default implementations of a CMS fall short when it comes to front-end development. There's html-code vomited from the core of the system, css handling is handled in the least efficient (even faulty) manner possible and coding structures dictate how html pages are structured. If you want to know what kind of CMS people are using, it often suffices to look at the html source code. This is of course plain madness.

If you press hard enough you'll learn that most CMSes do offer the option to override html and you can often tweak the html code to perfection. Either the knowledge to do this is too limited or the CMS itself makes it too difficult to accomplish this within the confines of a project, but the result is always the same. Your meticulously developed templates are thrown overboard or they're used as a general guideline rather than a blueprint. Previous css work becomes obsolete and you'll need every trick in the book to cook up something that somewhat mimics the original design.

consumers must suffer

A website should be user-centered. And by user, I mean the people visiting your site, not the ones entering content. Your visitors interface with the front-end, meaning html, css and javascript. Messing this up is simply not an option anymore as it will visibly decrease the quality of your site. If a CMS is poor at html output you need to grow experts to bypass these problems and/or you need to budget this from the very start. Out-of-the-box solutions are good if you want to set up a quick, private initiative, but they simply won't do for corporate sites and professional projects.

Some people seem to believe front-end developers spend their days happily tweaking html and css, only to go back to Fairyland every evening to play with the magical animals and sing jolly songs while dancing in the middle of flower fields. I can assure you this is a far sniff away from reality. The fact that our work is often discarded because it's too difficult to implement into some or other automated system definitely doesn't help. I don't believe it's wise to start pointing fingers, but I hope it's clear by now that this is counter-productive and doesn't help the quality of the final product.

slowly but surely

Truth be told, CMSes are slowly changing to accommodate to the needs of the front-end developer. Drupal 7 should make a serious leap forward (when it's out of beta), SharePoint 2010 has dropped most of its tables (hell yeah!). Still, the need for skilled html skinners remains, no matter how hard it is to accomplish in the system of choice. If CMSes want to becomes WMSes they should remember that outputting html is a key feature and flexibility to change and adapt code is a priority.

If outputting custom html becomes easier developers should have little trouble implementing our work into their CMS of choice. Whether this is a definite promise remains to be seen.

output mess

Functionality has always been more important than the actual output our tool generates. In the past we've always focused on implementing new fixes rather than clean up the output code we produce. And while there is still room for improvement, this latest version optimizes the output to minimize file size and further code clean-up.

We didn't include an option to minimize the actual css code, there are plenty of tools out there already that are designed to do just that, but we tackled duplicate fixes and tried to remove them from the output. This makes the resulting file smaller and makes it easier to manually remove harmful fixes from the output code.

a peek underneath the hood

Our tool is built to fix issues in a sequential manner. First the given css is analyzed and structured, then we run through the resulting list on the look-out for statements that require a fix. This is done separately for each fix checked in the gui. Each result is then appended to the previous one to form one single fix-list.

.example {float:left; margin-left:-1px; overflow:hidden;} ie6 css fixer output .example {display:inline;} .example {position:relative; zoom:1;} .example {zoom:1;}

Consider the first line of css above. When thrown at our fixer it returns three separate fixes. The zoom:1 and display:inline might conflict when put together though, so in a fair few cases the zoom:1 needs to be removed manually after the tool is finished. In this particular case, both the overflow and negative margin result in a zoom:1 fix. To get it out of the resulting output we have to delete two separate lines in two separate locations. This is not good.

And so we improved the script a little to avoid these duplicate lines. First the more complex fixes are executed, after that we run the easier fixes and we leave out any duplicate statements. This way, if a fix proves harmful you can simply remove the selector from the output file and rest assured that the newly introduced problem will be gone. Mind though that several different selectors can still target one single html element and like most of the improvements we make it's not entirely fail-proof (and it never will be as we lack the html to verify the final css implementation).

Try out v0.9 now if you want to see what it can do for you.

conclusion?

So what does all this mean? In short, smaller output files and less trouble fixing the output when it introduces issues of its own. It's a small improvement but it might save you some grunting and it puts a little less strain on ie6, which is already slow and unstable. If there are any more ideas or suggestions for new fixes and improvements, do let us now, version 1.0 is nearing. Enjoy!

websites huh

Usually I start off by saying I "build websites". And even that seems to be a too big a challenge to grasp for some, giving me that hardened websites need to be built?-look. If these are strangers I quickly try to abandon the subject, but if they are friends or close relatives I usually insist a little longer. Before you know it you're that guy that does things with computers and you have your agenda booked with Windows installs and network setups. Believe me, I'm not that guy.

These occasions are becoming rarer though, most people these days have had some first-hand experiences with websites. And so people will likely categorize you as a programmer (back-end/cms programming) or a designer (the guy choosing the colors). If you happened to have worked on a site they like to frequent they will probably tell you about how they don't really like the color palette or they'll bring up that one time when they hit a 404 error when using the contact form. Again, if you're not too familiar with these people, better to abandon the subject right there.

If I'm in a good mood though (or just can't stand the fact I'm being blamed for something I didn't do) I'll insist just a little longer. That's when terms like front-end, browsers, rendering, accessibility and a range of other difficult words start flying across the table. I also like to add I try my best to make sites accessible to (visually) disabled people, though beware, some people don't like the fact you're making fun of them. Convincing them you're not kidding around can be quite difficult in its own right.

If all that fails, I'll resort to using analogies. Never a good sign but when one runs out of options there is little else to do.

it's just like building a house (but not quite)

Problem is, I haven't been able to nail a simple, understandable analogy yet. I usually compare building a site to building a house, but there are some obvious differences of which my line of work is probably the most glaring one. Still, it does at least help to make them understand the complexity of building a website.

The architect drawing the plans combines the functions of wireframers and designers, construction workers can be seen as the back-end people building the actual site. Writing css is like doing the actual interior decoration according to the plans of the designer. The problem is that building a house doesn't really require life-size prototyping. Writing html as a prototype for cms output is rather unique to our job and doesn't really fit the house analogy. It puts our job somewhere between the architect and the construction worker, but we don't really belong to either side.

Still, it's the closest I've come to properly explain what it is I do all day at work, so until I find something better I'll keep using this analogy.

back-end solution

If you want to make it easy on yourself you can dump all the hard work on the back-end developers. This solution requires you to do very little as the design of the carousel will remain exactly the same. The only thing that needs to be done is to provide urls to the current page with different query parameter values. Those parameters will determine which item should be shown. Advancing to the next item involves a page refresh but at least this way all the information is still available (for those who care). Do mind that things become a bit more complex when more than one carousel (or similar component) resides on a single page.

The urls will be replaced by onclick events in the javascript version so regular visitors won't notice anything. Another small pro is that you can actually link to a specific item in a carousel now. Still, this method is just not as fancy as it could be, so let's leave this option behind and keep it for those moments when time is of the essence.

front-end solutions

If you want a front-end solution know that there will be some additional design work. Instead of showing only one item you'll need to show multiple items, which is usually not possible in a regular carousel design. This doesn't mean the extra design should be anything fancy (remember you're just catering for a very small percentage of your visitors) but it should still be clean and usable.

The main html-related question here is what to do with the navigation part of the carousel. Since all the items are on one single page the navigation becomes somewhat obsolete, though there are situations where it can be made useful again.

conclusion

It could be that I've missed one or more possibilities here, if you have any suggestions do leave a comment in the comment section. I'm still not entirely sure what option I prefer myself. I like the theoretical slickness of option 3, but the implementation itself is somewhat fuzzy and dirty. Hiding away html code in the javascript will almost definitely result in problems later on and might even show some performance issues. From that point of view, option 2 is probably the most stable way to go. The navigation is in the html, if not needed you can still hide it with css (even from screen readers) and everyone will know where to look when the code needs to be adapted.

Like always, I hope these articles say just as much about methodology as they say about the actual techniques. I hope this article illustrates the varied range of graceful degradation techniques and how to approach them. There is still a huge need for defined best practices in our line of work, sadly these topics remain less sexy than the newest css3 fad (which probably only works on Chrome anyway).

a carousel you say?

I assume we all know what a carousel is, these days you find them almost everywhere (except for blogs). Still, there is quite a big difference between recognizing a pattern and properly describing one. A good way to start doing that is by establishing what it is not first, pinpointing the exact differences between a carousel its related patterns and going from there.

A very close relative of the carousel is the slideshow. A slideshow often features the same content transitions and it has almost identical navigational controls. Depending on how advanced your slideshow is, you'll have prev/next links, a set of links to show each separate entry and automatic rotation. The difference between these two patterns lies with the content itself. A slideshow is a decorative element or an element where the content (most likely images) has a logical relation to its contextual content. For example, if you're checking out hotel rooms you may find a slideshow showcasing various pictures of the interior design.

Then there are tabs. The link between tabs and carousels might not be as obvious at first, but apart from typical graphical implementations both patterns actually share a lot of common ground. Both patterns offer an economical way of offering plenty of content on a very limited space. Both patterns have similar navigational controls, though it must be noted that tabs never feature prev/next links. Also, tabs never auto-rotate. Very important differences right there. The inner content is also different. Tabs are used to section main content on a page in different logical groups and visualize them one by one.

So what does that tell us about carousels? For one, all elements within a carousel are from the same (repeatable) semantic content type. They can be traversed in either sequential or user-preferred order and serve as gateways to other sections within the site (or even content on external sites). Carousels are effectively displaying what I usually refer to as "focus blocks", promotional blocks for content you want your visitors to notice. This description differentiates the carousel from slideshows and tabs in an clear way. With that (admittedly concise) definition, we can finally go to work.

translating text to html

Now we know what a carousel really is, we can translate this information to a html pattern. You already know html is all about semantics and since we defined the carousel as a selection of focus blocks, it makes sense to see that return in our html pattern. To start of easy though, let's define the base component identifier:

<div class="carousel">...</div>

This element will identify the component as being a carousel. If you go a little deeper we notice two important elements. First there are the navigational controls, then there is the content itself. This separation should be visible in the html, which translates to the following code:

<div class="carNav">...</div> <div class="carContent">...</div>

The carousel navigation should be constructed like the other navigational elements on your site, so I won't go in further detail about that here. The content area is more interesting to explore. As I've said before, the content of a carousel is a list of focus blocks. Whether you use the actual list element is up to you (as you might have read elsewhere, everything can be a list so it's all about balance). I for one believe that a carousel is a clear summation of elements, so a ul/li construction is probably a fair option here:

<ul> <li class="focusBlock">...</li> <li class="focusBlock">...</li> ... </ul>

If you want to go html5 you could opt to use the section element for each .focusBlock, though in that case I would drop the ul/li structure altogether. Also, the article element would be quite suitable as base element for our carousel pattern. And ideally, the inner html of the focus blocks should be identical to other focus blocks on your site.

One other thing to note is that there are some variations of focus blocks that can be found in carousels. Most carousels showcase one item at at time, but if you consider related products patterns you'll see that certain variations are essentially the same as carousels. They fit the description we established above, only the content itself is a more specific form of focus block (not just any content type but a related product). This variant can easily be defined by adding a second class on the base element, if you want more direct semantics you'll also need an extra "related" class on each focus block element in your carousel.

the finished html pattern

Putting all that together, we come to the following examples. The first example is using (x)html, a list and simple focus blocks.

<div class="carousel" <div class="carNav">...</div> <div class="carContent"> <ul> <li class="focusBlock">...</li> <li class="focusBlock">...</li> ... </ul> </div> </div>

The second example uses html5 for a related items carousel:

<article class="carousel related" <div class="carNav">...</div> <div class="carContent"> <section class="focusBlock related">...</section> <section class="focusBlock related">...</section> ... </div> </article>

Further comments, additions and reservations are welcomed, some critical feedback never hurt anyone. That's what the comment section is for.

what's next?

Apart from working out the actual code, I hope this article also illustrates the process of writing semantic html and how components and design patterns play quite an important role when developing a piece of html code. There's more to it than simply slugging out some tags for a specific project in order to style and animate it.

There are so many functional and graphical carousel variations that it's hardly interesting to go through all of them, but there is one other aspect of a carousel that deserves some extra attention. Like all javascript components there is graceful degradation involved, so next time I'll be looking at different ways to handle this properly for a carousel. Stay tuned.

it's all about the moneys

To make one thing clear from the start, I don't have any cashflow problems whatsoever. Keeping this site up and running doesn't cost me anything so I don't need the extra cash to keep the domain name, pay for traffic and webspace or to the keep the servers ticking. That's all been taking care of for me. And even if I had to pay for it myself that would still be fine. So there's no need to worry, this blog isn't going down any time soon.

On the other hand, there's a pretty big mortgage that demands a serious portion of our paycheck each month and the property itself isn't exactly cheap to manage either, so a little extra money does come in handy. Small stuff like curtains, floor tiles, lights ... they're all remarkably expensive and after going through the investment to buy an apartment you can't leave it half finished. All these things added up made me look at the ad proposition from a slightly different angle.

And finally, I do spent a lot of my free time on this site. Toying around with the html and css is nice but not exactly company-sponsored, and I'm not even talking about writing two or three articles per week. Asking money for that is against my ideologies, but getting a few bucks from those who like to follow an ad seems hardly offensive.

Before continuing, let me remind you that clicking like a madman on random ads won't really help me, so please refrain from doing so. Google keeps a rather strict policy and I'd like to keep to it.

why I don't like ads

For ads to work well, people need to notice them. This means that ads will usually be placed in spots that somehow intrude on the regular browsing experience, yanking the viewer away from the content and pulling them towards the advertisements. Especially popular on blogs is to place the ads between the introduction and following paragraphs of an article. Google text ads in particular are made to blend in with the rest of the content, so you're making it harder for your visitors to focus on the content, actually trying to confuse them to click on the ad links.

I've read about how to maximize profits and most methods focus on getting your ads noticed. While this means more money, I definitely don't want the ads to demand much attention. So I took a good look at my site, trying to find spots where the ads would not intrude on the browsing experience. Pretty ironic, I know, but there are just some lines one doesn't want to cross. That's also the reason why I don't want image ads on my site. They just demand to much attention, pulling people away from the content on my page.

where to put them

When looking around on my site I found a few interesting places where the ads would not intrude too much, often filling spaces that were empty anyway. First pick was of course the IE6 Fixer tool page. As it is a little service people use to save time and work, it's not unfair to add a few small ads there. I shortened the intro text a little and put the ads right in between the intro and the tool itself. It doesn't intrude much for regular users but it's visible enough for those who want to click.

I found another empty space that could be filled in the right column of the blog overview and detail pages. The left column is usually a lot longer than the right column anyway, so filling the empty space there was no big deal. It's a shame Google doesn't offer any better-fitting banner formats (the ads are a little small for the available space), but all in all it looks pretty nice.

There are possibilities on the homepage (near the footer), but I don't really like to place ads on the first page people most likely encounter. The page grid is quite tight on the homepage, so adding them there would ruin the design. And so I left it at that, these three spots will suffice for now.

about google adsense

Google Adsense is pretty easy to use but quite limiting indeed. I understand they like to keep some control, but their banner formats aren't exactly all that easy to integrate on my blog. I don't see the harm in tweaking them a bit more than possible now.

What's worse though (and really hard to understand) is the undeniably crappy code the ads generate. Luckily it is hidden away in an iframe, but for an extremely simple component like this it is hard to grasp why they would invalidate their code and litter it with non-semantic tags (tables - really?). You're not telling me that these simple ads are impossible to create cross-platform, cross-browser with semantic code and clean css.

conclusion

Toying around with Google Ads was a pretty nice experiment in itself. As a website owner it's another fun stat to play around with, but one with monetary value behind it. The implementation is free of charge, every click (and how implausible it may sound, people do click) generates a little revenue.

I hope I've made my case clear, if you still find the ads to be intrusive or too big of a diversion, you can let me know in the comments. I'm still planning on tweaking them a little bit, but as for now I'm pretty happy with the result.

prologue: living in a small European country

Being a front-end developer, there are a few advantages to living in a small European country (in my case, Belgium). Europe is a pretty big place, housing many different nationalities, cultures and most importantly, a whole lot of different languages. In Belgium (population 10 million) alone we have three different official languages. This has a big impact on our job as most sites we build need to be multilingual by default, sometimes covering up to five languages for one single site (English and Spanish are not official languages here but are still important if you want a site to have international appeal).

Having to deal with a multilingual site is a pretty interesting experience. You usually develop a site in one single language, when its finished you check how the other languages behave in the design. This often brings about all kinds of spacing and alignment issues that won't necessarily show up on single-language sites. Even more problems and issues you may think (and you're definitely right about that), but it also helps you to build more flexible layouts and designs, foreseeing variable content for almost every component you design. Something which is useful in later design iterations and/or reworks.

There are also some obvious disadvantages to living in such a small country though. Last week I wanted to order an item from Amazon, something I needed rather quickly. There is no local Amazon store here so I had to look outside the Belgian borders. The nearest Amazon store is in Germany, sadly my German skills are pretty bad. Still, rather confident that I was comfortable with the Amazon design and flow I tried to maneuver my way through the site based on recollection and graphical input alone. To be honest, I was very disappointed with the whole experience.

doing it right

This little experience got me thinking as I compared the Amazon checkout wizard with other stores I often like to visit (take play.com). Even though this site is not multilingual, it's not too difficult to imagine the play.com checkout wizard in a different language. A totally different experience where language wouldn't prove to be such a big hurdle at all.

The biggest difference between the two wizards lies with their visual (functional) design. The play.com wizard is designed as such that the advance buttons are where you'd expect them to be. Cancel buttons look like cancel actions, buy and confirm buttons emit a definite "go ahead" feeling. Through the use of arrows, size, position and color the function of a particular button becomes almost immediately obvious. You don't even have to move your mouse pointer to cycle through the individual steps of the wizard. If your design functions like a guide the text labels become secondary information, simply there to verify your visitor's assumptions the first time he uses the wizard.

The Amazon wizard is a lot messier and forces you to read the labels to understand the action of a button or link. This makes the interface less intuitive even when you perfectly understand the language used on the site. When you can't understand the language, you're left to switching between Babelfish and the application, hoping the translation is somewhat accurate.

testing your designs

These days it's not unusual to set up a user test for a proposed design. These are not the most straight-forward tests to perform but on the whole they will tell you something about how your users perceive the design you want to use. An interesting variation on these tests would be to perform such a test based on design alone, stripping all descriptive labels and content. You can test specific user flows and measure how far the design will take the user in a flow purely based on the feedback a design is giving.

The web is not just about content, it's also about flow and actions. Guide your users from start to finish and make that journey as easy as possible. When considering flow, you could argue that functional design is king and content is queen. Labels are nice, but if a user can be guided by design alone the interface will feel a lot more intuitive to them. Testing a design for just that is still somewhat of a novelty but could prove very valuable in the future.

conclusion

The past few years applications have gained quite a lot of territory on the web, content is getting a big competitor in the form of flow and actions. We're not just browsing the web for information anymore but we're also looking to perform actions and tasks. Design isn't just a secondary worry or simple eye candy, but should be taken into account, especially when talking about functional design and how it influences the way a user performs a specific task.

As our job becomes more and more professional, more elements of our job will require user testing. When testing for functional flow designs, text and copy are not as important and could ( even should) be removed from the equation to reach maximum result.

you don't get what you see

There is nothing particularly wrong with the concept of wysiwyg, in fact it helps clients to make the content they are entering into the system less abstract. They can see the impact of what they are writing in real-time which is a big advantage to them. The problem though is that concept and reality are often miles apart from each other, pretty much nullifying the advantages wysiwyg is supposed to bring them.

The best way to incorporate a wysiwyg editor is as an in-page editor. By giving the component a subtle yet recognizable look you'll be able to mimic the actual appearance of the content. Important is to make sure the width of the wysiwyg is equal to the actual content area and to transfer all the appropriate content styles (fe line-height, font size and color, ...). If the actual content area is just a few pixels wider than the wysiwyg editor it could already mess up some carefully constructed content. Mostly though wysiwyg editors are used for back-end editing. This makes it a lot harder to display the editor at the appropriate size with all the correct styles applied to the content, let alone imagine the content in its actual context.

All of that is just about what you can see on screen. What you get is actually a lot worse. The wysiwyg editors generate their own html in the background. In theory a good thing as it generates headings, paragraphs and list items (semantics!) but the reality is not as nice as they'll make it out to be. Especially when removing content the editors often leave behind empty tags and crappy html poo, sometimes even invalidating your html code. Depending on the css you've written, this could become problematic.

cuff your clients

Those in charge of sales love wysiwyg because of its many possibilities and features. Clients can change the font, color and styling of the text. They can insert images, lists and headings, they can even build their own content table. And best of all, it's not you who has to do all the hard work, the client can do so himself. Many forget that by working like this you're effectively turning the client into a web master, a job often not suitable for them.

The more possibilities you give a client, the more ways he will find to screw things up. You can talk hours about company styles and guidelines, but give them the option to mess around with fonts and colors and before you know your carefully constructed site is filled with bold, italic purple text in some or other exotic font. And that's only if you're lucky, Comic Sans is probably a more realistic example.

Leaving options like changing colors and fonts in is usually not a good idea. Most wysiwyg editors allow you to tweak its capabilities one by one but only rarely is an editor tweaked to leave just the necessary tools. It still doesn't guarantee that clients won't find other ways to mess things up (they are quite inventive when they need be), but at least it closes down some very obvious doors.

so what can we do

As much as you'd like to prevent the problem rather than curing it, you'll find yourself more than once confronted with issues originating from wysiwyg content. There isn't a whole lot you can do about them (apart from entering the back-end and manually editing the content yourself), but there are a few tricks you can learn.

be creative

And that's about all I've got so far. If you have any more tips or tricks, please do share. For a long time I've ignored the issues of wysiwyg content but I think it's about time to get rid of the most glaring issues. Other alternatives (like wyisywym - mean) are simply not as user-friendly or advanced as the current wysiwyg editors, so I'm sure we'll just have to deal with them for now.

With the pointers above though I'm sure you'll be able to counter the most common issues, or at least have a solid base to start countering them.

learning from your mistakes is good

Sharpening your front-end skills is an iterative process. There are some things in life you can learn from a book, html and css are not among them. Creating a flexible html component takes time, spitting out some decent css even more. The only way to learn it is through trial and error. Each new project you start is a fresh chance to get better at what you do, slowly bringing your skills up to an acceptable level. The ultimate goal is peace of mind, one of the greatest riches you can imagine.

Key here is to look back at what went wrong in previous projects and to try and find good solutions to prevent these problems from happening again. Whether you take a week off to come up with new strategies or simply try something different to see where you'll end doesn't really matter. Different approaches lead to new experiences which will serve you well no matter how they turn out.

So far nothing new, but it turns out that learning from one's mistakes is often easier said than done.

the lazy beast

Most projects reach a stage where the problems start piling up and the once so glamorous outline seems nothing more than a figment of your imagination. This is the moment where mistakes and misjudgments made earlier will roar their ugly heads and hit back hard. Many people understandably hate this stage in a project, at the same time there's plenty of interesting stuff happening. It is the best opportunity you'll get to get better at your job.

Seeing and understanding the things that go wrong is a crucial aspect in finding better ways to handle these problems. If you want to learn from your mistakes, it is not enough to just make them and leave the dirty work to something else. If you truly want to get better, you need to fully experience these problems and issues, only then will you be ready to commit yourself to solving them once and for all.

Mankind is somewhat of a lazy beast though. It's easy to let someone else do the dirty work and leave a sinking project in the hands of an unfortunate successor. On the other hand, that same laziness can motivate you to wade through the hard parts now and to make sure you'll be able to do a better job in the future. Making it easier for yourself as a front-end developer involves getting your hands dirty, the messier the situation the better.

there is no dirty work in front-end development

So when you're doing overtime, cursing and grinding to fix a seemingly endless bug list, try to think of it as an opportunity to improve your skills. Don't leave it to someone else because I can guarantee you you'll be making all the same mistakes in future projects to come, creating the same pile of crap over and over again.

It's not always easy as there are many elements working against you (ever-changing project requirements, browser issues or implementation inconsistencies), but in the end it will be worth it. Solid and flexible code is not necessarily harder or doesn't take longer to write, you just have to make sure to do it well the first time around. To get to such a level of expertise you'll have to do a lot of hard work, but it pays off, so do persevere.

I guess I'll conclude with the most classic example of em all: I never learned so much about html and css as during ie6 debugging sessions. And that's the truth.

we wii

For those who didn't get the irony of the picture above, there wasn't much time for leisure or sweet vacation pics this year. The past two weeks were primarily dedicated to moving our butts (and everything else we own) from point A to B. After a year and a half long wait we were finally able to move to our very own apartment. Sadly there was still plenty of work to be done before we could actually move.

To soften the blow a little we bought a Wii, so if you were wondering why I didn't even post any film reviews during my vacation, there's your answer. Most of our free time was spent on stripping down everything there is to find in Mario Galaxy 2, which proved to be the perfect distraction from all the hard work in between.

We did watch some films though (and a couple of good ones too) so be prepared for reviews of No-Do and Harry Brown in the very near future.

we are back

With all of that behind us, blog activity will resume as usual. First work update will probably be for next week, expect the personal blog to kick-start a little earlier than that. Cheers for sticking around and stay tuned!

hi, I'm a pager

A pattern is always a solution to a specific problem. In the case of pagination the problem is excessive amounts of content appearing on one single page. This could be in the form of an overly long article, a product result list or any other situation where the content of one single page cannot be logically transformed or spread across multiple pages. Usually the content follows a certain order and can't be categorized under different sets of themes. If that is the case it might be better to look at a tabpane.

Pagination exists in many different forms, but the core of the pattern is a numbered list of links pointing to each separate page. You can include extra navigation (first, previous, next, last), a result indicator, an instances/page indicator and even a little sort form can be present, all depending on the data inside the pagination pattern. They are all aids to improve navigating the separate pages, making it easier to find what you were looking for. In some very specific cases it might even be possible to remove the numeric pager and only keep the next/prev links.

When it was first introduced pagination caused some confusion among web developers as it blurred the concept of a "webpage". Is each link in the pagination referring to a different page or is it all the same page with a pagination component showing different states? That question became easier to answer when AJAX took off and many pagers where converted, eliminating the need for a page refresh just to reload the content of the pagination component. The links would just refresh the content part making it faster though often a little less accessible to screenreader users.

new horizons

This last year some popular services (like Facebook, Twitter and Bing Images) have been using alternative patterns nullifying the need for a pager. Recently Google Images jumped on the bandwagon, truly launching this new pattern into the mainstream. The idea is that when a user reaches the end of the paginated content, the pagination component will load the "following" page. This can be done automatically, sometimes an extra action is needed to trigger the content load.

For some applications (like the image search) this works wonderfully well. No more going back and forth between pages trying to remember where this one particular image was located, you simply scroll up and down to find what you need. Getting more images is done by scrolling down, the gallery will then load new images all by itself without any extra action from the user.

why it won't kill pagination

While this pattern is becoming more and more popular and has many advantages over oldskool pagination, there are some limits to its use. The most important one is that you can't skip to a particular page anymore. You have to go through all the content in sequence to reach a specific part of your information. For content that isn't predictable (the Bing and Google image search) this is no big deal, but Facebook and Twitter are balancing on a tightrope.

A numeric pager gives you an indication of how much content there is. Based on that information you can decide which page you want to go to. If one page of Facebook updates equals a day and you want to travel back a week in time, you can jump to page 7 or 8. It's never exact, but you don't need to cycle through all the other pages first. With the new pattern in place this is not an option anymore.

That's exactly the reason why I haven't implemented the automatic content load yet on my blog. I could very well remove the pagination on the archive page but from personal experience I know that I don't always go through the list in sequence. In the end, this should be the main reason for deciding whether to use the new automated pattern or to use the oldskool pagination pattern (or maybe a smart combination of the two wouldn't be all that bad either).

conclusion

Common sense is a good start to determine what pattern is your best option. If that isn't enough, some statistics might be useful. If you notice that people use the pagination in sequence (they start on page 1, then 2, then 3, ...) if might be good to switch to automatic content load, but if you notice that people are skipping through your content it's probably best to leave the old pager intact.

So while I applaud new ideas and patterns, it's always good to take a few minutes and to consider in what circumstances a particular pattern would benefit your needs. It's not because it's popular that it's any good (just see what happened to the tag cloud). That said, I love the automatic content load as it makes navigation a lot easier if a numeric pager isn't needed. I just fear that it might be used in places where it isn't needed.

define: design pattern

The word "problem" in this context is quite loosely defined. For example, navigation is a solution for getting from one page to another, a breadcrumb is a solution for lack of orientation within a site, a sitemap is a solution for getting a grip on the site's complete structure, and so on ... Once we're talking about a recurring problem, we can look for a standardized solution and turn that into a "design pattern". Before it becomes a real pattern though, it's key to look at it from as many angles as possible, defining the pattern as extensively as possible.

To give you a good idea of what kind of angles we're talking about here it's probably best to use a real-life example making the article a little less abstract. One such simple and easy to understand web pattern is without a doubt the confirmation message. A simple message that appears every time a user completes an action successfully. So let's go from there and see how such a trivial element can be defined.

how to look at patterns

It's best to keep a broad view when defining a design pattern, considering all aspects and all situations where such a pattern might be used. Following are some common angles that keep popping up when examining a pattern from up close:

• functional angle: where should the message appear (close to the action element or on top of the page), should it be shown on a new page or through an AJAX call on the same page, how long should it remain visible when implemented with an AJAX call?
• graphical angle: red is probably not the best color to use, green the most obvious one, could other colors be used, should we add an icon and if so, what icons are best?
• copy angle: does the message need a title, should we address the user personally?
• front-end angle: can we write a standardized html structure, can it be visualized using a whitelabel css, are there accessibility concerns?

All these questions need to be answered in order to define the boundaries of this pattern. Then it's interesting to see if the pattern is not part of a broader whole. A confirmation is just a variation on a generic feedback message. There are errors, alerts, help messages and you can probably come up with a few others. So grouping patterns according to type might be a good idea, often leading to new insights.

so what, I'm a developer

Remember how I always go on about structure and components? Well, design patterns are the perfect way to start building towards standardized code. Once a pattern is defined it's pretty easy to write a fixed html structure that can handle all requirements made for that particular pattern. And if you have the time and/or means, why not add a whitelabel design. You can have a live prototype up and running in a mere day.

As a front-ender it's not only important to know about html, css and javascript. It's also important to know a little thing about design, wireframing and copy. Not so you can do it all yourself, but to interpret the work others have done for you and to make the most of it when turning it into a web page. Consistency, standardization and a common language between all people involved in a project are all aspects of a solid design pattern library that can only increase the quality of the product you are developing.

The only thing to note is that while a design pattern library gives you easy access to a set of standardized solutions and a wealth of knowledge, the web is ever changing and if you have defined a pattern one or two years ago certain things might have changed. A few years ago the tag cloud was the biggest hype, now almost nobody uses it anymore. So make sure you keep questioning the patterns you are using while at the same time enjoying the benefit of all the work you (and others) have done in the past.

conclusion

While at first this topic might seem a little out of place on this blog, I figured a little introduction to web design patterns would still be useful. They are absolutely crucial in changing the way you think of html. Because html isn't a mere means to apply semantics to a single element or to structure a single page, it's a means to define components and to reuse these components throughout a whole site, even multiple sites.

If you want a good starting point, you can check the Yahoo library or Welie library. Both are pretty extensive and free to roam around in. These libraries don't feature html examples or css snippets, but once you have the functional (and sometimes graphical) requirements, writing up some structurally solid html for each pattern shouldn't be too hard.

hunted

First things first though. Looking for guest post opportunities is one thing, people picking up and publishing your stuff is even more fun. That way you don't have to do anything and you still get to reach new audiences. When I checked my site stats last month I noticed a serious bump in Japanese traffic coming to my site. On further exploration it turned out the article on 1px rounded corners made it in the June issue of Web Designing a Japanese (printed) magazine.

They were nice enough to send me a couple of issues. Not that I understood any of it, but how cool is that, holding a Japanese magazine with a reference to one of your own articles. From what I could read it did look pretty informative though. Shame they don't have an English translation out.

Want proof? Check the scan.

serious stuff

Sometimes it takes a little more effort, which isn't all that bad as long as you have something to show for it. A good two months ago I solicited to write a guest article for Smashing Magazine, one of the leading web design blogs out there. It ended up as one mean beast of an article, but the result is something I'm quite proud of.

The article is about semantic consistency and the lack thereof in most sites. Not only big corporate sites that have other things to worry about, but also blogs from the leading web design bloggers seem to suffer from semantic inconsistency. Quite strange, as it's not all that difficult to implement. The article gives you a little sample of content type implementation around the web and some pointers on how to make your own code more consistent.

Find it here: When One Word Is More Meaningful Than A Thousand.

predictions for the future

Well, that's a simple one. I just take what comes along. Whenever I feel the need to write something I believe deserves a bigger audience than my little blog can guarantee I'm sure I'll be able to land the article some place or another. And when that happens, you'll read about it here.

defining our goal

There are countless articles written on how input elements differ across browsers and operating systems, even OS themes. The conclusion of these articles is always the same. Don't mess with them. And usually I agree. In a normal form there are limits to styling form elements, if only to safeguard our own sanity. Small differences in size, spacing and appearance between input elements is something inherent to the web. In other cases though, I can understand the designer's frustration.

One of those cases is the small search form often found in the header of a site. A prominent element within a site usually consisting of a text input and a submit button. The design is normally tightly integrated into the whole header so any pixel differences there can result in a sloppy overall feel really fast. One long-running frustration is that the height of both text input and submit is hard to match cross-platform, cross-browser. But there are ways. We're talking css after all.

The goal here will be to create a consistent setup for a text input and submit button so they can easily be given a fixed and equal height, rendering the same cross-browser. It will get hacky and you will need to get your hands dirty, but in the end it might actually we worth the trouble, especially when used sparingly.

defining the problem

input[type="text"], input[type="submit"] {height:2em;}

In short, the code above illustrates what I am hoping to do. Add an equal height to the text input and submit button and hope they are rendered with the same height by all browsers. Of course, it won't be as simple as that. The first problem is easy to fix though. Both element appear to have a different base font-size in certain browsers, so adding a font-size:100% to both elements helps us forward a little.

The biggest problem lies with the borders though. The border-width on the submit button is included into the height, the border-width on the text input has no impact on the height of the element. In other words, the border on the text input is drawn on the outside while the border on the submit button is drawn on the inside. Some quick experiments with the -vendor-box-sizing css property didn't result in much (unless you don't need to worry about ie6 and ie7), so let's try the hard way.

input[type="text"], input[type="submit"]{height:2em; font-size:100%; border-width:0;}

The only smart thing to do is to disable the borders on both text input and submit button and to provide some generic wrappers to take over the styling. By doing that you avoid differences in rendering height between the two input elements. I know it's not very clean but at least it works.

the html code

<div class="search"> <form id="searchForm" action="#" method="post"> <div class="inputWrap"><input type="text" /></div> <div class="submitWrap"><input type="submit" /></div> </form> </div>

This is the final html code we will be using for our search form. Not complete rubbish, only the .inputWrap and .submitWrap elements are obsolete from a structural point of view. We will use these two elements for faking the borders around the input elements, on top of that we'll need to float both wrappers. Note that adding a display:inline-block (rather than floating) is also on option, but applying the floats gives us a little more control over the spacing between the two, which I prefer.

In Opera, Chrome and Safari there will still be a slight difference in height between the elements. This is caused by a padding on the text input which can be removed quite easily. And by adding a line-height the same as the element height we'll have better alignment of the submit button text (Chrome) and text input text (IE). All of this results in the following code:

.inputWrap, .submitWrap {float:left; border:1px solid #000;} input[type="text"], input[type="submit"]{height:2em; line-height:2em; font-size:100%; border-width:0; padding:0;}

This will yield perfect results in Safari, Chrome, Firefox and Opera on both Windows and Mac, sadly IE still experiences some of problems (but what else is new, right). There will be strange spaces popping up which shouldn't be there, but nothing a couple of floats (and display:inline fixes) won't solve. Here's the ie7- css code.

/* ie7- specific css*/ .search {zoom:1;} .search .textfield {float:left; display:inline;}

putting it all together

.inputWrap, .submitWrap {float:left; border:1px solid #000;} input[type="text"], input[type="submit"] {height:2em; line-height:2em; font-size:100%; border-width:0; padding:0;} /* ie7- specific css*/ .search .textfield {float:left; display:inline;}

That's "all" you need to have a search form show up consistently in a range of browsers and OSes. If you want some live example code you can check the test page:

Note that a similar problem exists with input elements widths, in that case though the -vendor-box-sizing property (border-box) proves a lot more useful. Sadly ie6 and ie7 don't seem to like it that much when it comes to defining heights.

I wouldn't recommend using this for every form and every input element, but when two inputs need to align pixel perfect, ensuring design consistency, it's a very useful option. If anything, it's a good trick to win points with your designers.

reality check

Most designs are made using "lorem ipsum" content. We all know that this is not the right way to tackle a design but more often than not a project doesn't leave us with many other options. And so we proceed with our work, realizing the actual content might not fit well into the design that's being made. To make it worse, bad (or complete lack of) copywriting can mess it up even more. You might have designed a horizontal navigation, but when it turns out the text for each link is half a sentence long rather than a clear and concise label you're in for some serious trouble.

As for today's topic, let's take a closer look at how long words (without spaces or split characters) can mess up your layout and how it can be fixed using some simple css.

the old days

If a single word is too long to fit into a designated space your options are limited by default, but back in the old days you were really screwed. You could only do one of the following things:

• Do nothing and let the content spill out the designated space, possible overlapping other elements. Ugly as hell, but at least the whole word was readable.
• Apply an overflow:hidden to the parent and hide the content that spills outside the designated space. Add fixes for IE and hope you're not hiding something crucial.
• Change the content to fit the design, either doing a little copy work or manually insert split characters (fe '-') inside the problematic words.

All of these options suck, but it was all we could do back then ...

modern times

Luckily css3 is catching up with our styling needs and we've been given a new option to toy around with. Still not perfect, but a whole lot better than the previous three: check out the word-wrap css property. Surprisingly enough, a property long ago introduced by Microsoft. Go figure.

selector {word-wrap:break-word;}

When set to break-word this property will break off a word when it doesn't fit on a single line. Note that it will not break off every word when it reaches the end of a line, just the words that won't fit as a whole. It's still not ideal as there is no indication whatsoever that a words is cut off, but at least it gives us another good option to consider, one that's quite useful in most situations.

And best of all ... it works in all modern browsers + the ie6+ range. What more could you ask for.

conclusion

It's little additions like these that make a big difference when you are near deadline and it turns out the given content won't fit into your design. Rather than start redesigning certain parts with the chance of breaking other stuff in a series of browsers, you can simply apply the break-word to cut off problematic words into separate pieces without losing any of the content.

1. stop unnecessary floating

.selector {float:left; width:100%;}

The code above is something you find quite often. A simple block level element that is floated with a width of 100% to make it span the complete width of its parent. In most cases, removing the float and width will result in exactly the same rendering, only with more flexible use of margins and paddings. So what gives?

What usually happens is people fail to understand the workings of collapsing margins. Floating the element triggers a more understandable use case where margins are not collapsing with margins of surrounding elements. This is okay until you need to add paddings, margins or extra positioning rules. Furthermore, this code isn't very browser-proof and you'll often end up with nasty ie6 troubles.

There are better ways to work with (or around) collapsing margins and besides, floats are never a good way to fix things. Using floats to fake a block level element is completely useless and will definitely result in trouble later on. So no more.

2. margins and paddings

.parent {margin:1em 0.5em 0em 0.5em; padding:0em 0.5em 1em 0.5em;}

Margins and paddings should never be used together to create one single space. Both properties can be placed on leafs (an html element with no children) in certain circumstances, but apart from this use case it's better to stick with either one of the two to define all spacing around an element.

Usually statements like these come forth of laziness or bad planning. They are the result of last minute changes or unfocused code weaving. All understandable excuses, but if you claim to have a professional attitude you just can't leave them in your code.

I don't really care whether you prefer, paddings or margins, but combining them to create one single space is never a good idea. So no more.

3. width abuse

.parent {width:50em;} .parent .child {width:49em;}

Use widths only when really necessary. People tend to go all math on their css while css is (somewhat) equipped to do most of the work for you. In the example above, the width declaration on the .child is completely unnecessary. It would be much better to simply add a right margin on the .child element (unless you'd really want the child to be 49em wide independent of the width of its parent). Using paddings or margins instead will ensure decent rendering even when the parent would change widths.

I've had several projects where the goal was to widen a site. It's true bliss if you can do this by adapting just a couple of values in the css without worrying to much about browser inconsistencies. A project like that turns into hell on earth when each component has a specific width defined, especially when these components just take up the available width anyway. It really makes the difference between an hour work or two days of hard labor.

For positioning an element relative to its parent, use margins or paddings. Only use widths when an element should explicitly have a fixed dimension (not saying it should always be in px though, it could be ems just as well). Widths are for reserving space, not for spacing. So no more.

4. mending and fixing

.selector {margin-left:-6px;}

There aren't too many things the web design community as a whole agrees on, but when it comes to ie6 most (if not all) people agree that it is an outdated, hard to code for piece of software junk. And while I won't contest that statement, it must be said that most of ie6's problems can be fixed quite consistently. Whether you use inline hacks or conditional comments doesn't even matter, how you actually go about fixing these issues is more important.

Many of ie6's bugs exist of (little) misplacements of elements. Most people try to fix these issues by re-aligning them specifically for ie6. For example, if an extra 6px space is added to the left you can counter it by defining a negative margin of the same size. This is crap coding though, as you're only just mending the problem rather than really fixing it. ie6 might be a true bitch, but most of its bugs can be countered as to make it behave like other browsers.

This is pretty important as these fixes will continue to work when the original css is adapted. Rather than defining a negative margin, make sure ie6 renders the item as it should, so future adaptations won't need extra fixing. Making ie6 behave is not easy, but far from impossible. So no more.

5. reset without rereset

* {margin:0; padding:0;}

I have nothing against reset css, be it coming from a standard script of coming from custom coding. As long as you make sure to set the general styles back, I'm fine with it. I do get furious when encountering a css where simple text paragraphs don't even have a margin (or padding) defined on them. This is simply not done and extremely sloppy coding.

So use these reset css styles as much as you like, just make sure to set the basic styles again. Make sure your paragraphs look like paragraphs and lists feature some kind of list element indications. These quick resets eliminate styles that are important for displaying general data, not setting them back to a good standard is pure amateurism.

conclusion

Basic as these five remarks might be, you'd be surprised how many front-end developers still make mistakes like these. There are many reasons that seem to fuel this state of affairs, like lack of proper schooling or a good fall-back place for css best practices to go to when starting out with css. Most people learn from scattered blogs and snippets found in articles, which is probably not the best way to get to the bottom of what we do. This makes finding a good solution a pretty tough task though.

The list above is more than just my top 5 of commonly seen css ugliness, it's hopefully a wake-up call to whoever feels the passion and energy to create some kind of starter's platform for css best practices. Through all the bling and sex of css3 these issues are once again eclipsed, but they might be even more relevant than two years ago with a whole new group of people starting to learn the tricks and trades of html and css.

So no more, it's time to take css to its next level. And no, I'm not talking modular css or advanced animation, just a good set of best practices and a well considered starters platform for people to get started.

dl: definition list or description list?

The definition list (<dl>) was without a doubt one of the most confusing html elements out there. Though actually quite properly defined, its practical value was very limited. Unhappy with this situation many people kept coming back to it, trying to find proper uses for the element. The definition of "definition" became an almost theological debate, leading the definition list to be used as mark-up for forms and other strange, completely unrelated structures.

It's time to let go of all of that. The definition list is no more, long live the description list. While its name could still cause some confusion, the definition to go along with the element leaves little to the imagination. Here's what the w3c has to say about it:

Important here is the use of "name-value" in the definition, broadening the use of the element significantly and making it a very suitable element for what I call the caption-detail structure. A very typical structure often seen in meta data and profile data.

If you'd like more practical information on the dl revamping, you can check the html5 doctor article.

why dl sucked in the first place

Thing is though, the biggest problem with the dl elements was never its poor practical use or strict definition, but its poor structure. It was originally devised as a list of definitions, a case where the list structure actually made sense. But even then, the fact that a unique couple of terms and definitions could only be determined based on order (since they lack a unique containing element) made it into a structural mess. Contrary to other html lists, there is no <li>-like element to speak of.

This structural weakness carries over to styling, something most people who've tried to properly style a dl should have experienced already. It's doable as long as the couples are displayed as a typical list, but try anything fancier and you're dead out of luck.

The new definition of the element further underlines its structural weakness. Should you use the dl for meta data, there is no proper way to add extra semantic value (classes like .author, .publishdate, .lastchanged, ...). Of course you could always add the class to the term and make it a rule that the following dds are included in the data, but that would go against 20 years of proper html and microformats structuring.

what it should be like

With the new description element, there's really no good reason to stick with the whole "list" concept. The dl element could function as a container for each couple, uniquely identifying one name-value group. The context of the element could (and should) determine whether the dl is part of a list or appears as a standalone element. Code speaks louder than words, so below a couple of examples of what I'm talking about.

Author metadata:

/* name-value as meta data */ <dl class="author"> <dt>author:</dt> <dd>Niels Matthijs</dd> </dl>

Full name data field in a profile:

/* name-value as profile data */ <dl class="fullname"> <dt>name:</dt> <dd>Niels Matthijs</dd> </dl>

Full name input field in a form:

/* name-value as input/form data */ <dl class="input fullname"> <dt>name:</dt> <dd><input type="text" /></dd> </dl>

conclusion

The name-value pair (dt-dd) of the dl element is one of the only html elements out there which is not defined by a unique parent. Even worse, it's current structure is effectively making it impossible to do just that. This is a big structural flaw with noticeable effects on styling and javascript. The new definition of the dl element is a lot better, but without structural change the element will remain a pain in the ass for years to come. Even worse, because the new definition is actually forcing us to use the element in more places. Let's hope the nice people of the w3c will take the time to fix that.

finding a use for triangles

Usually background images suffice when visualizing triangles. I actually prefer using an extra wrapper with a background image over some empty elements with a lot of crazy css applied to them, just to create a triangle. In this particular case though, the size of the triangle wasn't fixed and could change depending on the design.

The effect I needed to create was an angular bottom side on several boxes throughout a site. These boxes could vary in width so I needed a flexible solution to create my triangles. I've tried using the image technique before (creating one over-sized image and actually computing the height needed for the opposite side to make the hypotenuse - the side not containing a 90° corner - fit correctly) but that didn't work out too well. Too many rounding errors there, which led to sloppy results.

So I looked around a little and hit Jon Rohan's article on css triangles. A good summary of the technique with all the needed fixes for it to work in all necessary browsers (including ie6!). I tested it myself (better be safe than sorry) and actually got good results in all needed browsers, though the ie6/chroma filter fix needed an extra budge using zoom:1 to kick in.

My idea was to insert html elements into the boxes (using jQuery or whatever), turn them into triangles and position them absolute at the bottom of the containing box, mimicking the effect of an angular bottom side. At first I had some trouble making sure the triangle was as wide as the containing element (border widths can't be 100% apparently) but with a little javascript help all worked out fine. The results in Firefox were actually quite perfect. Up until then, everything was going smoothly, but you know what's coming next, right?

a line isn't just a line

It's a funny thing how running into an issue makes you notice certain things. Firefox rendered the triangles flawlessly, but when checking other browsers it turned out they had way more problems rendering the triangles.

If you look around for articles on the web, you'll notice that almost all examples use triangles with a 90°/45°/45° setup, meaning the width defined on both borders is equal. This ensure that the resulting hypotenuse is drawn under a 45° angle. More specifically, a line drawn like this needs no anti-aliasing to render properly since each next pixel is drawn at +1px/+1px from the previous pixel.

If the hypotenuse is drawn under a different angle, the line will start to look extremely jaggy if no anti-aliasing is applied. When used on top of images or other high contrasting backgrounds, the result is ugly as hell. Seems that apart from Firefox (and apparently Chrome for Windows), no other browsers apply anti-aliasing on the resulting lines between different borders. You can see the final results below:

who's to blame then

In this case it's difficult to actually blame browser vendors. The triangle method is one of those typical examples of creative thinking sprouting from the web community. The triangle effect is really a side effect from wide borders colliding, which hasn't seen much use in the past. Firefox' rendering is of course preferred, should you want to use fat, differently colored borders on a single element in your design. If not done like this, the separation line between both borders will look pretty crappy, but a high priority issue this is not.

So, even though the technique works alright, the application of it is still pretty limited due to rendering issues. Use it in situations where you have a 45° angle or when the background color doesn't differ much from the color of the triangle. Otherwise, you'll have to live with jaggy edges.

conclusion

For those interested to know how we fixed it: we used the html5 canvas and drew some triangles of our own. This was actually easier said than done, but for larger triangles it worked out okay. For smaller triangles though the drawing algorithm we used simply wasn't accurate enough, still resulting in ugly triangles. For those elements we still use background images.

In short, just another day at the office. I'll just repeat myself here and declare this another typical case of standard css development: read about it and be happy, try it and be disappointed.

what standards?

Since a couple of months there's been a real explosion of html5 and css3 talk. Several big web issues (like online video) have helped in gaining great support for these new standards, but like all things web, abuse is always just around the corner.

One thing web standards don't include is standard of quality. The past has learned us that with each new big technology introduced on the web, quality standards are the first to go. Maybe it's because the web is governed by techies who mainly care about technical achievements, but it's a given that when a new technology is launched on the web it gets fucked over for a couple of years before its actual benefits come to the surface.

you say sexy, i say ugly

Bloggers need attention. Fact. With all the css3 demos, techniques and experimentations going on grabbing the reader's attention is getting more and more difficult with each passing day. Hence all the posts with titles including words like 'sexy', 'cool', 'amazing', 'fresh' and other positive buzz words floating around the web, just to pull readers in. Checking them out usually amounts to watching demos of sluggish animations, graphically poor visuals and often completely unusable, even inappropriate techniques.

Web standards have fought for years to give semantics and accessibility a place on the web, all that is thrown overboard in the blink of an eye just to create a couple of ugly animations which serve little to no goal at all. People are trying to mimic the capabilities of Flash and failing horrible in the process, but it doesn't seem to be a big issue since they are at least using the latest technologies. That's the current state of the web, and the community of web developers are actively encouraging it.

Animation on the web has always been poor. Javascript isn't really suitable, Flash only to some extent (when it fits the typical Flash style). With css3 we seem to have hit a new low. A couple of rotations in sequence with some transformations are being sold as actual animations, ruining 80 years of professionalism in that particular field. If that's sexy, I'm just not interested in sexy anymore.

html5 is not css3

Another hot topic is whether hmtl5 is going to replace Flash. Most people don't even realize it's not so much html5 but the canvas element in html5 that's the real threat to Flash. Most people won't realize that animation comes from css3, which is no no way related to html5. And an even smaller group asks itself whether css is actually the right technology to define these animations.

The function of css has always been styling. Animation can be used form styling purposes, but much of it is treading on behavioral grounds. Just think of collapse and expand structures or other animations revealing hidden information. If your browser doesn't support the animation, more often than not you won't get to the content (unless you disable css). And it's not just the little ones doing it. You can find examples on the Apple site if you wander around a little.

And yeah, I'm quite confident this is only a temporary phase. In two years time we'll start questioning the purpose of all these horrid effects and animations, weeding out all the garbage and learning from our mistakes, but it would be frustrating to wait for another two years to see this process kick in. The web is slow enough as it is.

my redesign

Looking at my redesign, you might be wondering why I'm complaining so much about css3. The new design clearly includes overuse of css3 properties, which is true enough. Part of that is because I set out to use my blog as an experimentation platform for testing css3. It's fun to test and play around with css3 but in due time the unnecessary bells and whistles will be taken off again.

In addition I've compiled a little list of bugs, shortcomings and mis-renderings I've seen on my blog so far, just to indicate how buggy and/or incomplete most css3 implementations still are:

• Safari and Chrome: no support for inset on box-shadow
• Chrome: anti-aliasing on rounded corners sub-par
• Chrome: fuzzy box-shadow rendering
• All: multiple rounded corners stacked on top of each other result in rendering issues (check articles on homepage)
• Opera: box-shadow is clipped on tab navigation (homepage). Reappears when hovering certain elements
• Safari and Chrome: can't get rgba colors to work in gradients
• Safari and Chrome: crappy gradient control (no px allowed for stop points)
• Firefox: radial gradients are ugly as hell. Looks more like concentric circles than an actual gradient. Linear gradient not perfect either.
• Firefox: hover with text-shadow or box-shadow is extremely laggy
• All: no gradients possible (X)px from the end. Very typical css shortcoming.

Sure, not every browser should be pixel-perfect in its design rendering, but the list above gives a good indication of just how sub-par most css3 implementations are at the moment.

conclusion

It's not that I don't welcome html5 and css3. Far from it actually. But for now, people seem more interested in abusing these technologies rather than giving it some good thought first. And I really do understand the need to experiment, trying to find novel and breakthrough uses for these new technologies, but without a word of warning and with a big bold 'sexy' in the topic title these techniques will find their way to the live web, greatly diminishing the web experience for many out there.

Think wisely when coming up with css3 and html5 articles. Warn against the pitfalls and don't advertise everything as sexy or cool just because it is html5 and css3. Think of what web design stands for, not about how cool you look using one or other new, flashy and hip technology. Just my two cents and sorry if this rant spoiled your fun working with these new technologies.

web design and analogies: vomit bugs

Not too long ago I stumbled upon an article describing the vomit bug, a family of bugs causing the dom to scatter in all different directions, except the one you laid out initially. From what I have read so far it's related to the packet boundary bug (nesting of block elements inside inline elements I believe?) and occurs when nesting html5 elements inside a link. Looking at the resulting doms, the name is quite aptly chosen.

The problem that I'm experiencing occurs when nesting links inside other links. This used to be somewhat pointless, but now that we have block level links there are cases where this is actually quite natural. If you take the example of my shortlist articles you'll see I have a direct link to the comments section of the article, apart from that it could be that links are present in the intro text of the article itself. I assumed that these nested links would simply work as expected, as they lie on a "higher plane". The rest of the article element should react as being the block level link.

The resuls ... dom vomit, and not only in Firefox 3.6.

doms say more than a thousand words

Rather than describe the problem, why not show it to you? The following html code was used to generate dom structures in a range of modern browsers:

<div class="page"> <a href="#block" class="block"> <div class="test"> <div class="date">2010</div> <div class="vote">5.0*/5.0*</div> <div class="link"><a href="#test">test</a></div> </div> </a> </div>

As you can see, a very simple setup with a block level link containing several other block element and one nested link. Remove the nested link and everything is fine, but leave it there and all hell breaks loose. What follows is a screenshot of doms taken with dom inspectors in Opera 10.5 (1), IE8 (2), Safari 4 (3) and Firefox 3.6 (4):

The only one showing the dom correctly is Opera 10.5, though it must be noted that when giving a background color to the block level link Opera's rendering is off. Surprisingly, the only one rendering the block level link correctly is IE6 (seriously!), though the click area still doesn't correspond with the whole block level link. In short, block level links with other links nested inside are not working yet.

Those of you who've been following my blog a little longer will know this article fits right in with my articles on inner link spacing and cross browser underlining. All of these display wildly different behavior/interpretations of simple concepts across multiple browsers.

more about read more

Apart from this nasty bug, there is one other thing that caught my eye. When using block level links it's probably best to add a title to the link describing its function, as the content is not simple text but could be a whole content type. At the same time, block level links take away the need for multiple links leading to the same page, meaning that the omni-present read more link could finally be rendered obsolete.

When I tried to remove it though, I found that you lose a lot of visible, immediately recognizable feedback on the element telling you there is actually more to read. So while the read more link isn't exactly needed anymore, a "read