After a morning of team planning and intensive YouTube research, we settled on building a page for a fictitious gameshow on the Knuckleodeon Network called Triple Dare. Reagan put together some fantastic illustrations, and I designed them into a layout that I hope leaves lots of room for code-out interpretation. There are quite a few places where interesting animations, transitions, transforms, and interactions could be built in. Heck, this thing could also be built responsibly... I mean responsively... I mean both ;)

Be sure to read Reagan’s post to get the low down on his illustration process. We’re all very excited to see what people come up with. Happy front-ending!

Media-queried responsive & adaptive sites afford us the ability to re-architect content on a page to fit its container, but with this exciting new potential come equally exciting challenges. Web designers will have to look beyond the layout in front of them to envision how its elements will reflow & lockup at various widths while maintaining form & hierarchy. Media queries can be used to do more than patch broken layouts: with proper planning, we can begin to choreograph content proportional to screen size, serving the best possible experience at any width.

As I step into my 3rd responsive project with Paravel, I’ve made a habit out of picking apart media-queried sites I happen across, noting how things get rearranged at various widths. At times, it seems as though all of the site architecture & planning goes out the window as content reflows. I’ve also found that what might work very well for one type of content or site might not work so well for another.

Content Stacking

This is unavoidable. Take a 4 column site at full width: as the view narrows, 4 will become 3, then 2, and 1. The most common solution is to stack them on top of each other in chunks (fig. a). Simple enough, but what happens if the first column is really tall? Is the content in column 2 less important than all of the content in 1? It probably is for something like a full-length article, but I can’t help but think that in some cases, this method throws off the hierarchy.

Another approach could be to interdigitate content by folding elements into each other as the view narrows (fig. b). In real terms, what happens if a main column is a tall grid full of product thumbnails, and the sidebar features a coupon or promotion? When those columns are combined, it might be nice to slide the promo in between two product rows instead of shuffling that important piece to the bottom of the main column.

The Content Change-up

Another thing I’ve noticed is that media queries are being used to significantly redesign pages. I’ve seen background colors change and top-level elements move from left to right. If critical thought is applied here those choices may be spot on. But what happens if a user visits at full-width one afternoon and revisits your site in the evening on a tablet, and everything looks completely different? It’s annoying—like someone rearranging the groceries in your pantry every time you closed the door. The power of media queries can be intoxicating, but just because you can doesn’t mean you should.

De-compartmentalize the Workflow

The production model of passing a site down the assembly line from design to development to launch seems to be an inefficient approach for responsive & adaptive site design. I think the Paravel method of gathering around a table & slugging every decision out until launch lends itself to the level of reiteration necessary for these projects. We’ve found that the best way forward is to pull all members of a team together to design, build, test and then evaluate in multiple quick rounds.

Of course, the alternative would be to create designs for every media query you plan to include, but that kind of thinking seems inefficient and fails to take advantage of the device-agnostic approach that responsive web design offers. In my mind, it’s best to build something that works on any possible width or device instead of something that works on all current widths and devices.

Balancing all of these new facets of the web designer’s role may seem overwhelming, but that’s the nature of the profession and one of the reasons why I love it. Honing the craft of content choreography will help us to orchestrate the best experience possible at any screen size or resolution. In time, I believe knowing what works best will become second-nature to us—just like designing progressively enhanced CSSed pages without tables or superfluous markup is now. The best thing for us to do? Practice!

Just as we’ve moved beyond Helvetica and Times New Roman, we’ve begun to think about web type in finer detail than <h1> or <span> tags currently (semantically) allow. For example, when Dave Rupert and I prepared to markup the 3 sites for the Lost World’s Fairs project, we saw elements in each design that would require an excessive number of <span> tags to target words, even letters, at a time.

Ideally, CSS selector pseudo classes or elements would work, but even with options like :nth-child and ::first-letter we wouldn’t be able to target all that we needed.  As eager as we were to dive into building these beautifully designed pages, we couldn’t help but realize two things:

1. We needed more control over letters, words, and lines than CSS currently provided for.
2. The markup was going to be extremely difficult to manage because wrapping individual letters in <span> tags would get messy quick.

An hour later Dave came back with the best solution we could think of: a simple jQuery plugin that injected <span> tags around letters, words, or lines within any declared element. Lettering.js let us build out & revise the pages, saving heaps of code as well as grunt work. It was such a lifesaver that we decided to share it with the web community, launching letteringjs.com late fall 2010.

Lettering.js was well-received, though there are a few valid criticisms that I’d like to briefly address:

If you buy good fonts, they don’t need to be kerned.
That may be, but some fonts do, and the thinking behind Lettering.js goes beyond kerning into overall control. What if web designers want to use italics, font-size, or even change font-family within an element?

Lettering.js isn’t the only way.
True, and it isn’t the ultimate solution either. Let’s consider our options from most problematic to least:

1. Embed an image
2. Use CSS image replacement
3. Wrap letters or words in <span> tags
4. Use JS to inject <span> tags after the markup as we have with Lettering.js

Even though the <span> tags aren’t in the markup, there’s still bloat.
This is true. While Lettering.js keeps the source HTML clean, it doesn’t do the DOM any favors and inserts quite a bit of code.

Load times are increased. Javascript libraries are loaded just to target a few words or letters.
Again, consider the alternatives.  An image could easily outweigh javascript code.  On the other hand, yes, it’d be ideal to do this independently from JS.

Can we replace Lettering.js with CSS?

I hope so. Lettering.js is a solution, but perhaps it’s not the ultimate solution. As I mentioned earlier, CSS Selectors come close. What if the CSS spec was adapted to fill in the gaps? After scouring the internet, here’s a brief timeline recounting what’s already been discussed.

The W3C proposed Cascading Style Sheets, level 1 (CSS1) featuring the ::first-letter and ::first-line pseudo selectors.

Anne Van Kesteren explored the idea of expanding selectors to cover ::nth-line(n) and ::nth-letter(n).

Safari 1.3 was released as the first browser to fully support both the ::first-letter and ::first-line pseudo selectors. It’s worth mentioning that prior to this, IE5.5+ (July 2000 ) and Firefox 1 (November 9, 2004 )  had partial/buggy support for these selectors.

An extensive (50+ message) CSSWG thread on Proposed ::last-line and ::last-letter selectors was started by Andrés Delfino. The feasibility was discussed at length, and rejected due to narrow user base and high cost / complexity.

At the time, this thread had trouble coming up with good use cases. With the expansion of pseudo selectors & available web fonts, good use cases are now everywhere. The discussion focused heavily on ::last-line & ::last-letter which may not be particularly useful.

Dave Rupert built Lettering.js as a workaround.  Version 0.6.1 has been downloaded 1500 times, with 550 watchers on Github, indicating that alongside the growth of web fonts, the ‘narrow user base’ is widening rapidly.

From CSS1, we’ve been able to use pseudo-elements to target ::first-letter.  What if you extended that idea to targeting letters, or even words, within an element similar to the CSS3 ::nth-child(n) selector, resulting in something like this:

h1:nth-letter(4); or h1:nth-char(4);
targeting the 4th letter within an <h1> tag.

h1:nth-word(3);
targeting the third word within an <h1> tag.

I think this would be the ideal solution from a web designer’s perspective. No javascript would be required, and 100% of the styling would be handled right where it should be- in the CSS. On the other hand, I have no idea what goes into implementing these additions for a browser, which is why the idea has been proposed as a blog post with comments. Please, feel free to share your own thoughts about how we can gain more typographic control on the web.

When coding The Moon, by Jason Santa Maria, we used RGBa to blend all of the light blue border brackets into the gradient background.  We wanted to be precise, so we pulled the exact R, G, and B values from Photoshop and set the alpha to .3 to match the opacity.  Here’s an example line of code for one of our multiple CSS border properties:

#main{border-left:1px solid rgba(152,209,244, .3);}

In this case, RGBa was the most accurate option.  If you tried to pull the HSL values from Photoshop in the same manner, it simply wouldn’t match up. Now, when it comes to making on-the-fly adjustments, I prefer HSLa.  Hue is fairly easy to chart out once you find your way around the color wheel, and from there, fidgeting with saturation and lightness percentages is a breeze.  Naz Hamid’s El Dorado poster had some Photoshop color-burn blending effects on the type which made HSLa perfect for tweaking each of the color values to perfection.  Here’s an example of one of our CSS implementations for HSLa:

#eldorado{color:hsla(44, 100%, 33%, .70);}

Chris Coyier has a nice write-up on HSLa color over at CSS Tricks, which includes a handy resource for a Mac app called Colors that lets you select a color on your screen and converts it to the color value format of your choice.  I’d love to see something similar to that integrated into MacRabbit’s CSSEdit.

Update: Paul Irish just released a lovely HSL selection tool called MothereffingHSL.com
Also check out workwithcolor.com’s HSL color picker

When building Camp Wapo, we used inset on the action item buttons.

Lettering.js has an inset hover state on each of the linked images.

The feature box on A Book Apart has a nice vignette shadow framing the div.

When logged out, the Rdio homepage employs inset shadows on their features list.

Now, what about images? It’d be nice to be able to add a vignetting effect to photos sans-Photoshop, but the way browsers interpret box-shadow:inset is to throw the shadow behind the image, rendering it invisible. While this seems pretty useless, it does make sense when you consider other kinds of content. For example, if you inset a shadow you probably wouldn’t want it overshadowing the text within.

A reasonable way to circumvent this issue would be to wrap the image in a div or a span element and employ some basic z-indexing. See the example code provided below. While this method gets the job done, I wonder if it’d be sensible to update the CSS Working Draft to allow for inset shadows to be displayed on top when applied directly to an image. Despite the inconsistency, it seems intuitive to me and would ultimately lead to cleaner, simpler markup.

<div class="vignette">
<img src="mustang.png" alt="mustang" class="car_photo"/>
</div>
.vignette{
box-shadow:inset 0px 0px 85px rgba(0,0,0,.5);
-webkit-box-shadow:inset 0px 0px 85px rgba(0,0,0,.5);
-moz-box-shadow:inset 0px 0px 85px rgba(0,0,0,.5);
}
img.car_photo{
z-index: -1;
position: relative;
}

A while back, Jason Santa Maria called to see if I’d be interested in joining him on a team with Frank Chimero & Naz Hamid.  After confirming my participation, as well as the fact that this wasn’t a practical joke, I learned that our mission was to create 3 web poster sites that showcase WOFF and how well IE9 supports it.  After a couple of team Skype meetings we decided to follow a Lost World’s Fairs theme, which was an appropriate match for the adventurous nature of the project as well as the team.  My primary role being CSS & HTML code-out, I knew I had to start by doing two things: bring Dave Rupert in for additional dev support, and learn all I could about IE9.

IE9 Preview

Building for an unreleased browser with a subject-to-change property support list was equal parts daunting and exciting. I knew the stakes were high.  I’ve built plenty of websites where the layout depended on one or two properties to really sing, so I had to be 100% sure I was giving the team accurate information.  I began experimenting by coding a series of sandbox pages where I’d test IE9’s support for CSS properties listed in the developer guide.  I was glad to see support for many of the properties I hoped we could lean on heavily during the design & code-out:

Not only were many of the CSS3 staples supported, but when compared to Webkit & Mozilla engines, IE9 actually out-performed in a few cases.  For example, a border-radius & box-shadow combo actually looks better in IE9.  Eventually, I’d like to one day see text-shadow, CSS transforms and maybe even animations supported to the same high standard as the modules for backgrounds, borders, color and fonts.

Lettering.JS

Early on we realized that because these poster-style layouts were going to be tuned to the letter, we’d need to find a way to match that attention to detail while keeping the markup manageable & agile. This problem of avoiding <span> heavy markup facilitated Dave’s creation of Lettering.js.  Dave has provided an introductory write-up & GitHub download here.  On projects like this, where large-format type is front and center, this jQuery plugin saved the day.

Tandem Dev via Dropbox

Dave and I were able to code-out different aspects of the site by setting up our own localhosts & working from the same folder we share via Dropbox.  He’d position elements on the page in a structural CSS file while I’d finesse the lettering in a type CSS file until each page was pixel perfect.  It took steady communication, but once we ironed out the kinks we were able to have the initial code finished for each of the 3 poster sites in 3 days.

El Dorado

The Hatch Show Print take on a 1924 fair in El Dorado by Naz was fueled by his interest in experimenting with rgba/hsla color and opacity.  Because tweaking hue, saturation & lightness is so intuitive with hsla, we were able to adjust the tones for each individual letter, blending them into the textures and colors underneath.  We used CSS-pseudo elements to double up on lettering, giving the poster an authentic, rough-around-the-edges look.  During an impromptu screen-sharing design session, Naz and I used Jon Raasch’s Scrolling Parallax jQuery plugin to finish the page by floating Zeppelins across the skyline.

Atlantis

Frank’s 18,123 pixel (or 20,000 league) journey into Atlantis is the reason multi-touch / smooth scrolling was invented.  Above water, the horizontal, percentage-based background tracking shifts the ocean-scape as you resize your browser window. Below water, you’ve got a fixed-positioned sea elevator and a depth tracker (built with javascript by Dave) that accompanies you as you scroll through various layers of aquatic life.  The 10 year old me loved building this page.  If there were a Journey to Atlantis lunchbox, I would buy it and carry my iPhone around in it.

The Moon

Jason created a look ahead to 2040 with a Worlds’ Fair that considers the possibility of humans settling on the Earth’s Moon.  The celestial interplay of the Earth and Moon on the page was achieved through percentage-based fixed positioning.  The same was done for the poor unfortunate spaceman (if your browser window is wide enough to find him). The Worlds’ Fair logo was done with 100% CSS, using border radius to create both the containing circle and the top-right orbital sphere.

The Landing Page

My design contribution to the Lost World’s Fairs was the landing page.  I thought a colorful, travel poster inspired approach would serve as a great introduction for each fair.  My type lineup consists of League Gothic for all the heading fonts, FF Market Web for the script and my favorite serif, FF Meta Serif Web Pro for the body text.  It was extremely humbling to be trusted to take on this leg of the project, and I had a great time doing it.

Operation Condor: Complete

Praise be to Nishant Kothary and the MIX Online team at Microsoft for giving us complete freedom to create and for getting behind the vision. Congratulations on the new browser and the huge leap forward.

The only downside to our project (dubbed internally as Operation Condor) is that we’re finished. Being able to team up with such talented people as Jason, Frank, Naz and Dave, has been an honor and a privilege to say the least.  I felt like Louis Tully, suiting up as a Ghostbuster and running around the streets of New York for the first time. “Stay fit. Keep sharp. Make good decisions.”  It’s good to be a Friend Of Mighty.

Let’s face it, if your page fails to load in time, all the effort put towards information architecture, content strategy and interaction design will be for naught. During my formative front-end coding days, I did a fair bit of assuming that as Internet connections transitioned from dial up to DSL I’d be able to make compromises.  Piling sprite-less PNGs upon redundant CSS upon tons of HTTP requests became commonplace, and a few seconds for a page load seemed worth it.

Not Seconds, Milliseconds

But that’s not really how things are.  We close out the windows of tweeted links if the load bar lags.  We leave news and shopping sites early if they feel unresponsive and sluggish.  If a site is slow, the amount of time we’re willing to continue to invest decreases exponentially with every second... every millisecond. Bing and Google agree that slow pages lose users. Each company ran similar experiments where they deliberately delay server response time by a varying number of milliseconds finding that the longer users wait the less engaged they are with a page and the more likely they are to leave.

But good things come to those who wait. Right?

It’s tempting to want to build in enhancements-- if all those extra layers of functionality make a site more interesting, so what if they add to load times, right?  I’m not so sure.  Is it wise to assume that these features are something users will happily wait for? Users don’t crack open their browser thinking, “I can’t wait to experience the Acme Company’s website.”  They’re thinking, “I want to find a product / service / answer as quickly & easily as possible.” Waiting for content online isn’t about patience, it’s about simplicity. John Maeda sums it up brilliantly in his Laws of Simplicity (#3)

No one likes to suffer the frustration of waiting. Thus all of us, consumers and companies alike, often try to find ways to beat the ticking hand of time. We go out of our way to find the quickest option or any other means to reduce our frustration. When any interaction with products or service providers happens quickly, we attribute this efficiency to the perceived simplicity of experience.

We are building websites and creating user experiences for human beings.  More likely than not, that ‘good thing’ the user is waiting for isn’t your website-- it’s family dinner, time with their kids, or a few extra minutes of sleep.

We Are Presenters

But our job isn’t binary.  Unlike UPS or FedEx, whose job it is to get something from point A to B, web builders aren’t charged with just delivering information, but presenting that information through design.  Imagine a site like CampaignMonitor without its unique style, layout and imagery.  The design makes it easier to learn about the service, saving users time and effort. The balancing act here is to think critically about the graphics, scripts and code we’re serving to our users.  There’s an economy to it-- a give and take that shouldn’t be considered mid-process, but from the get-go.

The How-To

I’ll be the first to admit I’m no expert; nor do I consider myself a shining example of best practices.  Thankfully, Dave Rupert has been waving the page speed banner at Paravel for quite some time.  He’s led the way in changing the way we plan, design and code for web projects from the beginning to prevent users from having to wait to find & load content. Here are some resources & tips Paravel has found handy over the months/years. Whether you choose to lessen textures, simplify a design, and/or even swap images in favor of CSS3, that’s up to you. As we’ve found, little shifts, baby steps, can lead to a lot of gradual improvement over time. The most important thing one can do is to view a site visit not only as an impression or a page view, but also as a small part of someone’s day.

Resources

• Web Performant WordPress: 5 steps to a faster website from Dave Rupert
• Firebug: Firefox plugin for performance analysis
• Yslow: Firebug plugin from Yahoo that grades your page speed
• Google Page Speed: Evaluate website performance via Firebug
• Which Loads Faster: Pages compete in your browser for quickest load
• WP Super Cache: If you run WordPress, you need this.

Image Compression & Sprites

• Image Optim: A simple drag & drop for images, reducing disk space
• Smush.it: Batch shrink images while retaining file structure
• SpriteMe: Automatic image sprites and CSS for everyone!
• Specify Image Dimensions: Part of a Google article about optimizing browser rendering

Efficient CSS

• Minify CSS: Compress CSS & JS
• Efficiently Rendering CSS: Solid tips for how to keep your CSS lean & mean
• CSS Sprites Workflow: Chris Coyier’s implementation workflow

A few days after Steve Jobs announced the release of the iPad, I read that in Apple’s Reference Library: Preparing Your Web Content for iPad, and started to realize the drastic implications the evolution of multi-touch would have on interaction design. Anything we design for the web that requires a hover state has an uncertain future and could be subject to serious usability issues.

The Touch-Screen Boom

If you think this is something that can be addressed later, when multi-touch “catches on”, consider this: as of June 22, 2010 Apple has sold 3 million iPads in 80 days, 1.03 million touch screen phones are sold per day, and companies like Dell and HP have been developing & releasing touch interfaces for tablets and laptops for quite a while now.

The Hover Crutch

Hover states are everywhere. I don’t think I’ve ever written a stylesheet or designed a site without putting a significant amount of thought into how they should behave. As users, we’ve been conditioned to rely on hovers states to trigger changes in link color, reveal action items, and navigate through multiple tiers of a drop-down menu. Sliding our mouse pointers across a page to reveal hidden clickable points of action has become an automatic addition to our web browsing skill-set. As designers, we’ve turned to hover states to accommodate extra content and allow visual aesthetics to trump usability. Like it or not, those days are over and the interactions we design are going to have to stand on their own two feet.

I believe that in most cases, the best solution isn’t pursuing alternatives such as multi-touch hovering technology, trying to adapt hover-dependent designs, or transforming your website into an iPad/iPhone application. Instead of adding scripts, kilobytes, and billable hours to treat symptoms, I think the focus should be on simplicity and bullet-proof user experience design. In line with Luke Wroblewski’s statement that we should start designing for the web mobile-first, I propose that we should be designing for Multi-Touch first, and moving forward, we can only afford to add hover states as enhancements only.

Try to Avoid

• Hyperlinks that aren’t 100% obvious
• Javascript tooltips that show important information or metadata
• Displaying action items on hover. Examples I’ve seen typically involve edit / delete items.
• Displaying graphics in a less-than-ideal state until hovered: all those semi-opaque or black & white screenshots and photos that only display full color when covered by a cursor
• Drop-down menus. While some of these can be revealed on click or tap, be sure the user has cues that show those options.
• Focusing too much on hover dependent CSS3. I know it’s a bit of a heartbreaker, but while these have always been seen as enhancements, we’re going to have to settle with the fact that multi-touch users won’t be seeing our fancy transitions.

How do we adapt?

More often than not, making adjustments won’t be a quick or a simple process. The more layers of interaction a site has, the more work is going to have to be done to address usability issues. I’ve noticed that a few of my favorite sites have already taken a variety of steps to provide some fixes.

Show everything.

Prioritize your content, and if you’ve been hiding things behind hover states, make room to display them. The WordPress admin posts screen is a great example of this. Normally, action items are only visible on hover, but if you login with a touch device the links are always displayed.

Utilize tap to reveal a hover state.

Depending upon the implementation, this can be risky; Amazon has done fairly well with this method for their category-based shopping navigation. The paneled list and orange arrows help to make those areas clearly tappable. Another example can be found in Basecamp’s edit and delete controls for to-do lists, milestones, and files. When you hover over one of these the action items appear. For touch-screens they’ve built a javascript popup that works fairly well once you’ve figured it out. The problem is that users get no cue that tapping the to-do text is even an option, and I can’t help but think a solution similar to WordPress would have worked better. That being said, I’d happily pay a few extra pennies per month to get a mobile version of Basecamp.

Build specifically for touch-screen devices

and take advantage of native device controls, gestures and popovers. Touch-screen apps for Twitter and Gowalla play a key role in their overall success and are probably used more than the websites themselves. I use the Netflix iPad app regularly, but in many cases it feels like a hover-dependent website dropped into an iPad viewport. Currently, if you’re browsing instant titles and want to add something to your queue by tapping, you’re looking at a 3 step series of taps instead of an instant hover reveal option with a point-and-click interface. If you’re going to build specifically for touch, you’ve got to follow through.

Wait for touch hover technology.

I’m not convinced this would do anyone any good. It may be exciting to see what Cypress has come up with, and to know that Apple has applied for a patent for a proximity sensing touch-screen, but this does worry me. I’d hate to see us revert to our old shortcuts and make user experience sacrifices just because the technology is in place. Plus, we’re going to look like a bunch of idiots who are afraid to touch our smart phones & iPads. On the bright side, Phil Dunphy would love it!

We’re going to be OK.

Ultimately, I think seeing hover states fade away will make the web a better place. There never has been any substitute for concise content, clear interaction, and simple design. If we focus on core elements that make browsing the web great, our sites will function properly no matter how people use them.

.the {font: 30px "adrianne-1","adrianne-2","Times New Roman", Times, serif;}
.design {font-size: 68px;line-height: .9;text-shadow: #f5f5f5 -1px 1px 0;}
.cubicle {font-size: 40px;letter-spacing: 1px;line-height: .8;font-weight: 500;}
.main {
font-family: "refrigerator-deluxe-1","refrigerator-deluxe-2";
text-transform: uppercase;
line-height:1;
font-weight: bold;}
.tdc {
background: url(../img/diag.png) repeat;
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
z-index: -5;
display: block;
text-shadow: none;
font-size: 220px;
margin-top: -112px;
height: 160px;
font-weight: 700;}
.diamond {
margin-bottom: 12px;
margin-top:0px;
font: italic 14px/0 "Times New Roman", Times, serif;}
.view {
font: 15px "adrianne-1","adrianne-2", serif; margin-top: 10px;}
.explanation{
font: 12px/1.7 "adrianne-1","adrianne-2",serif;
margin-top: 0px;
margin-bottom: 30px;}
.line-left, .line-right {
border-bottom: 1px solid #f8f8f8;
width: 150px;
display: inline-block;
margin-bottom: -30px;
border-top: 1px solid #cdcdcd;}
.line-left {float: left;margin-top: 0px;}
.line-right {float: right;margin-top: -17px;}

I think I came pretty close. The main differences are related to the fonts I used, as Tungsten and Sentinel aren’t yet @font-face-able. Fortunately, Typekit was able to serve up Refrigerator Deluxe and Adriane as more than suitable replacements. Just like my last last experiment, some of the class styles may seem oddly titled. I sourced them from the first few letters from each line of text. At the moment this will only work in webkit, so fire up Safari or Google Chrome and check out the example.

.itried {font-size: 50px;}
.css {font-size: 206px;letter-spacing: 5px;line-height: 1;}
.itworked {
font: italic 60px/0 "bistro-script-web-1","bistro-script-web-2", cursive;
text-transform: lowercase;
margin-bottom: 20px;
margin-top:20px;
}
.hoo {font-size: 258px;letter-spacing: 5px;line-height: 1;}
.view {font-size: 57px;margin-top: -15px;}
.hoo, .css {text-shadow: #4a8d97 3px 3px 0;}
.css:after, .hoo:after {
background: url(../img/crosshatch.png) repeat;
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
text-shadow: none;
display: block;
z-index: -5;
}
.css:after {content:"CSS Three";margin-top: -198px;margin-left: 16px;}
.hoo:after {content:"Hooray!"; margin-top: -250px;margin-left: 18px;}

.line-left, .line-right {
border-bottom: 2px solid #2a4f54;
width: 160px;
display: inline-block;
margin-bottom: -30px;
}
.line-left {float: left;margin-top: 36px;margin-left: 15px;}
.line-right {float: right;margin-top: -34px;margin-right: 15px;}

Some of the class styles may seem oddly titled. I sourced them from the first few letters from each line of text. At the moment this will only work in webkit, so fire up Safari or Google Chrome and check out the example.

Update: Thanks to Jess Brown’s recent contribution via Dribbble, I’ve been able to revise the code, retaining the double shading effect without having to resort to coding the same text twice.