ich to place a fallback <img> in the case of no JavaScript being available. I'll let you decide if that's semantic or not.

//AN_Xml:

Do I care about validity?

//AN_Xml:

Validity as in "Does it validate?" according to the W3C Markup Validation Service. Validation is a tool to help you find problems and write better markup. But just because something doesn't validate doesn't make it bad or wrong. If invalid code works wonderfully in all browsers, you nor anyone else should care.

//AN_Xml:

If you do care about validity (perhaps a client irrationally requires it from you and is holding your paycheck randsom) then there are a few techniques that you can't use. The picturefill technique, for instance, uses the <picture> element to work its magic. This may ultimately be standarized, but it isn't yet, so it's technically invalid syntax. It's also required that <img> elements have a src attribute, so techniques that remove that to get around the double-image-request problem are invalid.

//AN_Xml:

I'd recommend these techniques if validity is a requirement for you: Adaptive Images, HiSRC, or Responsive Enhance. All of which use simple, valid <img> syntax that include a src.

//AN_Xml:

Do I care about art direction?

//AN_Xml:

Some responsive images techniques serve different resolution versions of the exact same image. While that makes things easier (i.e. less work) it may not acceptable. Here's a visual example:

//AN_Xml:

//AN_Xml:
On the left, the "mobile" and default src. In the middle, a slightly larger image that could be used on (ahem) "tablets". On the right, the largest of the images.(credit)
//AN_Xml:
//AN_Xml:

These images are hand-crafted by a designer, cropped to retain meaning and impact. If you took the image on the right and just scaled it down, the people in the image would be very small and the feel of the image my be lost.

//AN_Xml:

If this idea of art direction is important to your project, you'll need a technique that will allow you to specify exactly which src to serve under which circumstances. This is picture perfect (GET IT?) for picturefill which allows you to be very specific about sources and what circumstances get what.

//AN_Xml:
<picture alt="description">
//AN_Xml:  <source src="small.jpg">
//AN_Xml:  <source src="medium.jpg" media="(min-width: 400px)">
//AN_Xml:  <source src="large.jpg" media="(min-width: 800px)">
//AN_Xml:</picture>
//AN_Xml:

JavaScript takes it from there.

//AN_Xml:

Do I care about JavaScript?

//AN_Xml:

Most of these responsive image techniques utilize JavaScript to work their magic. Some only a tiny bit to set a cookie, but JavaScript none the less. Some of them have you put an <img> in a <noscript> tag so that there is a fallback image in the case that the user has JavaScript turned off. If you don't like that, and you need to make absolutely sure that your images work without JavaScript, Sencha.IO is your best bet. This service works by identifying your device through it's User Agent string and serving an appropriately sized image. So you link to the largest (reasonable) version you have of it and Sencha will squeeze it down and server smaller versions if need be (it doesn't scale up, for obvious reasons).

//AN_Xml:

What about JavaScript *library* dependency?

//AN_Xml:

HiSRC and rwdImages are both jQuery dependent. If your project is using a different library, these probably aren't for you. But hey, you could port it and open source that! If you aren't using a library, well, you probably should be but let's not get into that.

//AN_Xml:

Do I care about Server Side Components?

//AN_Xml:

Some of these techniques aren't solely JavaScript dependent. Adaptive Images works it's magic primarily through .htaccess and PHP. Well, .htaccess presupposes an Apache server. And, while of course we all know and love PHP (ahem), many websites run on technologies like Ruby or Python.

//AN_Xml:

Responsive Images (the original Filament Group technique) also uses .htaccess. So if you're using something like Nginx as web server, this is either out or you'll have to port over the .htaccess component to Nginx's similar-but-different syntax.

//AN_Xml:

Do I care about bandwidth testing?

//AN_Xml:

Testing the browser window width and making decisions on what image to serve based on that is pretty cool and fundamental to the concept of responsive images. But it's really only half of what the decision of what image should be served should be based on. The other half is available bandwidth. If the user has a very fast internet connection speed, serving large images is OK. If the user has a very slow internet connection speed, they should get smaller images (regardless of screens size). Unfortunately native bandwidth media queries don't exist.

//AN_Xml:

Two of the current techniques do bandwidth testing as part of their decision making: Foresight.js and HiSRC (both are based on the technique in Foresight.js). It works by downloading a test file and measuring how long it took (configurable). The test itself is a slight performance hit, but theoretically the savings gained by serving images based on knowing the current bandwidth is a net (GET IT?) gain.

//AN_Xml:

Do I care about relying on third parties?

//AN_Xml:

Sencha.IO is a completely third-party way of handling responsive images. As far as I know, it works great and hasn't been inflicted with any major downtime, but of course you always run that risk.

//AN_Xml:

You might be thinking: Wow, the Sencha.IO technique is really cool but I worry about the third-party dependency. I wish I could run that on my own server. If you want to go down that road, there is the public WURFL database and this Server Side Responsive Images technique which puts that to work locally.

//AN_Xml:

There are also third-party services like Device Atlas Cloud which does device detection for you. It's also a third-party dependency for your app. No doubt their goal and focus is staying up and fast at all times, but you have to be very careful about who and what you rely on for your business.

//AN_Xml:

Is there a specific CMS with specific CMS powers involved?

//AN_Xml:

Say your project is in WordPress. WordPress has a media uploader built in. When you upload an image with it, it can create multiple versions (scaling down) of that image for you. That's pretty cool and powerful and you could/should take advantage of that. Keir Whitaker talks about using that ability in his article Automatic Responsive Images in WordPress.

//AN_Xml:

This isn't just a WordPress thing though. I'm sure the concepts at work here could be done (or made to be done) in any Content Management System.

//AN_Xml:

Can I wait for the future?

//AN_Xml:

The release of the "new iPad" (the third one, for longevity) is what sparked a lot of these techniques and conversations. Its high pixel density is great for vectors and big photos, but actually not great for things like small icons that need to be scaled up to be the correct size and can be blurry. But serving higher resolution icons means larger file sizes and slower websites. Hence, the need to only serve them in situations/environments that need them.

//AN_Xml:

The world of web standards is aware of this problem. There is a whole group dedicated to talking about it. In time, they may solve it and then we can start using whatever way they come up with (assuming its awesome and better than what we have now).

//AN_Xml:

It may be flipping out the src of images through CSS content like Nicolas Gallagher suggested. It might be the <picture> element. It might be a srclist attribute in HTML or src property in CSS. It might be a prefix.

//AN_Xml:

 

//AN_Xml:

More resources

//AN_Xml: //AN_Xml:

Which responsive images solution should you use? is a post from CSS-Tricks

]]> //AN_Xml: http://css-tricks.com/which-responsive-images-solution-should-you-use/feed/ //AN_Xml: 37 //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: l: Do Something //AN_Xml:</button> //AN_Xml:

What's the most common result of clicking something on a website? Moving to a new URL, like you would clicking a link (an <a href="/example/"></a>) element).

//AN_Xml:

The <button> element, by itself, can't do that. There have …

//AN_Xml: //AN_Xml:

When To Use The Button Element is a post from CSS-Tricks

]]> //AN_Xml: You use it when, uhm, you want a button on your page that users can click, right? Well, unfortunately it's a bit more complicated than that. It's not too bad though, let's figure it out.

//AN_Xml:

//AN_Xml:

It looks like this:

//AN_Xml:
<button>
//AN_Xml:  Do Something
//AN_Xml:</button>
//AN_Xml:

What's the most common result of clicking something on a website? Moving to a new URL, like you would clicking a link (an <a href="/example/"></a>) element).

//AN_Xml:

The <button> element, by itself, can't do that. There have been various conversations about allowing "href anywhere" over the years, but nothing has came of it.

//AN_Xml:

Clicking on a button does do something though, when used in its natural environment...

//AN_Xml:

Button is a Form Element

//AN_Xml:

Web forms have submit buttons. You might think of that like this:

//AN_Xml:
<form action="/" method="post">
//AN_Xml:  <input type="submit" value="Submit">
//AN_Xml:</form>
//AN_Xml:

A <button> element in a <form>, by default, behaves identically to that submit input above.

//AN_Xml:
<form action="/" method="post">
//AN_Xml:  <button>Submit</button>
//AN_Xml:</form>
//AN_Xml:

However gross the UX, forms can have reset buttons as well. You can duplicate that behavior by changing the default submit type to reset.

//AN_Xml:
<form action="/" method="post">
//AN_Xml:  <button type="reset">Reset</button>
//AN_Xml:</form>
//AN_Xml:

Clicking that button will clear all the other inputs (and textareas) with the parent <form>.

//AN_Xml:

Buttons can have content

//AN_Xml:

The primary reason for using a <button> is that it has both and opening and closing (</button>) tag. Which means there can be stuff inside. A common use case would be something like:

//AN_Xml:
<button>
//AN_Xml:  <img src="tiny_birthday_cake.png" alt="">
//AN_Xml:  Submit
//AN_Xml:</button>
//AN_Xml:

While an input can be <input type="image">, this mixed content would be hard to pull off.

//AN_Xml:

As far as I can tell, there is no limit to what kind of content you can put in a button, so feel free to get real weird with it. Pseudo elements can be used too.

//AN_Xml:

Let's leave styling <button>s for another day, but different browsers generally have a special style they apply to buttons. You'll want to either leave that alone so the default comes through, or remove it thoroughly so your new styling can be consistent across browsers.

//AN_Xml:

Let's consider: "if a button doesn’t have a meaningful href, it’s a <button>"

//AN_Xml:

I said recently that I enjoyed that sentiment. That's what kicked off this article for me. At the time, I was thinking of how I enjoyed the semantics of it. As in:

//AN_Xml:
<a href="#0">
//AN_Xml:  I'm kinda sick of doing this for buttons.
//AN_Xml:</a>
//AN_Xml:

There is no meaningful href there. The 0 is just there so it doesn't jump the page, because ID's can't start with a number.

//AN_Xml:

Chances are, HTML like the above means: I'm going to make clicking that do something with JavaScript. Somehow that feels better than a <div> whatever, because you get the cursor change and whatever else default styles.

//AN_Xml:

If you don't like those meaningless href's, a <button> can seem like a nice alternative. But unfortunately outside of the context of a <form>, a <button> is equally meaningless.

//AN_Xml:
<button>
//AN_Xml:  Outside of a <form>, I'm just as useless.
//AN_Xml:</button>
//AN_Xml:

But <button> feels better anyway

//AN_Xml:

Even if a <button> doesn't do anything outside of a form without the help of JavaScript, it still feels better for things you can click that do stuff other than change pages. A bogus href link definitely doesn't feel right.

//AN_Xml:

Alright. Let's insert it with JavaScript then.

//AN_Xml:

That's probably the best solution. If JavaScript is required for the clickable-thing to do anything at all, it might as well not even be there at all unless JavaScript runs. We can do:

//AN_Xml:
// 1. Create the button
//AN_Xml:var button = document.createElement("button");
//AN_Xml:button.innerHTML = "Do Something";
//AN_Xml:
//AN_Xml:// 2. Append somewhere
//AN_Xml:var body = document.getElementsByTagName("body")[0];
//AN_Xml:body.appendChild(button);
//AN_Xml:
//AN_Xml:// 3. Add event handler
//AN_Xml:button.addEventListener ("click", function() {
//AN_Xml:  alert("did something");
//AN_Xml:});
//AN_Xml:

You could easily have "button adding" be a part of your JavaScript workflow.

//AN_Xml:

When links make more sense

//AN_Xml:

If there is any kind of href you could put on that link that makes sense, by all means, use an anchor. Even if you override that behavior with JavaScript. That's progressive enhancement at it's finest. For instance:

//AN_Xml: //AN_Xml:

If nothing makes sense, insert the button with JavaScript.

//AN_Xml:

Accessibility concerns

//AN_Xml:

Let's say using an anchor link does make sense. After you give yourself a nice little back-pat for being good at progressive enhancement, there is accessibility to consider as well.

//AN_Xml:

You might be like, I got this!

//AN_Xml:
<a href="#meaningful" class="button" role="button">
//AN_Xml:  I'm good
//AN_Xml:</a>
//AN_Xml:

But you aren't out of the woods yet. MDN covers it well:

//AN_Xml:

Warning: Be careful when marking up links with the button role. Buttons are expected to be triggered using the Space key, while links are expected to be triggered through the Enter key. In other words, when links are used to behave like buttons, adding role="button" alone is not sufficient. It will also be necessary to add a key event handler that listens for the Space key in order to be consistent with native buttons.

//AN_Xml:

Get that? You activate links and buttons with different keys, so consider that.

//AN_Xml:

Go forth and uhm, make clickable things correctly.

//AN_Xml:

//AN_Xml: //AN_Xml:

When To Use The Button Element is a post from CSS-Tricks

]]> //AN_Xml: http://css-tricks.com/use-button-element/feed/ //AN_Xml: 94 //AN_Xml: //AN_Xml: //AN_Xml: //AN_Xml: