(Flickr photo by Hey Paul)

Most modern websites use a grid to visually organize content into columns and rows, and nearly every front-end framework includes a robust grid system. If you’re totally new to front-end frameworks, I also recommend the course Framework Basics on Treehouse. Even if you are familiar, the grid in Zurb Foundation 5 might be a bit overwhelming at first. However, it’s worth learning, because it dramatically reduces the amount of project-specific code that needs to be written.

The first step is to download Foundation and include it in your project. If you’re a beginner, I recommend the official Foundation CSS guide, but you can also use Foundation with SASS or integrate Foundation with a web app.

Grid Basics

Foundation creates columns and rows by applying CSS classes to HTML elements. This is a simple idea on its own, but Foundation is also a responsive framework that uses a mobile-first approach. That means that Foundation is designed to work on mobile phones, tablets, and larger displays like laptops and desktops, in that order.

When building websites with Foundation, it’s best to start by thinking about the mobile experience first and then gradually work your way up to desktop sizes. This might seem counter-intuitive, but it’s a smart workflow. Multi-column layouts don’t work well on mobile web browsers because they tend to be on small screens that are taller than they are wide. Cramming a big layout onto a small screen is much more difficult than starting with a simple mobile layout and working up to complex desktop designs.

GRid Template

Before I describe each grid class, I’d like you to see the “big picture” by looking at this HTML template from Zurb’s website:

This is a screenshot of the HTML template available at http://foundation.zurb.com/templates/banded.html

The grid in Foundation is 12 columns across. Each major horizontal section of the site is a row. Then, a series of columns is nested inside the rows. Each group of columns inside a row should generally add up to a total of 12, but there are more advanced features that allow you to bend this rule.

In the template example, the header is a row. Inside the header there’s a div for the logo and a div for the navigation. The logo div has the class large-3, which means it should span across three grid columns. The logo has the class large-9, meaning it should span nine columns. These two classes added together fill all 12 columns inside the header row.

Next, the large image in the center of the page is a row with a single column inside. This single column has the class large-12 because it should span across all 12 columns. The rest of the page is constructed in a similar fashion, using rows and columns. In this second screenshot, I’ve added a bright orange outline to the columns class to help you see how the page is built.

This is a screenshot of the same HTML template with an orange outline added to the columns class.

If you view the source for this example template, you’ll see quite a lot of code, much of it not related to creating the grid itself. I’ve simplified the template’s code to only include the elements and classes that are necessary for creating the grid. Study this code for a moment, and then move on to the more detailed explanations of each class below.

    <!-- Header and Nav -->
    
    <div class="row">
      <div class="large-3 columns">
        <!-- logo -->
      </div>
      <div class="large-9 columns">
        <!-- navigation -->
      </div>
    </div>
    
    <!-- First Band (Image) -->
    
    <div class="row">
      <div class="large-12 columns">
        <!-- large center image -->
      </div>
    </div>
    
    <!-- Second Band (Image Left with Text) -->
    
    <div class="row">
      <div class="large-4 columns">
        <!-- left image -->
      </div>
      <div class="large-8 columns">
        <!-- text content -->
      </div>
    </div>
    
    <!-- Third Band (Image Right with Text) -->
    
    <div class="row">
      <div class="large-8 columns">
        <!-- text content -->
      </div>
      <div class="large-4 columns">
        <!-- right image -->
      </div>
    </div>
    
    <!-- Footer -->
    
    <footer class="row">
      <div class="large-12 columns">
        <div class="row">
          <div class="large-6 columns">
            <!-- copyright -->
          </div>
          <div class="large-6 columns">
            <!-- footer links -->
          </div>
        </div>
      </div>
    </footer>
    

Grid Classes

There are five basic grid classes that you should commit to memory when working with Foundation 5. They are:

• row – A row is a horizontal container for vertical columns, and never the other way around. As you add content to a web page, each new row will span the width of the page. For example, the header, content, and footer of a website might each have a row class with columns nested inside.
• columns – Inside each row, you can add the class columns to any element that should occupy some of the 12-column space. For convenience, you can use either the class columns or column and they will work exactly the same. Any element marked with columns should also have classes to specify their width.
• small-# – Foundation has several classes to specify the width of columns at different responsive sizes, and each one is followed by a number that specifies how many columns it should occupy. For example, an element with the class small-4 will span across four columns. If no other responsive sizes are specified, such as medium-# or large-#, then the styling will be inherited by those larger screen sizes.
• medium-# – Medium is new in Foundation 5, and it’s meant for tablet resolutions. If an element has a small-# class and a medium-# class, then the small column size will be used for mobile phones and the medium column size will be used for tablets and anything larger. For example, you could have an element with the class small-4 and then medium-8 if you wanted it to take up four columns on mobile phones, but expand to eight columns on tablets.
• large-# – As you may have guessed, the large-# column sizes are for laptop and desktop screen sizes. However, if you only specify a large size without adding the small-# or medium-# classes, then the columns will stack. This can be very useful if you want a multicolumn desktop layout to collapse to a single column on tablets and phones. In the example template above, you’ll notice that all of the sizes are large. If you navigate to the template again and resize the browser, you’ll notice that all of the elements with a large-# class collapse to a single column at smaller sizes, because no small grid sizes are specified.

That sounds like a lot, but it’s actually pretty simple. If you want to create a two-column layout that collapses to a single column at mobile sizes, you could do something like this:

    <div class="row">
      <div class="large-8 columns">
        <!-- text content -->
      </div>
      <div class="large-4 columns">
        <!-- right image -->
      </div>
    </div>
    

Building on this example, let’s say that you wanted both columns to take up equal amounts of space at small and medium sizes, but maintain the asymmetrical balance at large sizes. You can accomplish this by adding the small-6 class to both columns.

    <div class="row">
      <div class="small-6 large-8 columns">
        <!-- text content -->
      </div>
      <div class="small-6 large-4 columns">
        <!-- right image -->
      </div>
    </div>
    

The small-6 class on both columns will make them equal in size. This size will also cascade upward to larger sizes, until the large-8 and large-4 classes override it.

Advanced Grid Features

As you might expect, there are many more advanced features of grids in the Foundation framework. This guide is only intended to cover the basics, but if you want to go further with grids, here are some topics to investigate in the Foundation documentation.

Nested Grids

It’s possible to include rows inside of columns, which are, in turn, inside of rows of their own. This is known as nested grids, and while it is technically possible, it can be a bit confusing if you’re not careful. Use responsibly.

    <div class="row">
      <div class="large-8 columns">
        <!-- nested grid -->
        <div class="row">
          <div class="small-4 columns">
            <!-- nested text content -->
          </div>
          <div class="small-8 columns">
            <!-- nested right image -->
          </div>
        </div>
      </div>
      <div class="large-4 columns">
        <!-- right image -->
      </div>
    </div>
    

Centering Columns

In some instances, you may want to create an element that does not span the full 12-column grid, but also needs to be centered. For example, perhaps you want to add a footer image that’s slightly thinner than the rest of the page. The class small-centered will center an element inside of its parent row. If you only want the element to center at large sizes, you can use the class large-centered instead.

    <div class="row">
      <div class="large-8 large-centered columns">
        <!-- centered content -->
      </div>
    </div>
    

Offsets

Analogous to centering columns, you might find yourself in a situation where you have an element that doesn’t span the full width of the grid, and the element should have some space on the left side to fill the rest of the parent row. In these cases, you can add an offset class, such as large-offset-3. This will move the column over to the right by a specified width. Similar to the column classes, these can also be used at small, medium, and large sizes.

    <div class="row">
      <div class="large-8 large-offset-3 columns">
        <!-- centered content -->
      </div>
    </div>
    

Incomplete Rows

Offsetting columns is helpful, but what if you want to leave space on the right side instead of the left side? If there’s a row that does not add up to 12 columns, Foundation will automatically float the last element to the right and fill the remaining space. This helps resolve some cross-browser rendering issues, but if you would like to override this default behavior, you can add the end class to the last element to float the element to the left.

    <div class="row">
      <div class="large-2 columns">
        <!-- left column -->
      </div>
      <div class="large-3 columns">
        <!-- middle column -->
      </div>
      <div class="large-2 end columns">
        <!-- last column -->
      </div>
    </div>
    

Source Ordering

Creating content using columns and grids can create some unique situations where you may want to visually present content in an order that’s different than how it appears in the HTML structure. For example, let’s say that your site is a two-column layout consisting of a left sidebar and a main content area. For accessibility and SEO reasons, you need to put the main content in the HTML first, but you still want the sidebar to be on the left.

The two columns can be rearranged and swap places using a feature of Foundation source ordering. Using classes like large-pull-3 and large-pull-9, it’s possible to swap elements (or a group of elements) of a corresponding size.

    <div class="row">
      <div class="large-9 large-pull-3 columns">
        <!-- main content -->
      </div>
      <div class="large-3 large-pull-9 columns">
        <!-- left sidebar -->
      </div>
    </div>
    

And more…

This has been an introduction to Foundation’s grid system, but there’s far more to explore, including form-styling, modals, and typography, to name a few. You can read more in the Foundation documentation or learn more about frameworks on Treehouse.

The post The Beginner’s Guide to Grids with Zurb Foundation 5 appeared first on Treehouse Blog.

Léonie Watson with a much-needed reference on how to do a good job with SVG accessibility. A couple of takeaways: 1) Use it, the sharp clarity of SVG is good for low vision folks. 2) Inline SVG offers better accessibility 3) Use <title> and <desc>. Plus several more you should definitely read about.

Direct Link to Article — Permalink

Tips for Creating Accessible SVG is a post from CSS-Tricks

Freelancing as a Web Designer or Developer Means Finding Your First Client. No-Duh, Right? It’s Possibly Harder than It Sounds.

If you’ve spent any amount of time online over the last couple years, you’ve probably encountered advertisements or comment spam that read something like this:

Make hundreds of dollars an hour working from home!

Get full-time pay… in your pajamas!

Never answer to an angry boss again!

You’ve probably also noticed a critical voice in your brain (otherwise known as your “scamdar”) encouraging you to stay away from the sites those ads are pushing, and rightly so.

But if you’re studying an in-demand tech skill like UX design or coding — or, for that matter, plain old writing — there’s undoubtedly a legitimate work-from-home gig perfectly suited to your experience and education out there right now. Better yet, cash is only part of what it offers: Relevant work experience and a good reference for future jobs are just two of the extra perks working from home could grant you.

Welcome to the world of freelancing.

Free trial on Treehouse: Do you want to learn more about front-end design, mobile apps, and frameworks? Click here to try a free 14-day trial on Treehouse.

To be clear, going freelance isn’t for everyone. It can be a feast-or-famine field, and you shouldn’t rely on it to pay all your bills, at least not to start. If you keep with it, however, you’ll soon see the clients rolling in — and find yourself in one of the most flexible, easiest-going positions any industry has to offer.

Here are a few tips current and former freelancers shared with Treehouse this week about getting your own freelance service off the ground.

1. Find Your First Client

Jeremy Jantz

Does the first point sound like a no-brainer? Maybe, but finding that first client will potentially be the biggest challenge of your early freelance career.

Jeremy Jantz echoes that sentiment. He spent three-plus years doing freelance web design and front-end engineering and now works for Treehouse from South Carolina.

“I think it’s always difficult when you’re just starting out because you don’t have any ‘real’ work to show to convince potential clients to hire you for their project,” Jantz, 34, says. “Assignment projects during school are great, but there’s no substitute for solving real problems for real people with real deadlines and an actual budget.”

Talking to local businesses andsearching the web for clients can result in nice freelance opportunities, but personal connections could be the most important part of scoring that elusive first gig. Doing work for family, friends, and other people you know helps put that “real” work Jantz talks about into an actual professional portfolio. That, in turn, “makes landing your next project just a little bit easier,” he says.

2. Go Local

Once you’ve completed your first successful gig as a freelancer, you may be tempted to hit the web and search for clients around the country (or even around the world). While this can be an effective strategy to landing future jobs, 26-year-old freelance web developer Gabe Garrett of Long Island, N.Y., says a focus on local clients can be every bit as lucrative — especially if you take time to get your name out in your community.

Gabe Garrett

“You never know who might need your work and where they may look for help,” says Garrett, whose freelance portfolio includes work with StablePal and Cryptedge. His solution involved a lot more than emailing resumes: He went as far as hanging flyers in high-foot-traffic areas to make sure potential local clients could find him when he first started.

Making a name for yourself on a local level, in other words, can be a big boon to your freelance service. Taking Garrett’s flyer idea a step further, you may want to search for sites belonging to local businesses and see what you can do to improve them. Once you’ve located several, send each one a personalized email or letter explaining what you offer and how you can help their visibility or overall web presence.

Make sure to check local classifieds, too, since many small-business owners may not know about online portals dedicated to finding designers, writers, or coders. That last point in particular can definitely help your cause when it comes to finding local work: Typical clients would rather work with a person they’ve met face to face than someone they can only talk to via email or phone.

3. Stay Professional — and Develop Lasting Relationships

One-off gigs are great. Recurring work is even better — and getting it means keeping your existing client base happy. Ozark Christian College grad Matt Spiel, who worked on several large-scale freelance design projects as a student and now also works for Treehouse from Joplin, Mo., said that “the relationships [he] had were what yielded the most work” in his time as a freelancer. That means friends, family, and coworkers, of course. But more than that, every client you serve will likely either need more work done or know someone who does.

Establishing those relationships, then, is one of the smartest things you can do for your freelance service. That means more than doing good work at a fair rate: Timely responses to emails and missed calls are key, as is a pleasant and professional demeanor, even when you’re dealing with demanding or otherwise less-than-pleasant clients.

“You’ll be surprised how often you’ll get an email or call with someone on the other end wanting to hire you for their next project,” Jantz says. “It’ll seem random at first until you find out they heard about you through […] that client you worked for over a year ago.”

Doing good work and keeping a professional demeanor helps ensure your name is the one they mention.

4. Be Your Own Brand

Now more than ever, anyone applying for any position has a so-called “personal brand” to maintain — a voice, visual or written style, and overall body of work that reflects who they are and the kind of projects they’re best suited to complete. Though it might not seem too important in the early going, establishing that brand as quickly as possible can give you an edge when competing with others for jobs.

“Read about what others are doing, share your work, and put yourself out there,” Jantz says. “Attend conferences and meetups to network with others in your same position.”

In many cases, “getting yourself out there” involves keeping a consistent visual identity on the web, even if you don’t work in a visual field: Use the same profile picture everywhere you post online and make sure your service’s website accurately represents your experience and skill level. (Even picking a personal color scheme can also help; this guide at dustin.tv is a great starting point if you’d like to learn about the intricacies of choosing the right tones.)

Much of your personal brand will fall into place as your body of work grows. That said, it’s never too early to keep your overall identity as a freelancer in mind.

Focus on “doing good work and making happy clients,” as Jantz says, but don’t be afraid to market yourself beyond the standard resume-and-cover-letter approach. Potential employers can recognize passion. When you care about what you do, it should show in everything you do, including how you project yourself online.

5. Don’t Be Afraid to Go Over Your Head

Matt Spiel

Shortly after Spiel graduated,a childhood friend reached out to offer him a freelance position with a large company — one big enough to have its name behind a major college football bowl game.

“It was massive, daunting, way over my head,” Spiel, 29, says, “and the smartest, most fruitful project I could have ever taken on. It single-handedly transformed the trajectory of my career.”

The point?

Challenging yourself as a freelancer is one of the smartest moves you can make, within reason. Problem-solving skills are key to going freelance in any industry. If you’re offered big work, chances are you have the skillset needed to accept a job a little larger than you think you’re capable of doing. Besides the cash and resume fodder — two big perks by their own merit — succeeding at large-scale jobs gives you the confidence needed to take on even bigger gigs in the future.

When Garrett tackled the daunting task of setting up a custom login system for a site he was working on, he dove in and found himself surprised at the result: “In under four hours, the system was successfully set up,” he says, “[when] before I hadn’t had the slightest clue of how to do it.”

There’s a balance to be struck here, of course — if you feel you’re far under-qualified for a position, it’s probably best not to apply to it — but you’ll soon get a feel for when the naysaying voice in your head is correct and when it’s being too critical.

As a freelancer, you’re solely responsible for your own progression, and you never know how good you can truly be until you challenge yourself.

The post Beginner’s Guide to a Freelance Web Career appeared first on Treehouse Blog.

by Clare McCauley

Not since the early days of web standards have I seen our community rally around a seemingly small issue: responsive images.

Over the last four years (yeah, it’s been about four years), we’ve seen many permutations of images in responsive design. From the lazier days of setting max-width: 100% (the absolute minimum you should be doing) to more full-featured JavaScript implementations, such as Picturefill and Zurb’s data-interchange method, we’ve spent a lot of time spinning our wheels, banging our heads and screaming at the wall. I’m happy to say that our tireless journey is coming to a close. The W3C and browser makers got the hint.

The State Of Responsive Images

In our search for the holy grail of serving the right image to the user, our attitude towards browser makers until now has largely been, “Forget you — we’ll do it ourselves.” I’m certainly no exception. We were so attentive to responsive images and were exposed to all of the guesswork and trials that are not typically released to the public that we got impatient (rightfully so) and did it with JavaScript.

The difference between a CSS transition and a responsive image is, of course, how they degrade. If a CSS transition doesn’t work, who really cares? Your interface might be a little jumpy, but the experience as a whole won’t really suffer because your users will still be able to accomplish their goal and consume the content they need.

That really isn’t the case with images. How does a new image tag degrade? The img tag is so widely accepted that I couldn’t even find when the W3C recommended it as a standard, other than a small reference in the HTML 4.01 specification. Replacing or even expanding on the img tag would be like telling Frank Sinatra to wear a baseball cap instead of a fedora — you’ll get some pushback.

Resource Problems

As responsive design grew in popularity and as the media through which users consume information became uncontrollable, we slowly realized that img by itself wasn’t going to cut the mustard. We started asking questions like, “What screen size is the user on?” and “What’s the pixel density of the screen?” These questions fuelled our image techniques until we realized that screen size and pixel density have absolutely no relationship to the amount of bandwidth available to serve up a huge high-definition image.

The RICG began working on the picture element, sharing its work with the W3C along the way.

The solutions got pretty complex. Talk of the picture element started, and a group called the Responsive Images Community Group (RICG) appeared. The RICG began working on the picture element, sharing its work with the W3C along the way. The result has led us to today and this discussion about all of the progress that’s been made.

The Introduction of srcset

Because most of the responsive-image community was on board with the picture element and looking forward to it because of the great polyfills, such as Picturefill, it went ahead and released a well thought-out and fleshed-out document outlining something called srcset, which is an extension of the standard img tag. Yeah, I know — it feels like it came out of nowhere. It was also super-complicated and overly limiting by restricting you to (implied) pixel values and using a microsyntax that didn’t allow for scalability with media queries in the future. Luckily, the syntax has matured into what we have today, which is a fairly robust recommendation.

Most recently, Andrew Clark said it best when he tweeted, “Looked at the responsive images srcset & sizes attributes for the first time. Blimey it’s complicated.”

I couldn’t have said it better myself. Let’s look at what we’re dealing with:

<img alt="dog" src="dog.jpg" srcset="dog-HD.jpg 2x, dog-narrow.jpg 300w, dog-narrow-HD.jpg 600w 2x">  
    

Three major attributes are in the snippet above: alt, src and srcset. The alt attribute is the same as it’s always been; src is the fallback if srcset isn’t supported; and srcset is obviously the meat and potatoes here.

We can see three arguments in srcset. The first is the image path. The second gives the browser information about the natural widths of the sources, so that it knows which resource to serve to the user (based on the user’s preferences and cross-referencing with the sizes attribute – I told you it was complicated). The last piece sets the optional pixel ratio (2x in this example specifies the high-definition image).

One thing I really love about srcset is that the specification states that the browser should contain image-allocation preferences for certain bandwidth situations. This means you don’t have to worry about serving a 2x image to a high-definition screen if that device is on a cruddy 3G connection. The user’s preferences should take over, and the browser would choose the appropriate image to serve.

Preparing for the picture Element

After much complaining about our new weird friend, srcset, the RICG continued working on the picture element, which is finally getting some serious traction with browser makers… well, that is, with Chrome. The proposed syntax for the picture element might look familiar because we saw it largely in the first version of Picturefill, and it’s not unlike how <audio> and <video> are marked up.

<picture>
      <source media="(min-width: 600px)" srcset="large-1.jpg, large-2.jpg 2x">
      <img alt="A fat dog" src="small-1.jpg">
    </picture>  
    

As you can see, a source tag is in the picture element, along with a normal img tag. Just as we saw with src in srcset, the img is a fallback. In the source tag, we have what looks like a media query, alongside a srcset attribute that contains the same image-source and pixel-density arguments as before. This seems like a nice clean way to popularize responsive images; we’re generally familiar with the syntax, so it should be easily adopted.

Browser Support

The srcset attribute has been supported in Chrome since version 34. At the time of writing, it is not supported anywhere else. Mozilla appears to be working on an implementation (fingers crossed). Internet Explorer is nowhere in sight.

The picture element has even worse support; it isn’t even in Chrome yet. But like Mozilla with srcset, Google is currently working on implementing it. If you can stomach reading through a specification, I highly recommend it. Even though there isn’t much of a plot and the character development is pretty weak, it’s still a pretty good read.

Picturefill 2.0 was created because native support is reasonably close. You know we’ll need a rock-solid polyfill to use when the time officially comes, so let’s take a look at it!

Introducing Picturefill 2.0

Picturefill 2.0 was recently released as beta, and it’s quite a large jump from version 1. The RICG really aimed to create a one-stop solution for responsive images. The challenge was to create a script that allows you, the developer, to use any combination of the solutions currently being standardized, without bloating it to the point that not using it at all would be more lightweight.

Imagine polyfilling an image that would normally take 2 seconds to load using a JavaScript file that takes 10 seconds to load — it wouldn’t make much sense. Picturefill 2.0 avoids this by following the specification very closely (with some intentional omissions, which we’ll go over in a bit) and letting you use either srcset or picture or a combination of the two.

Picturefill is an responsive image approach that mimics the proposed picture element using divs. (Larger version)

While we can’t reliably achieve everything in the specification using JavaScript (such as reasonably detecting bandwidth, which would be a user setting anyway), we can certainly take care of all of the pieces that are meant to be in HTML (i.e. elements and attributes). This version of Picturefill gets us one step closer to not needing Picturefill, which is the ultimate goal of anyone who has ever written a polyfill.

If you’re currently using version 1.0, I highly recommend upgrading to 2.0. It’s a big step towards a better solution to serving the correct image to the user. Some big changes have been made to the syntax and functionality. Let’s look at what’s new.

What’s New in 2.0

One thing that makes this polyfill different from others that I’ve seen is that it polyfills a concept, not just an unsupported block of HTML. Picturefill 1.0 used spans and custom attributes to mimic how we thought responsive images should work. For the record, it is a great solution, and I currently use it for many of my projects that haven’t been converted to 2.0.

In the last year or so, the specification for srcset and picture have matured so much, so we can now actually get to use something close to the real syntax. Picturefill is starting to look like a true polyfill, one we can strip away when real support shows up.

Installing and Using the Polyfill

If you’ve read this far, then you’ve probably dealt with some form of polyfill in the past. This one isn’t much different. Polyfills are supposed to be set-it-and-forget-it (to steal a line from Ronco), but because this is an HTML polyfill, you’ll need either to create the picture element manually or use some form of HTML shiv to do it for you. Luckily, HTML shivs are pretty common and ship with toolkits such as Modernizr; just verify that picture is supported in whatever shiv you choose.

<!-- Create the actual picture element if you haven’t already. -->
    <script>
      document.createElement( "picture" );
    </script>
    
    <!-- Asynchronously load the polyfill. -->
    <script src="picturefill.js" async></script>  
    

Other than creating the picture element, you simply have to link to the script. Using the async attribute is also recommended, so that Picturefill doesn’t block your page from loading.

Using Picturefill 2.0 With srcset

Let’s look at the syntax that provides the best support and that uses srcset. It should look familiar because it has the same attributes that we saw when discussing the specification.

<img sizes="100vw, (min-width: 40em) 80vw"
    srcset="pic-small.png 400w, pic-medium.png 800w, pic-large.png 1200w" alt="Obama">  
    

The most glaring difference between this snippet and the specification is the absence of a fallback src attribute, which was intentionally removed to prevent images from being downloaded twice in unsupported browsers. And, really, what would be the point of this if images were downloaded twice? Other than that, it’s pretty faithful to the specification, but it will probably evolve over time as the specification fleshes out and the polyfill matures.

The sizes attribute tells the browser of the image’s size relative to the viewport. This often gets overlooked because srcset is the buzzword now, but this attribute is equally important. If you’d like to learn more, Eric Portis makes a lot of sense of this “blimey complicated mess.”

Using Picturefill 2.0 With the picture Element

The RICG did such a good job with this second version of Picturefill that the syntax of the picture element should come as no surprise. It matches the specification very closely:

<picture>
      <source srcset="extralarge.jpg, extralarge.jpg 2x" media="(min-width: 1000px)">
      <source srcset="large.jpg, large.jpg 2x" media="(min-width: 800px)">
      <source srcset="medium.jpg">
      <img srcset="medium.jpg" alt="Cambodia Map">
    </picture>  
    

The biggest change between versions 1.0 and 2.0 is the removal of some traditional HTML (divs and spans) and the addition of newer elements (picture and source). Also, srcset support is built in (heck, why not, right? It’s in the spec!). This is great step forward for this polyfill.

Use as many or as few of these options as you’d like. In line with the specification, if you don’t want to use the 2x option, you don’t have to (and so on). The difference between this and the official picture element is the img fallback. You’ll notice here that the img fallback also has a srcset attribute, instead of a normal src (which is widely supported). Again, this is to prevent double-downloading (it’s a real problem). The srcset in the img tag would also cause double-downloading if the browser supports srcset but not picture. This bug should get worked out in the beta version.

Like many good polyfills, Picturefill 2.0 can be executed programmatically by exposing a global function, picturefill(). This allows you to use it in any ultra-hip JavaScript framework that you’d like. You can read about a few options for targeting specific images in the API documentation.

Degrading Gracefully

Earlier in the article, I alluded to the challenge of degrading the img tag gracefully in unsupported browsers. This was another problem in creating Picturefill 2.0. Because it is a polyfill, the concept of unsupported browsers doesn’t really exist (kind of) — we’re using JavaScript to force it to work.

The edge case is this: If a browser doesn’t natively support picture or srcset and has JavaScript turned off, then you’ll get a frowny face. I can already feel your eyes rolling, but knowing the limitations of a system is important before you rely on it on a large scale. If a user were to come across a Picturefill’ed image in an unsupported browser with JavaScript turned off, they would see the image’s alt text — a nice little way to reinforce the importance of descriptive and meaningful alt text, isn’t it?

Alternative text is the fallback because the previous <noscript> solution caused problems with browsers that support picture or srcset but have JavaScript disabled (two images would render). The group also explored adding a src attribute to img (as in the specification), but that results in double-downloading, which defeats the purpose of allocating the appropriate image assets to the user.

We’ve come a long way with responsive images. We can see the light at the end of the tunnel, but a lot of work still has to be done. And we’d love your help!

How To Get Involved

If you’d like to get involved and help out with the responsive-images movement, join the RICG via the W3C. If that’s too much, we’re always looking for people to try out Picturefill’s beta version and submit bugs through the issue tracker on GitHub.

You can also spread the word about great tools like Sizer Soze, which calculates the performance cost of not using responsive images.

Resources and Further Reading

• Responsive Images Community Group
• “The picture Element” (specification), RICG
• “The srcset Attribute” (specification), W3C
• @respimg, RICG on Twitter

(al, ml)

The post Picturefill 2.0: Responsive Images And The Perfect Polyfill appeared first on Smashing Magazine.

If you’ve seen a lot of web design agency sites lately, you might have noticed that they all share a few common traits:

• Needlessly vague wording (if I have to hear "integrated solutions" or "innovative solutions" one more time, I may break).
• Clean design.
• Absolutely no pricing details whatsoever. Prospective clients are forced to fill out a quote request form to get even a general price range.

The last point is what I’ll be talking about.

Example of a quote request form found on the Foundation Six contact page.

Somewhere along the line, someone must’ve told all the web designers in the world that publicly disclosing our prices is a terrible thing to do.

The thinking goes a little like this. If you market yourself on price, you’ll get clients who only care about price. If you advertise yourself as a service or as in investment then you’ll get clients who will pay whatever it takes to achieve their design goals.

Makes sense, right? When I founded my web design business, Plato Web Design, I certainly thought so. And, for years, we kept our pricing details under wraps.

Then, last year, we decided to make a simple change: We started openly showing our prices on our site.

And not in some tucked away pricing page either. We placed our prices right on our site’s home page.

Transparent pricing displayed on the home page of Plato Web Design.

Our reasoning behind this is pretty simple: Eventually you’re going to have to talk about costs. Why not get it out of the way early?

Results

Being completely open with our web design prices has led to:

• 15% increase in revenue
• 20% more returning clients
• An incredibly simplified sales process

Let me talk about some of the biggest benefits we’ve gotten from transparent pricing.

We Save Loads of Time

In the past, we spent the majority of our days having fuzzy discussions with prospective clients that, as we’d later find out, didn’t have the budget required for our services.

With our pricing now openly listed on our website, we entertain far fewer clients outside of our target market, and we know that the leads we do receive have seen our prices, and are comfortable with them.

In other words, we’re able to prequalify our leads, saving us a lot of time as well as allowing us to focus on clients that are more likely to work with us.

We Make More Money

We improved our average revenue per client by about 25% and total revenue by 15%.

When you’re pitching to a client that has a vague budget range, you’re forced to play a guessing game: You can either go for the big sale (with lots of services included) and risk scaring them off due to sticker shock, or you can go for the lower-priced, but more guaranteed, sale.

But there’s no need to play this guessing game, because most clients are willing to tell you how much they’re willing to spend.

Once we’ve gotten a cursory understanding of what a client wants, we come up with a fast ballpark figure and run it by them. Something like: "That’s probably going to run you $4,000-$6,000. Is that comfortable for you?"

If they say "no", we come up with a pared-down solution. If they say "yes", we know we have some leeway to work with.

When we’re more aware of what clients intend to spend on their site, we’re able to fit our offerings to their budget.

We Stopped Scaring Potential Clients Away

Good design firms have sites that look amazing. And when you put in that much time and effort to make your site look awesome without disclosing your prices, you can give potential customers the wrong idea that you’re way out of their price range, even if you aren’t.

We Build Trust Early

When you’re upfront and transparent about the costs of your services, something strange happens: Your clients start to thank you for it. Being open with our prices helps earn the trust of our clients.

The art of on-boarding new clients is about building trust and finding a way to make their life easier. Transparent pricing helps do both.

When we openly disclose our prices, it gives clients the idea that we’ll also be transparent and straightforward with everything else we do.

The Bottom Line

Being transparent with our prices gives us more qualified leads, generates more revenue, and helps us develop trustworthiness very early in the project cycle.

It may not be right for every business, but if you’re in web design, I really believe it’s a no-brainer.

Related Content

• 7 Pricing Strategies Based on Research Studies
• Designing Pricing Plans for Subscription-Based Web Apps
• 5 Pricing Tips to Earn More on Client Projects
• Related categories: Business and Web Design

About the Author

Casey Ark is the founder of Plato Web Design, a custom web design agency located in Harrisburg, PA. He’s also a newspaper columnist. Casey has over 9 years of experience in web design, development and print design.

The post An Argument for Transparent Pricing in Web Design appeared first on Six Revisions.