by Kyle Weems 5.January 2009 10:39
Normally the New Year is a time for people to make a series of resolutions that they'll promptly break by February 2nd. I have my own list of web related resolutions that I'll be putting up at some point at CSSquirrel, but today I'm actually setting out a New Year's dare for others to take to heart, involving everyone's favorite forgotten standard: HTML5.
The Leadup: HTML5 In Recent News
A lot of talk has been made about HTML5 in the past, with more recent commentary this past year being about whether it'd ever actually be ready to use. Ishtml5readyyet.com is probably the most succinct on that front, although Jeff Croft's blog post back in September on the subject was a nice touch on the subject (especially in the comment stream that followed), and prompted me to parody the topic in a CSSquirrel strip.
The catch is, of course, that the kerfuffle is actually over really poor terminology. The fact is, a standard getting "proposed recommendation" status means two browsers already are completely rendering the standard properly and interoperably. Which means to me that the W3G and anyone else using these terms need their heads checked, as recommending something that's already come to pass is like making prophetic statements about yesterday's lunch. Which I predict was a beef burrito.
The reality is that HTML5 is already coming into use, with several big names in the web design world putting their work where their mouths are and using the standard for some of their recent sites. Eric Meyer's coding for An Event Apart's new website is in HTML5 (he writes about the experience here), and Jeremy Keith's Huffduffer and the new UX London site are also both HTML5 (which he writes about here.)
Is HTML5 ready for being used for every website by every designer? Probably not. The spec's doubtlessly got a ways to go before it's solidified, and there's definitely gaps in implementation by browsers. But as cutting edge web designers, I don't think we should let details like that that stop us from getting our hands dirty and start some hands-on learning.
The Dare
So my dare to you all is as follows: Start digging into HTML5, start making websites with it, and write about the experience. Jeremy Keith has already recommended it, so if everything goes wrong let's just agree to blame him (and not me.) Still, I think it's a great idea. Sure, most client projects should probably stay in a safely defined standard, since experimentation and other people's money doesn't always blend smoothly. For that matter, I'm not sure how stable HTML5 is, and I have even less of a clue as to how much of it is implemented by the various browsers, or what can be faked.
Hence the dare. The only way any standard gets the kinks worked out is for people to start banging on the tires. So let's do it!
To put my money where my mouth is, I'll be attempting to get CSSquirrel, my personal blog/comic/identity rack, up and running in HTML5. I'm sure I'll be cursing a lot during the process, but I've got a certain confidence that it'll go a lot more smoothly than my early experiments as a lad with taking spring-loaded toys apart and failing to put them back together. And, of course, I'll write about it, hopefully teaching a few people a thing or two in the process.
So, to get things rolling, you'll need a starting point. Here's the WHATWG's specs for HTML5, and here's the W3G's. I'm not sure if they differ, or to what degree, or who's has precedence, but between them there's enough to keep you scratching your head. If you plan on using any elements that IE doesn't recognize yet, you may need to utilize John Resig's HTML5 Shiv technique. If you're not feeling up to using new wacky elements like <article> in your markup, then consider at least getting in practice by utilizing class & id names that follow those naming conventions (an idea that Andy Clarke has championed here).
To make sure your code isn't going all wonky, you can now use the W3C's validator for HTML5.
And if you're feeling like that's not enough of a dare, you could also try to integrate RDFa at the same time. (More on RDFa in the future.)
by Kyle Weems 22.December 2008 12:05
Ever since the web standard movement convinced web designers to move away from tables towards proper semantic markup, we've constantly struggled with a seemingly simple task: lining elements up horizontally next to each other.
Somewhere in the far future, probably after the creation of the neuro-web that I predict in this CSSquirrel comic comes to existence, browsers will finally start implementing the Advanced Layout Module.This amazing piece of CSS3 will make it so simple to stack elements in any order that it'll make you feel like you're rooting around with dirty tables in the mud again, but this time in a completely semantically-neutral, web standards way.
However, that utopian future is dismally far away, leaving us with the original problem: lining up block elements next to each other.
You would think that this would be an easy enough thing to accomplish. After all, bricks can do it:
Artwork can do it:
And even ducklings can do it!
But for web desigers, though, it's an incredibly difficult thing to do without generating more problems, especially with CSS.
A common solution is to use float:left to float block-level elements next to each other. This creates a number of headaches, though, usually involving float behavior that isn't predicted or having to clear the floats to keep the elements tucked inside their parents. I've found myself often guilty of creating incredibly complex markup and style structures to keep things in place, only to later find a bug cropping up when some additional content is added.
There's been a solution proposed for quite some time in CSS 2.1 - display: inline-block.
What is inline block? Well, according to the W3C definition it is "A block box, which itself
is flowed as a single inline box, similar to a replaced element.
The inside of an inline-block is formatted as a block box, and the
element itself is formatted as an inline replaced element."
In English, I'd say that it's a block-level element that flows inline, but retains all the width/height/margin qualities of a block-level element.
This means we can have our cake and eat it too, by giving an element all the dimension-setting qualities we enjoy while still stacking it side-by-side with another block of content. And all this without floats.
So why hasn't this always been in use? Simple, browser makers hate us.
Well, I don't know if they actually loathe our existence. But through their actions we can infer that they at least enjoy tormenting us. Firefox 2 (and prior) doesn't support inline-block at all, and Internet Explorer only supports it on inline elements (which is actually contrary to the situations we're going to most likely want to use it in).
However, there's a bright light that makes me say that from now on you should drop those floats (except where they're genuinely needed) and use inline-block for your everyday horizontally stacking needs. First, Firefox 3 has been out for some time and the conversion from 2 to 3 has been fairly rapid. Firefox 3 also supports inline-block. Secondly, not only is Internet Explorer 8 on the horizon with proper inline-block support, but we can trick IE 6 & 7 into doing what we want with only a little CSS voodoo.
Here's an example, then, of using inline-block to line blocks up next to one another. (Here's the normal stylesheet, and here's the additional IE sheet).
By and large, there's nothing special that needs to be done beyond applying the display:inline-block style to the elements you want to flow next to one another. There's some considerations to take into account, though. First, elements with this style are whitespace sensitive, which means you'll have space betweent the blocks if you've got a space between the elements in your markup. Secondly, if you want the elements to line up on the top instead of the bottom you need to make sure they have the appropriate vertical-align style set.
Of course, for IE versions prior to 8 there will be issues. Namely that if you're using inline-block on a block element (which is usually the case) it won't work by default. However, there's a simple trick to making IE comply.
First, in your normal stylesheet do the usual display:inline-block declaration. Then, in an IE stylesheet that is conditionally called (for versions below 8) and that comes after your normal sheet, give that same element (or elements) the display: inline property. The elements will retain the block style, but will now also be inline, as desired.
The example shows this IE trick.
The last hurdle you might face is supporting Firefox 2. I'm of the opinion that the Firefox 2 userbase is so vanishingly small at this point that it's a non-issue. However, for the sake of sounding genuinely concerned about all users, here's a solution for that browser version:
- Give the element(s) display:-moz-inline-box; (yes, it's box not block)
- The content may spill out of the elements, so you may need to wrap them in other elements with the width set to hold the contents inside.
By adopting inline-block into our CSS vocabulary, we can jettison a lot of the baggage of complex float solutions for many seemingly simple designs. Sure, it's no Advanced Layout Module, but it's still a steady improvement.
by Kyle Weems 24.November 2008 10:07
Back in September, Andy Clarke re-issued his challenge to web designers to replace the fairly standard practice of designing static visual proofs in Photoshop or Fireworks for presenting to clients with (X)HTML/CSS prototypes. It's a pretty radical departure from the norm for most designers' workflows, and so I had anticipated it to be met with a lot of skepticism or hostility. After all, there's a number of time and money issues related to such a change.
The Conversation Thus Far...
Instead, I found myself surprised to see that by and large the response was cautious optimism, which reflected my own opinion on the technique, marred only by the nagging fiscal concerns. After all, wouldn't all that time spent writing HTML and CSS add to the design time, resulting in either a larger bill for clients or a bitter pill for studios to swallow? Wouldn't this slow down the design process, and bloat it with items that belong in the development phase? (aka, browser inconsistencies, bugs, etc.)
Andy's response was that the technique would help relieve the issue by ushering us into a post-progressive enhancement era where instead of trying to build a full feature set on the weakest browser first and then scaling up from there, we'd start with the fanciest appearance on top, and carefully utilize CSS3 properties now available to achieve this in a way that don't load in older browsers without harming the impact and professional appearance of a site's design. More to the point, we'd be front-loading a client's expectations by giving them the chance with prototyping to see the inconsistencies, liquid layouts, font stacks, simple interactions (like hover states), and other realities of a website from the very beginning, rather than surprising them later in the site creation process.
Conversations on the topic pretty much stalled at this point. Although most participants agreed that the technique was desirable, there was a large amount of disagreement on whether the design phase would expand too much as a result, making the technique moot for most studios' real-life situations and budgets.
To me, this meant that there was only one thing to be done. The prototyping technique needed to be tested. Theorycraft is all well and dandy, but nothing can prove or disprove something more effectively than actually attempting it. So with a Modest Proposal I challenged Mindfly (and the world) to take a chance and try it out. After a bit of examination to the proposed method to determine whether Andy Clarke was a complete nutter (which I suppose he could be, just not in regards to this) we all agreed to give the Ol' College Try.
The Design Phase
Janae, one of our visual designers, was tasked with testing the waters with a small e-commerce site she was designing. Here's a summary of the results of that project. (I'd link it, but this site has yet to go to a live publish).
For the first design phase, Janae went a bit over three hours over. Part of this was due to investing time in the (X)HTML/CSS prototype, and part of this was due to this being of Janae's first projects where she was solely responsible for the design. She was able to take this design to the client via the prototype and show (and not just tell) where the design would differ between browsers (IE's lack of rounded corners, etc), as well as how the site would behave (links hover states, navigation, etc). She found this process to be quite painless, and armed with the client's feedback she went into the design revision phases. These went rather quickly, and when it came time to design the differing appearances of other pages she found that she'd saved quite a bit of time thanks to the pre-existing color and layout styles that the prototype already had.
By the time the design phase was over, she was only three and a half hours past her predicted design budget. Not bad for a first try. It was at this point that I wrote the post The Ol' College Try, where I optimistically predicted that we'd come in under budget by the time the project was finished.
I'm pleased to say I was correct.
The Big Payoff: The Development Phase
The front-end build process (AKA - making the site) was fast. Incredibly so. Our CSS was already 90% finished, and most of the HTML that we inserted into the site's CMS system was modeled after what came from the prototype. This was pretty much what I expected, and I was pleased to be correct. What I didn't expect, but was even more pleased to find, was how few browser compatibility issues we encountered. Usually at some point in a website development process we get Internet Explorer balking at some point with how our CSS is behaving, requiring us to do some corrections to compensate for hasLayout bugs or IE6's complete lack of support for certain features.
However, because we'd made the intentional decision to use CSS3 styles whenever possible to support minor design features like rounded corners for modern browsers (and having these non-critical elements drop on older browsers) instead of going from a bottom-up approach of designing rounded corners for IE first (using old hacks like rounded background images, etc) we had a much simpler, streamlined set of HTML and CSS to begin with. Cleaner HTML and CSS meant less areas for non-standard browsers (aka IE) to screw up, which meant much less time correcting for design bugs. We ended up spending less than a third of our usual time with cross-browser glitches as a result.
That for me is huge, as it's the unexpected browser glitches that usually causes me to start dreaming of pubs before noon.
By the time the front-end was done, we'd gone from being three and a half hours over our projected time to being three and a half under. For those with poor math skills that means we saved seven hours in the front-end build process as a result of using prototyping! More importantly, the client feedback during this phase, which is usually a painful period of adjusting their expectations as a static proof becomes a dynamic website, was instead largely positive as she was already armed with the proper expectations and got to see those become a reality instead of adjusting her vision to match something more realistic than a proof.
This turned out to be incredibly useful, as we ended up with a last minute decision to change the e-commerce engine the site ran on, and were able to absorb the back-end development time that cost us without going over budget.
The Proof Is In the Pudding: AKA, It Works
Overall, this was one of the most pleasant experiences I've seen in developing a website, especially in regards to client relations. Using prototypes, rather than static proofs, not only helped us control our client's expectations with a presentation that reflected the reality of a website, it also saved us a tremendous amount of development time by making much of that design time usable in the finished product. Furthermore, by augmenting the procedure by relying on CSS3 to present advanced (but not critical) design elements that would disappear without generating bugs or an unpleasant result on older browsers. In the end, we were able to produce more results in less time.
It's worth noting that this was a first attempt. There's bound to be areas where we can streamline the process even more. I can't say for sure that this technique will work for all website creators, but based on our experiences thus far, I think any studio can glean some increase in efficiency from it. Go forth and prototype. You won't regret it.