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.

input elements

<div class="inpElement"> <label class="inpCaption" for="a"> input label <span class="captionHint">(...)</span> <span class="req">*</span> </label> <div class="inpControl"> <div class="control"> <input type="text" id="a" name="a" maxlength="20" size="1" /> <span class="controlHint">(...)</span> </div> <div class="controlHelp"><img src="..." alt="..." /></div> </div> </div>

An input element is always defined by a caption and input control. Even when the caption is not visible, all input controls should have exactly one label element so screen readers know what the input control is for. Each form row will always hold at least one input element, but might hold more. The html code you see above is an example of a full-blown input element, all options included. The main structure is easy enough, within the input element are two sections. One section for the caption of the control, one section for the control itself.

The input caption holds everything related to the label. This means a possible label hint and a possible required indication. Since both are important and valuable additions to the label they must be nested within, where screen readers will pick them up. The class "inpCaption" might seem redundant, but is used for consistency's sake so the same html structure can also be used for a list of checkboxes, where the actual label tag will be placed after the input control and the input caption will be defined by a div. This way, the structure and css is singular and remains clear.

The input control holds a separate control div (in the case of a checkbox list, you'll have a series of control divs), inside this element the actual form control is nested with possible input control hints. After the control structure a possible control help can be added (usually an image of a question mark with a popup on click) for lengthier explanations and information about the input data.

css

.row .inpElement {float:left;} .row .inpElement .inpCaption {float:left; width:11em; text-align:right; position:relative;} .row .inpElement .inpCaption .req {position:absolute; right:-0.6em; top:0;} .row .inpElement .inpControl {margin-left:12em;} .row .inpElement~.inpElement .inpCaption {width:auto; margin:0em 0.5em;} .row .inpElement~.inpElement .inpCaption .req {position:static;} .row .inpElement~.inpElement .inpControl {margin-left:0; float:left;}

The above css is all you need for a basic setup. The input element itself is floated to the left (to allow for additional input elements on the same row). The label is also floated and given a width. The control is then positioned past the label with a right margin. You could float it, but if the control hint becomes bigger than the length of a line this will break the layout. All following input elements added inside a row have the same styling, only with the width reset on the inpCaption and the left margin taken off the inpControl. The required indication on the first input element is set absolute (so the text of all labels is neatly lined out), in consecutive input elements the required indication is reset to static.

As you can see, this is relatively little css for a pretty complex and flexible layout. Of course, the css needs to be expanded a little if you want to start adding extra styling to the captionHint, controlHint, controlHelp etc etc.

work in progress

Since the day I started on my current job I've been working on this little piece of html. I'm constantly tweaking it, trying new things and shifting things around. What I don't like about this structure is that I'm using the label tag as a structural element, which is outside its intended purpose (hence the display:inline). As a kind of guidance rule, I try to keep elements on the same structural level with the same css display property, effectively trying never to mix inline with block elements. This is easily solved by nesting the label inside a div.inpCaption (which is how I did it before), but that extra div really is quite useless since all additions to the caption need to be nested inside the label tag anyway.

Another weakness in the css lies with the width on the inpCaption and the left margin on the inpControl that are always related. Change one and you have to change the other if you want to keep your design balanced. I tried fixing this once by floated the inpControl and simply applying a right margin to the inpCaption, which is fine until you cross the line length (which happens pretty quickly is you're adding a checkbox list with longer labels) which causes the layout to break.

Valuable comments (so please nothing about bloated html and divitis) are always welcome!

conclusion

Working with this kind of structure has several advantages. Most importantly, it is robust enough to allow for late changes in the graphical and functional design. Adding an extra hint or help doesn't mess up your complete css and html structure as the structure already takes such elements into account. Graphical changes are made easier too as you have plenty of structural elements to play around with.

On a structural level, this setup makes a lot of sense too, as it groups and separates all the right elements. It's a structure that can be carried over to different projects quite easily without having to make many changes, which adds to the predictability of your code. Advantages a plenty, unless of course you worry about file sizes and "abundant" divs that are not needed for css styling.

Whatever method you use, it's up to you, but consider for a moment the structural relevance of html and whether you think it's okay to throw it overboard just because you don't need certain elements for styling.