Using a combination of more advanced selectors such as sibling and nth-of-type you can target elements based on their position in the markup rather than a given name. The practical upshot of this is that your markup is much leaner and cleaner, removing class and ID names has a notable impact.

Using advanced selectors

For a complete list please see http://www.w3.org/TR/css3-selectors/

The more advanced selectors take information about an element to determine whether it matches a certain criteria, for example body>div will target a div that is a direct and immediate descendant of the body; p+p will target a paragraph immediately preceded by a paragraph.

On this basis, you could select (for example) your main content div by knowing that it’s the second div in your content wrapper: body>div div:nth-of-type(2). Broken down we have:

• body—sets the root
• >div—the first div inside the body (the wrapper div)
• div:nth-of-type(2)—the second div in the wrapper (just after the header div).

Why I think this won’t catch on

For the time being, let’s completely disregard that Internet Explorer completely disregards these selectors…

As you can see from the above example, targeting the single, lone, unique content div has taken two advanced selectors and 27 bytes. The selectors are fixed, the content div will always have to be the second div in the div that is an immediate child of the body. This is incredibly restrictive. Surely #content{…} is far better than body>div div:nth-of-type(2){…}…?

For the sake of ease, instead of rambling about pros and cons, I’ve simply drawn up a list of advantages and disadvantages:

Advantages:

• Leaner markup.
• Promotes more sensible structuring of code.
• Promotes semantics.

Disadvantages:

• Difficult syntaxes to remember.
• Extremely restrictive—elements are styled based on their location meaning that any moving/restructuring means all styles tied to an element are lost. This leads me on to…
• The CSS is no longer just describing style, it also describes structure. CSS is a styling language, not a markup one.
• Arbitrary elements such as images and divs that change depending on page content (blog posts for example) aren’t fixed enough to be styled based on their structure. This means that any variable content will require IDs and classes anyway, so you might as well us them across the board as opposed to a mix of with and without.
• Difficult to understand. I wrote the CSS for the demo page and I’m having a hard enough time doing the calculations to work out what does what. Imagine inheriting that!
• Jenga. As soon as you alter your markup, the structure dependent CSS will come falling down too, what might be the first child might become the second, making the second child the third and so on, creating a domino effect.

Final word

While the more advanced CSS(3) selectors are impressive, and incredibly powerful, they aren’t flexible enough to allow any large dependency upon them. That, and they’re more awkward to understand than the tried and tested ID/class ‘hooks’ we know and use. There are far too many downsides to make cleaner markup a big enough plus-side in my opinion… Oh, and Internet Explorer doesn’t seem to honour any of them, but that can’t have come as much of a surprise.

Okay, okay. That was a very alarmist intro. There is no web developers’ apocalypse around the corner (not that I know of anyway, please don’t take anything I say about the apocalypse as read. I don’t want that responsibility.), nor are we going to have to regress to using tables and spacer GIFs again. The real issue here is that with all this new technology that keeps emerging and exciting web developers is unwittingly reimposing the restrictions of yesteryear…

Screen resolutions

Remember trying to break away from 800×600px?

With the movement toward a more mobile web, screen resolutions are in fact getting smaller. The iPhone’s maximum resolution is 480px, increasingly popular netbooks are set at about 1024px wide. Such a shift toward mobile and portable devices mean that screen sizes are actually getting smaller.

In my opinion, iPhones and other mobile devices should be handled separately, serving them device specific CSS. Netbooks on the other hand are still ‘desktop’ machines like any other. Their smallness is their key feature, and at 1024px horizontal resolution, they aren’t that small anyway…

With the 960 Grid System, and an optimum line length of 52–78 characters, sticking to 1024px shouldn’t be that difficult anyway. I believe that although desktop monitor sizes are generally getting larger, other equally important technologies are creeping up, and as responsible developers you should cater for them. Sure you may want to start adopting the 1080 grid, which is all well and good if you know your audience, but to cater for the majority, we’re not ready to burst 1024 yet.

Connection speeds

Remember building for 56k dial up connections? (I don’t)

Where permanent and fixed connections are getting much faster, connections to mobile devices through means such as 3G are much slower. The ability to optimise sites to be fast loading over such connections is getting more important. As edge-case resolutions are getting smaller, edge-case connections are getting slower. Much slower.

A word on Flash

Remember 2Advanced? A site of yesteryear…

Flash seems to be dying a death anyway these days, slowly being superseded by Javascript and Canvas et al. However, what was once a fantastically powerful technology has been ousted completely from Apple’s i products, making in an inviable option for content which needs to be universally accessible.

A real life example?

Anyone with an iPhone will know what I mean—spending any amount of time on an iPhone loading poorly optimised sites is a real grind, and via some sensible optimisation these problems can be easily alleviated.

However, a more interesting example might be the one that happened to myself… When we first started at Venturelab we really were building the company from the ground up. For the first few weeks we were without desktop machines and internet. I was working on a 10.1″ netbook with a screen resolution of 1024×600px, and over a poor 3G connection via a dongle.

“Accessibility isn’t just about disabilities, it’s about varying degrees of ability to access content.”

Working in this manner really made me wonder whether enough people are delivering content in a manner which is accessible on numerous levels. Accessibility isn’t just about disabilities, it’s about varying degrees of ability to access content. As responsible developers your content should be accessible through a full spectrum of means and in an acceptable manner.

All it takes is some decent optimisation (which is also set to reap SEO benefits) and a reasonable page layout and you’re already halfway there.

However, it’s not all that bad. As border-radius.com would have you believe, the syntax to create an element with top–left and bottom–right corners with a 50px round, and top–right and bottom–left corners with 10px rounds would be:

-webkit-border-radius: 50px;
-webkit-border-top-right-radius: 10px;
-webkit-border-bottom-left-radius: 10px;
-moz-border-radius: 50px;
-moz-border-radius-topright: 10px;
-moz-border-radius-bottomleft: 10px;
border-radius: 50px;
border-top-right-radius: 10px;
border-bottom-left-radius: 10px;

Wrong, you can actually use the border-radius shorthand to nail this in three lines:

-moz-border-radius:50px 10px 50px 10px;
-webkit-border-radius:50px 10px 50px 10px;
border-radius:50px 10px 50px 10px;

The sytanx follows the following rule: border-radius:top–left top–right bottom–right bottom–left;. I’ve tested this in Firefox (-moz-border-radius), Webkit (-webkit-border-radius) and Opera (border-radius) and it works just fine.

Addendum

You’d think Webkit would just be Webkit, right? Wrong. This works in Chrome but not Safari. I’ve had reports that Safari 4.0.4 (I guess it’s not found it, get it? Oh never mind.) doesn’t work. Useful…

Still, this version will work, and is still considerably shorter:

-webkit-border-radius: 50px;
-webkit-border-top-right-radius: 10px;
-webkit-border-bottom-left-radius: 10px;
-moz-border-radius:50px 10px 50px 10px;
border-radius:50px 10px 50px 10px;

Also, follow Suze on Twitter.

As the site was built very quickly, we are adapting it as it grows and fixing any bugs as they happen. Let me know if you find anything astray. Anyway, enough talking, go look for yourselves!

Many hands make light work

There are lots of contradictions in sayings and phrases. Like this one, if many hands do make light work, then how does this next one work?

Too many cooks spoil the broth

A stitch in time…

While the cat is away…

Absence makes the heart grow fonder vs. time is a great healer

This one is another glaring contradiction, so I decided to combine the two into one poster.

Out of sight, out of mind

Two wrongs don’t make a right

This one doesn’t really follow the code paradigm, but I thought I’d include it anyway.

Got any more that would work in this way? Leave any suggestions in the comments.

Also, I do realise that, programmatically, not all of these posters make perfect sense. For example, $cooks > 'enough' doesn’t really work in a programming sense… It’s just a bit of fun!

Here is a little tongue-in-cheek post taking some of the things an offending designer/developer might say, but from the lips of a surgeon. After all, I do love a good analogy.

If you can think of any more, please feel free to add them in the comments. And this is just a light-hearted, jokey post. I’m not comparing the importance and responsibility of surgery with that of web design… honest.

View demo

The trick here is to force the list to break at the right point. If you want two columns, you need to float the list items left and set them at 50% width, therefore the list items will only ever fit two side-by-side, then begin again on the row beneath. By that token, three columns would require a width of 33% and floated left, four would be 25% and so on.

The code

Both the markup and CSS for this is incredibly simple, nothing fancy, no CSS3, nothing progressive, just basic styling applied to lean markup.

The markup

The markup for this is just a simple ul, thus:

<ul id="double"> <!-- Alter ID accordingly -->
  <li>CSS</li>
  <li>XHTML</li>
  <li>Semantics</li>
  <li>Accessibility</li>
  <li>Usability</li>
  <li>Web Standards</li>
  <li>PHP</li>
  <li>Typography</li>
  <li>Grids</li>
  <li>CSS3</li>
  <li>HTML5</li>
  <li>UI</li>
</ul>

And to make this into a multiple column list:

ul{
  width:760px;
  margin-bottom:20px;
  overflow:hidden;
  border-top:1px solid #ccc;
}
li{
  line-height:1.5em;
  border-bottom:1px solid #ccc;
  float:left;
  display:inline;
}
#double li  { width:50%;} /* 2 col */
#triple li  { width:33.333%; } /* 3 col */
#quad li    { width:25%; } /* 4 col */
#six li     { width:16.666%; } /* 6 col */

When to use this

Use this wisely… It displays content in an ambiguous manner and should not be used where order of reading is imperative.

This method should only be used if the lists content doesn’t require any specific ordering as the markup is written linearly and the list is displayed in a matrix. As you can see, the way the content is displayed means it can be read across»down»across or down»up»down. This means that the way you write your content is not necessarily the way it will be read. In my example this isn’t an issue, as the content can safely be read in any order.

I just want one!

Okay, I didn’t actually register http://ʎɹɹɐɥ.com/, I registered what you might call its alias: http://xn--jna6b0ca7h.com. So, by that token, you find the upside down version of your domain (mine being harry) via this upside down letter converter, paste the result (mine being ʎɹɹɐɥ) into this IDN converter and add whatever domain extension (mine being .com) to the resulting string (mine being xn--jna6b0ca7h). You then register the outcome, and you can access it via the upside down version! http://ʎɹɹɐɥ.com/ is just an alias of http://xn--jna6b0ca7h.com/ in a sense…

If you view the source of this page you’ll see the markup actually links to http://ʎɹɹɐɥ.com/ but resolves to http://xn--jna6b0ca7h.com/ in the status bar when you hover it.

I want details!

If you want to actually understand the technicalities behind it, you ought to read the two articles linked previously.

Why would I need this?

You don’t, but it is cool, right? Although, you could use it as a pretty nifty short-URL for your blog on Twitter like Daring Fireball’s awesome http://?df.ws one.

Which leads me on to…

You don’t have to have an upside down domain, you can use glyphs in there too. Grab some glyphs from CopyPasteCharacter and pop those into the converter too.

Registering your domain

This is not a plug…

I’ve heard reports of people being asked about languages for the IDNs from their registrar of choice. I went with Heart Internet and registered http://xn--jna6b0ca7h.com/ no trouble, just as if it was a regular domain.

Be sure to comment it you buy/have bought one yourself.

View demo

Look at the site in IE8, then Firefox, then Safari/Chrome. Keep refreshing.

I have created a demo page which simply represents three items of data expressed as percentages. It is not the data itself or the numbers we are concerned with here—it is the proof of concept. The fact that this can be done on my made up data shows that you can do it too, on real life information.

Progressive enhancement

At Venturelab, we decided to use progressive enhancement as a matter of course. CSS3 and designing in the browser all the way!

Progressive enhancement is, in my opinion, one of the most exciting schools of thought web development has seen in years (though I have only been in the web for three…). It is the idea whereby any non-essential features (i.e. anything whose absence will have no adverse effect on the usability or accessibility of a website) are added to the website in a progressive manner—usually through CSS3.

The benchmark example is rounded corners; to apply these through old means, for example with images, would have taken a developer a substantial amount of time—time the client is paying for. It seems silly now to think that way-back-when, putting rounded corners on a div might have taken upward of 30 minutes, when we can apply it in about 5 seconds using -moz-border-radius:5px;.

It really is a no brainer—anyone visiting the site in a browser with no CSS3 support will see square corners. Does this matter? Of course it doesn’t. No one visits a site to look solely at the design—they visit for content. Does it matter to them what shape the corners of your RSS button are? No again. Progressive enhancement saves you time, and your client money.

Isn’t this just graceful degradation?

Graceful degradation = building for the best and getting worse; progressive enhancement = building to cater the worst and getting better…

The line between progressive enhancement and graceful degradation is fine but significant. Graceful degradation is the idea that you’d build a site for, say, Firefox, then selectively break and downgrade it in the likes of IE(6). Progressive enhancement takes a much more positive attitude in that you build for IE(6) and then selectively upgrade it in browsers like Firefox and Safari. It’s no longer starting great and getting worse, it’s now starting great and getting better.

Internet Explorer

N.B. Only tested in IE8 as this is not a final solution, rather a proof-of-concept.

Internet Explorer(8)’s take on my bar charts is as you’d expect from any browser, it renders it perfectly well, providing clear, accessible content, with a flawless UX and perfectly usable. This is not bad! We don’t need to downgrade anything, this is our starting point. It looks good and it functions perfectly. If you did as above and visited in IE8 first, you wouldn’t know that there were round corners missing—because that doesn’t matter.

Firefox

Next up is Firefox, where we add some round corners to the blue bars, and also a very subtle drop shadow (text-shadow:;) on the text. This is no more usable than before, the content is no more accessible than in IE, but it does look a tad nicer.

Safari/Chrome

It is in Webkit based browsers such as Safari and Chrome that the real magic happens. Webkit’s proprietary CSS is above and beyond that of any other rendering engine…

What if I couldn’t be bothered opening Photoshop to make a subtle gradient .gif for the bars? No worries, use Webkit’s gradient CSS. A little reflection might look nice on the bars too, but I don’t fancy any superfluous markup or .pngs to fiddle with. Ah great, Webkit has a bit of reflection CSS too.

However, for the real show-piece, the Webkit animation. I’m not using any Javascript libraries anywhere else in the page so I don’t fancy pulling a whole one in for something that won’t really be missed if it’s not there. I hear Webkit has animations… magic!

The code

Now that’s the theory covered, let’s look at what does all this stuff… Please note, I have used some PHP to randomise the values used by the bars of the chart. As a result, some CSS appears in the source code of the PHP file, and the rest in the page’s CSS file. The code shown in the examples below is condensed into one large chunk.

The markup

The markup simply comprises of one uncluttered dl. The reasoning behind a definition list is that each item is a title, followed by some information about that title. Not only is this semantically correct, it’s a nice set of elements to be working with to achieve the layout we’ve got.

<dl id="chart">
  <dt>Sales increase this week</dt>
  <dd><span id="data-one">47%</span></dd>
  <dt>Revenue increase this week</dt>
  <dd><span id="data-two">59%</span></dd>
  <dt>Profit increase this week</dt>
  <dd><span id="data-three">26%</span></dd>
</dl>

That’s all there is to it.

The CSS, CSS3 and progressive enhancement

/*------------------------------------*\
  CHART
\*------------------------------------*/
#chart{
  width:520px;
}
#chart dt{
  width:160px;
  float:left;
  margin:0 20px 5px 0;
  padding:2px 0;
  display:inline;
  font-weight:bold;
  text-align:right;
}
#chart dd{
  width:339px;
  border-right:1px solid #ddd;
  float:left;
  margin-bottom:5px;
  display:inline;
}
#chart dd span{
  color:#fff;
  background:#09f;
  text-align:center;
  padding:2px 0;
  display:block;

  text-shadow:1px 1px 1px rgba(0,0,0,0.2);
  -moz-border-radius:2px;
  -webkit-border-radius:2px;
  border-radius:2px;
  background:-webkit-gradient(linear, left top, →
  left bottom, from(#09f), to(#077fd0));
  -webkit-box-reflect:below 0 →
  -webkit-gradient(linear, left top, →
  left bottom, from(rgba(0,0,0,0)), to(rgba(0,0,0,0.25)));
}
#data-one{
  width:47%;
}
#data-two{
  width:59%;
}
#data-three{
  width:26%;
}
#data-one{
  -webkit-animation-name:bar-one; /* Give the bar an animation with a
    unique name */
}
#data-two{
  -webkit-animation-name:bar-two; /* Give the bar an animation with a
    unique name */
}
#data-three{
  -webkit-animation-name:bar-three; /* Give the bar an animation with a
    unique name */
}
#data-one,#data-two,#data-three{ /* Define animation styles for all three
    bars at once */
  -webkit-animation-duration:0.5s; /* Animation duration in seconds */
  -webkit-animation-iteration-count:1; /* Amount of times to loop */
  -webkit-animation-timing-function:ease-out; /* Ease in, out etc. */
}
@-webkit-keyframes bar-one{
  0%{ /* Define bar-one styles at 0% (0 seconds) */
    width:0%;
  }
  100%{ /* Define bar-one styles at 100% (0.5 seconds) */
    width:47%;
  }
}
@-webkit-keyframes bar-two{
  0%{ /* Define bar-two styles at 0% (0 seconds) */
    width:0%;
  }
  100%{ /* Define bar-two styles at 100% (0.5 seconds) */
    width:59%;
  }
}
@-webkit-keyframes bar-three{
  0%{ /* Define bar-three styles at 0% (0 seconds) */
    width:0%;
  }
  100%{ /* Define bar-three styles at 100% (0.5 seconds) */
    width:26%;
  }
}

In detail

There may well be some bits in there that you’re not familiar with, particularly CSS animations. Basically, to animate an element you need to do a few things:

1. Assign the element an animation name. This name is the ‘hook’ to link an animation, defined later, to an element.

   #data-one{
     -webkit-animation-name:bar-one;
   }

2. Assign the element animation properties. Here you set things like duration, repetition and ease-in/out.

   #data-one,#data-two,#data-three{
     -webkit-animation-duration:0.5s;
     -webkit-animation-iteration-count:1;
     -webkit-animation-timing-function:ease-out;
   }

3. Set up the keyframes of the animation. Here you set the various points. Here we have one thing to animate through two states, so we simply set a beginning at 0% and and end at 100%. We could set at any percentage in between but as we just have a beginning and an end, we don’t need to—Webkit sees to that.

   @-webkit-keyframes bar-one{
     0%{
       width:0%;
     }
     100%{
       width:47%;
     }
   }

With regards the Webkit reflections, it may be a better idea to consult the Surfin’ Safari page on that, as anything I’d say would most likely be a poorly pulled off rehash.

Closing word

So there you have it, a real life, justifiable and wholly appropriate application of CSS3 and progressive enhancement coupled with data visualisation. Don’t be held back by the limitations of older browsers—relish in the opportunities new ones bring.

And as a final bonus, @VIPickering requested this (view in Safari/Chrome)… enjoy.

From my point of view, creating the widget could not have been simpler—simply writing some basic form HTML which posts to the blog will yield results, and it then just requires dropping into an XML document and placing on a live server, and linking to via the Netvibes developer centre.

You can view the ‘master’ XML document here: http://csswizardry.com/netvibes/index.xml