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 more" indication could still be useful after all. Maybe just on hover with a little css3 animation, but definitely something to look into.

conclusion

My conclusion isn't any different from most conclusions found in articles about new html and css techniques. Cool stuff, but it's just not working yet. For simple wrappings without html5 elements and links block level links seem to work, but when you nest another link inside it breaks down completely. Which is a shame really and I just hope it gets fixed soon. Up until that time you'll still need to use the links on the title and "read more" text or remove all links inside a block level link.

welcome css3

I'm not a designer, by far. Give me a white PhotoShop sheet and rushes of cold sweat are inevitable. The original design was created by a friend of mine but I felt it was time to try and stand on my own two feet. Rather than start up my graphical software, I turned to css3. Something I can at least understand.

At the same time, it proved a good exercise to get to know the flaws and limitations of css3. The (somewhat final) result is a design that's maybe a bit heavy on typical css3 graphical features, but still came out pretty much okay for a non-designer blogging for a more technical-oriented audience. Truth be told, I also got some professional advise and feedback along the way which was extremely helpful.

time-lapse iterative redesign!

Along the way I was pointed to one of the articles I wrote some time ago on iterative design. It gave me an opening to make the whole redesign process a little easier to handle. The idea is to take a month or two for implementing the redesign. Live. On the blog. No test development server needed.

The design will be implemented little by little, one component at a time. I'm sure at some point this will clash with the current design I have, but that's not too big a deal. The orange warning message you see on top will cover that and will lead people to this article if they want to know more about the strange things they might be seeing. At the same time, I like the transparency of the redesign process it creates and it gives me immediate results rather than working against deadlines I'm not going to make anyway.

exciting times

So I hope you guys bear with me for a while. I'll try not to screw things up (too badly) while doing my redesign work and I'll try to keep the overall design at least decent, even when the visual design of components might clash from time to time. I also hope to rework some things under the hood (read: get some more html5 in there), which should be mostly invisible to you all.

The first updates should hopefully be visible later this week.

45 seconds of iPad pleasure

A few weeks ago I had the pleasure of toying around with the iPad. I let the iPhone pass by because phones and teeny tiny screens really aren't my kind of thing, but I was rather curious to see the iPad work its magic. When checking my site everything looked okay-ish (save some graphical glitches in the main menu and some other minor quirks), but when I arrived on my gallery section I ran into some less pleasant surprises.

Apparently some of the pictures in my gallery were shown in landscape mode rather than the expected portrait mode and visa versa. A very strange effect that didn't seem to have any immediate html/css cause. I took it as an exciting (yet annoying) mystery that demanded an explanation and set out to solve it. Time for some serious digging.

onderhond holmes and the mystery of exif data

Looking at the affected images (a clear minority) it started to dawn on me that these were all images I edited in my photo editing program of choice (Paint.Net - free and loads quickly). The images affected were all photos that had been rotated in some way or another, either because my camera had failed to give them the correct orientation or because I simply thought they looked better this way.

It took me a couple of search queries and some live human consultancy before the magic word dropped. EXIF. A photo standard that stores a series of properties related to the photo, ranging from size to focal length and camera model. Apparently, one of the properties it stores is orientation. When a photo is rotated manually this property should be adapted by the software that is used to rotate it, but not all software is properly equipped to do this.

steve says exif owns browsers

The orientation property is extremely useful, especially when considering the tilting/spinning behavior of the iPhone and iPad. Using the orientation data, the OS can easily determine how to show a picture. The question is, how far are you willing to take this OS intervention.

Looking at my gallery, browser and EXIF are contradicting each other. As a web developer I'm assuming that the browser's rendering engine will place my image according to its dimensions, but the iPhone/iPad OS intervenes and decides to rotate the photos according to the EXIF specs, effectively ruining my design and blocking some part of the content on the page.

i say: get out of my browser steve

While I understand the process behind the bug, I'm not at all content with the OS deciding to rotate an image I've placed in my html. I'm sure it's handy when viewing photos in the OS itself, but I don't see any benefit tweaking people's websites with the danger of ruining the layout. It's not because the standardized data is available that you should immediately act on it in all possible circumstances.

I could start looking for a different image editor or start adapting the EXIF data manually, but that sounds like complete overkill for a decision that should've turned out the other way in the first place. So please Apple, keep your hands off my images when I place them in my html. I'm a web developer, I know best. I rule my html, my css and my design. Please don't intervene please and leave things as I intended them.

code explosion

css3 was never really made for shortening our css code, but rather with the idea that it would deliver a more flexible experience. A background color gradient used to be only achievable through the use of a background image, meaning that if the gradient needed tweaking you had to keep recutting the image over and over again. By moving this graphical effect to css it would be possible to simply define the needed colors and let the browser do all the drawing. Sounds good, right?

Now I know we are into some kind of intermediary phase, but ever since both webkit and Firefox started proprietary support for the gradient property it has made my css life completely miserable. As a front-end developer with a passion for getting to know latest techniques and methodologies I'm eager to start using the css3 way (you know, live and learn), but it's damn time and byte consuming to get things working across a range of browser. For a pretty simple fade I had to create yesterday, I came up with the following piece of code:

/* how it used to be */ background:url("...") left top repeat-y; /* using automated gradients */ background:#FEF3D1; background:-moz-linear-gradient(top, #FFF1CC, #FDF5D5); background:-webkit-gradient(linear,0 0,100% 0,from(#FFF1CC),to(#FDF5D5)); -ms-filter: "progid:DXImageTransform.Microsoft.gradient (GradientType=0, startColorstr=#FFF1CC, endColorstr=#FDF5D5)"; filter: progid:DXImageTransform.Microsoft.gradient (GradientType=0, startColorstr=#FFF1CC, endColorstr=#FDF5D5);

This makes the fade available in FF 3.6+, Safari/Chrome and IE5.5+. Opera users and IE users without filter support simply see the fall-back color. In contrast, using an image makes it available in every single browser version out there without any issues.

The problem is not so much that the css3 syntax is a little longer but that it looks like a block of css which could style half a site. And that only for one fade.

support doesn't equal quality

An image is an image. Apart from some color profile nonsense, it shows up the way it was made, consistently across all browsers. This is not true for css3 effects. It's not because a browser supports a certain css3 property that it knows how to render it properly. Firefox gradients are of sufficiently lower quality than those in other browsers. Especially light fades over large areas are known to create ugly stripes.

These artifacts are dependent on the conditions when viewing the gradient (screen settings and such), but on my home screen the difference between Safari and Firefox gradients is really striking. And this is just one example of course, I'm sure differences in rendering quality will keep popping up in the future. Gaps in quality you won't have when working with images.

One other area where css3 is seriously failing is animation. While it's neat that you can define (non-functional) animations in css, I still haven't seen one implementation that runs smoothly. And I mean smooth, not hey, for a browser this is kinda okayish. Replacing Flash with open standards is fine by me, but as long as the same level of quality can't be guaranteed I'd rather watch Flash animations to be honest. css3 animation is definitely nerdy cool, but quality-wise it's utter crap.

support doesn't mean full support

Still, all the above didn't put me off enough to stop css3 gradient experimentation. I started a new project today and pretty much the first thing I had to do was define a background gradient for my site. Not a full gradient mind, a pretty big harsh fade 3px high, which led to a slight fade of about 500px high.

It took me less than a minute to work it out in Firefox and about an hour to find out there was no (easy ?) way to accomplish it with the -webkit syntax. Apparently you can set stop-points, but only in relative measures. Why, I don't know (documentation is rather lacking on the webkit site), but the outcome is pretty obvious. No css3 gradients for me. Sigh.

conclusion

The bottom line is simple. The theory behind css3 is awesome, but practical use is something entirely different. I hope this intermediary fase won't last too long and that it won't create a similar backlog of compatibility issues the way IE6 did. Public availability on pre-standards are what causing all this at the moment, so I would really advise browsers to keep their proprietary css locked away in development versions, but I'm afraid they're not really going to listen.

It's not the first time I'm complaining about this, but theoretical complaints seem to be materializing rather rapidly these past couple of months. As it stands now, I find it easier to debug sites for IE6 (with the help of the IE6 CSS Fixer) than it is to get css3 working nicely across a range of browsers and browser versions. It's a somewhat sobering thought in sharp contrast with our past dreams, but it's a reality nonetheless.

google sucks

One of my main internet frustrations of the past couple of years is the lack of progression in the search engine field. With an insanely high market penetration of around 85% Google is industry leader, but their search engine hasn't really evolved all that much. The internet has though, it's been growing ever since it was conceived, making it more difficult to find valuable sources of information with each passing day. I simply spend too much time wading through irrelevant and outdated sites.

In my opinion Google currently lacks two very important elements. First of all there is the date factor. Older articles have had more time to build a strong link base and will often rank higher than more recent articles, increasing the danger of receiving outdated information. A publish date filter is nonexistent, at least to my knowledge. But more importantly (and relevant to this article), Google's search engine lacks solid recognition of content types. When I look for film reviews, I want to receive a list of actual reviews, not pages with the word review on (usually grayed out because none have been submitted yet). And that's our where semantics would come in handy.

we all wish to fly

Obviously I'm not the first one to think of this. Several steps have been taken in the past to extend the semantic power of our html code. Currently there are two (common) methodologies that try to accomplish this: Microformats and html5 microdata. Then there's RDF, but I'm going to leave that out of the discussion now.

Microformats extend html semantics through the use of standardized (not necessarily semantic) class names. The most popular Microformat is the hCard which holds the data of a person or company (name, address, contact data, ...). There are a couple of other formats defined too but they are mostly ignored by the web (though Google does parse some of them). The adoption rate of Microformats is depressingly slim, yet as a developer I can't say I'm all that surprised. Syntax is often fuzzy, unclear and downright impractical.

Then there's html5 (yay, hype!) microdata. You can read the spec yourself, but currently it's still a working draft with hopefully a lot of drafting left to be done. Through the use of four (4!) properties (itescope, itemtype, itemid, itemprop) you are able to add extra semantics to your html. Two main problems exist here. First of all, it all sound overly complex for what it's supposed to do. On top of that, most values for the itemprop seem to correspond with the class names you'd normally put on there, which you still need for styling. So it sounds an awful lot like double effort to me.

processability vs findability

The problem as I see it is that we're overreaching here. Of course it would be awesome to automatically and fully process content types on the web. Google is trying to do just that with Google Squared (thanks to Mathias for the heads-up), but I would me more than happy if it would just find my damn search queries.

The complexity of Microformats and microdata lies in trying to provide a full standardized description of a content type, while most people would be happy with the raw data itself. I don't need a full matrix of data comparisons when looking to buy a dvd, I would be thrilled enough if Google could direct me to valid product pages only. Attempts to process everything at once are holding back technological advancements. We're waiting for full-fletched definitions of content types while basic recognition would simply suffice for now.

conclusion

Rather than define a complex model for content types, why not start with defining a simple, standardized and semantic base identifier. For most content types these identifiers would hardly need discussing. Use "event" for events, use "product" for products, use "review" for reviews. Prefix them (maybe), but stop there and try to make that work for a start. After that, there will be plenty of time to try and process all the data within.

In my opinion, classes should suffice for this. Design and meaning are actually linked closely enough to warrant the use of class names. I'm really a big fan of the Microformat ideology, I just think it's overcomplicated and over-descriptive at the moment. Which is a shame, because bad search results are actively ruining my internet experience every single day.

inline-block

The following fix has been suggested by a couple of people before (thank you!), but somehow we always seemed to lack the time to really dig into it. It seems that for a while now there has been a pretty valid workaround for ie6 and ie7, enabling the inline-block behavior on elements. Some testing revealed that the fix isn't perfect (still some issues left with vertical alignment it seems), but in most cases it works just fine.

I won't be going into full detail about the specifics of the inline-block display value, you can read up on that in yesterday's article on floats vs inline-block, but it's an invaluable asset to solve certain longstanding design/css issues. The problem with inline-block is that is had poor support in older browser versions. Both ie6 and ie7 have partial support (it works on native inline element - meaning you can't use it on divs or lis, rendering it somewhat useless), FF2 had -moz specific support.

ul li {display:inline; zoom:1;}

That's all there is to it really. Use display:inline and add a zoom:1 for block properties support. A pretty logical fix if you think about it, but this gives us basic inline-block support in ie6 and ie7. An additional advantage is that you can now decrease the use of unnecessary floats, eliminating the need for fixing certain overflow:hidden declarations and floats in general. On top of that, the "add zoom to backgrounds" option becomes less harmful as it behaves flawlessly inside inline-block elements (while in floats it pushes the element to 100% width).

On top of that, version 0.8 has some additional performance fixes and better png detection. The 0.7 version was a little flawed when using different syntaxes for background image declarations. So that should make it easier to get all pngs fixed.

test it yourself

So that's all for the 0.8 release of the IE6 CSS Fixer. For thoughts, comments or suggestions you can always contact us. Let us know what you are still missing!

Check out v0.8 of the IE6 CSS Fixer.

looking alike

At first sight inline-block and float (left) look incredibly alike, and in a fair few situations both statements can be used to accomplish the same visual effect. Both statements are used to create a horizontal flow rather than the standard vertical flow. A popular design element for navigation, image lists, product lists and a whole range of other commonly used web patterns. That's where the confusion started for me, as randomly choosing a method isn't really my kind of thing.

The inline-block value was created to give an element two different faces. Its parent will treat it as an inline element, with all the typical inline properties. But the element itself considers itself a block element, meaning it can have widths, heights, paddings, margins and all other popular properties of block elements.

Finding the differences

As much as they seem to have in common, once you start looking at the finer points it becomes clear that both methods can be used to different effect and both have their own set of use cases. Below is a list of the most visible and useful differences, allowing you to make a weighted decision when confronted with the choice.

conclusion

Seeing all the differences, there are quite a few differences than can help you decide what method to use in a particular case. If you want control over alignment, inline-block is usually the best option, but if you want more control over individual elements then floats are still preferred.

Then there will still be situations where both methods will yield the same result. For now I guess I'll go with the inline-block method, if only to learn more about the ins and outs of this display value. I'm sure there are more differences, be sure to list them if you think I've forgotten something.

Later this week there will be more info about inline-block in IE, after that there will at least be one more article revealing a pretty interesting technique using inline-block. So stay tuned.

fixing spacing

For all the specifics, examples and tiny loopholes, you can check the w3C specifications yourself. The grid we'll be using for our example is a 3x3 list item grid. The code below gives us a basic layout:

1/ ul {padding:1em;} 2/ ul li {float:left; margin:0em 1em 1em 0em;} 3/ ul li:nth-child(3n) {margin-right:0;} 4/ ul li:nth-last-child(-n+3) {margin-bottom:0;}

The main issue has always been with the spacing of the individual elements related to their parent. Since the block items are floated margins won't be collapsing. If you're aiming for an evenly spaced grid layout, the second line of css above will leave you with too much spacing on the right and at the bottom of the parent element. What we need to do is remove the right margin on each third element and remove the bottom margin on all three bottom elements.

With the third css statement we can target each third list item. The 'n' takes on increasing integer values and matches it against the items in the dom. The fourth css statement does a similar thing for the three last list items. The syntax is a little less transparent but works all the same.

If the horizontal dimension of the grid changes you simply have to adapt the number 3 in these css selectors. Not ideal since we'll need to adapt multiple values for one single effect, but at least it works.

adding corners

Adding some complexity to our little setup, we now want rounded corners on each corner point of the grid. On our 3x3 grid this means adding a corner on the first, 3rd, 7th and last list item. The following code does just that:

1/ ul li:first-child {border-top-left-radius:10px;} 2/ ul li:last-child {border-bottom-right-radius:10px;} 3/ ul li:nth-child(3) {border-top-right-radius:10px;} 4/ ul li:nth-last-child(3) {border-bottom-left-radius:10px;}

Easy enough, though a little rigid and lengthy. And of course, for it to work in Safari, Chrome and Firefox you need to add a whole lot of browser vendor crap.

Check the first example on the test page to see it working.

what's not to like

Even though this setup works remarkably well across the latest selection of browsers, the whole idea just crashes when one list item is removed. You can add or remove full rows without any trouble, and the solution for fixing the margins works in all cases, but the rounded corners will end up on the wrong elements since we're targeting them through :last-child variants.

What we're lacking here is the concept of rows. The "seventh" child in our example really is the "first element of the last row". This cannot be expressed in css, so we still have to resort to workarounds. I have no idea how difficult this could be to implement (though I suppose it shouldn't be that hard, as the browsers needs to know it has to break to another line anyway), but for cases like this it would prove extremely useful.

a smarter solution

There is one more solution, but it only works in theory (and in some fucked up Webkit way). Rather than set the rounded corners on the list items, we could place them on the wrapper around it. This way, we'll be sure that they will hit the four corners of our grid.

1/ ul {overflow:hidden; border-radius:10px; } 2/ ul li {float:left;} 3/ ul li:nth-child(3n) {margin-right:0;} 4/ ul li:nth-last-child(-n+3) {margin-bottom:0;}

Sadly, remembering my earlier article on the trouble with rounded corners, there is no way to keep the visual styling of the list items from spilling over the rounded corners defined on the ul element. Only in Webkit, by using the horribly misused overflow:hidden property, can you fix this behavior.

So while in theory this solution is way more robust and flexible, it simply doesn't work like it should. Where are the times we still believed that css3 would fix all our troubles ...

conclusion

While css3 will give us a broader set of tools to work with, enabling us to do way more with a limited amount of html, it is still far from perfect. Even common patterns prove difficult to accomplish in flexible, best practice worthy ways. The more I play around with the possibilities of css3, the more I keep coming back to the same tired old concept of workaround, fixes and alternative methods. It's a somewhat depressing realization.

space combinator

.class1.class2 {...} .class1 .class2 {...}

Spacing is pretty free-form in css. The most important exceptions are the space characters used between the first and last element of your css selector. Remembering the old days, it took me a while to figure out that the space character was more than just a way to increase readability. It wasn't until I started putting multiple classes on a single html element that I found out about the difference in both statements above. The W3C calls the space a descendant combinator, their exact definition can be seen below.

So basically, the simple selector after the whitespace could appear anywhere in the DOM below the simple selector in front of the whitespace for the full selector to match. It's a pretty vague relationship that doesn't cut it in modern web design, still we're stuck with this single combinator to do most of the work today. There's a very good reason for that.

ie6 and combinators

It's time to point fingers to that certain browser once again. IE6 is notoriously bad when it comes to combinator support. Apart from the descendant combinator there is not much that works. Now, it's not the first time that IE6 is being a bitch about css support, the thing is that there are no good workarounds to make combinators work like they should in IE6. It will basically fail to recognize your selector and ignore your well-written css.

/* child combinator */ .class1>.class2 {...} /* crappy fix */ .class1 * {margin:1em;} .class1 * * {margin:0;}

There are some JavaScript solutions to add support, just as there will probably be a .htc hack floating around, but none of these give any solid results. Attempts to fix it in css usually end up in tears, as the example above illustrates. The child combinator links selectors which are direct children (no DOM levels in between). The fix works in certain circumstances, but the last statement might overrule some elements far below .class1 which did receive a margin of their own. It's really no way to start writing css.

education

Most people learn css on their own. They check other people's code and try to understand what is happening. Some buy books, but even those can be quite vague when it comes to the different combinators available. Fact is that combinators besides the descendant combinator are hardly ever used in real-life web design. There aren't too many css files out there that make full use of the available combinators, even those sites that won't support IE6 no more.

That why it is extremely important to make junior css developers aware of the possibilities out there. When left to themselves, chances are that they will take a long time to find out about these crucial tools. Of course it's much easier to just tell them about what the space character means and how they can apply it, but if you leave it at that they will face a serious hurdle trying to overcome their combinator handicap later on.

the future

With all the blame put on IE6, you might expect that we will see some serious improvement once that browser is finally put to rest. That's why I would advise you to go out and try to make maximum use of these other combinators available. It won't take you too long to start noticing that there are still plenty of issues left to be discussed. Here's a short list of things I noticed so far:

• Readabiltiy greatly decreases when using ">", "~" or "+".
• The child combinator is rendered useless when inserting an extra wrapping element in your html code.
• There's no obvious difference between .class>*~* and .class>*+*.
• Setting up a basic parent/child grid (.parent>* {margin:1em;}) can be quite tricky.

Current day web development asks of us to design elements as separate components. Nested elements shouldn't necessarily be influenced and context should decide for itself how to handle these components. With all the extra combinators currently available I still haven't found a way to achieve these requirements. Furthermore, I've found some very practical issues when applying the current combinators as is. This is not very hopeful.

conclusion

The combinator remains one of the weak point of css. Sadly it doesn't receive too much attention from us web developers either. We as an industry are screaming for fancy graphical support, but with all that we still can't write solid, robust css code which is portable, reusable and flexible all at once. We often blame IE6, but those who tried using unsupported IE6 combinators might have noticed already that they won't really suffice either.

abstract case: where am I

Real-world case: I'm standing on this Earth, in Belgium, in Antwerp, in Central Park
Translated to css: .planet#Earth .country#Belgium .city#Antwerp .park#Central me

Before starting, let's consider this little abstraction of the issue we're dealing with. Throughout the article I'm going to use the above case to illustrate the difference between regular specificity and css specificity. It's a real world case easily translated to css, describing my current position on this very planet. I've used classes for generic concepts and ids for unique instances of these concepts.

specificity

Specificity is about eliminating options. Making a description more specific will eliminate the chance of error and misunderstanding. It's like a game of darts, where you try to hit the bulls eye. The concept was introduced in css because certain elements in the DOM could be targeted by multiple css rules. When the same property is defined in two separate css rules, specificity helps to determine which property will win the battle for dominance.

#Belgium me {...} .country me {...}

When they developed css they tried to mimic regular specificity as much as possible, but they hit a few problems along the way. In simple cases though, it works just as expected. By using ids and classes they managed to come close to what we would logically expect. In the example above, the the first rule is more specific than the second because the id marks a unique instance of the class, meaning what is targeted by the id should be more specific, which is obviously the case.

This is the basic idea of css specificity, but it lacks one major aspect that regular specificity has.

proximity

.city .park me {...} .planet .country me {...}

Consider the code above. In css, both rules have an equal weight because they both contain two classes. Because the second rule appears last it wins the battle of dominance. In the real world though, the first rule is considered to be more specific. It tells you I'm in a city park, the second rule only states I'm in country on this planet. Let's look at another example:

.country #Antwerp me {...} #Belgium .city me {...}

Again, in css both rules have an equal weight because they both contain a class and id. In the real world , the fact that the first rule uses an id for city creates a greater specificity than when the id is used for country. And one final example:

.planet .country me {...} .city me {...}

This example shows the problem is bigger than simply the order of our css statements. While the first rule appears to be more specific in css, in the real world the second rule would be considered the most specific of the two, as it manages to put a bigger limitation on my whereabouts.

What's lacking in css is the concept of proximity. The css language doesn't care how close (in the DOM) a class, id or html element is to "me", it merely sees how many of each are in a selector and computes a weight. Contrary to our everyday world, where proximity is pretty much crucial to determine the specificity of something.

time for revolution

So is css failing us? To truly answer this question we should work out a full model where proximity would be introduced in css. This is a bit too complex to do right away, but my gut feeling tells me that including (DOM) proximity would make things way more complicated. While it would probably be possible to create rules that lie closer to our own mental model of specificity, the clarity and ease of understanding of the current css model would probably be lost.

Maybe I'm wrong though, and some form of proximity could be easily included without completely messing things up, but that I'll leave to greater minds than myself. As for now, the issues that arise seem smaller than the trouble to go and change this core concept of the css language.

conclusion

Know that css specificity is different from what we normally understand when talking about specificity. I personally try to avoid the term specificity when dealing with css. I'd rather use "weight" to talk about selectors, as it comes closer to how it actually works in css. It doesn't make much of a difference, and from time to time I still find myself forgetting about the difference between both, but knowing where the exact differnece lies surely helped me in conquering this pretty common mistake.

a quick tour around the 4 panel

While the comic pretty much speaks for itself, I'm going to elaborate a little on the third panel which contains the essence of this comic.

When a css project is "finished" we are often afraid to dive back in and change stuff, because we've forgotten why half of the statements are in there and how they effect components across several pages. Many of the css files out there contain absolutely useless statements simply because "it worked any nobody dared to tweak it anymore". Just do some random probing on websites and you'll find an excessive amount of properties that are remnants of failed css experiments. They won't affect the current design, but might affect future changes. These statements are sure to come back and haunt you at a later time.

The final delivery of a css file is often met with an unhealthy amount of fear. By then the css is often unstable and untrustworthy, but "works" for the delivered design and html. Most of us just hope that there won't be any feedback and we can happily forget we ever worked on it. That is, until phase 2 is set up. That's when it crashes.

conclusion

This comic could be about more than just css projects, but css must really be one of the ugliest, uncontrolled and unchartered fields in web design out there. The lack of best practices, clarity, clean code and bad browser support results in time bombs that eat away at every project.

It's a pretty sad state of affairs that doesn't receive enough attention. While tutorials for the newest css3 properties are flooding the web there is very little to be found on how to improve the way we write, build and structure our css. As long as people keep neglecting this, there won't be a css3 property out there that will help to avoid the css crash of web projects out there.

You can use the comic at will, but please be nice enough to keep the credits in there.

the issue

/* base component ...................... */ .class ul li {background:...} .class ul li.first {background:none;} /* variant */ .class.variant ul li {background-image:...}

The code above gives you a simplified version of the issue we're looking at. Just think of this as the code of a horizontal navigation. The background images on the list items are there to create a visual separation between the navigation items (often nothing more than a boring vertical stripe). We've created a base component but the design dictates to create a variant with a different separator, so we've added a rule to change the background-image for the specific variant. That's where the trouble starts.

The thing I keep missing is that the weight of the second and third selector are exactly the same. Because the third selector is lower in the css code the first li element in the variant will again show the newly declared background-image. This is definitely not what I intended. All I wanted to do was keep the original component as is and change the background-image used to separate the navigation items.

not so good solutions

I've experimented a little and came up with four workarounds, one of which is commonly used to counter this problem. None of them is actually any good so I won't be spending much time running through them. I guess that most of these are pretty self-explanatory anyway. In short:

1. 1. change css order: put the variant rule above the basic component. This way the weight is still the same, but the base rule will come last in the source, winning the specificity battle. Messing around with the order of your css like that is pretty bad though.
2. 2. increase weight: add a random (but working) class befor the second rule. This will increase its weight, but apart from fixing this particular issue it makes no sense at all to do so.
3. 3. !important: Add !important to the background declaration in the second rule. Another abuse for the !important rule, so nothing I will recommend.
4. 4. duplicate styles: The most common solution, simply add a fourth rule that disables the background again for the variant. This means duplication of unnecessary css code, which I also dislike.

None of the solution above are considered extremely harmful (well ... maybe only the third solution), but seeing all the effort I put into maintaining a clean and readable css file, there isn't one solution I'd consider good practice. So let's go on to some more advanced solutions.

advanced solutions

You can read "advanced" as "not working (properly) in every browser". The key to fix this particular issue is to make sure that you only target the elements that need a background in the first place. Rather than overrule the background property of the first list element, let's make sure it never receives this background property at all. For that, we need some advanced css combinators.

1/ .class ul>li+li {background:...} 2/ .class ul>li~li {background:...}

Above are two variants on the same concept. The '>' combinator makes sure you're only targeting element on the same level, the '+' and '~' combinators both exclude the first (in this case) list element. Depending on the structure of your html you can chose what works best, though option 2 is definitely my favorite (as the ~combinator expresses exactly what we're aiming for). If you're working with different elements on the same level you can simply substitute "li" with "*".

This of course won't work in IE6, so if you still need to support that browser you can either leave this solution be or write some IE6 specific code in a separate css file. This means more work at first but a better css file when you can finally eliminate support for IE6 (and that time is definitely nearing). Your call.

conclusion

Even though this issue is not impossible to fix using some more advanced css selectors, there's still an underlying issue that remains. There is more happening here than simply bad browser support, but to really get to the bottom of this I'll post a follow-up article in the near future. So check back in a short while to read why an issue like this can keep creeping up on us.

quick recap

I assume most of you will know the basic difference between a px and em design, but I'll provide a quick recap anyway. px is a unit used for screens. It's an absolute measure that defines the size of an element based on the resolution of the client. On the other end we have em, which is a unit based on the value of the font-size. 1em equals the height of the current font-size (translated to px).

A good time ago em designs became in fashion as people starting thinking about the best way to handle font resizing using the browser. In an em design, the whole design is supposed to zoom with the font-size, making sure that none of the text spills over or out any graphical elements. Traditional px designs are not that flexible and retain their measures in absolute values, no matter what the font-size might be, often causing the layout to break.

Opera was the first to put a lid on the whole px/em argument by introducing a visual zoom to their browser. Rather than size the font, the whole site was visually zoomed. A nice feature, though you'll probably know that none of the browsers today can provide a perfect graphical zoom. Besides that, the method is somewhat flawed at its core because any images used will turn out fuzzy and unclear. Using em designs and simple font-sizing often gets you the better results (if it is designed as such of course).

designing for flexibility

The reason why px designs "sound" easier is because it is assumed that lengths are definite and unchanging. Once you receive the design, you can determine the width of elements, so trickier visual elements with rounded corners and drop shadows can be cut in lesser images. If you use images to create a box with rounded corners, inner fade and outer glow you'll quickly end up with 8 extra non-semantic and non-structural elements simply to accommodate all the background images. In a px design, you'll only need three.

At least, that's the common way of thinking. Which isn't exactly accurate if you like to write css with flexibility in mind. Assuming a width is definite is always a dangerous thing. I still have to participate in the first project where the design didn't receive some small touch-ups halfway through the development phase. Including changes in general layout, fe widening or reducing the width of side bars.

And even if you leave out the possibility of mid-project design changes, there's always the chance that a component will need to be used in an unforeseen area of the site. It isn't the first time I have to include an extra alert message in some or other component. If your css isn't flexible enough to accommodate these changes, you haven't done a very good job.

So even though you could start constructing your design in px values again, there is still the need to make the design of components flexible enough. An em design inherently focuses on this flexibility, making it clearer to incorporate this flexibility into your css. A px design might appear more definite, but if you're aiming to do a good job, you'll end up with just as much unnecessary html wrappers and just as many images.

so there's no difference?

parent>* {margin:1em;}

There is one major advantage that px designs have. The little css rule above defines a basic grid for all children of a certain parent. Since we are working with ems here, the actual size of the margin is dependent on the font-size of the children. While the rule gives the impression of ending up with an evenly spaced grid, the reality is that some of the children (often headings) will end up with a bigger margin because they have a larger font-size.

This is actually a pretty annoying problem (and my main reason for inserting a span element inside each heading I define). When applying a px design, you won't have this problem as the margin will be an absolute measure unrelated to the font-size of the child. The negative side is that when you size the font, the spacing between elements won't size accordingly, creating a somewhat muddled impression the more you size your font.

conclusion

While the need to avoid px for font-sizes is fading little by little, this doesn't mean you should simply switch back to the px design of the olden days. And when you do, make sure to remember that flexibility is a very strong asset in your work. Make sure that content can size horizontally and vertically without breaking the design, no matter whether you're implementing a px or em design.

As long as we'll have the need to use css background image to create certain graphical effects, the need for flexibility will stay and the difference between px and em design will remain rather futile.

The main thing to keep in mind is that whatever method you use and whatever design you are fed, designs are subject to change and implementations that are built to be resistant to such changes are of far more quality.

1. learn about semantics

And by that, I mean truly learn about semantics. Not just the simple meaning of the available html tags, but also the reasons why we aim to write semantic code. This might sound very simple, but take one of your websites and take a good look at the class names you defined. Did you give them simple names or complex computer-like descriptions. Did you make sure you applied them consistently across all the pages. Not to copy css or javascript functionality, but because the elements are essentially the same.

bad .productList li good .productList .product

If you have blog posts, products, events or whatever other returning content type on your site, did you make sure that every content type, no matter what its context, received the same class name? .productList li doesn't cut it. A program doesn't make the assumption that productList is a concatenation of two words, making the list items "products". A program sees two different class names and leaves it at that, unless specifically programmed.

You once read that it's smarter to define a base class to an ul rather than place a class on each li? Sure, I've read that too. It's not necessarily wrong, but we're talking semantics here, not styling. So take a moment to consider how you handle semantic value in your documents. Are you really thinking about semantic value, or are you just worried about how to get your css in there?

2. learn about structure

html is more than semantics alone, it's also about structure. Tags like header, section and footer are there not to give specific semantic meaning to elements, but to group elements and to express relations between them. They are the foundation of your document.

Don't write html as a means to style your site or to add certain functionality. Wrap elements that belong together not because they are visually grouped, but because they belong together. If might not be useful now, but once the code is implemented in whatever cms you will notice that these elements give you a more flexible html structure.

Concepts like iterative design and scrum allow for quicker and smaller updates. Make sure that the code you write is somehow resistant to these little changes, or even complete redesigns. If you have to ask a code change for each question asked, you'll end up looking like an amateur.

3. keep your css clean

Sure, you've read this a hundred times already, but do you actually make sure that your css file is as clean as can be. Did you define general sections like grids, navigation, simple content, components, forms etc to structure your css? Did you group all css rules for each component, starting from the root tag, gradually going deeper into the component. Did you separate different components with a little title in a css comment? Made sure that your whitespace between rules and sections make any sense?

I see lots of css files pass by on a daily basis that do none of these things. The idea of keeping a clean css file might make a lot of sense to you right now, but once you start styling, it's a lot harder to actually achieve it. Take a half day off and make yourself a template for your css files. Define which sections return in each project and stick to them. Keep all the css of a single component nicely grouped and make sure that you comment where necessary.

When phase 2 of your project starts, you will thank yourself. Other people working on your code will do the same.

4. think, evaluate, improve

Usually projects are running on a tight schedule. This means you'll have to make choices during development that aren't as well-considered as they should be. This is not a bad thing, just make sure to take the time afterwards to think them over. Have a good idea, write it down and implement it in your next project. If it doesn't work out, just drop it and try something new.

Becoming a good front-end developer takes time and practice. Just make sure that you learn from your mistakes. Some parts are harder than others, but if you keep looking at a certain problem from different angles you will end up with a solution that's at least satisfactory. And if you're really stuck, ask others to give their opinion. There's a world of front-end people out there blogging about their job every single day. Most of them are very willing to help you out.

5. don't believe the hype

If you want to be good, inform yourself. Doesn't matter whether it's books, blogs, colleagues or courses, just make sure that you are following whatever is going on in our tiny world of front-end development. Just don't believe all the hypes. Many bloggers use their articles as self-justification for their own methods. No matter how many times you've read it these last couple of weeks, don't believe that css3 is ready for use. Don't simply believe in graceful degradation.

Read and ask all you want, but be sure to make a critical evaluation of what is being told to you. It's all about agreeing, not about believing. Front-end development is a pretty specific field dealing with a billion different people, using a billion different setups. Make sure that you give them an experience worth having, even if they are using crappy hardware or software. Things might look good on your screen, but if they suck on someone else's, you've lost your credit.

Using the latest technologies is fine, as long as you know where their limits lie, what the impact is on future development and how they leave older setups. People are right when they say that a single person will not compare your site in different browsers, but be sure that he will compare it to other sites. And he might be wondering why yours is so square and using solid color drop shadows. He'll probably think your site is a little sloppy compared to all those others. Is that really what you want?

conclusion

Nothing new you say? True enough, but the fact is that these pointers are still being neglected to the point where many professional companies are coming off as truly amateurish. Like most things that appear simple, mastering them can be a real pain. So make sure that each new project you tackle adds something to your skills. Read, try and think and rethink if it's not helping you, that's all there is to it.

the tower of babel

There is no final css3 spec for css gradients, which blows. Firefox and Safari are currently holding on to their own vendor prefixes and syntax, which are wildly different from each other. A similar thing is happening with the css3 border-radius property, though the differences in the css3 gradient syntax are way bigger. My preference goes to the Firefox syntax as it ties in closer with the existing css syntax. The Webkit syntax feels more like reading an awkwardly constructed English sentence. On the other hand, the actual rendering of the gradient is much better in Webkit. A lot cleaner and homogeneous, whereas Firefox still shows clear color levels in certain gradients.

There is another problem in Firefox where a gradient defined on the body is repeated if the site isn't as big as the browser window. I haven't really checked for default behavior of the body tag in this particular situation, but Webkit simply continues the gradient over the complete browser area, which is a lot nicer. It can be fixed adding a min-height of 100% on both html and body tag, but clean it ain't.

Then there is Opera 10.5 which currently doesn't support css gradients, so no gradients for Opera users. This is probably not a bad thing as Opera isn't into vendor-specific prefixes. Introducing it now with a syntax that is nowhere near completion will result into bigger problems later on. And then there is IE of course. Usually the last one to get any of the spiffy features, though it turns out gradients have been possible in IE from IE5.5 onward, through the use of DX filters. Not the quickest or cleanest way to do anything design related, but as a last resort not such a bad option.

The conclusion is clear though. Three vendors, three syntaxes, not one of them according to any official spec.

specs and graceful degradation

What does this mean for the future? Imagine a final spec in a year or two. We then have to add the actual css3 proposed property, hope that Opera has the same syntax as the final spec, leave the vendor-specific properties alone until all versions that depend on the vendor-specific properties have died out and add the DX filters for IE. All that for one simple css gradient.

Sure it saves us one server request, sure it's a lot cleaner to do it in css, but I'm not really looking forward to this way of working. Certainly if you count all the other semi-supported css3 properties currently in use. The same will happen for border-radius and box-shadow. I'm not really pointing fingers (though I do believe Webkit and Firefox are being a little childish) but all these semi-supported css3 properties are not making our job easier and will become problematic in a couple years time.

So much for the graceful part of degradation.

mind IE

Also mind that even though IE support gradients, you still won't be able to use it in all circumstances. If you're reading this blog in the latest versions of Firefox, Safari or Chrome you'll see the gradients in the background of my site. If you're reading it in IE they won't be there. The reason is simple but wasn't immediately clear when I first read about the IE support for gradients.

The problem lies with the rounded corners of my main frame. Since the height of my blog isn't fixed I cannot predict where the bottom rounding will hit the gradient. As the rounded corners are done using images in IE I have to cut the background color inside the image,yet I don't know where they'll hit the gradient so I have no idea what background to cut into the corner images.

For IE I had to choose between gradients and the absence of rounded corners, or rounded corners and no gradients. I chose the latter as the impact on the rest of the site is a lot bigger. So know that css gradients can be used in IE, but they still don't act nice if rounded elements need to be positioned on top of the gradient.

conclusion

The conclusion is quite obvious. css3 gradients are cool if you can apply them to simple elements or if you have a client who can live with the fact that some browsers won't show the gradient. Sadly all the different implementation will muddle your stylesheet (the syntax isn't exactly short either) and will continue to pollute it long after the official spec has launched.

If you want quality gradients across all browsers, it's still better to work with a css background image. You'll have complete control over the rendering and it will work seamlessly across all browsers. But if you need to save server requests and you don't mind lesser implementations and muddy css code, at least you finally have a valid option.

how to define quality

If you ever had to judge the code of someone else you might already know how difficult it is to put some kind of grade on it. Not only because of differences in coding styles, but also because the quality of good front-end code doesn't really show itself at face value. The quickest way to judge is to take a look at the source code of the html, css and javascript, but that will only tell you so much.

I'm not too interested in defining a grading scale, as that is quite impossible anyway. I think it's more important to define what areas and scopes there are to define the quality of front-end code. In my experience, there are four important levels that need to be taken into account. I'll start off with the easiest and smallest one, working my way up from there.

1. making a page

This is where it always starts. You make or receive a design, sit yourself down in front of your computer, you pick your favorite browser and start work. Writing html, css and javascript to match a design and functional breakdown is quite the challenge in the beginning. As a non-designer it took me some time to understand the delicacies of good design and to translate those to a web page. On the other hand, this is probably the easiest part of the job.

Apart from design issues, you also have to worry about writing valid code and you have to make sure that your page is accessible to people not using regular web browsers. For most people this will open doors to a whole new and unfamiliar world, but it's essential for the overall quality of your code.

Checking the quality of this first level is quite easy. Code validators, a quick glance across the source and quickly scanning the page with css turned off will tell you a whole lot. But of course, this is only the beginning.

2. making a page work cross-browser and cross-platform

Time to zoom out. Making one single page to work in your favored browser is one thing, making sure it works okay in a range of browsers and operating systems is a whole different challenge. First of all, it is important to note that it's not necessary to have the page show up exactly the same in all browsers. For older browsers it suffices to make it look and work okay, just without the fancy stuff. It is important though to make sure all the functionality is still there. Sacrificing essential functionality is simply not done.

Usually worrying about browser-compatibility is something that happens afterwards, but it's actually important to have it in mind when you start on a project. Some techniques work better than others, some techniques are easier to fix than others. Choosing the right ones from the beginning will make browser-testing and fixing so much easier for you. Knowing the ins and outs of browsers and slightly changing your code course to steer away from the biggest issues is a long and tiring process, but it helps to improve the quality of your code by a great deal.

Measuring the actual quality of this level is a tad harder, though the length of the browser-testing phase is a good indication of this. The better you get, the easier it becomes to tackle browser problems, and the faster you'll be at making sure all browser show a page in an acceptable way. But even then, some extremely obscure bug might keep you up all night.

3. making a site

Time to zoom out once again. A site is more than a simple collection of pages. You'll notice that several components will be featured on different pages within the site, you'll also notice that css and javascript files will be used across multiple pages within the site. Keeping your code consistent across all those pages might be a lot harder than you first imagined.

The key is to think in components. html is a descriptive language, so independent of visualization or context, a certain "block of content" should always be constructed using the same html. An example I like to use is that of a news article. This can appear in a separate focus block, in a summary list, as a search result or as a whole on a detail page. Essentially it is always the same thing (a news article), so the semantic part of the html (also think class names) should be the same for all these instances. Variations in design should be based on context or by defining variants (adding an extra base class for differentiation). Once you got all of this covered, writing the correct css and javascript should be a a lot easier and code duplication will be reduced.

This level is actually quite easy to check. Simply take a few pages from a site, single out a few components with clear design variants and check how they are constructed and styled. If there is no common base, this will surely affect the quality of your site in the long run.

4. stability and flexibility

The three levels above are all important, but even matching all three criteria the quality of your code can still be quite subpar. Your code will only truly shine when it proves itself to be stable and flexible. The problem is, you can only measure this when it is effectively too late. You can look for several indicators though.

The first one is when you've reached the point of "the 5 last bugs". These are either last minute changes or bugs with a slightly lower priority you postponed because they are quite hard to fix. You know you did a good job when you can quickly dispose of them. On the other hand, if fixing these bugs introduces new ones or requires reworks of complete sections, there is still plenty of room for improvement.

Another good indicator is "phase 2". How well prepared are you to incorporate functional and design changes without ruining half your site. Can you drop an existing component somewhere else without having to rework the whole css? Can you make your left column wider by only adapting a minimum of css values and without recutting any images? Can you create a design variant of a component without having to deliver new hmtl code? How easy is it to switch places for components? What if a breadcrumb spans two lines? All these elements are indicators of the stability and flexibility of your code.

conclusion

If the quality level of scope 4 isn't met, it might cost you a lot of time, effort and money. Simple questions of your client will have to be answered by complicated technical answers your client doesn't really care about. It will lead to overtime, missed deadlines, stress and a decline in the relationship with your client.

It is a serious learning process though, as flexibility and stability are only attained by mastering the first 3 level and evolve from there. If you want to improve your skills, take a look back at the project you just finished and grade yourself on these four categories. See where you've slipped and think of ways to make sure it won't happen again. If you do so with each project, the sky is the limit.

the problem

First of all, let's take some time to define the problem. If you're serious about web design and css you've probably learned how to think web components rather than web pages by now. Style a component, style possible variants, use them everywhere and style them according to a changing context. This is a very clean way of working, but effectively not truly supported in css yet. Not even in the most experimental of specs.

<div class="focusBlock"> <header>...</header> <section>...</section> <footer>...</footer> </div>

Consider the html code above. A simple focus block (a somewhat generic name for a block that can be used for whatever content promotion - can be used in main content, contextual column and even navigation column). I've used some html5 elements to make the function of the nested elements a little clearer. The difficulty here is that just about anything can be nested within the section part of our focus block. For all you know (and care), they nest an article with its own header and footer section inside. That's where our styling problems start.

/* focus block ....................... */ .focusBlock>header

The little piece of css above shows the best way to style the focus block as a component. The > combinator makes sure that nested components don't inherit unnecessary styling rules belonging to the focus block. This method can already be used in all browsers (except for IE6). Sadly there's no real IE6 alternative to make it work well, and leaving it as is leads to rather ungraceful degradation. Annoying, but not the core issue right now.

The child combinator (as it is called) is a really helpful tool, but when taking a closer look it doesn't really provide a one on one match for our problem. There are two situations where it will fail horribly. First of all adding wrappers (usually divs) inside the focus block (and around the header, section and footer) will break the css completely. I know these elements are considered a "temporary setback" among the powers that be, but even then extra structural elements (with structural relevance, not added for mere graphical trickery) could mess up the css. Not good.

Even if you think the first reason is not strong enough, there's always a couple of functional tags that could equally break the css. What if you need to add a form or link tag (we can do that now!) around the header/section/footer? It will again break the css you've written before, even though the elements you've added have little relevance to content and style. It's a shame that every time such changes are made we have to go back to the css to fix things.

the solution

What we're missing is a combinator with a functionality that lies between the space combinator and the child combinator. A combinator that expresses that a selector can be anywhere below its parent, but only the first (level) it encounters will receive the css rules. What this combinator should be named or which symbol should be used is not something I'd like to worry about, but his functionality is painfully missing from our css today (and tomorrow). It's the only way to express the style of component in a truly flexible and logical way.

conclusion

I can respect the relative complexity of implementing such a combinator, but I believe it's an important functionality that would finally enable us to translate a design to css the same way we conceive it with our minds. I find it a little strange that such a combinator is still missing, so I assume there were good reasons to neglect such a combinator in the past. That said, I hope this article presents some solid arguments to possibly re-open an older discussion.

standards huh

A web standard is a trusted, solid, supported and unique solution to a particular problem. When people are talking about "web standards", they mean the collection of all separate standards involving front-end development. This might sound like a somewhat trivial point to make, but there's a good reason to have it out of the way.

The plural of the word "standard" often indicates that there isn't really a true standard to begin with. A standard can only be a true standard if it is unique in its implementation. Multiple standards can exist for fixing a particular problem, though resulting in a weaker and less pure use of the term. The existence of multiple standards is what we've been fighting all these years, trying to approach a "one problem - one solution" situation.

2009 turned out to be a pretty bad year for web standards.

browsers and evolution

In 2009 five big browser vendors ruled the world of web. Internet Explorer, Firefox, Safari, Chrome and Opera are divided among four different families of rendering engines (though in reality Chrome is just as different from Safari as the rest). Each of these families released different versions of their browsers resulting in a pretty wide area of browsers to support. This growth will probably continue in 2010, if not by as much as in 2009.

There is no real browser war like there was before, but it is obvious that these people are competing with each other. Implementation of the newest development techniques (css3 and html5) became a big thing again, luring the eager and bored front-end developer to start experimenting with these new options. This made 2009 a pretty interesting year, though also one of large frustrations.

was it progressive enhancement or graceful degradation?

Two other important concepts are progressive enhancement and graceful degradation. Both deal with catering for browser-specific audiences, making sure each and every person gets the full functional experience, but also providing the best possible solution for each separate browser version. Combined with the wild growth of browser versions over the year, this has made our job a lot more complex.

Certain new techniques are "available" to us, today. We can start using html5, we can do rounded corners in css, we can use web fonts and natively embed video. All these techniques feature a lot of "if"s and "but"s with different implementations for specific browser families and versions. If you want to use web fonts, you have to provide four (4!) different kind of font files and a pile of css for it to work. Go figure.

Rounded corners feature a similar problem. None of the browsers today follow the official standard (which doesn't even exist yet). There's a syntax difference between Safari/Chrome and Firefox, a rendering difference between Chrome and Firefox/Safari, no support for Opera (and no way to fix it) and a fallback method for IE. How terrible does that sound?

2010 and how to deal with it

Let's face it. IE will be lagging behind for quite some time. IE6 will still be there by the end of 2010, so how are we as front-end developers going to deal with these browsers, especially when 2010 will undoubtedly bring his own share of innovations for newer browser versions (a good friend of mine showed me an article on html5 forms, great stuff).

Adopting a new technique is doable, but adopting all these new techniques is just too demanding for commercial projects. Especially when we're still providing the time-consuming fallback methods which also work in newer browsers. Sure, designing for the future is a good thing, but not at twice the cost for a simple website. For example, it is perfectly possible to do rounded corners with (almost-)css3 for Firefox and Safari, leave Opera users in the cold (though the new version of Opera will support it) and provide images for IE users.

This is indeed faster for modern browsers (which are faster already) but a tad slower for IE (which needs to load the base css and the IE specific css). And the image solution still yields better results in Safari and Opera. So why go through the extra trouble to provide slightly faster (but not-standard) code for Firefox and Safari?

conclusion

If you look back at the hottest techniques of 2009, you'll see that almost all of them feature fallback methods and require more than one true standard to work. If you want to use web fonts, you have to stick to a different standard for each browser family. This is simply wrong, but on the other hand web fonts beat Cufon and sIFR to a pulp.

I'm still not sure how much I should adopt from these new methods. I'm eager to use new technologies. Ones that work faster, that are more logical and indicate the way of the future. But I also think it might be better to wait until they turn into a respectable standard before using them in any commercial project. It's not an easy choice to make, certainly while others are jumping on the boat already, gaining experience in what might be the techniques of tomorrow.

A very tough decision if you ask me. Opinions and input is always welcome!

10. All css frameworks are awesome

Or at least, that's what they want us to believe. I spent too much time this year trying to figure out how a particular css framework works, only to find out it's not really helping me. At all. These frameworks are definitely not a good thing and the time they're supposed to save you is lost on thoughtful and well constructed css setups. No more css frameworks for me in 2010.

09. Twuuuuuut

I'm on Twitter. I don't do much with it, but I'm on there. I still hate the inhumanity of the tool though. Shortened urls, bad user experience, dozens of desktop apps to fix the shortcomings, unreadable posts and untraceable discussions. Not worth the hype if you ask me, and it surprises me that no-one has taken the time to make a better version of Twitter yet.

08. css animations

The idea is cool, although I fear abuse will be much more common than sensible use. They shouldn't be used for functional presentation (expand/collapse) as css is a tool for presentation, not functionality. I also wonder about the practical implementation and who's going to do it. Animators will have a hard time with programming their animations in css, programmers will have a hard time with the creative process of the animation. And older machines and browsers will have a hard time handling the animation, pretty much ruining the effect altogether (same limitation as JavaScript animation). One thing is certain, css animation are not the next best thing and need a whole lot of rethinking before they might live up to their hype.

07. Go to br.gro.pbb.fs

Shortened urls. Revived by Twitter, horrible to use. Blindly following links without knowing where you'll end up is quite simply annoying. That and the fact that they look like utter gibberish in normal text. And they are known to mess up site stats. The benefits you ask? I have no idea. Unless you have a mere 130 character cap to work around.

06. No more ie6 excuses

If you like to stop ie6 support, fine. It's not very "web-like", but each firm or developer has to make the decision for himself. Just stop making up all these horrible excuses. Designing for the future, designs don't look the same in different browsers anyway, ie6 users have it coming ... The Digg survey revealed that about half of the remaining ie6 users have little to no control over their situation. If you stop supporting ie6, you're cutting those people off. That's your choice, be a man enough to face it.

05. Chrome = Safari

Chrome uses Webkit, so there's no extra work required when doing browser checks. Right? Hah! I've had more differences between Safari and Chrome than I had between Safari and Opera or Firefox this year. That and the fact that it's still a browser that adds absolutely nothing and is gaining popularity just because of Google's pushy behavior. Nopes, still not a fan.

04. html5 header tag, where's the functionality?

Quite irritating to see the discussions on html5 where people are questioning the "lack of functionality" for new tags like header and footer. Ten years of html awareness and we're still having these discussions? Come on people, if you want to work with html, at least learn what it's all about. Let's hope html5 will refresh people's memory in 2010.

03. Google everywhere

Google is too pushy. They try to be everywhere, there marketing is aggressive and people are simply accepting everything they do, hyping it as the best thing in the world. While in fact Google is lagging. Their output is often below par (time to update your search!) and their marketing simply deceptive. Google is thriving on fandom, never a good thing.

02. css rounded corners

Let it be clear, there is no decent support for css3 rounded corners in any of the latest browsers. Three of the major players have browser-specific extensions (with a different syntax) and nested elements can still spill over the rounded corner of its parent. The implementation is buggy, not standard and not global. If you're using css border-radius, you're not designing for the future. You're merely avoiding some http requests (which is still a good thing though).

01. browser support for all

The word "standard" lost a lot of its meaning in 2009. I already hinted at it above, but "support for all browsers" is becoming time-consuming business. You need 4(!) font files if you want to use web fonts, 2 types of videos for native video support, browser-specific syntaxes for new css properties ... we can make things work in different browsers by writing separate code for each browser. This is everything but a standard, only getting us back to the place we've started. These browser extensions are fine for experimenting, just don't tell people they "can use it without any trouble at all".

10. The Ever-Evolving Arrow: Universal Control Symbol

A very broad and in-depth article about something very simple. The arrow symbol. One of the cornerstones of the web that often goes by unnoticed. Which is why I loved the idea behind this article. A refreshingly in-depth glance at the seemingly normal.

Read the article: The Ever-Evolving Arrow: Universal Control Symbol

09. Internet Explorer 8

There have been a couple of major version updates for most browsers this year. But IE8 is the one with the biggest impact. For the first time since I've been involved in web development browser checks in 1 specific IE browser won't take me longer than checking Opera, Chrome or Safari. If you're still using IE6 or IE7, switch now!

Check the link: Internet Explorer 8

08. Digg takes the time to study the pain of IE 6

We've been staring at the stats for more than two years now. IE6 is still around and many of us wondered why. Digg took initiative and launched a little study among its users. The results were very interesting indeed.

Read the article: Digg takes the time to study the pain of IE 6

07. When can I use ...

So many browser versions, so many changes to the existing technologies. Ever wondered when you could finally start using a certain technique cross-browser? This little site helps you (plenty) in determining whether a feature is ready for use or not, and who's holding it back from going global.

Check the site: When can I use ...

06. There is no page fold

Countless blog posts have been spent on discussing the page fold. This little page illustrates perfectly well why these discussions are somewhat pointless. People scroll. Don't believe me? Try it out for yourself. Then show it to your clients.

Check the site: There is no page fold

05. Font Squirrel: @font-face toolkit

@font-face is one of the big breakthroughs of 2009. We aren't there yet, but there are solid implementations for each browsers so we can finally start using web fonts. Apart from some legal issues (which are serious), the world of web is ready. Font Squirrel is the perfect web tool for helping you out with all the different implementations.

Check the site: Font Squirrel: @font-face toolkit

04. HTML5 and The Future of the Web

2009 is the year of html5. Not quite ready yet, but web developers are starting to experiment away. Some very minor groups can't benefit from the new specs yet, but for the majority of the web the basics of html5 are ready to use. Be sure not to miss the boat.

Read the article: HTML5 and The Future of the Web

03. Working With RGBA Colour

A very lovely feature erasing all issues with transparency in the blink of an eye. Of course not supported in all browsers, though working very well in most modern versions. No more transparent text, no more transparent single-color pngs. Way of the future.

Read the article: Working With RGBA Colour

02. The 3 Basic Rules for Writing HTML

I've been spending lots of time digging to get to the core of html. And Mr Meiert wrote a very interesting article about the most basic rules of writing html. A little concise and open to erroneous interpretation, but this article does hit the mark. A good starting point for everyone getting serious about html.

Read the article: The 3 Basic Rules for Writing HTML

01. The HTML5 section element

The one that blew me away. The impact of the section elemnet on how we'll use headings is enormous, pretty much messing up a very important part of SEO optimization. I predict this will become a "big thing" for us web developers. A powerful new feature, but one that will require some adapting no doubt.

Read the article: The HTML5 section element

seo

Ah yes, the buzzword that made money flow like water for a good couple of years. Even us front-end developers loved the SEO hype, since we could tag along and demand proper html implementations as this improved rankings. Which is true, but only to some extent.

"Sadly", people grew wiser and found out that there are only a few html tags that will actually make a difference. True enough, good structure will help your ranking a little, but there's little difference between a clean div with one single class and four nested divs littered with CMS-specific classes. So even though you might have your paragraphs and heading tags, you still have no defense against the messy tangles of automatically generated CMS code.

SEO is still a valid argument in the battle for good html. Certainly with html5 being almost ready for implementation. html5 is a much richer language, which means you'll have more power to your disposal for marking up content and indirectly improving search-engine rankings. But for now, the scope of the SEO argument is limited to headings and paragraphs mostly. If the html code is truly horrible though, this is a good place to start.

future-proof, flexible, cost-effective in the long run, ...

I tried this one a couple of times before. It does work for big projects, sometimes. But when deadlines are nearing, money is running out and clients are breathing down your neck these arguments hold little weight. Suddenly html becomes a "phase 2" concern and all that matters is getting the site to work and look right in all (or most) browsers.

It's a shame, because well-planned html makes future updates so much easier. Especially when new parts are added to the site or complete redesigns are issued. It's the core of a website, so if corners are cut there, they will show themselves at later dates. These arguments will hold some weight when explained in the beginning of the process, though will find little support for improving any current implementation.

Also note that you are practically taking away work from those implementing the site. A complete redesign usually means work (and income) for the implementors too as there are usually quite some code changes. By implementing solid, future-proof html this work is brought back to a minimum. Good for your clients, but make sure you don't offend your technical partners in the meantime.

stylability

This is actually one of the most solid arguments out there. Badly implemented html makes it way more difficult to style a website. In several ways. For one, finding "your" class in a string of 6 or 7 badly-edited cms classes is not as easy as simply picking out a single value in the class attribute. Secondly, styling on cms-generated classes is usually quite dangerous as they reflect the inner kitchen of the cms and hold little to none semantic or structural relevance when it comes to the actual document. Who knows where else they might end up.

Missing classes or missing structural html elements will result is unstable css, creating problems cross-browser. And switching to default classes might (and in our case will) hurt predictability of the code. For example, at my current job we hardly need the html code to start styling the main navigation as structure and class names are standardized.

There's also a timing issue. After creating the html templates you could start working on the css. But only if the implementation of the html is (as) perfect (as possible). If not, most of the css work will be useless anyway. Waiting for the implementation on the other hand does add some extra time to development as css work and implementation can't happen at the same time.

The bottom line. Bad html will jeopardize the quality of the css, will jeopardize the quality of future updates, and even more importantly, might hurt the wallet of your client as this extra work needs to be paid. And best of all, there are very little counter-arguments against this argument.

analogies

Analogies! Always helpful when trying to explain a somewhat vague concept like html. And always someone who tries his best to find the differences with the analogy you are making. I've been looking for a good one to explain the importance of html, but found it rather hard. One analogy that's often cited is between building a website and a house, but html doesn't really fit in as front-end development is a step between architectural work and the actual physical work not (often) present in construction.

The best analogy I came up with is the difference between a golden object and a gold-plated object. This concept is understood by everyone and illustrates the difference between a web page constructed using correct html and one using crappy html. Even though the difference between both objects is not immediately visible from the outside, there is a definite difference in quality (and worth) between the two.

Gold-plated objects only have a golden shine. The top layer (css in the analogy) hides what's underneath, but over time the golden object will prove to be way more robust and thus valuable. It's also stronger and tougher, with a higher resistance to external influences. But there's more than simply the nature of the core material, there's also the texture. If the texture of the core material is rough, you need more coating material to smooth out all the irregularities. And the more coating you need, the more expensive the object will become.

Like all analogies not perfect, but still clear and understandable, even to non-tech people.

about languages

We all know that html is a descriptive language, with its own spelling and grammar rules. Much like the human languages in fact. We write it to describe elements within a page, giving meaning to components and making it possible for automated features to recognize these components and process the data for whatever reason possible.

The html language is a very simple language with few words. To cover for the unknown elements we have the div element, equivalent of the English word "thing". Further specification is done through classes giving our "thing" extra semantic meaning. For elements that do have an equivalent in html, we use the assigned tags. This all sounds very logical, but the reality is quite different.

draconian error handling

The difference? In case of human languages it's our brain doing the error handling. We are interfacing directly with the language. In case of html, we interface with the product of the language (the actual web page), not the language generating the page. That's why it's not immediately apparent when the html of a page is full of grammar and spelling mistakes, as the browser effectively hides (almost) all the ugliness from us.

Ai coud rait laik dis and with a little bit of effort you would be able to read it perfectly well. Still, people would be quite annoyed if I wrote entire articles likes that, no matter how interesting the content. But when talking about html, people don't seem to care, even when it's bordering on complete nonsense. Since there's an automated service trying its best to cope with these errors, it appears to be free for all.

history

To be fair, this way of handling html did help to launch the internet. It eclipses some of its finer points and helped in getting things online for people to see. In many cases, badly marked up content is better than no content at all. But for professional websites, it is time we stop ignoring the potential of html, as its current state is actively hindering the progress of the internet today. Semantics in combination with automated processing is an area still very much underdeveloped, partly due to bad html structure and grammar.

conclusion

While there are little arguments against well-written html, it's a sad fact that all I've written above will usually get you nowhere. For now, html is still considered a low priority, and when CMS or other automated html-generating tools remain spewing grammatically incorrect code.

When you compare it to human languages you will make people understand, but at the same time the argument is too theoretical to have much weight when a crisis is looming. Next article will delve a little deeper into more practical weapons to battle the rapers of html. Stay tuned.

issues

While such strings of blocks are popular elements featured on many web pages, there's not really one clean way to css them. The main problem lies with the outline of the blocks related to elements above and below. You need to set a margin to push the individual blocks away from each other, but since the blocks are floated none of the margins will collapse. This will create an extra space to the left or right which is unwanted in most designs.

There are a few typical solutions to fix this. You could mess around with the left or right spacing of its parent (leaving a space equal to the margin between the floated blocks) or you can work with a .first or .last class, using it to nullify the margin on the first or last block within a row. The first fix is messy and upsets the logical flow of the css. The second option only works if you know how many items will be in a row (in other words, it fails in liquid designs) and is quite ugly to implement.

issues

<ul> <li>...</li> <li>...</li> </ul>

We're going to use the above html as a base structure for our floated blocks. I usually add a structural div around it to allow for headings and such, but this is not really important for the issue at hand. The html is composed of a simple unordered list. The li elements will be floated, the ul will act as the container for the floated blocks. The unordered list is a typical way of marking up such elements, but you could just as well use nested divs if you'd like.

ul {overflow:hidden; margin-left:-1em;} ul li {margin-left:1em; width:Xem;}

The trick is very simple. Rather than mess around with the spacing between its parent we'll use the ul to create the needed space. We'll pull it to the left using a negative margin equal to the margin defined on the li element. This way the first block will receive the same position as if no styles were applied and the last item will be able to align with the right edge of the element (as we've used a left margin). All that is left is to determine a good with for the alignment to work. Note that the same method can be applied for vertical alignment.

This little trick requires us to keep two separate values equal to create the effect, which is something I don't like doing. In this case though, it's better than the alternatives I listed above. As we're using negative margins we'll have to add a position:relative and zoom:1 for IE6 (what else is new) and we have to be a little careful with overflow:hidden statements on surrounding element. If for some reason the negative margin is bigger than the margin on the floated blocks than you'll have to use a different clearing method as some elements will hide behind the overflow.

Check the test page to see it working.

conclusion

A very simple trick, but one that many people seem unaware of. Nothing earth shattering, but a good trick to have in your inventory, resulting in cleaner and leaner css. As often the case, the good stuff doesn't have to be hard. Enjoy!

new and improved

As promised in our previous article we looked into incorporating a fix for transparent background pngs. This quest led us to a pretty interesting method conceived by the good people behind TJK Design. This fix is not exactly perfect, but it's as good a fix as I've come across. It messes around with scripting and IE css expressions to achieve the wanted result, but can be a little hard to memorize.

First of all a little word of warning. This fix will only work for clients who have scripting enabled. The fix makes use of javascript and Alpha Filters (Direct-X), so if your visitors won't or can't support these techniques it will fail. Probably worse is the fact that the fix breaks the css background-position property. In other words, the fix is only useful for images positioned top left (which is the standard background position value). And finally, the fix can become a burden on the performance, so be careful not to overuse it.

What our tool does is look for all pngs in a given css file and apply the fix to all the selectors it finds. Depending on what image formats you prefer to use, the selector list could become quite long and the fix will be applied to a series of selectors that don't need fixing. After applying the fix it's key to make sure that only the needed selectors are making use of it.

So why include this if there's such a high chance of breaking stuff? Well, simply because the code is a bit too complex to memorize, and removing some unneeded selectors is often faster than remembering where it was you last used this fix. Remember, it's purely optional, so if you consider it not worth all the trouble, simply leave it unchecked.

that's all folks

So that's all for the 0.7 release of the IE6 CSS Fixer. For thoughts, comments or suggestions you can always contact us. More updates sooner or later!

Check out v0.7 of the IE6 CSS Fixer.

detecting there is no javascript

document.body.className = document.body.className.replace("noJS", "");

Our first problem is finding out if a user has javascript enabled, which brings us to a rather interesting technique that could be used independent of the whole html5 deal. The trick is to add a .noJS class to the body element of every page. Then, first thing after opening the body tag we insert a little javascript removing this class. If the .noJS class is still present after that, you can be sure the user has javascript disabled. You can now use the .noJS class as a selector prefix for restyling elements when javascript is disabled.

Note that the javascript above "does the trick" and isn't the cleanest or leanest way possible to do this. Also note that this action should be done as quickly as possible, that's why I chose to do it right after opening the body tag. Unobtrusive ways require a longer waiting time and waiting for document loads or other events will most likely cause some graphical glitches as the base css might already be applied while loading the page. Modern browsers are getting quicker, but remember we're also doing this for IE6 users.

<!--[if lte IE 8]> <link rel="stylesheet" type="text/css" media="all" href="/style/html5-ie.css" /> <![endif]-->

The .noJS class can be used for all situations were no-javascript degradation is required, but in this case we only need it to handle IE browsers. That's why we'll create a separate css file for our downgraded design and serve the css through conditional comments. We can use the same conditional comment we created for the html5 shiv javascript file, which is quite nice. You now have all the means to serve javascript-less IE users a downgraded design.

how to be a gentleman

Serving a seriously degraded design is still a pretty drastic decision, and most people will probably fail to understand what has happened to your site. Just put yourself in their place. One day you are visiting a nice looking site, next you know the design went from nice to completely crap (but still usable). It's only fair to inform them why this is happening to them. Sadly, actually doing this in a clean way is not as easy as you might think.

Remember that we are doing this for IE users without javascript enabled. That means you can't use any normal overlays or spotlight effects to draw their attention. Also, I wanted the message to appear only once, namely the first time they visited my site after I switched to html5. Only on their specific demand should they be able to see the message again. It took us a while, but we worked out a solution. Here goes.

being a gentleman

First thing to do is to create an overlay which will be inserted the first time they visit your site after the switch. The .noJS class is extremely useful as you can style the overlay to show by default, effectively hiding the rest of your site. Simply add a specific class to the overlay you'd like to show and apply all styles to .noJS .your-preferred-classname. So now they know.

Of course, once they've read the message in the overlay you shouldn't bother them anymore. Setting a cookie is a good place to start. As long as the cookie is set (from the back-end, no javascript remember), you can make sure the overlay isn't inserted in the html code. So what about people without cookies? A bridge too far you say? Well, maybe, but with the current solution these people will keep getting the overlay for each page, and since they don't have javascript either the only way to reach a new page for them is through an actual page refresh, triggering the overlay again and effectively making your site completely inaccessible.

So we looked a bit further and came to the url referrer. This parameter (accessible in the back-end) will tell you where your user came from before he hit the current page. If your domain isn't in the referrer you can show the overlay, since you know it is the first page on your site he hits. If your domain is in the referrer, you keep the overlay out of the html code. This means that a visitor with javascript and cookies disabled will see the message with each visit, but that's his punishment for being so stubborn I guess. Some quick testing revealed that the referrer was also entered for new tab and new browser hits, which only works to our advantage.

Finally, you can add an additional check on the user client string, filtering out IE users. Another security measure it to delete the overlay with javascript on body load. This way, there's no way it will ever surface in the wrong circumstances. Furthermore, it's a good idea to add a little warning box which can trigger the overlay again at any time, overriding any of the previous conditions. There's always people who might want to read it again. This warning box can be easily hidden for javascript-enabled and non-IE users, using the noJS class.

conclusion

A whole lot of trouble for just a couple of visitors? Maybe, but you can take from this method whatever part you like. There's no shame in dropping the url referrer option, or to simply insert a contextual box for IE/non-javascript users which directs them to a separate page containing the message. This method is merely an exercise in graceful degradation, and trying to be as graceful as possible.

If you want to see it in action, visit my blog with IE and javascript turned off. You can even disable your cookies (and make sure to clear them first) to see the referrer option in action. Again, this method is a bit far-fetched, but it should give you all the means to be as polite about it as possible. If any other measures or workarounds exist, do let me know.

clearing the skies

Before I start let it be clear that this article is not about any of the new functional html5 elements. Elements like video and audio are unsupported in older browsers and should be approached with graceful degradation in mind. This are elements which require added browser functionality for them to work. This article will focus on the use of new semantic and structural elements (like nav, aside, header and footer, ...), which require no additional browser functionality to be of any value and, at least in theory, should be ready for practical use.

starting with the good

You would assume that making use of these new elements is quite straight-forward. And for most modern browsers this is actually the case. Even though the new elements lack any standard css styling (fe you still have to explicitly define display:block for header and footer elements in css) they are accessible for use in css and javascript and they automatically carry their semantic weight in them.

Of course, when I say most modern browsers you already know what's coming. None of the IE browsers available today allow you to use these elements in css or javascript. On top of that, FireFox 2 has a DOM issue were the engine will immediately self-close each tag he doesn't recognize as html, completely ruining the html structure. The new html5 elements won't wrap the inner elements any longer but will be placed above them, containing nothing.

/* basic html5 */ <nav class="mainNav">...</nav> /* fixed html5 */ <nav> <div clas="mainNav">...</div> </nav>

One possible solution is to add the new elements, but strip them from all classes and ids, also making sure there are no direct references to them in the css and javascript. Then, transport the classes and ids to an inner wrapper (preferably using a div element). This is shown in the code example above. This solution will bloat your html like hell and sounds rather pathetic, but in reality it isn't (... quite as bad as you might think). After all, you're still adding richer semantic and structural information to your html document, which is exactly the purpose of these elements.

Currently this is the only know method to incorporate html5 elements without sacrificing any support from most everyday common browsers. Even FireFox 2 should handle this well, as this setup will only result in some unstyled and empty elements scattered through the DOM. Then again, I believe this has very little real world value, so let's see what else we can accomplish if we try a little harder.

sacrifice

If you plan on taking a different route, you should be prepared to make some sacrifices. Currently there is no flexible solution for FF2 users. That doesn't mean people are not working on a solution, but for now there's not much in the way of FF2 support. You can either write a custom js function, fixing the DOM after it has loaded completely (which doesn't sound too maintainable and might cause design jumps) or you could serve your pages as xhtml. Know that this will kill of any page on your site that doesn't validate according to the xml specs (resulting in a yellow screen of death), so it's best to do this for FF2 users only. A risk I'm willing to take with my blog, but for commercial sites or sites that gather user content I would strongly advise against. A detailed explanation of both methods can be found on the html5 Doctor site.

<!--[if lte IE 8]> <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js" type="text/javascript"></script> <![endif]-->

Then of course there is still the IE problem. Luckily here we have a better change of fixing things (which in all fairness is also an IE constant). Quite early on a little javascript was made available to fix html5 support in all IE versions. The html5 shiv principle is quite simple and works like a charm. The code is hosted on Google Code so you won't even have to download the actual file. The rule above will serve the javascript to all IE browsers, leaving the other browser families alone and providing (near) full support for the new semantic and structural html5 elements. Ain't that sweet!

This just leaves us with a group of IE users that's cruising the net without javascript support (for whatever reason). There's not much we can do for them, but there is something. What we're going to do is serve them an extra css file based on the non-html5 elements. This means serving them a seriously degraded design (as you won't have as many structural elements to work with), but it does give you an opportunity to even out any graphical nonsense resulting from styles that could not be applied. How much you'll have to degrade your design will depend on how many html5 elements you used and where you added your classes and ids, but it will never be as bad as leaving the site as is. The result will still be a fully functional site, only with a bare bones design.

conclusion

Actually providing this extra css file is a little harder than you might expect, especially if you want to be a gentleman about it, so I'll leave that for the next article. Still, this article should have given you a good enough idea of the current issues with implementing new semantic and structural html5 elements. Reading all this might discourage you, which isn't all that strange as there are still plenty of ifs and buts here, but for personal and non-commercial projects I would say that things are looking bright enough to start experimenting with these new elements. Alternatively, be sure to check FF and IE stats before you consider sacrificing browser support. You might be surprised how many people out there are still using outdated browsers.

The next article will delve a little deeper and will provide a method to serve IE users without javascript support with an alternate layout and a nice warning message. So stay tuned.

dead ends

These last couple of months we've been looking into minimizing unwanted effects resulting from the use of our tool. Sadly all our experiments have failed as we're lacking the html on which the css gets applied. This makes it impossible to find out what the range of css properties is for each element on a page. Our tool applies fixes based on each separate rule in a css file, but isn't aware of overriding or cascading. As for now this remains the biggest issue in our tool.

.error {background:url("");} .error.spec {display:inline;}

Currently we have one possible optimization, explained by the little code snippet above. Our tool will place a zoom:1 on the .error class if the background fix is applied. This poses a problem for elements set to display:inline, so for .error.spec we could set value of the zoom property back to 0. It's a very small fix which doesn't sound too effective as this is still not a 100% fail-proof solution. We're keeping this option open, but don't expect it to appear anytime soon.

new, new, new!

On to better news. The most notable addition to v0.6 is the option to fix transparency for ie6 (and 7 for that matter). The fix scans for the opacity rule in the css and replaces it with the IE filter statement. Mind that this doesn't work for transparent pngs, only for those rules where the opacity property is explicitly defined in the css. Also know that the IE filter fix doesn't work with scripting disabled in IE. These are the normal constraints of the fix, there's little our tool can change about that.

The second addition is an option to generate the fixes for IE7 (using the IE7 specific hack). Not all fixes might be necessary for IE7, but we noticed that by applying them to IE7 nothing breaks and stuff still gets fixed in the process. What we usually do is place the generated code in a css for IE7 and below (through conditional comments), only excluding the part about min-heights as this works in IE7 by default and the fix will actually break IE7 behavior. As the conditional comment solution is not always available (project constraints), we added the option to generate the fixes specifically for IE7 (without the min-height fix).

Finally some minor code changes were made, making the tool a tiny bit faster, though this is hardly noticeable. Still, faster is better.

future additions

We are still looking into adding an option that accepts a url to a live page which will filter all the css found in the html code (of that single page) and applies the fixes for the combined css. Sadly we encountered some issues, mostly related to password-protected sites (usually the case for development environments, which we assume will be a typical scenario for this particular option).

Besides that we'll be looking in the transparent png fix for ie6. This will probably be added in the near future, but will be marked as "dangerous" as it could destroy the layout in a fair number of cases. The fix breaks the background-positioning property (the image will always be positioned top left) and as it will be applied to all pngs found in the css this might very well have some negative effects on the layout. Still, we believe it will be useful, even if you have to remove some lines from the generated file, as the fix is quite messy and almost impossible to write from memory.

So that's it for now. If you want to test out v0.6 of the IE6 CSS Fixer tool, it's still at same location. Hope this helps!

what are they?

The header and footer are structural html elements. For the last couple of years the focus of html has been semantics, but html is more than semantics alone. The header and footer elements don't really tell you what kind of data is in them, they tell you how that data relates to the main content of a certain content type.

The header and footer elements are structural elements and will help you to build a more structurally meaningful document, giving queues as to how parts of contents relate to other parts. These two elements come to the aid of the div and span elements, relieving some of their functions. A good thing, as they aren't really the most popular tags to begin with.

what do they do?

Both header and footer elements don't do anything. They weren't conceived so they could do anything. Some people still seem to assume that html elements should do something in a browser. This doesn't have to be anything big. Take for example the p element, which typically comes with a standard margin defined. To some people, that seems to be the only function of the p element.

Standard browser styling is not a bad thing, but it has little to do with the html element itself. Just look at all the talk about reset css files, nullifying these exact browser css rules. The core of html is still semantics and structure, which, from the point of view of a visual browser, is something that doesn't really surface in the visualization of elements.

what's their semantic value?

Close to none. Surprised? Well, like I said before, there's more to html than pure semantics. Similarly to div and span elements, the header and footer elements don't really give you an indication of what can be found within.

Still, their function is a welcome one. Those of you remembering the whole "divitis" deal will probably see where the value of these two new elements lies. Curing "divitis" is not done by removing a whole bunch of divs, or by renaming them to p and ul/li structures. It is done by increasing the diversity of structural elements. Elements that give extra information about the structuring itself.

That's what the header and footer elements are for. The header element holds information that's important to know before the bulk of the content. Typically there's a heading telling you in short what to expect, but other data like publisher, publish data, rating, ... can be included too. The footer element has a similar function, but holds data that comes as an afterthought to the bulk content. A 'read more' link, link to comments, 'send to a friend' link. All these things are only useful after you've been through the bulk of the content.

And rather than using divs to group this content, we now have header and footer elements, reducing the amount of divs used and adding extra meaning to the structure of the document. Who benefits from this? Programs interpreting our html code, ranging from screen readers to search engines or even customized code.

so it's all good?

Some time ago most outstanding issues with the footer elements were solved. As of now, almost all restrictions are lifted, allowing you to throw in whatever element you seem fit. At first the footer element couldn't hold several other html tags, making it in some cases absolutely useless. Luckily we have some people looking out for us, so that's one thing less to worry about.

There is of course still the problem of when to include these extra elements. If there's only a single heading present, should it still be wrapped in a header element? A question that already exists today and which I usually answer based on the probability of extra elements being included at a later date. But as a default answer, I would say that header and footer elements should be included wherever they seem appropriate, even if there's only one nested element inside, especially now they provide extra meaning to the document structure.

Of course there's still IE, which doesn't recognize these elements without the use of some clever javascript, making it impossible to apply any css to these elements. A real pain, but as long as you include a little javascript file (and maybe even provide some simplified styling for people lacking jsavascript) you're fine.

Only remaining issue is related to cssing nested elements. Older versions of IE still don't support the '>' (child) selector, which might make it difficult to style nested content. You could of course overrule a whole lot of css for the deepest nesting, but this is hardly beneficial to the flexibility of your css. So for these cases, extra classes for differentiation still work best. In the end this doesn't reduce the amount of classes you use, but it still provides extra meaning to the structure of your document.

conclusion

Will these elements change the web forever? Probably not, but they do underline the structural function of html, which is definitely a good thing. Also something many people seem to have forgotten after joining the divitis mob.

The header and footer tag reinforce the structural value of html. That's what they are all about.

finding a solution

As far as I know there is no elegant solution to this problem, but elegance is not always a key factor. There's a huge difference between "I cannot do it" and "it can be done, but it'll be dirty and time-consuming", especially when talking to project managers who demand results. And so I started looking for a solution that worked, not one that would revolutionize the world of css. If you start from there, it's actually quite easy to accomplish, you just need wrappers. Tons of wrappers.

One rule I set for myself was not to use any empty structural elements above, below or inside the box. Even though some people see wrappers divs as an equally dirty trick, at least they maintain structural integrity, while empty structural elements mess up the structural composition of your document.

the basics

/* the images */ .box {background:url("corner-1.gif") right bottom no-repeat;} .boxWrap1 {background:url("corner-2.gif") right top no-repeat;} .boxWrap2 {background:url("corner-3.gif") left bottom no-repeat;} .boxWrap3 {background:url("corner-4.gif") left top no-repeat;}

The key is to make sure there just isn't a background color behind any of the transparent images. We start by setting the four corners of the box. That leaves us a cross-shaped area in the middle to fill with the background color of the box.

As a little side note, I usually apply a strict order in placing background images. Bottom right corner first, then bottom left corner, top right corner and finally the top left corner. It doesn't matter much when you're restricting yourself to pure wrapper divs to apply said images, but if you're using structural elements part of the contents of the box (hX tags or footer tags) the bottom right corner is usually the hardest one to reach. That's why I apply it as quickly as possible.

Like I said, just a little side note. You don't even need to agree with the order I'm using here, but any strict order will increase predictability of code over time. Just make sure to set a standard, even if it's just for yourself.

Check out the first example on the test page.

the trick

/* the background color */ .boxWrap4 {margin:0px 8px; padding:8px 0px; background:#cc0;} .boxWrap5 {margin:0px -8px; background:#bb0; } /* ie fixes */ .boxWrap4 {zoom:1;} .boxWrap5 {zoom:1; position:relative;}

The difficult part is getting the background color in the remaining area of the box. First we apply a left and right margin the same width as the corner images, and a top and bottom padding the same height as the corner images. Giving a background color to this wrapper fills in the center area and the top and bottom strips between the corners. Next we apply the same background color and a negative left and right margin (same numbers as the margin defined on its parent), so we can fill in the remaining left and right strips between the corner.

If the width of the top and bottom corners differs, choose the widest of the two. Same goes for the height of left and right corners. And to make this work in IE, we need the typical fixes for negative margins. Nothing too complicated.

Check out the second example on the test page.

the finishing touch

/* the background color */ .boxWrap6 {float:left; width:100%; margin:-8px 0px;} .boxWrap7 {padding:5px;} /* ie6 fixes */ .boxWrap6 {position:relative; zoom:1; padding-right:16px;} .boxWrap7 {position:relative; zoom:1; margin-right:-16px;}

In most cases this should suffice. The only remaining problem is that the inner box doesn't span the complete surface of the outer box. If you have big corner images you could be losing a lot of valuable space. The design might even dictate that text should be appearing in the strips between the irregular corners. To fix that we need two extra wrappers. The first one is floated and given a negative top and bottom margin (same size as the padding defined by the heights of the corner images). We also need a width:100%; to make it span the whole box. The second wrapper adds the needed padding to push the most inner box (boxWrap7) away from the edge again. Because of the width:100% declaration on the floated wrapper, this needs to be placed on an extra wrapper, otherwise you'll mess up the widths.

ie6 doesn't like this though, and loses Xpx (X being the sum of the left and right margin) with the float. Adding Xpx padding on the float and crossing it again with a negative margin on the next wrapper fixes this. I'm sure there must be a more elegant way to do this, but nothing I tried worked so far. Please do share your thoughts and fixes.

Anyway, check out the final example on the test page. A border was added to illustrate the position of the most inner box.

conclusion

As you can see, elegant it is not. Many double declarations and computed values of paddings and margins. It's a pretty messy setup requiring 5 extra structural elements and a massive 7 if you want it perfectly controlled. On the other hand, if anyone knows better alternatives which are just as flexible (and using wrappers, not empty structural elements), do share!

In the end, the technique works, cross-browser and without too many hiccups. And even if you despise the use of so many extra wrappers, you can now tell your project manager you know of a way, you just don't like the implementation. Looks better on your CV, trust me.

1px rounded corners

The technique we'll be discussing today is suited for a specific kind of rounded corner. By cutting out the 1px corners a designer can give the impression of a rounding without actually designing some elaborate rounded corners. It's an easy technique with good visual effect.

To implement this we could stick to our regular patterns, creating four wrapper divs and applying a 1px background image (correct color) in each corner. This works fine, but means a lot of hassle for such a simple visual effect. And remembering the problem described earlier, cutting several 1px images in different colors and providing all the right classes could become a tedious job. There has to be a better way to do this.

css'ing outside the box

/* example 1 */ .example1 .outer {background:#0cc; margin:0px 1px; padding:1px 0px;} .example1 .inner {background:#0cc; margin:0 -1px;} /* example 2 */ .example2 .outer {margin:0px 1px; border:1px solid #0cc; border-left-width:0; border-right-width:0;} .example2 .inner {background:#cc0; margin:0 -1px; border:1px solid #0cc; border-top-width:0; border-bottom-width:0;} /* combination */ .example2 .outer {background:#0cc; margin:0px 1px; padding:1px 0px;} .example2 .inner {background:#cc0; margin:0 -1px; border:1px solid #0cc; border-top-width:0; border-bottom-width:0;}

The solution is simple and only involves two html (block) elements. The outer element will set a simple base color, the inner element will be pulled 1px outside the outer element on the left and right side. By making sure the inner element is 1px away from the top and bottom of the outer element the wanted effect will be created somewhat out of the blue. It's really as simple as that.

Example 1 shows this technique using a top and bottom padding on the outer element. The inner element contains the core of this technique, the 1px left and right negative margin. Example 2 is more or less the same but uses borders. This way the padding is not needed. A combination of both techniques (padding on outer and borders on inner) could also be used. The extra left and right margin placed the outer element is to keep the box within the correct vertical flow of the document.

I prefer the first example for situations where the background color is singular since it doesn't need as many color definitions. If the border color differs from the background color you could either pick example 2 or the combination of both methods. There's no real theoretical preference there, though I myself would probably pick the combination method (hate those border-x-width statements).

Whatever method you choose, since we are using the negative margins the color of the 1px corners will automatically take on the right background color as these pixels are not actually part of the box we are building. And there is more ... this technique works in all IE clients without extra hassle. Yay for that!

Want to see this in action? Check out the test page demonstrating example 1 and 2.

conclusions

You often see this type of rounded corners used with buttons layouts. Rather than start wrapping them like over-sized Christmas presents you now have a better way of handling these little design critters. This technique won't help you with other cases of rounded corners, but every little bit helps.

The technique works well cross-browser, requires only one extra wrapper and supports alternate border colors. And you don't have to worry about the visual context of your box. If only all css tricks were this easy.

back-end implementation

Before I was hired at my current job I worked for a firm where I had to do almost everything from start to finish (excluding design work). Database setup, html/css/javascript and back-end coding were done almost simultaneously. It's there I learned that doing all these things yourself will often compromise the quality of certain aspects. More than once I changed html code simply because it was easier to implement in the back-end.

This has a serious impact on the quality of the final product, though at the same time I realize that the decision between fixing an error in the price calculation or adding a seemingly useless class to the html is an easy one to make. What I suggest is rather than forcing such decisions it would be much better to eliminate the need for these kind of dilemmas.

the invisibility cloak

While it is quite easy to explain the importance of css, it's usually a lot harder to do the same for html. The reason is simple: html is hardly visible. There is no way you could say anything about the quality of the html by using a website or by looking at it. The cleanest and brightest html can come of as ugly when the css or back-end is badly implemented. Similarly, the crappiest html can look shiny and impressive when viewed in a browser.

Only a couple of fringe cases will ever get a glimpse of the quality of your html. People using assistive technology or people browsing with css disabled is one such case. Then there are automated scripts and programs interpreting your html page and finally the quality of the html might show itself as the level of flexibility when a website needs a visual tune-up. Especially this third issue is key to the consistent quality of your project over time.

These cases are often somewhat ignored in the pre-launch testing phase, of course that doesn't mean that the quality of the html should be a low-priority issue and should suffer from it.

we, the html guys

As an html guy I spend quite some time tuning my html to deliver structurally and semantically correct documents with high level of flexibility towards future changes. I might add classes where I think they'll come in handy or where they are needed for semantic differentiation, even if that means I don't need them right away. It's not because a class has no direct function in css or javascript that it is useless and should be left out.

It's for the same reason I don't like extra classes generated by automated back-end systems (often CMS systems) because they can clash with the current or future implementations and mess up the clarity of the html. I also don't like structural differences even when they don't impact the visual output. Simply because structural relevance in very important for flexibility. When elements on a page belong together there's a very real possibility that one point they will be visualized as such.

This is what htmlers worry about. This is where our expertise lies and this is where we hope to earn people's trust. It is a difficult task as it's not easy to come up with direct proof of how important the quality of our work really is, but nonetheless the html remains one of the most essential parts of a web page. Without html, almost nothing can exist in a browser window.

concluding

The implementation of html is often checked by looking at a template in a browser. When the implementation matches the design it is often considered ok. While this might give an indication of an approximation of the html structure, it's hardly proof that they indeed match each other. I believe that css and javascript are not at all needed for implementing the html, maybe even a little counterproductive. When implementing html it is important that the output matches the structure of the static deliverables. This can not be seen by loading a page in a browser, but by comparing the html source of both the static and implemented page.

I believe that it would be helpful to have someone in the implementation team responsible for the correct implementation of html templates. As far as I know this isn't a standard profile nowadays, with every person part of the implementation team writing both programming logic and implementing the html code. It is perfectly normal that this setup puts most of the weight on the programming logic rather than on the html implementation, which often nullifies a lot of the work put into our html.

More than wanting to dictate how others should do their job, I hope this article demonstrates the time and effort spent in coding html pages and the need for an implementation as close to the delivered templates as possible. People writing html often don't write it in function of styling (css) or functionalities (javascript) but have other/more priorities to take into account. So put a little trust in us, most of us know do what we are doing :)

the hgroup tag

It was a new tag that immediately caught my attention. One of the new html5 additions is the hgroup tag. Rather than explain myself, I'll simply stick to the official definition of this new element. This is what the working group has to say about the hgroup tag:

I've been using split titles ever since I started this blog and I've been struggling with them all along. But needless to say, I'm not in the least bit content with this proposal. I fail to see how this is going to work in practice and what impact this will have on the general heading structure of a page.

heading headaches

Headings are horrible, always have been. The fact that there is not one single tag for headings (with an attribute describing the level) but six is quite the bother, especially when you're aiming to create a logical heading structure within a webpage. Furthermore, even though all heading tags are block elements, other block elements can't be nested inside them. This is particularly annoying when you have split headings with subtitles or quotes.

It's these kind of restrictions that become problematic over time. I understand that they are added to help the starting htmler get a better grip on the language, but more often than not they turn out to be too restrictive for experienced htmlers (see the recent footer example). For the split titles on my blog I was forced to use span elements. Bleh.

why the hgroup is not such a good idea

<hgroup> <h1>...</h1> <h2>...</h2> </hgroup>

It's nice that they tried to tackle this issue but there are so many things wrong with the hgroup that it's difficult to understand how this came up as a recommendation. What bothers me the most is that we need to use an extra heading level to capture a subtitle or even tagline/quote. This creates an empty level in the heading structure of your page which is completely unneeded and unwanted. In my case, my article titles should become h3 tags simply because I'm using a little subtitle? The subtitle itself is not really a heading of a section or part of my site, but more like a small expansion or side-thought related to the main title. Creating an extra heading level for that is utterly nonsense.

Another issue I have is that taglines or quotes might be closely related to the main heading, but are not really headings themselves. Using a hgroup for grouping a heading and a quote is impossible since quotes are marked-up using blockquotes, which don't belong in the hgroup. What am I supposed to do now, put quotes in hX tags? That can't be right.

Finally, you're adding another heading tag separate from the existing hX structure and making the whole heading concept even more complex. And I don't even see what the hgroup tag adds semantically. It's not even grouping similar elements as subtitles, alternative titles, quotes or taglines don't even count as separate heading levels and should be marked-up using different tag anyway.

why I shouldn't complain

I know my comments should be directed at the mailing list but I'm simply not signing up to these things anymore. I hate them, they are worse than spam and are completely outdated. So I'm simply posting them here. If anyone agrees and feels like picking them up, please submit a link to this article to the whatwg mailing list (or simply recap the issues I raised here). If not, then so be it.

My conclusion is simple. The hgroup tag adds little to no semantic value and makes the whole heading structure even more complex than it already was. It solves a very contained problem that could've been avoided by lifting some restrictions that were unwanted in the first place, but instead a new tag was added that could lead to even more semantic nonsense and structural chaos. They must've had some good reasons to add this tag, but I fail to see how they could stand up against the issues it brings.

Alternative, why do we even need structural restrictions in the first place. I've seen very little examples where they helped me to build better html but I can name plenty of examples where they proved very bothersome indeed (no block elements within the a tag?). In theory it's a good idea, only it supposes that we are well at predicting the future. The past has learned us we are not.

split issue

A few days ago I received a design for a splash page. The page functioned as an entrance to two different (but closely related) sites. To accentuate the split the design of the splash page was cut in the middle, each side using its site-specific color scheme. The design was screen-filling, meaning that the left half of the screen featured one color, the right half the other color. Sadly there is no easy way to accomplish this in css.

.container {background:url("...") 50% top repeat-x;}

The problem lies with the background-repeat property, which is unable to repeat a background from a specified point. It can only repeat across a whole axis. If you look at the code above you could assume that the background would be repeated across the x-axis starting 50% from the left base point. Sadly this doesn't fly. No matter what value you state for the left parameter, the background will be repeated across the entire x-axis.

split solution

After some pondering the solution proved to be quite simple, though it does require an excessive amount of structural elements. The method is not much different from creating a two column grid, only now we're not going to create separate columns.

<div class="container"> <div class="wrap1"> <div class="wrap2"> ... </div> </div> </div>

The code above will be used to create the wanted effect. It's a simple setup of three nested divs.

.container {background:#0f0; /* right */} .container .wrap1 {width:50%; background:#f00; /* left */} .container .wrap2 {margin-right:-100%;} /* ie6 negative margin fix*/ .container .wrap2 {position:relative; zoom:1;}

We start by applying a base color to the container div. To create the split, we nest an extra div, make it 50% wide and apply a different background color to it (which will visually create the left column). To finish it off, we nest another div to pull the content back to the entire width. Some very simple math tells us we need a negative right margin of -100% to accomplish just that.

We are now back to square 1, only with the background in place, forming a perfect, screen-wide 50% split that goes on forever. Of course a small fix is needed for ie6 as we're working with negative margins, but all that is needed is a pos:rel and zoom:1; which always does the trick when fixing negative margins in ie6.

check out the test page

conclusion

As you can see, you need quite a few structural elements to pull this trick off, so use it only when necessary. If you have to create this effect within a 100px wide element it might be better to simply cut a background that's wide enough. But if you don't mind the extra divs, this is a simple css method that works like a charm and lets you keep all control in css.

The next couple of weeks I'll be quite busy with enjoying my vacation, so this will be the last work update for three weeks. Until then!

transparency rules, css transparency sucks

The biggest problem with css transparency remains its basic implementation. Setting the opacity property will make everything inside the targeted element transparent. Text, images and even nested html ... the whole deal will receive an alpha filter. While this is the desired result in a select number of cases, usually you just want the background of an element to be transparent. And even though behavior in the different browsers is pretty consistent when it comes to the opacity property, it is not much comfort considering the effect it has. Luckily, there are two main options to avoid this behavior.

first example on the test page

ie8, transparency and hovers

Not too long ago I was implementing a horizontal navigation with a transparent background. Since the transparency was ever so slight, using the opacity filter was not a big deal. The hover state on the links simple changed the background color defined on the link. All worked well, except ie8 wasn't showing the hover state. When I finally stopped sighing and cursing I tried a few of the basic fixes.

.base {filter:alpha(opacity = 50);} .base a:hover {background:#f00; position:relative; filter:alpha(opacity = 50);}

Placing a zoom:1 on the hover state didn't do much, so I started experimenting with pos:rel. To my surprise, the hover state showed, but broke the transparency for ie8. Adding another transparency filter worked but created (of course) a different color. You could use another hover color which in theory should give you the same effect as in other browsers, though I'm afraid this involves a lot of trial and error.

I've seen a couple of mentions of this bug on the web, but without any definite replies or solutions. Even though the one above is hardly perfect, it beats having no hover effect at all. If better solutions exist, I'd be glad to hear about them.

conclusion

As you can see, there's still a long way to go before css transparency becomes a reliable way to style page elements. It's already here and it can be used, but chances are you'll run into some kind of trouble sooner or later. Just another day in the life of a csser.

what's been done

Several small things have been added these last couple of months. The most visible of these additions is probably the ie6 stats graph on the homepage. Depending on my referring sites stats the graph nears the 0.5% mark, but it will definitely be a while before I can bid farewell to my ie6 css. For those of you wondering how these stats are generated and shown, I'm still planning on writing an article about just that but for some reason I can't seem to get around to actually writing it.

Another, more recent addition is the share block on the articles page. In the bottom right corner of the article is a little box containing links to Twitter, Facebook, Delicious and Technorati (which I will probably change to Digg later on). Some of you might be surprised by this addition, as I've been quite outspoken about my dislike of these services. Thing is, they do work and since reaching readers is the primary goal of this blog, it would be silly to completely ignore these options.

A third major change is of course the addition of the ie6 css fixer. I'm still waiting to develop a separate "Tools" section until I/we actually have a second tool to add, but that is certainly a possibility for the future. The ie6 css fixer itself is doing good and should receive another small update in the next couple of weeks (though it will probably be a bit later still), so keep checking for updates.

Another nice extra that might have been overlooked is the notification of articles being available in other languages. It's not something that happens every day, but when I do find them (thank you Google Analytics) I think it's valuable to add as people might feel more comfortable reading this stuff in their native language. Mind that these articles are not translated by me, so the accuracy and quality of the translation is dependent on other sources I have no control over.

Final update is the addition of article stats. I've chosen to add a little transparency to my blog by adding the reader stats of each article for all to see. Of course they are untampered with, as you will clearly notice on the less popular articles. More about that process can be found in the site stats for all to see article.

what's coming

The first big thing that's coming is a long, long vacation. I'll be gone for a good three weeks, so updates will be extremely scarce, if not actually non-existent. That's still two weeks away though, so there will still be a couple of updates the next couple of days.

As for updates to the blog itself, I still need to have good look at the gallery overview page, which is hardly functional right now. Using javascript tabs wasn't such a smart idea after all. I'm also considering to rework the blog html to html5, though I'll have to see how much trouble that will give me with ie6 and other, older browsers.

And finally some small visual touches here and there. Won't be doing much work on the html of the site itself, but the css could use some cleaning up and some parts could benefit from some accentuation.

what's a width

A css width states the horizontal length of a box, that's about all there is to it. It works on all but inline elements, no matter how they are positioned or whether they are floated or not. Widths work.

The only real difficulty concerning the basic use of width is that paddings, margins and borders are not included in the stated width. This means that the actual width of a box is bigger if any of these properties are defined. This confuses many people at first, to the point where they are actually introducing a css switch, allowing you to toggle between the two ideologies (css width including or excluding paddings/margins/borders).

The css switch isn't supported anywhere yet, still it is possible to see the all-included method in action. Just set quirks-mode in ie6 and marvel at the different implementation of the css width property.

what's wrong with widths

You might be wondering how such a simple property can be abused, yet the answer is quite simple. From time to time my job consists of widening a site. Usually older sites that were at one point optimized for an 800x600 res and now need to be changed to work on a 1024*768 res. While this could be an extremely simple task, more often than not I find myself cursing over a calculator while adapting widths for an unhealthy number of elements.

/* using widths */ .outer {width:960px;} .inner {width:936px; margin:0 auto;} /* using widths (variation) */ .inner {width:936px; margin-left:12px;} /* using margins (or paddings) */ .inner {margin:0em 12px;}

The problem of the width property is that its function is not really clear to everyone. Widths are for reserving space, not for spacing. The difference might seem small and negligible, but it really isn't. If, for example, you have a site of 960px wide and you want the header to be 12px removed from both sides, there are two ways of going about it. The snippets above will do exactly the same, the difference is that for the first example we used widths to take care of the spacing, the second example used the proper css properties intended to take care of spacing.

Problems arise when the width on the .outer element is changed. Since the .inner width has a separate width declared on it, it will not take up the newly created space when the outer width is enlarged, nor will it shrink when the outer width is made smaller. What you have just created is an inflexible layout that doesn't adapt if you change the base width. In some cases this is actually the desired effect, in most cases it's just bad coding.

You might find this example silly, but you'd be surprised how many people work like this. So let's run through some methods trying to avoid the use of (unnecessary) widths.

away with widths

Below is a small selection of techniques that will help you reduce the use of widths in your css

result

The result of using all these methods is that you can effectively widen your side by adapting one single value in your css, namely the width defined on you main container. You can actually try it on this blog. Changing the width on the #allContainer will make the whole site wider without creating gaps. It's a little more work if you want the grids to grow proportionally, but it's far from any width hell I had to experience a couple of times.

conclusion

Widths are for stating space, and should be used for only that. When an element on your page has a definite width, declare it as such. But when it is simply supposed to fill an existing space, use other methods to position the element. If you want spacing, use margins and paddings, and you will find that the calculator isn't something you should use all that often while working with css. It will save you time, not to mention the next guy who has to adapt the width of the site in the future.

easy does it

The general idea behind Zeldman's article is that since easy things are easier to pick up, they have a better chance of succeeding. The web became big because everyone was able to make a site. html and css were picked up for similar reasons. Vendors found the languages easy to implement, people found them rather easy to learn. And so every fanboy in the world was able to make a site about whatever subject he fancied, it only took about a day or two to get something online that looked remotely d"cent. All that remained was content, and many a fanboy has plenty of that.

Of course there is certain truth in this statement. Simplicity made the web accessible to many and made it possible for people to publish their own content. It helped make the web.

easy did it

While I agree this was a key aspect to the success of the web, at the same time it is also responsible for the mess we are in now. Everyone's nephew was able to make a site, and so everyone's nephew did, without too much knowledge of what they were doing. Therefor, the web was, and still is, a complete mess of crappy html code and hilariously bad css. The perceived simplicity made the web crap from a technological point of view, as it successfully hid the complexities.

Today, the web is a different place. We live in a semi-post-web2.0 era where there is little room left for little fansites looking like the ones made ten years ago. The days of making your own site are basically over, as you don't need to know any html and css to get your own little hideout on the web. You subscribe to a free blogging service, download one out of a million possible themes and off you go. The responsibility of html and css has shifted from your every day Joe to Joe Professional. This shift is very important for the continuation of the web and for our line of work, since it allows us to tackle bigger, more complex projects in a more professional way. The web is growing, the days of everyone's nephew are over.

simple is complex

I agree that many ideas about the future of css are somewhat far-fetched. Constants might be nice, but stuff like inheritance, macros, conditional statements and the likes don't really belong in css and will only result in more styling chaos. That said, css quickly needs to get a level where a series of best practices and solid methods of working are established. Sadly, the current restrictions are preventing this at the moment, of which css simplicity is one.

More importantly, the simplicity of css turned it into something very complex indeed. We have to use the little means we have to build complex sites, and so we abuse everything we have at our disposal to come to the wanted result. Many properties (like float) are used outside their intended purpose and confuse newcomers to the job. Even oldtimers have a hard time explaining all the finesses of seemingly simple things like floats, margins and paddings.

times change

Simplicity might have introduced css, times have changed and today css is an accepted language. It is time to let the language grow. The same simplicity that made css big is now suffocating the language and causing a whole lot of trouble. What was once simple has become very complex, because the context (building websites anno 2009) has changed. The result is quite obvious looking at many existing tools, programs and sites.

Personally, I am tired of dealing with horrible html documents and badly written css. When I have to make a site wider, I want to adapt one value in the css and leave it at that. Not run through a whole css file with a calculator next to me to recalculate a bunch of unnecessary widths. When I need to style a select box, I don't want to find out the box is actually constructed out of three input type="text" elements, two of which are used for styling the arrow. I am tired of styling applications obviously constructed over the course of 10 years and handled by a village of developers. All of these examples are direct results of the simplicity of the languages.

Consistency and flexibility should become the keywords of the next wave of css improvements. When I style a form on one page I want it to look the same on all other pages. The only way to make this work is to claim our job and to make sure the tools we work with become better suited for professional use. Does this mean html and css will become harder to learn? Sure, but if this means it will reduce web-tools built by Java programmers or simple amateurs at home with little interest in writing flexible and correct code, I'm all for it really. The web has come to a point where it has proven its use, now it's time to take it one step further.

conclusion

I guess if you're fine with all the above than you might promote the simplicity of css as something positive. I acknowledge its usefulness in the past, but it is really time to move forward, otherwise we'll be in this same rut for another 10 or 20 years. The web matured, now it is time for some of the corner stones of the web to do the same. It is time to add complexity to html and css so working with these languages will become easier, more flexible and more standardized. And people wanted to do webdesign will simply have to learn the trade, not dabble along while screwing things up for the rest of us.

easy does it

The general idea behind Zeldman's article is that since easy things are easier to pick up, they have a better chance of succeeding. The web became big because everyone was able to make a site. html and css were picked up for similar reasons. Vendors found the languages easy to implement, people found them rather easy to learn. And so every fanboy in the world was able to make a site about whatever subject he fancied, it only took about a day or two to get something online that looked remotely d"cent. All that remained was content, and many a fanboy has plenty of that.

Of course there is certain truth in this statement. Simplicity made the web accessible to many and made it possible for people to publish their own content. It helped make the web.

easy did it

While I agree this was a key aspect to the success of the web, at the same time it is also responsible for the mess we are in now. Everyone's nephew was able to make a site, and so everyone's nephew did, without too much knowledge of what they were doing. Therefor, the web was, and still is, a complete mess of crappy html code and hilariously bad css. The perceived simplicity made the web crap from a technological point of view, as it successfully hid the complexities.

Today, the web is a different place. We live in a semi-post-web2.0 era where there is little room left for little fansites looking like the ones made ten years ago. The days of making your own site are basically over, as you don't need to know any html and css to get your own little hideout on the web. You subscribe to a free blogging service, download one out of a million possible themes and off you go. The responsibility of html and css has shifted from your every day Joe to Joe Professional. This shift is very important for the continuation of the web and for our line of work, since it allows us to tackle bigger, more complex projects in a more professional way. The web is growing, the days of everyone's nephew are over.

simple is complex

I agree that many ideas about the future of css are somewhat far-fetched. Constants might be nice, but stuff like inheritance, macros, conditional statements and the likes don't really belong in css and will only result in more styling chaos. That said, css quickly needs to get a level where a series of best practices and solid methods of working are established. Sadly, the current restrictions are preventing this at the moment, of which css simplicity is one.

More importantly, the simplicity of css turned it into something very complex indeed. We have to use the little means we have to build complex sites, and so we abuse everything we have at our disposal to come to the wanted result. Many properties (like float) are used outside their intended purpose and confuse newcomers to the job. Even oldtimers have a hard time explaining all the finesses of seemingly simple things like floats, margins and paddings.

times change

Simplicity might have introduced css, times have changed and today css is an accepted language. It is time to let the language grow. The same simplicity that made css big is now suffocating the language and causing a whole lot of trouble. What was once simple has become very complex, because the context (building websites anno 2009) has changed. The result is quite obvious looking at many existing tools, programs and sites.

Personally, I am tired of dealing with horrible html documents and badly written css. When I have to make a site wider, I want to adapt one value in the css and leave it at that. Not run through a whole css file with a calculator next to me to recalculate a bunch of unnecessary widths. When I need to style a select box, I don't want to find out the box is actually constructed out of three input type="text" elements, two of which are used for styling the arrow. I am tired of styling applications obviously constructed over the course of 10 years and handled by a village of developers. All of these examples are direct results of the simplicity of the languages.

Consistency and flexibility should become the keywords of the next wave of css improvements. When I style a form on one page I want it to look the same on all other pages. The only way to make this work is to claim our job and to make sure the tools we work with become better suited for professional use. Does this mean html and css will become harder to learn? Sure, but if this means it will reduce web-tools built by Java programmers or simple amateurs at home with little interest in writing flexible and correct code, I'm all for it really. The web has come to a point where it has proven its use, now it's time to take it one step further.

conclusion

I guess if you're fine with all the above than you might promote the simplicity of css as something positive. I acknowledge its usefulness in the past, but it is really time to move forward, otherwise we'll be in this same rut for another 10 or 20 years. The web matured, now it is time for some of the corner stones of the web to do the same. It is time to add complexity to html and css so working with these languages will become easier, more flexible and more standardized. And people wanted to do webdesign will simply have to learn the trade, not dabble along while screwing things up for the rest of us.

what's that h1 again

The h1 tag is used as the main title for the content of a page. This means that it roughly describes what a user can expect for the contents of the page he is on page, similarly to the page title defined the in head of the html. Structurally you would expect an h1 tag to be the first heading tag in the source, though that is usually not the case. The h1 describes the content, yet most sites start with a site header, making the h1 tag usually appear after the site header and as first heading in the site content.

Almost every page on a site has a main heading, no matter what type of page you can come up with. But there are of course exceptions to each rule.

the homepage

The homepage of a site usually doesn't have a heading. It's a landing page for people visiting your site, containing several content snippets you want to promote and will lead the visitor away from this page, deeper into your site. You could of course use a heading saying "homepage" and place it inside a h1 tag, but this is quite silly (which is exactly why you won't see it too often).

Which of course doesn't mean you shouldn't place a h1 tag on your homepage, as it is still a structurally relevant element. A common solution is to place the logo and tagline inside the h1, but only on the homepage. Which makes sense, as it's the entrance gate of your site (even though we know that many people don't enter your site through the homepage). The h1 tag serves as welcomer, stating the brand name and possible tag line. The visitor will know where he has landed, and will continue from there.

The difficulty lies with getting this implemented, as the logo/tagline are usually placed inside the site header which is often a fixed piece of code that is simply included on each page. So inform your implementors well, as they will have to make an exception for the homepage and generate a slightly altered piece of code there.

the code

<h1 class="siteLabel"> <span class="logo"><img src="..." alt="Brand:" /></span> <span class="tagline">...</span> </h1>

The code is quite simple, with one base element grouping the logo and tagline. We use a class="siteLabel" to style it independently of where it is used in the site (and at the same time add some semantic information through the classname). This base element contains a span for the logo and a span for the tagline. A div or p tag can't be used since html doesn't allow such elements within a h1 tag. For that reason, I've added a ":" in the alt of the image as to make sure it works as one single sentence. Small detail which I might write about at a later time.

This of course is the code used on the homepage. On all other pages, you could replace the h1 with with either a div or p tag, depending on what you think makes a line of text an actual paragraph. I myself use a div, but the choice is up to you really.

conclusion

One thing to avoid is to use the h1 tag to group your logo and tagline information on every single page, as it says very little about the content on a page. For the homepage though, it makes sense enough to place your h1 tag in the site header.

That said, I still think this setup has room for improvement, so if you have any good ideas, be sure to share them with me.

crappy headings

The html heading setup is pretty horrid, but since we're stuck with it we just have to make the best of it. In html, we have 6 hX tags to our disposal, each describing a different heading level. The weak point of this system is that there is no generic heading element, creating a setup that is often more rigid than asked for.

From these six heading tags, the h1 tag is without a doubt the most important one. It is supposed to contain the main heading of a page, describing what can be found on this exact page. It is typically nested as the first element inside the content area of the page.

only 1

Since the h1 tag is supposed to hold the title describing the content of a specific page, logically there is only one h1 tag needed per page. This quickly became a rule of thumb for us web developers. No matter how you structure the headings following the h1 tag or where you put your h1 tag in the structure (fe, h2 tags in the header might precede the h1 tag in the content), just as long as there is only one per page it's all good.

The importance of the h1 tag was soon picked up by search engines, which made the h1 tag a big deal in SEO too. The content within the h1 tag was considered important to filter keyword selection for finding a page within your site. To counter abuse, search engines soon limited themselves to the first X number of characters of the first h1 tag in the source (so no keyword stuffing or multiple h1 tags for SEO). For more detailed information about this subject, just search the web as it is filled with articles on the h1 tag in relation to search engine optimization.

more than 1

So far so good, until a few weeks ago, when I was started on this particular page. Without paying too much attention I ended up with three h1 tags on one single page. When I found out my first reaction was to remove them right away, but after taking another good look at the situation, I actually found that the structure as was made quite a lot of sense. So what had happened?

The page I was working on was a landing page. They've been out of fashion for some time, but in some situations they are still very much needed. Since I live in Belgium (which has three official native languages and a lot of political issues) the choice of language is often a delicate problem. Setting a default language often leads to a can of political nonsense you don't want to be involved in, so a language page is actually a pretty decent alternative.

I've said that each page should have one main title, which of course makes a lot of sense. But in the case of a language page we find ourselves in a unique situation. This page is meant to receive people that speak different languages. There is of course still one title, but for each existing language this title should be available in the corresponding language. So for each language, a separate h1 tag should be used. The net result is a page that holds multiple h1 tags, holding the same content but translated for each target audience.

conclusion

Of course this doesn't mean you should just forget about the initial rule, which is still very valid and a pretty definite guideline. What this article hopes to do is to give you a solid reminder that no rule is to be followed without critical consideration from time to time. In some cases, breaking a rule or guideline might actually result in a better setup.

disclaimer

Before starting, it might be useful to say a few words about the ideology behind our work. First of all, I work for a company specialized in front-end development. We do everything from information architecture to making static html/css/javascript templates. After that is done, our templates are shipped to a technical partner who then uses this batch of templates to build the actual site. In that sense, it is important that our html is flexible and robust. Changes in css are easy (overwrite the css file), but html changes can mean a lot of extra work and a serious communication overhead.

Secondly, one of my pet peeves is the structural relevance of html. I'm not a fan of "using just enough elements so it can be styled", since such ideology still mixes style and content. Writing structurally "correct" html often results in elements you don't really need for styling, but are needed to group or separate certain elements, ie provide structural meaning to the document.

So let's take a quick tour around the form layout I prefer using.

rows

<div class="row clearfix"> ... <div class="feedback">...</div> </div>

Even though a "row" is not necessarily a semantic element and is definitely not needed in every form, it can still come in handy for several reason. First of all, it has a very strong structural meaning, as it groups input elements which are closely related to each other. Postal code and city, first name and last name, street and nr/bus. These are all typical examples of form data that is so closely connected that it is often displayed on the same line in a form. This grouping of elements is accomplished by our row element.

The second reason for defining the row structure is to mark a feedback area for input elements within a row. This div is used for error messages or confirmation messages (fe writing a numerical date which is then confirmed in full writing) on row level. You could argue that feedback should be possible for each separate input element and thus should be added to each individual input element (and you would be very right indeed), but practically this is almost impossible to do without running into some serious styling troubles later on. One of those situations where semantics have to make way to work around real world problems I'm afraid.