It seems like everything is on a grid, right?
Although a grid is a great way to begin a project, especially if you need to through around your design and elements as you design. However, there are those projects that you know exactly how you want your site to lay out. You don’t need 12-16 columns with 20px gutters, maybe you want 4 columns? Or, maybe you don’t even want your site on a grid!
Gridless is the perfect boilerplate.
Gridless is a solid HTML5 and CSS3 framework for making responsive, cross-browser websites with nice typography. Gridless takes a different approach to responsiveness:

Most responsive and adaptive HTML/CSS frameworks or boilerplates start with desktop styles and use media queries to serve mobile browsers the right layout. The problem is that most mobiles won’t respond to these media queries because they don’t support it. Also, using a polyfill like Respond.js will not give you any result because they are very limited devices and don’t even support JavaScript.
But Gridless uses a different approach: it uses media queries to serve a progressively-enhanced responsive layout, starting from mobile and building up to desktop sizes.

Here are the main features of Gridless:
Responsive (responds to the user’s device screen width with the adequated CSS).Progressive enhancement and mobile first.Cross-browser compatible (even IE6 and 7).CSS normalization instead of CSS reset.Beautiful typography with a vertical rhythm and heading sizes based on golden ratio.Print styles optimized for performance.Optimal caching.HTML5 and CSS3 ready.Safe CSS hacks instead of conditional classnames/stylesheets.Micro clearfix hack.A well-organized folder structure.Learn more, grab the code, fork the Git, and try the demo on the Gridless website.
You just finished reading "Gridless, HTML5, CSS3, Responsive Boilerplate" on ChurchMag! Feel free to comment on it! We use the Standard Theme for our blog platform!

A web developer walked into a bar. But quickly left when he saw the table layout. #RimShot

We had YUI grids, and then 960 and friends…. but we seem to have a new burst of activity around CSS frameworks in various shapes and forms. Here are some that have tickled my fancy:

Skeleton

Skeleton is a small collection of CSS & JS files that can help you rapidly develop sites that look beautiful at any size, be it a 17″ laptop screen or an iPhone. Skeleton is built on three core principles:

Responsive Grid Down To Mobile: Skeleton has a familiar, lightweight 960 grid as it’s base, but elegantly scales down to downsized browser windows, tablets, mobile phones (in landscape and portrait).
Fast to Start: Skeleton is a tool for rapid development. Get started fast with CSS best practices, a well-structured grid that makes mobile consideration easy, an organized file structure and super basic UI elements like lightly styled forms, buttons, tabs and more.
Style Agnostic: Skeleton is not a UI framework. It’s a development kit that provides the most basic styles as a foundation, but is ready to adopt whatever your design or style is.

Normalize.css

Normalize.css is a customizable CSS file that makes browsers render all elements more consistently and in line with modern standards. We researched the differences between default browser styles in order to precisely target only the styles that need normalizing.

What does it do?

Preserves useful defaults, unlike many CSS resets.
Normalizes styles for a wide range of elements.
Corrects bugs and common browser inconsistencies.
Improves usability with subtle improvements.
Explains what code does using detailed comments.

Griddless

Gridless is an awesome HTML5 and CSS3 framework for making responsive, cross-browser websites with beautiful typography. Gridless has a simple approach on markup and styles. There aren’t any pre-made grid systems and the CSS isn’t littered with silly classes. Gridless is only a starting point, that should be edited to suit each project’s needs.

Features

Responsive (responds to the user’s device screen width with the adequate CSS)
Progressive enhancement and mobile first
Cross-browser compatible (even IE6 and 7)
CSS normalization instead of CSS reset
Beautiful typography with a vertical rhythm
Print styles optimized for performance
Optimal caching
HTML5 and CSS3 ready
Safe CSS hacks instead of conditional classnames/stylesheets
Micro clearfix hack
A well-organized folder structure

What CSS frameworks are tickling your fance?

39 Box Shadows: View it in Chrome.

CSS Lint was just released and shown on stage at Velocity by Nicole Sullivan and Nicholas Zakas (newly out of Yahoo!).

It does what the name implies, and why wouldn’t you run your CSS through the system to take a peak at what it has to say?

The website allows you to send up some CSS, or you can a) grab the CSSLint code on GitHub, b) install via npm (at this time of writing npm couldn’t find the module…. and there is a space in the name).

I ran the CSS that FunctionSource.com uses (via stylus) and it found a bunch of warnings (and one parsing issue).

The types of issues that bubbled up:

Broken box model: using width with padding. padding: 0;
Values of 0 shouldn’t have units specified. text-shadow: rgba(255,255,255,0.3) 0px 1px; (I personally get irky on this. 0 is 0 is 0…. but I have been burned by this with 0s for times (which some browsers require))
Missing vendor-prefixed CSS gradients for Internet Explorer 10+, Opera 11.1+ (sorry! can add this to our stylus functions)
Element (h1.title) is overqualified, just use .title without element name.
Don’t use adjoining classes. .sidebar .item.about h3
Too many floats (11), abstraction needed.
Too many font-size declarations (21), abstraction needed.

dropshado.ws: Resolving anti-aliasing on WebKit hardware-accelerated elements: David does it again:

Activating hardware acceleration in WebKit with 3D CSS transforms changes the way WebKit renders text. WebKit composites the element so that when rendering the transform, it doesn’t have to re-render sub-pixel anti-aliasing for every frame. This feature is a good thing in that vastly improves…

I wasn’t sure what to make of Joe Lambert’s Flux Slider project after reading the first line in the announcement blog post:

I’ve been experimenting a lot lately with the lesser used aspects of CSS3, specifically with the powerful new CSS3 animations/transitions pioneered by the Webkit team

I dunno about you, but it seems like accelerated CSS3 effects have been anything but obscure over the last few years. But when I looked at the project, I was impressed. Check out the effects via a live demo or via a video capture:

While the blog post talks of a future release, Joe’s already made the code available on GitHub and via a link in the demo page.

Using Flux Slider couldn’t be easier. Setup a <div> that contains a series of <img> elements, then create a flux instance:

window.f = new flux.slider('#slider', {
pagination: false,
autoplay: false
});

Once you’ve got that, invoke start() on the flux instance and you’re off to the races; provisions for manual advancement and custom selection of the transition are provided.

Each of the presently supported eight transition effects are implemented as methods of flux.transitions and they involve appending a bunch of hairy CSS to the DOM, as in:

flux.transitions.concentric = function(fluxslider, opts) {
return new flux.transition(fluxslider, $.extend({
blockSize: 60,
delay: 150,
alternate: false,
setup: function() {
var w = this.slider.image1.width();
var h = this.slider.image1.height();

// Largest length is the diagonal
var largestLength = Math.sqrt(w*w + h*h);

// How many blocks do we need?
var blockCount = Math.ceil(((largestLength-this.options.blockSize)/2) / this.options.blockSize) + 1; // 1 extra to account for the round border

for(var i=0; i<blockCount; i++)
{
var thisBlockSize = (2*i*this.options.blockSize)+this.options.blockSize;

var block = $('<div></div>').attr('class', 'block block-'+i).css({
width: thisBlockSize+'px',
height: thisBlockSize+'px',
position: 'absolute',
top: ((h-thisBlockSize)/2)+'px',
left: ((w-thisBlockSize)/2)+'px',

'z-index': 100+(blockCount-i),

'background-image': this.slider.image1.css('background-image'),
'background-position': 'center center'
}).css3({
'border-radius': '1000px',
'transition-duration': '800ms',
'transition-timing-function': 'linear',
'transition-property': 'all',
'transition-delay': ((blockCount-i)*this.options.delay)+'ms'
});
this.slider.image1.append(block);
}
},
execute: function() {
var _this = this;

var blocks = this.slider.image1.find('div.block');

// Get notified when the last transition has completed
$(blocks[0]).transitionEnd(function(){
_this.finished();
});

blocks.each(function(index, block){
setTimeout(function(){
$(block).css({
'opacity': '0'
}).css3({
'transform': flux.browser.rotateZ((!_this.options.alternate || index%2 ? '' : '-')+'90')
});
}, 5);
})
}
}, opts));
};

view raw
fsct-fs.js
This Gist brought to you by GitHub.


Be sure to play with the transition gallery!

Everyone will talk about Angry Birds, but the most important talk at Google I/O is the presentation on the future of the Web platform by two Alex’s and an Ian. This is Alex’s coming out party. This is where we see his vision for the future. Take note.

It kicks in with a look at some of the great things available, but it really gets going when bearded Alex discusses some of the core problems with the platform today. He talks about how we have to be far too prescriptive, and that we need to reduce:

Maintenance burden
Time down the wire
Execution time
Cognitive overhead and complexity

Then clean shaven Alex talks about what we need to fix. He covers:

Maintaining our CSS

CSS variables
CSS mixins
CSS Nesting/Hierarchy (this looks very much like what I do with Stylus today, baked in!)

and fixing CSS in other ways:

Better measurement facilities
Native CSS values
Better layout data
More predictable performance
CSS Layout
CSS Object Model

You can play with some of this via experimental CSS prototype project.

Better Animations
When I build a complex application, I end up wanting to have a clean set of state transitions. Current CSS transitions and animations don’t give me an easy way to do this. Adding a class to the body to force pathways grows unwieldy with anything substantial. What if we had a more explicit way to tie things together, and define a state transition:

/* state transition */
button { state-interaction: normal; }
button:active { state-interaction: pressed; }

@transition button {
  over: state-interaction;
  from: normal;
  to: pressed;
  animation: fancy-press .1s;
  interrupt: reverse;
}

/* relative positions */
@transition div.alert {
  over: left;
  animation; fly-with-bounce 0.5s;
  interrupt: restart;
}
@keyframes fly-with-bounce {
  0% { left: from(); }
  90% { left: calc(to() + 10%); }
  100% { left: to(); }
}

view raw
sample.transition.css
This Gist brought to you by GitHub.


Model Driven Views
We need to fix the integration between JavaScript and CSS/DOM.

An experimental library Model-driven Views aims to back data-binding and templating into the platform:

A proposal for extending HTML and the DOM APIs to support a sensible separation between the UI (DOM) of a document or application and its underlying data (model). Updates to the model are reflected in the DOM and user input into the DOM is immediately assigned to the model.

<div id="example">
Goals:
<ul>
<template iterate>
  <li>{{ goal }}</li>
</template>
</ul>
</div>

<script>
document.getElementById('example').model = [
  {goal: 'Fast'},
  {goal: 'Safe'},
  {goal: 'Simple'},
  {goal: 'Stable'}
];
</script>

<!--
OUTPUT

Note: Extra whitespace/formatting is added in the output part of code samples for clarity's sake. Template instances in the design and prototype do not add extra whitespace.
-->

<div id="example">
Goals:
<ul>
<template iterate></template>
  <li>Fast</li>
  <!--template-instance-->
  <li>Safe</li>
  <!--template-instance-->
  <li>Simple</li>
  <!--template-instance-->
  <li>Stable</li>
  <!--template-instance-->
</ul>
</div>

view raw
mdv.sample.html
This Gist brought to you by GitHub.


This may be controversial, as people have strong opinions on templating and the like. Getting it into the platform would be a huge advantage however, so I look forward to seeing this work evolve.

We just got a glimpse of the future, embodied by the prototype projects:

Experimental CSS
Traceur: prototyping via a JS to JS compiler
Model-driven Views

We now owe it to ourselves to join the cause and make some of this more of a reality.

Layer Styles is a fun little tool that gives you a panel to tweak styles for shadows, backgrounds, and borders. You get to see your preview div in real-time, and get to see the CSS at a click of a button:

border: 1px solid black;
background-image: -moz-linear-gradient(top, #fcfcfc, #f7f7f7 3%, #f2f2f2 12%, #d9d9d9 90%, #bfbfbf);
background-image: -webkit-gradient(linear, center top, center bottom, from(#fcfcfc), to(#bfbfbf), color-stop(3%, #f7f7f7), color-stop(12%, #f2f2f2), color-stop(90%, #d9d9d9));
box-shadow: -1px 1px 5px 7px rgba(51,66,204,0.6);

view raw
sample.layer.style.css
This Gist brought to you by GitHub.

Gradient Scanner: From gradient mock to CSS gradient.

The next talk here at An Event Apart in Boston is one I’ve really, really, really been looking forward to: it’s a presentation by my hero Ethan Marcotte. I’ll try to liveblog it here…

The talk is called The Responsive Web Designer’s Workflow but Ethan begins by talking about his grandmother. She was born in 1910 and she’s still in great shape. This past Christmas she gave Ethan a gift of three battered and worn books that were her father’s diaries from the 1880s. They’re beautiful. The front is filled with almanac data but the most fascinating part is the short updates, mostly about the weather. They’re imperfect with crossing out and misspelling but they’re very visceral.

Stories are important. Passing on stories is an important part of what makes us human. Ethan illustrates this by showing some of my tweets about eating toast.

Newspapers are an odd paradox. For one day they are filled with the most important stories but just a day later they lose that immediate value. Take the Boston Globe, for example. It has a long history. Looking at old copies, the artefact itself is quite lovely.

But it’s a changing industry. This year nearly half of American adults will receive their news through mobile devices. The industry is trying to catch up with various strategies: separate mobile sites, iPad apps, and so on.

Ethan’s response last year was to talk about Responsive Web Design, which breaks down into three parts:

flexible grids,
flexible images and media and
media queries.

The idea has taken hold and lots of very talented designers have adopted a responsive approach.

Well, today you can add one more site to the list: The Boston Globe, relaunching with a responsive design this Summer.

Up ‘till now, responsiveness has been about layout—that’s different to design. As Paul Rand wrote:

Design is the method of putting form and content together.

There were three firms involved in the Globe redesign: The Boston Globe itself, Upstatement, and Filament Group. Ethan was in that third group. Everyone’s got a wide range of skills. It’s tempting to divide skills into visual design and interaction design. But that distinction is often a reflection of the job roles at design agencies.

Is the traditional design agency process part of the problem? We have this linear approach: discover, design, develop, deliver—like a relay race. But for a responsive site, you can never really say what the final deliverable is. You could try to come up with Photoshop comps for all possible layouts but that just doesn’t scale.

Then there’s the tools. The first thing you do when you open up Photoshop is to create a fixed canvas size in pixels. This is what Jason was railing against in his quest for a real web design application.

For the responsive workflow, what’s needed is …design-o-velopment (no, not really).

The group convenes. The designers introduce the comp, explaining their decisions. The developers ask lots of questions. Where does content come from? How does the user interact with it? And the important one: how is going to look on a smaller screen? How should it adapt? They discuss the various input modes: mouse, touch, keyboard, voice. The questions are more important than any particular answers at this point.

“What value does this content have for our mobile users?” That question can be best answered by adopting Luke’s Mobile First approach. Narrow screens force us to focus.

Look at an article on AOL. The mobile version is great. The desktop version is cluttered. We drown the content. “Mobile” has become a synonym for “Less” and “Desktop” has become a synonym for “More.”

If you were asked to describe a mobie user, you might think of someone on the go, easily distracted. Whereas you may imagine a desktop user as sitting comfortably with plenty of screen size and attention. But it’s not that simple. People use their mobile devices in all sorts of environments at all sorts of times.

Making decisions about what people want based simply on the device they are using is a little bit like telepathy. Context doesn’t necessarily determine the user’s intent.

Even a good mobile experience, like Flickr’s, gets things wrong. Content is withheld from visitors with mobile devices. Lots of people click on that “desktop version” link because they feel they are missing out.

When you practice Mobile First, you’re making a commitment to the content. Everything that’s displayed on the page deserves to be there. Mobile First really means Content First.

Now you prototype like wild. A pixel-based tool like Photoshop is limited in what it can convey so you need to start making prototypes from the outset.

Figuring out the proportions for a flexible grid is fairly straightforward: target divided by context equals result. Slot in your pixel values to that equation and you get a percentage that you can declare in your stylesheet. Now you’ve got a liquid layout.

Resizing images is simple:

img { max-width: 100%; }

For important large images you can use Scott Jehl’s script to swap out the image src attribute based on the viewport size. It defaults to the smaller-sized image.

Finally, there’s the media queries. There’s a lot of devices to test on. Fortunately the Filament Group are involved with jQuery Mobile so they’ve already got a lot of devices. But rather than designing for specific devices, they searched instead for commonalities, like screen sizes. These are common breakpoints so they are what’s used in the media queries.

There’s very good browser support for media queries but there are still some laggards. Scott Jehl’s other script, Respond, bootstraps media query support using JavaScript.

It’s worth pointing out that they don’t have comps for all these breakpoints: they’re designing in the browser at this point. But they take these prototypes back to the designers so that they can vet them. They ask more questions. How well does the layout adapt? Do individual elements still feel usable? Most importantly, do any page elements need additional design work?

The masthead of the Boston Globe was a tricky problem. The result from prototyping wasn’t satisfactory so the designers came up with a different solution. As the layout shrinks, the masthead functionality changes. This solution wouldn’t have been possible without reconvening to review the prototype. So they’re designing in the browser but what they’re designing are design recommendations.

A responsive site isn’t flipping between a set of fixed layouts. It’s liquid. Breakpoints that you haven’t thought of will still work.

You have to figure out what is the most appropriate experience for what device. Stephen Hay wrote a great post called There Is No Mobile Web. His point is that the rise of mobile should encourage to revisit our principles of accessibility and progressive enhancement for everyone.

When responsive design meets Mobile First—starting with the narrowest width and building up from there—what you’re doing is progressive enhancement. You’ll even see this layering in the way that the stylesheets are structured.

The basic experience is still very attractive. The next step is enhancing for browsers that support media queries …and Internet Explorer. They get an enhanced stylesheet.

There are other things you can test for: are touch events supported, for example. So an iPad has the screen size of a laptop but it also supports touch events. They get some enhanced JavaScript functionality.

A really tricky question is “is this key content, or is it simply an enhancement for some users?” Web fonts are good example of this grey area. For the Boston Globe, they decided to make a hard cut-off point and only serve up web fonts to viewports above a certain size.

Conditional loading in JavaScript is very useful for serving up the right functionality to the right devices.

Let’s pull back a bit before we wrap up.

Just as there has been discussion “Mobile” and “Desktop”, there has also been discussion of “Mobile” and “Responsiveness.” A lot of the discussion is around butting heads between idealism and realism. Ultimately the decision about whether to make “Mobile” site or a “Responsive” site is more about the designer’s philosophy than about devices.

This has been quite a day for announcements. As well as the forthcoming Boston Globe redesign, Ethan also has a publishing date for his book: Responsive Web Design will be published by A Book Apart on June 7th.

Tagged with
aea
aneventapart
aeabos
liveblogging
conference
ethanmarcotte
responsive
mobile
design
css
mediaqueries

CSS3 brings with it a lot of rich styling. One example is CSS gradients. If your workflow involves getting comps/mocks from a designer you find yourself seeing a lovely gradient, and needing to convert it from the image in front of you to the equivalent CSS style. Beyond trivial gradients this can actually be quite tricky.

In the rich UNIX tradition of creating smart tools that do one thing well, I wanted to great a Web-based tool that does this for you, and the result is the Gradient Scanner.

This project was an attempt to bring more CSS3 goodness to mock-based development processes. Rather than creating a possibly large and difficult/impossible to sprite external image for a border-image/9patch or trying to generate a gradient by eye balling, gradient-scanner attempts generate the CSS for a gradient within a composite image with minimal input from the developer.

How do you use it?
Converting a mock to the associated CSS is a simple process:

Open the image via local file system access or URL
Drag select the line containing the gradient image
Adjust the heuristic’s sensitivity
Manually edit or disable color stops as necessary

How does it actually work?
Gradient Scanner is implemented entirely in JavaScript, taking advantage of canvas and node to provide access to the image data and some client-side heuristics to get the selected content for possible matching gradients.

The code is available on github @ kpdecker/gradient-scanner.

How I used it
I have been hacking on FunctionSource, and in true dogfooding style this has already been used to implement the gradients used in FunctionSource buttons as well as the featured gradients in an upcoming theme refresh.

This is an early release so I’m looking for feedback on what works and doesn’t in the current implementation. Feel free to provide feedback via github issues, commenting below, or by contacting me directly. Oh, and of course pull requests are very much invited!

  I believe in the power, speed and “update-ability” of CSS3. Not having to load background images as structural enhancements (such as PNGs for rounded corners and gradients) can save time in production (i.e. billable hours) and loading (i.e. page speed). At our company, we’ve happily been using CSS3 on client websites for over a year now, and I find that implementing many of these properties right now is the most sensible way to build websites.
Until today, all of that was based on an assumption: that I can produce a pixel-perfect Web page with CSS3 quicker than I can with older image-based CSS methods, and that the CSS3 page will load faster, with a smaller overall file size and fewer HTTP requests. As a single use case experiment, I decided to design and code a Web page and add visual enhancements twice: once with CSS3, and a second time using background images sliced directly from the PSD. I timed myself each round that I added the enhancements, and when finished, I used Pingdom to measure the loading times.
Here’s a fictitious Web page for Mercury Automobiles that might have been online had the Interweb existed back in the 1950s. The page was designed to showcase specific widely compliant CSS3 properties that in the past would have had to be achieved using background images.

Above is a diagram that breaks down where I applied visual enhancements first with CSS3, and then with CSS background images (i.e. the image-based approach):
linear-gradientborder-radiusradial-gradienttext-shadowbox-shadow with RGBaThe Experiment ProcessDay 1I coded the HTML and CSS from a structural standpoint. That means no rounded corners, no shadows, no gradients and no images aside from logos and car photographs. I decided to include Web fonts at this phase because I wanted to focus on stuff that could also be done with the Web-safe font of your choice (Helvetica, Georgia, etc.). Furthermore, @font-face was around long before CSS3.

This gave me a blank canvas to add visual enhancements. The index page shows the end of my day 1 work, as well as what unsupported browsers will display, the appearance of which is structurally intact and visually pleasing. More on this later, but the way I see it, older browsers aren’t penalized with a broken layout, and modern browsers are rewarded with a few visual bonuses. Part of implementing CSS3 is about planning ahead and designing websites that look fine as a fallback.
Day 2Starting with the base index page, I created a CSS3 page. It took 49 minutes to complete. Here is the CSS code (css3.css):

/*-----CSS3 Started on 2/26/11 at 7:28 AM CST-----*/
h1 {
text-shadow: -3px 2px 0px #514d46; }

#nav {
-moz-box-shadow: 0px 0px 12px rgba(88, 83, 74, .7);
-webkit-box-shadow: 0px 0px 12px rgba(88, 83, 74, .7);
box-shadow: 0px 0px 12px rgba(88, 83, 74, .7);
background-image: -moz-linear-gradient(top, #5c5850, #48473e);
background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #5c5850),color-stop(1, #48473e));
background-image: -webkit-linear-gradient(#5c5850, #48473e);
background-image: linear-gradient(top, #5c5850, #48473e); }

nav a {
-moz-border-radius: 12px;
-webkit-border-radius: 12px;
border-radius: 12px; }

nav a:hover {
background-color: #3a3e38;
background-color: rgba(47, 54, 48, .7); }

nav a.active {
background-color: #070807;
background-color: rgba(7, 8, 7, .7); }

body {
background-image: -webkit-gradient(radial, 50% 10%, 0, 50% 10%, 500, from(#FBF8E3), to(#E6E3D0));
background-image: -moz-radial-gradient(50% 10%, farthest-side, #FBF8E3, #E6E3D0); }

#learn_more, #details img {
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
border-radius: 8px;
-webkit-box-shadow: inset 0px 0px 8px rgba(88, 83, 74, .2);
-moz-box-shadow: inset 1px 0px 1px rgba(88, 83, 74, .2);
box-shadow: inset 0px 0px 1px rgba(88, 83, 74, .2); }

#learn_more a {
-moz-border-radius: 8px;
-webkit-border-radius: 8px;
border-radius: 8px;
background-color: #cc3b23;
background-image: -moz-linear-gradient(top, #cc3b23, #c00b00);
background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, #cc3b23),color-stop(1, #c00b00));
background-image: -webkit-linear-gradient(#cc3b23, #c00b00);
background-image: linear-gradient(top, #cc3b23, #c00b00); }

a {
-moz-transition: all 0.3s ease-in;
-o-transition: all 0.3s ease-in;
-webkit-transition: all 0.3s ease-in;
transition: all 0.3s ease-in; }

/*-----CSS3 Finished on 2/26/11 at 8:17 AM CST (49 minutes) -----*/
Day 3I added visual enhancements by slicing and CSS’ing background images directly from the PSD. Even though there is less code, all of the extra app-switching and image-slicing added up to a total of 73 minutes to complete. Check out the page for the CSS image-based approach. Here’s the code (css.css):

/*-----CSS (the image-based approach) Started on 2/27/11 at 12:42 PM CST-----*/

#header {
background: url(../img/navbg.png) left top repeat-x; }

body {
background: #e6e3d0 url(../img/radial_gradient.jpg) no-repeat center top; }

#nav {
background-color: transparent; }

h1 {
background: url(../img/mercuryautomobiles.png) no-repeat center center;text-indent: -9999px; }

#learn_more {
background-image: url(../img/learn_morebg.jpg);}

#details img {
background-image: url(../img/detailsbg.jpg);}

#learn_more a {
background: url(../img/learn_more_abg.jpg) no-repeat;}

.css3 {
background: url(../img/css3_hover.png) no-repeat center top; }

.smashing {
background: url(../img/smashing_hover.png) no-repeat center top; }

.trent {
background: url(../img/trentwalton_hover.png) no-repeat center top;}

.css3:hover {
background: url(../img/css3_hover.png) no-repeat center -20px;}

.css:hover {
background: url(../img/css_hover.png) no-repeat center -20px;}

.smashing:hover {
background: url(../img/smashing_hover.png) no-repeat center -20px;}

.trent:hover {
background: url(../img/trentwalton_hover.png) no-repeat center -20px; }

.css {
background: url(../img/css_hover.png) no-repeat center -50px; }

/*-----CSS (the image-based approach) Finished on 2/27/11 at 1:55 AM CST (1 hour and 13 minutes)-----*/
Production Time ResultsSo, we’re looking at a 24-minute difference: 49 minutes to add visual enhancements with CSS3, and 73 minutes to do it with images. For me, CSS3 was not only quicker but far more enjoyable, because I was focused on only one window (my CSS editor), unless I opted to pull some of the code from CSS3 Please. On the other hand, slicing images and switching from Photoshop to FTP to the CSS editor and back again was a hassle, and it did take longer.
It’s also worth noting that I did my best to stack the deck against CSS3. I coded it first so that any initial hashing out would be done before heading into day 3. Also, the images I did slice are as optimized as I could reasonably make them: one-pixel repeating slivers, and medium-resolution image exports. Overall, 24 minutes may not seem like a lot of time, but this is a fairly simple page. Imagine how much time (and money) could be saved over the course of a year.
What? Still not convinced?…
File Size And Loading Time ResultsI took both of my pages over to Pingdom Tools to compare file size and loading times.

Both pages are pretty fast, but CSS3 prevailed, with 10 fewer requests and a file size that was lighter by 81.3 KB. While loading times were close, the larger PNG files used on both pages accounted for most of the heft, which amounted to a .75 second difference on average. And when we’re talking 3 to 6 second loading times, those differences sure can add up.
CSS3CSSDifferenceSize767.9 KB849.2 KB81.3 KBRequests122210For argument’s sake, I created yet another version of the image-based CSS version, with a sprite containing all four images used in the original version, and then I measured loading times. This CSS Sprited version did improve things, taking HTTP requests from 22 to 19 and the overall size from 849.2 KB down to 846.7 KB. The way I see it, these differences are minimal and would have added to the development time, so it’s all relative.
Without getting too sidetracked, I think the difference in loading times is significant. If a website gets 100 hits a day, the difference may not matter much, but on a higher traffic website the effect compounds. Shaving seconds or even milliseconds off the loading time of a website is no small improvement in user experience. The image-based approach could lead to upwards of a 15 to 27% drop in page traffic (based on a 5 to 9% per 400 ms rate). That’s a lot of dinero to lose. I wonder how much time and money could be saved by serving a CSS3 border-radius sign-up button on a website with as much traffic as Twitter’s.

Another striking example is all the CSS3 that can be found in Gmail’s interface. The CSS3 gradients and rounded corners are there to increase page speed. Speaking of Gmail’s continued use of HTML5 (and CSS3), Adam de Boor had this to say about speeding up page rendering:
Google’s current goal is to get Gmail to load in under a second. Speed is a feature.”
And this:
The company has found that using CSS3 can speed the rendering time by 12 percent.
Convinced yet? No? Okay, I’ll keep going…
Thinking About The FutureWebsite Updates: The Easy Way and the Hard WayCSS3 really pays off when it comes to making updates and future-proofing Web pages from a maintenance perspective. Looking at the Mercury Automobiles website, think about what would have to go into changing the height of the three-column car images or the width of the bubble hover states for the navigation. For the sake of a quick production, I sliced these images to match precisely. One option would be to open Photoshop, rebuild and resize the images, update the appropriate CSS properties, and upload. Another would be to plan ahead and slice “telescoping” images, making one end a short rounded corner cap and another longer image on the opposite end that slides to fill the interior space. Y[…]

Adapt.js: More efficient responsive design: As the mobile space continues to grow, there has been a growing interest in Responsive Web
Design,
making use of CSS media
queries to selectively target
device screen size and layout orientation in CSS stylesheets. But as
Jason
Grigsby points out, media queries have
substantial
drawbacks. Since media queries only filter styles and (and related image assets) on the client, you may end up pushing a lot of data down to the client that the user may never see. In mobile applications, this is extremely costly.

Nathan Smith, JavaScript hacker and
creator of the 960 Grid System has released
Adapt.js, a lightweight JavaScript library that
will let you specify a list of stylesheets and the screen sizes for
which they should be loaded:

// Edit to suit your needs.
var ADAPT_CONFIG = {
// Where is your CSS?
path: 'assets/css/',

// false = Only run one time, when page first loads.
// true = Change for window resize or page tilt too.
dynamic: true,

// First range entry is the minimum.
// Last range entry is the maximum.
// Should have at least one "to" range.
range: [
'760px = mobile.css',
'760px to 960px = 720.css',
'960px to 1280px = 960.css',
'1280px to 1600px = 1200.css',
'1600px to 1920px = 1560.css',
'1920px = fluid.css'
]
};

When your page loades, the appropriate layout is written to the
of your document based on the screen width of the page. If you enable the
dynamic setting, additional stylesheets will be fetched when the user
resizes the browser window or rotates their mobile device.

Silver bullet?

Nathan admits that every project is different and there are tradeoffs
between stylesheet size and extra network hops:

As with any area in which technological approaches are open for
debate, there is the danger of religious fanaticism, where we each
rally behind a respective method and defend it vehemently. I would
caution you to weigh the options, consider mobile users, and choose an
approach makes sense for you.

[Source on GitHub] [Web
site]

With the increasing better support from browsers for CSS we can rely more on code for content presentation. I noticed that a lot of websites don’t look farther then the design and typography. It’s good practice to include images with your articles and weblog entries. But many people don’t think about enhancing photos and using CSS to make it stand out more.

On my personal weblog I always edit photos in Photoshop if I take them with my camera or I edit my iPhone photos with apps for a nice effect. Much used effects are vignette, converting photo to a vintage look or B&W. To finish it I always have a CSS style in place to add borders and shadows to the photo. Now with CSS3 you can do even more with your photos, especially transition offers many possibilities.

Try out these Photoshop tutorials and remember to use Action recorder to make it easy to re-apply these effects on future photos. Then next, pick out your favorite CSS technique to apply to your photo on your website.

Photoshop Photo Tutorials
How to turn your photo into movie-like effect using Photoshop?

How to give a retro-look to your photos

How To Give Your Photos a Vintage Polaroid Effect

How To Give Your Photos a Dark Processed Lomo Effect

How To Give Your Photos a Cool Retro Analog Effect

Selective Sepia

Cross Processing Effect

How To Make Digital Photos Look Like Lomo Photography

Photoshop vintage effect

Black And White Conversions In Photoshop

CSS Image Presentation
Border Radius Rounded Images and Avatars

Fancy Inset CSS Image Borders

CSS3 box-shadow and image hover effects

Going Nuts with CSS Transitions

Now we have something else to be thankful for. Nathan Smith of Sonspring has created a library that gives designers and developers “some measure of control over form elements, without changing them so drastically as to appear foreign in a user’s operating system.” Smith calls his new library Formalize CSS:

I’ve attempted to bridge the gap between various browsers and OS’s, taking the best ideas from each, and implementing what is possible across the board. For the most part, this means most textual form elements have a slight inset, and all buttons look consistent, including the button tag.

For more, including demos, options, screenshots, thanks, and the library itself, read Smith’s write-up at SonSpring | Formalize CSS. Hat tip and happy Thanksgiving to my good friend Aaron Gustafson for sharing this gem.

Benjamin De Cock’s vCard: A simple new vCard website, with some beautiful CSS effects built in.

Typical cheatsheets tend to be over-sized documents, far too large to be viewed in its entirety on a desktop and not too handy for the super-fast reference that is needed. To get the full benefit of any cheatsheat, your only real option is to print it out and keep it close at hand. Wouldn’t it be nice if there was an easier way, a quicker way. Of course there is – what good be handier than having a cheatsheet set as your desktop wallpaper? Always there for quick reference, no need to print it out and no need to scroll through an over-long document.
In this post we have rounded up a selection of cheatsheet wallpapers, in various sizes, covering various technologies, like CSS, HTML5, WordPress, Javascript and many more.
You may also like these articles: 14 Essential WordPress Development and Design Cheat Sheets » 17 Productive Photoshop Cheatsheets and Reference Cards to Download for Free » The Best Cheat Sheets for Web Designers and Developers (From CSS, Ajax, Perl, Vbscript…) » CSS References, Tutorials, Cheat Sheets, Conversion Tables and Short Codes »WordPress Help Sheet Wallpaper The WordPress Help Sheet Wallpaper is a simple desktop wallpaper listing Basic Template Files, PHP Snippets for the Header, PHP Snippets for the Templates, Extra Stuff for WordPress, based on the WPCandy WordPress Help Sheet. Download: 2560x1600px.
Drupal Cheat Sheet Desktop Wallpaper The Drupal Cheat Sheet Desktop Wallpaper is a desktop wallpaper that features the most popular variables of the open source content management system Drupal. Download: 1024x768px – 1280x800px – 1440x900px – 1680x1050px – 1920x1200px.
HTML5 Canvas Cheat Sheet The information on this wallpaper is pretty much just a copy of what is found in the WHATWG specs, just condensed and a little bit easier to read. There are virtually no explanations, and no examples other than some graphics for compositing values. It's basically just a listing of the attributes and methods of the canvas element and the 2d drawing context. Download: 1388x1027px.
CSS Cheat Sheet Wallpaper in Helvetica This is the very popular CSS cheat sheet in Helvetica from styl.eti.me. Simplistic in appearance, but very useful for quick referencing. Unfortunately we can not find a working download link for this cool wallpaper, but the good news is they do have a PSD version available. So download it and resize. Download: CSS Cheat Sheet Wallpaper in Helvetica.
TextMate Shortcuts Wallpaper Here is a TextMate wallpaper that will guide you through some of its powerful features and help you get a handle on all of the keyboard shortcuts. The PSD file is also available. Download: 1280x800px – 1920x1200px.
Yahoo! UI (YUI) Cheat Sheets as Wallpaper Yahoo! provides a number of cheat sheets for their YUI library widgets however these are all in PDF format and not usable as wallpaper. However, here you will find all of those cheatsheets converted to PNG images of various sizes all for your desktop. There are wallpapers available for Animation, Calendar, Connection Manager, Dom Collection, Drag & Drop Event, Utility & Custom Event Logger, Slider and TreeView. And all are available in the following desktop sizes: 1400x1050px, 1280x960px, 1165x900px and 1024x768px. Download: Yahoo! UI (YUI) Cheat Sheets as Wallpaper.
jQuery 1.3 Cheat Sheet Wallpaper Download: 1440x900px – 1680x1050px – 1920x1200px.
Prototype Dissected Wallpaper If you need a little help in getting to know Prototype a little better and some help in understanding how the code works, then this is the wallpaper for you. You have a choice of either a dark or white wallpaper, and are available in these sizes: 1280x960px and 1440x900px. Download: 1280x960px (Dark) – 1440x900px (Dark) – 1280x960px (White) – 1440x900px (White).
Git Cheat Sheet Wallpaper Download: 1100x850px – 3300x2550px.
A Themer's Cheatsheet Wallpaper A Themer's Cheatsheet Wallpaper is a quick refresher of web design fundamentals directly on your desktop. It is available for download in several different colors and the original SVG has been released to the Public Domain. Download: 1280x800px (Blue) – 1280x800px (Red) – 1280x800px (Black) – 1280x800px (Green).
Font Anatomy Wallpaper Download: 1920x1200px.
SEO Wallpapers Think of it as a desk reference checklist that is always at your fingertips. From pre-campaign to reporting, the basics (and more) are right here for you to put directly on your desktop. Download: 1024x768px – 1280x960px – 1280x1024px – 1440x900px.
Periodic Table of Typefaces Download: 1024x768px – 1280x800px – 1280x1024px – 1440x900px – 1680x1050px – 1920x1200px.
Color Theory Quick Reference Poster The Color Theory Quick Reference Poster for Designers has all of the basics of color theory contained in one place – specifically, a cool infographic-esque poster. This way, you can quickly reference things that may have slipped to the back of your mind since design school. Download: 1280x800px – 1440x900px – 1680x1050px – 1920x1200px.
Web Designer Wallpaper Download: 1280x1024px (White) – 1280x1024px (Dark) – 1680x10050px (Dark) – 1280x1024px (White).
You might also like…14 Essential WordPress Development and Design Cheat Sheets » 17 Productive Photoshop Cheatsheets and Reference Cards to Download for Free » The Best Cheat Sheets for Web Designers and Developers (From CSS, Ajax, Perl, Vbscript…) » CSS References, Tutorials, Cheat Sheets, Conversion Tables and Short Codes » 20 CSS3 Tutorials and Techniques for Creating Buttons » 50 Useful Tools and Generators for Easy CSS Development » 50 Essential Web Typography Tutorials, Tips, Guides and Best Practices » The Blueprint CSS Framework – Tutorials, How-to Guides and Tools »

I went along to the fifth Barcamp Brighton on the weekend. It was a truly excellent event, hosted in The Skiff, a great coworking space. Alas, a creeping cold meant that I couldn’t stick around for too long, but I made sure to give a presentation before I bailed.

I spoke about media queries. As you may have gathered from my recent entries, this is something I’ve been thinking about a lot lately.

I didn’t prepare any slides. If I had, they would have consisted of screenshots and CSS, so I figured why not just show the actual sites and CSS instead? It was a fairly rambling, chaotic presentation but it helped me to clarify some ideas. Prem asked if I would reprise the presentation at Async—Brighton’s JavaScript meetup—on October 28th so that will give me a chance to marshall my thoughts.

In reiterating my point about fluid grids being a necessary prerequisite for responsive web design, I tried to take a long-zoom approach and went all the way back to John’s superb A Dao of Web Design article—now ten years old!

The tool problem

I still feel that most designers haven’t yet fully embraced the web as its own medium, choosing instead to treat it along the same lines as print design. Or, as Mark put it his excellent talk on designing grid systems, designing from the canvas in rather than the content out.

Far too early in the design process, a tool such as Photoshop or Fireworks gets opened up and a new file is created with an arbitrary width (960 pixels being the current width du jour). That process lends itself well to creating paintings of websites but it’s not a great first step in creating a living, breathing website. Experiments like Liz’s Evening Edition not withstanding, what I wrote back in 2006 still holds true:

CSS hasn’t revolutionised web design. The reason lies not with the technology (which is revolutionary), but with the designers using it. Most designers have simply swapped the old technology (tables and font tags) for the new technology, without fully exploring what’s so completely new.

My point is that responsive web design isn’t something that can be tacked on to the end of an existing workflow. It requires a different mindset, one that considers the medium from the outset. If you’re currently thinking in proportions rather than pixels, the transition to responsive web design will be relatively painless. But if you’re stuck in the world of converting PSDs into web pages, you’re going to have a tough time.

I’ve written about the problems with our tools before and Stan has crafted the definitive call to arms for A Real Web Design Application so I’ll spare you another rant.

A new approach

At Barcamp Brighton, I encapsulated my thinking by saying:

Instead of thinking in terms of pixel perfection, we should be thinking of proportion perfection.

Then I showed a bunch of sites I’ve worked on that are using media queries to adapt to different screen sizes: Huffduffer, Salter Cane, St. Paul’s School and UX London.

All of those sites are built in a similar way. First, CSS is used to create the optimal layout e.g. three columns floated alongside one another. Then media queries are used to over-ride those float and width declarations so that the content is linearised.

That’s all well and good but, as someone correctly pointed out during the presentation, what about small-screen devices that don’t support media queries?

That’s an excellent question. The answer requires another shift in perspective. Instead of thinking of the widescreen version as the starting point, why not consider the small screen layout first?

In a way, this is an extension of Luke’s Mobile First exercise — thinking of the mobile experience before building the desktop site.

In his presentation at Over The Air, Bryan Rieger advocated this approach for media queries. As he correctly points out—and this is something echoed by PPK—what we’re talking about here is essentially progressive enhancement.

Instead of just using progressive enhancement to throw in some rounded corners, opacity or gradients, we can apply the same thinking to layout: start with the most basic CSS—colours, fonts, etc.—and then apply floats and widths according to the capabilites of the browser …as determined by media queries.

That’s what I did for the Science Hack Day website and now I’ve decided to take the same approach with adactio.com.

At this point, you might be wondering if I’m going to mention the elephant in the room. You know: the elephant …from Microsoft …elephant versions 8 and lower.

My first thought was to use conditional comments. All browsers get the same stylesheet but elephantine browsers get an extra one which contains the same float and width declarations that are contained in the media queries. But that violates the DRY principle: any time I make a layout change, I would have to remember to make the changes in two different stylesheets. Prem suggested placing an @import rule within the media query to pull in the same stylesheet that IE is getting via conditional comments …but alas, @import rules need to come first in a CSS document.

So, for now, users of Internet Explorer visiting adactio.com will just get the linearised content. I may decide to violate the DRY principle and use conditional comments at a later date.

Revisiting adactio.com

Over the years, I’ve resisted the temptation to do a complete redesign of my site. Instead, I’ve added different designs as options that can be selected from any page on the site. After all, isn’t the whole point of CSS that it’s separated from the structure? Changing the visual appearance shouldn’t necessitate changing the markup; that’s the lesson of the CSS Zen Garden.

So I’ve stubbornly refused to update my markup for almost ten years. But now, what with having written a book on HTML5 and all, I figured I could make a few changes.

The doctype has been updated. Elements that had previously been given IDs are now identified with ARIA landmark roles instead (and referenced in the CSS with attribute selectors). These days, I rarely use IDs for anything other than making document fragments addressable, so it was interesting to see how my past self did things differently.

My past self was also trying to be far too clever with the separation of concerns in the CSS. I was using three different stylesheets for each theme: one for colour, one for typography, and one for layout. In retrospect, this was a bad idea for two reasons:

I’m increasing the number of HTTP requests.
While it might be obvious that font-family declarations belong in the typography stylesheet and background-color declarations belong in the colour stylesheet, it’s not nearly so simple to figure out where margins and paddings should go. Is that layout? Is it typography?

It turns out that a more holistic approach to CSS is far, far easier to work with. It felt good to finally merge those separate CSS files into one.

Oh, there was one more good point raised at the Barcamp Brighton presentation… I had being going on about how assumptions can be dangerous—assuming that the user is visiting your site from a desktop machine, assuming that a large monitor size equates to a large viewport size, assuming that a large browser window means that large bandwidth is available, and so on. Somebody pointed out that, in applying my media queries using pixels, I was making assumptions about equating pixel width to viewable area. An excellent point! For that reason, all the media queries used in the different themes on adactio.com are triggered with ems rather than pixels.

For the record, here are some useful em widths that can be used as trigger points:

40em =~ 640px
50em =~ 800px
64em =~ 1024px

Default

Tate Modern

Seaside

Zeldman

Adactizilla

Sci-fi

Renaissance

Hirnlego

Tagged with
css
design
adaptive
responsive
mediaqueries
adactio
progressive
enhancement
barcamp
brighton
bcb5

Jay Robinson and Edward Sanchez worked together to create this handy WebKit/CSS3 Cheat Sheet. Check it out! (PDF)

dropshado.ws: -webkit-line-clamp: Incredibly useful tip about -webkit-line-clamp from Dave Desandro’s new blog, DropShado.ws. -webkit-line-clamp is like text-overflow: ellipsis but for paragraphs!

I did some quick testing to find it works on iOS 3+ but it did not work on Android 2.1 (Eclair).

Our very own Christian Heilmann has posted a tutorial on creating a fancy sticky note effect using CSS3 and HTML5:

He breaks it down in five easy steps to produce the final following demo:

Via Zachary Johnson (aka the Zachstronaut) comes a cool experiment using pure CSS to generate pulsing rings/map markers. He's put together a nice video explaining the concept:

He has a cool demo (Chrome or Safari + Snow Leopard only) of the effect:

The pulsing effect, for example, is generated by a CSS3 Animation:

PLAIN TEXT
CSS:

@-webkit-keyframes ringpulser
        {
                0%
                {
                        opacity: 1.0;
                        -webkit-transform: scale(0.2);
                }
               
                80%
                {
                        opacity: 0.0;
                        -webkit-transform: scale(1.0);
                }
               
                100%
                {
                        opacity: 0.0;
                        -webkit-transform: scale(0.2);
                }
        }
 

The map itself is rotated to a 3D angle using a CSS 3D Transform:

PLAIN TEXT
CSS:

#map
        {
            position: absolute;
            top: -430px;
            left: 50px;
            background: url(planis-map.jpg) top left no-repeat;
            width: 800px;
            height: 548px;
            -webkit-transform-style: preserve-3d;
            -webkit-transform: rotateX(60deg) translate3d(0, 0, -500px);
            opacity: 0.75;
        }
 

While the pin, marker, and pinhead themselves are a combination of CSS 3D, CSS Transforms, CSS Gradients, and more:

PLAIN TEXT
CSS:

        .marker
        {
                position: absolute;
                width: 100px;
                height: 100px;
                -webkit-perspective: 600;
        }
       
        .pin
        {
            position: absolute;
            top: 10%;
            left: 52%;
            border-left: 2px solid transparent;
            border-right: 2px solid transparent;
            border-top: 40px solid #666;
            -webkit-transform: rotate(9deg);
            width: 0;
            height: 0;
        }
       
        .pinhead
        {
            position: absolute;
            top: 8%;
            left: 49%;
            width: 15px;
            height: 15px;
            -webkit-border-radius: 15px;
            background: #999 -webkit-gradient(
                radial, 95% 40%, 5, 85% 40%, 10, from(rgba(0, 0, 0, 0.40)), to(rgba(0, 0, 0, 0))
        )
 

We've seen a number of nice CSS3 generators. I stumbled across another one recently that has a nice set of features for autogenerating the following from a single CSS3 generator web page:

Border Radius
Gradients
CSS Transforms
CSS Animations
CSS Transitions
Text Shadow
Box Shadow
Text Rotation
@Font Face

Free for use in all web projects, professional or personal, HTML5 Reset by Monkey Do! is a set of HTML5 and CSS templates that jumpstart web development by removing the styling native to each browser, establishing basic HTML structures (title, header, footer, etc.), clearing floats, correcting for IE problems, and more.

Most of us who design websites begin every project with bits and pieces of this kind of code, but developer Tim Murtaugh, who created these files and who modestly thanks everyone in the universe, has struck a near-ideal balance. In these lean, simple files, without fuss or clutter, he manages to give us the best-practices equivalent of everything but the kitchen sink.

Tim Murtaugh sits beside me at Happy Cog, so I’ve seen him use these very files (and earlier versions of them) to quickly code advanced websites. If you’re up to speed on all the new hotness, these files will help you stay that way and work faster. If you’re still learning (and who isn’t?) about HTML5, CSS3, and browser workarounds, studying these files and Tim’s notes about them will help you become a more knowledgeable web designer slash developer. (We need a better name for what we do.)

My daughter calls Mr Murtaugh “Tim the giant.” With the release of this little package, he earns the moniker. Highly recommended.

Gradient Text In WebKit: Mitch Johnson with a nice clean code sample.

Over at the the YUI blog the team just announced the preview release of YUI 3.2.0. YUI3 now has some interesting new features that the team wants you to try and tell them if they work out for you. The changes to the already very powerful library are quite ambitious:

Touch event support for mobile interfaces including flick and move gestures
Browser capability loading - which means that every browser gets the least amount of code necessary to make it work
Transition support for the animation module - meaning only browsers that don't support CSS3 transitions get the JavaScript animation fallback
An update to the CSS grids to allow for more flexible layouts
A ScrollView widget similar to the one in Apple iOS
The uploader has been transitioned over from YUI2 to YUI3

So check out what is on offer and give the YUI team feedback on what would be nice to have and what is broken. In their own words:

The goal of a preview release is to make it as easy as possible for all of us in the community to evaluate progress of the upcoming release and provide feedback. Please take some time to test 3.2.0pr1 and let us know what you find by filing tickets in the YUI 3 bug database marked as “Observed in version” 3.2.0pr1. We’ll do our best to address preview-release questions on the YUI 3 Forums, too.

There are three ways to get started with the preview release: YUI 3.2.0pr1 is available on the CDN via the 3.2.0pr1 version tag — so you can reference preview-release files like http://yui.yahooapis.com/combo?3.2.0pr1/build/yui/yui-min.js. If you switch to this seed file for the preview release, all subsequent use() statements will continue to load YUI 3.2.0pr1. Or You can download the full YUI 3.2.0pr1 from YUILibrary.com, including source code and examples for all components. Or you can simply explore the functioning examples roster.

Everyone's chomping at the bit to leverage new HTML5 and CSS3 features but with some older browsers not supporting them, hacks are still needed to make things work in a cross-browser fashion. We've seen libs that make things easier such as Remy Sharp's html5shiv and Modernizr and now we can add another one.

Jason Johnston's new PIE library makes it easy to rendering several of the most useful CSS3 decoration features within Internet Explorer versions 6 through 8. He took an interesting approach by using IE DHTML Behaviors to style the elements and provide the necessary functionality to emulate the CSS3 functionality. So to add rounded corners to an element, your CSS code might look like this in plain 'ole CSS:

PLAIN TEXT
CSS:

#myElement {
    background: #EEE;
    padding: 2em;
    -moz-border-radius: 1em;
    -webkit-border-radius: 1em;
    border-radius: 1em;
}
 

To add support in IE 6-8 using PIE, you'd add this:

PLAIN TEXT
CSS:

#myElement {
    ...
    behavior: url(PIE.htc);
}
 

PIE currently has full or partial support for:

border-radius
box-shadow
border-image
multiple background images
linear-gradient background images

Unfortunately, there seems to only be one demo at the moment, which is border-radius rendering via the home page, but it's still seems like a good start with a lot of future potential.

I've never personally used IE DHTML Behaviors or HTML Components so I looked them up and found these intro links for those who might be interested in better understanding them:

Using HTML Components to Implement DHTML Behaviors in Script
Introduction to DHTML Behaviors

Franz Enzenhofer has created a nice new webkitTransform plugin that helps you manage transforms and state.

Franz tells us more:

With jQuery.css you can't easily change the webkitTransform CSS because webkitTransform is not your average CSS.

If in one step you add .css('-webkit-transform', "rotate(20deg)") and in the next step .css('-webkit-transform', "scale(2.0)") the rotate value gets reset, as you have rewritten the complete -webkit-transform CSS value.

You could use the WebKitCSSMatrix javascript element, but it's currently buggy, not consistently implemented and a pain to use.

Additionally you can't just retrieve the '-webkit-transform' css with .css('-webkit-transform') as this just gives a matrix code.

Our goal with webkitTransform() was to fix this problem. With it, every element you assign webkit-transform css with can be edited in a simple way, without resetting every other -webkit-transform values.

Louis Harboe has recreated the iOS4 icons in Pure CSS. These are incredible, and totally resolution independent. (via jayrobinson)

How to tailor CSS for iPhone 4 (Retina display) (via esquareda)

Geuis Teses has released an enjoyable library called Helium that has the goal of testing your stylesheets for unused style.

You inject helium into your site (e.g. put it in an included footer) and then when you hit the first page you will have a popup asking for the pages you want to test. Helium will find the style sheets that you use and will store that information and the page information inside of localStorage. Then it will XHR around (so your styles need to be on the same host), test each page, and finally give you results.

I put up a trivial example to give it a ride and ended up with:

I ran into a minor issue with regards to relative stylesheets so I did the Github thing and forked, fixed, and pull requested. I love Github :)