Happy Thanksgiving to everyone in the U.S. and a belated Happy Thanksgiving to our Canadian neighbors to the north.
For the last few years I’ve shared pictures of my annual New York trek for the holiday. I was hoping to get some new images of the floats being blown up for the Macy’s parade this year, but the weather didn’t cooperate.
Unfortunately I don’t have any pictures to share, but I realize I’ve never shared why I choose Thanksgiving for my annual visit and how the visit included a walking trip through Manhattan. If you were looking forward to see some images here are some from Thanksgiving past.
Hopefully the weather is better next year and I can offer some new images. I’ll try to do better and take more pictures of the entire week next year, just in case.
Moving to Colorado
For those of you who don’t know, I grew up in New York and moved to Colorado a little over 17 years ago. Thanksgiving became a good time to fly back and visit family. The holiday meant I’d have Thursday and Friday off. By taking three days of vacation from work and including the weekend before and after I could extend the trip to nine days.
I don’t remember exactly when it started, but one of the first years I was back visiting my mom and I decided to take the train into Manhattan to see some exhibits at one or two museums.
My brother joined us and we turned our day trip into an all day affair. Every year we now take the train into Penn Station and then walk through the city until we reach the museums uptown.
It’s about a three mile walk and along the way we stop at various places one or all of us want to see. I stop often as we walk to take a few pictures of whatever catches my eye.
We usually take in a couple of museums and then walk across Central Park to get to the west side. We exit the park a couple of blocks from where the floats are being blown up for the parade and watch for a bit.
After a bite to eat we start to walk back down the west side. Most years we’re exhausted and so we hop on the subway back to Penn Station before taking the train back to Long Island. Some years we’ve managed the entire walk back.
September 11, 2001
Not long after I moved the events of September 11, 2001 occurred. I think I felt like a lot New Yorkers who weren’t living in New York at the time. First was the worry for my family.
My brother worked across the street from the twin towers. He had been on vacation the week before and that day decided to run a couple of errands before taking the train into work. He arrived just after the second plane struck the south tower. He never made it to work. His building was one of those that served as a temporary morgue.
Once I knew he was safe, there was a feeling of guilt for my being safe a couple of thousand miles away. Why wasn’t I there kept running through my mind.
It’s easy to take the things around you for granted, but once something is gone you realize how many other things you also take from granted. Thanksgiving of 2001 we walked downtown instead of uptown to get as close to ground zero as we could. It was a sad and reflective day.
It hit home in many ways and in the years after we added new stops to our day trip such as the top of the Empire State Building and Rockefeller Center. I don’t think I was ever inside either of the Twin Towers and I didn’t want to say the same about some of the other well known buildings in Manhattan.
We’ve seen a lot of the city these last 17 years. The museums have been a mainstay, but we’ve taken in many of the sights New York has to offer. There’s a lot to see in Manhattan and even with a trip every year, I’ll never get to see everything I’d like. Still I’ve gotten to see much of what I’d taken for granted before moving away.
Over the years friends have joined us at times and my mom’s sister has become a permanent member of our traveling crew.
It’s strange how I know Manhattan better now that I live in Colorado.
The Holidays in New York
Aside from not wanting to miss the sights tourists take in and many New Yorkers take for granted, I just like the holidays in New York.
Maybe it’s the Christmas movies set in the city or the decorations on the buildings, or the displays in department store windows. I don’t know the exact reason, but I do know that for me no other city feels as right as New York this time of year.
It could simply be this is the time of year I get to come home and visit family and friends I don’t see as often as I’d like. On this day of thanks, that’s what I’m most thankful for. My family, my friends, and the city I’ve always called home even if I now live a couple thousands miles away.
No matter where you live or where you are take a look around at the people and things around you. Don’t take either for granted. Happy Thanksgiving to everyone celebrating today. Happy Thursday to the rest of the world.
What makes for a high resolution image? Is it the pixels per inch (ppi)? Is it the dots per inch (dpi)? What distinguishes an image as @1x, @2x, or @3x? If we’re going to create pixel dense images for high resolution devices, it probably makes sense to understand a little about what is a high resolution image.
For the last couple of weeks I’ve been talking about responsive images, specifically how the spec is stabilizing around the srcset attribute and the picture element.
As part of the series, I’m building a simple demo and as I set out to create the high resolution images, I realized I didn’t have as good a handle on what exactly makes for a high resolution image as I thought. I figured if I didn’t have a great handle, there are probably others feeling the same.
It seemed like a good opportunity for more research to answer my questions and then present what I found here. I want to share what I learned about what makes for a high resolution image along with a CSS4 property that can be used to change background images based on their resolution. I’ll close with some general thoughts about responsive images.
What is a High Resolution Image?
My instinct is to think high resolution means more pixels per inch (ppi). In a sense it does, but it has nothing to do with the settings you might choose in Photoshop or your image editor of choice.
You want to display a single px of the image in a single px on the screen
For years I’d heard that 72ppi was the limit on the web, because that was the resolution of computer screens. 96ppi gets thrown out as a limit too, depending on whether you’re viewing something on a Mac or a Windows based PC.
It’s all myth. The numbers (72 and 96) are from ancient days (the early 80s). Today’s screens have higher resolution obviously. If they didn’t this whole conversation about serving high resolution images would be meaningless. When you’re setting resolution in Photoshop it’s really for print and not for screens.
The important factors are the pixel dimensions of the image and the container it displays in and, of course, the resolution of the screen. Say you have an image that’s 800px by 600px and you want to display that image at the same size on the screen. If the screen is @1x resolution then every pixel in the image will fit exactly into one pixel on the screen.
If, however, the screen is @2x then each pixel in the image will need to represent four pixels on the screen. Twice the width and twice the height means you’ve gone from 1px × 1px to 2px × 2px or 4 pixels total.
To get back to a 1:1 ratio of pixels between image and screen, the image needs four times as many pixels. The original image would need to be 1600px by 1200px, which when displayed as 800px by 600px on the screen will be matching the @2x resolution of the screen.
In the end, the goal is to display a single pixel of the image in a single pixel of the screen. If you want an image to fit inside an 800px by 600px area on a screen with @2x resolution. you need to create an image twice the width and height or four times the area and then display it in that same 800px by 600px space.
Now that @3x screens are coming, we’ll need to create images with 9 times the total pixels (3px × 3px) as well. You want to start with the most pixels you can get and create images with smaller dimensions from the original image.
One additional consideration is image compression. Daan Jobsis discovered that compressing an image with 0 quality results in a smaller file size than it’s half sized version saved at 90 quality. All without any significant loss in quality.
Awhile back I ran some testsk with mixed results, though I suspect the fault was more to do with me than the idea behind compressive images.
How to Work with Background images
One of the things you may have noticed in the previous posts in the series is that the images were all included in the HTML. What about background images?
Switching background images is nothing new. You set a background-image with a url() and you change the url for various conditions. For example
1 2 3 4 5
.background { background-image: url("path-to-image-one"); } @media only screen and (min-width: 30em) { .background { background-image: url("path-to-image-two"); } }
Most of the time your media queries, probably do little more than test for a min or max width. I know most of the media queries I write are for a simple test of width. But there are other conditions you can test against, including pixel density.
The standard way to test for pixel density is to use min/max-resolution like
1
@media only screen and (min-resolution: 2dppx) { }
Allowed units are:
dpi (dots per inch)
dpcm (dots per centimeter)
dppx (dot per pixel unit)
Unfortunately not every browser supports the standard just yet. IE9+ and Opera Mini support only the dpi value. Safari and iOS Safari support the non standard min-device-pixel-ratio: 2.0 with the -webkit vendor prefix.
1
@media only screen and (-webkit-min-device-pixel-ratio: 2.0) { }
Switching images this way is easy enough though one issue to consider is whether or not browsers download all images inside and outside of media queries or if they down only the one needed?
Tim Kadlec ran some tests a couple years back to find out and you should check his post for the details. Tim ran a variety of tests, many with surprisingly good results. I want to call attention to one, the test using min-device-pixel-ratio.
1 2 3 4 5
.background { background-image: url("path-to-image-1x.jpg"); } @media only screen and (min-device-pixel-ratio: 2.0) { .background { background-image: url("path-to-image-2x.jpg"); } }
With one exception, browsers loaded only the appropriate image given the above code, which is what we want. However, in the time since these tests, a standard emerged and we should use the standard values for supporting browsers and offer fallback for others.
About two years ago Chris Coyier offered what at the time was a future proof media query to target resolution.
1 2 3 4 5 6 7 8
@media only screen and (-webkit-min-device-pixel-ratio: 2), only screen and ( min--moz-device-pixel-ratio: 2), only screen and ( -o-min-device-pixel-ratio: 2/1), only screen and ( min-device-pixel-ratio: 2), only screen and ( min-resolution: 192dpi), only screen and ( min-resolution: 2dppx) { }
Relative to Chris’ post it is the future and given the increased support for min/max-resolution we can probably reduce the above to the following:
1 2 3 4 5 6 7
@media only screen and (-webkit-min-device-pixel-ratio: 2), // Safari and iOS Safari only screen and (min-resolution: 192dpi), // IE9+ only screen and (min-resolution: 2dppx) // All other browsers { Image switching code here }
Looks like all we need right? Actually no. The code above works for the art direction use case, but it doesn’t allow browsers to make an optimal choice in which image to display. Fortunately CSS gives us a way to let them.
Using image-set() on background-image
During the research for this series I came across a great and short post at Google’s Developers site on using images in CSS. The post introduced me to image-set(). CSS4 adds image-set() as a value you can use on the background-image property.
Having worked with the srcset attribute over the first two posts in this series, the above shouldn’t be too hard to understand. The image-set() value lets you set multiple urls and associated resolutions as background-images and lets browsers decide when each should be used. Browsers will automatically scale the images so your @2x image will display at half it’s dimensions.
Browser support for image-set() isn’t quite as good as it is for srcset. You need vendor prefixes to make this work, however, if you do use them, you can make this work in the same browsers as srcset. In fact given the browsers that have support, it’s only the -webkit prefix you’d need at the moment.
Unfortunately image-set() isn’t built into the Picturefill polyfill so we have no way to support Firefox, Internet Explorer, or Opera Mini at the moment. Also be aware things can change between now and when the spec is recommended.
The good news is you can still set a default background-image for those browsers without support and progressively enhance for those with support. In other words there’s no reason you can’t use image-set() now in practice as long as you don’t mind the vendor prefixes.
Non-supporting browsers will display fallback-image.jpg, which is the same thing they’d do if the image-set() code wasn’t there.
Closing Thoughts
I hope you’ve enjoyed the series to the this point. My experience working with srcset, picture and their associated attributes and elements is admittedly limited. However, even with that limited experience, working with the srcset attribute and the picture element is fairly easy.
It takes a little more thought to figure out the best sizes for the images, but the code is straightforward and it shouldn’t take long to figure out how to work with it. It’s worth the effort.
Even though browser support isn’t perfect, I think you can use srcset and picture now as well image-set() and everything else I’ve mentioned in this series. You can use the Picturefill polyfill for non-supporting browsers or you can just make good decisions about fallback images.
The hardest part will be creating the images. A little practice and choosing sizes will become just another thing we do. Of more concern is actually getting and creating the images. It’s easy enough to create several versions of an image for the few boilerplate images in a design. It’s all doable, but how often do your clients send you images now that are good enough for @1x, let along @2x, or @3x?
How about sites that add multiple images every day or sites that feature image galleries. An automated solution will be necessary for these sites. Fortunately automated solutions exist. Photoshop actions for example could make resized versions of your highest resolution in the background.
WordPress can automatically resize images you upload, though you need to stick to a handful of defined sizes to make it practical. A variety of responsive image plugins already exist as well.
I’m not overly concerned. I’m sure as more sites create multiple versions of images, we’ll discover new tools and others will be created to help.
Art direction probably won’t become any more popular, but those sites wanting to art direct images can now do so more easily.
Bitmap images will still remain a performance bottleneck and I think the common wisdom in regards to images will hold. Where possible you should:
Replace images with code
Replace bitmap images with SVG, icon fonts, and other vector based images
Combine images into sprites to reduce http requests
Overall try to reduce the number of bitmap images you use
Next week I’ll finish this series by presenting a more practical, though still simple demo that puts much of what we’ve covered in this series into practice.
How much time do you put in to understanding the perspective of others? Do you judge anything that differs from your own personal taste as poor quality?
Today I want to talk about personal taste and learning to appreciate a perspective not your own. You don’t have to agree with the perspective, but you should respect it and learn to appreciate it.
Ryan’s article defends Taylor Swift’s music as part of a larger point about appreciating the perspective of others. I’m not particularly against Taylor Swift’s music, though I’d hardly call myself a fan. I can certainly appreciate where the music comes from.
The idea is that different types of music use a different vocabulary to communicate and you should understand that vocabulary before passing judgement. Here are a couple of quotes from Ryan’s article.
It's easy to dismiss music and musicians without listening closely when you don't take the time to learn the language they're using, to discover where the intelligence and artistry lies.
it often requires intellectual/emotional openness and very close listening (or, like, dancing) to understand what a piece of music is getting at, what language it's speaking, what feelings it wants to evoke—even who its target audience might be—before we can fairly judge what's successful or unsuccessful about it.
I think the idea of communicating with different vocabularies and having different perspectives extends beyond music. It’s true of all creative work. It’s true of business. It’s true of life.
Everything doesn’t have to be for everyone. Many things require you put some effort into the consuming (listening, reading, or viewing) before you can appreciate what went into the creation and often through that appreciation you learn to enjoy something you might not have enjoyed otherwise.
Understand Before Judging
As an industry web designers can be quick to judge the work of others (In fairness it’s people in all industries that do this). Take logos for example. Whenever a large company introduces a new logo, it seems to get panned across the web as garbage.
When Apple, Google, Microsoft or any other large company redesigns their operating systems or release new versions of software, posts are written talking about what each got right and wrong. It’s good that we discuss and critique designs, but we shouldn’t rush to judgement.
Too often we judge without an appreciation of the designers who created the new site, operating, system, or software. Did the designers have all the time they wanted? What’s their roadmap? Are they introducing something today that won’t be entirely finished until the next release?
We may not truly appreciate the constraints the designers we’re judging worked under. Perhaps something we think they should have done wasn’t technically possible. Maybe the designers were overruled by marketing or the CEO.
I know a certain amount of what ends up in client sites isn’t always my choice. It’s my best attempt to integrate a client’s choice into the design, but it’s not always what I thought best for the design.
I think the larger point of Ryan’s post is not to judge until you’ve walked in another person’s shoes. It’s important to think and speak critically, but we should do our homework first.
Design is Subjective
As I’ve tried to get across a number of times design is subjective. Everything that involves human beings is subjective because it involves a human being. It’s subjective by definition.
People bring their own perspective, their own context to your design. Many will judge your site purely on aesthetics and based on their perspective of what aesthetics should be.
We can’t expect visitors to spend time analyzing our visual language in order to understand our perspective in designing the site. Hopefully in time they do learn our visual language, but in the beginning they just need to use the site.
If you’re familiar with Maslow’s pyramid, and how it placs necessities like food, clothing, and shelter at the bottom and creative and spiritual things at the top, it suggests the higher up you get in the pyramid, the more perspective and subjectivity come into play.
It suggests that fewer people will like or appreciate your aesthetic choices. That’s ok. It’s to be expected. What we can and should do is gain a better understanding of the context visitors will bring and specifically design a site for their perspective and taste. Still any aesthetic treatment is going turn some away.
Who Are You Designing For?
As a business owner, creator, service provider, etc. you should realize you aren’t going to please everyone and instead focus in order to appeal to a specific group within the whole. It’s ok to turn some people away in order to please others. Not realizing this was one of the mistakes I made in my first business.
You aren’t designing a site for you. You’re designing a site for your client or rather their clients or customers. Each of your client’s customers will visit with a different perspective, a different context.
We aren’t necessarily familiar with a client’s industry. I’ve been familiar with some, but others I had to learn starting with zero or near zero knowledge.
You have to learn to appreciate other perspectives if you’re going to design a site that motivates them to click or call or buy something. It’s where speak their language and not industry jargon comes in.
We can’t realistically know everything about every visitor, but we can do what we can to understand the common perspectives of potential clients and customers. These often become personas. The more we understand them, the more we can create something in a language they understand. The more we can use a visual language that communicates to them.
Clients have Perspective Too
It’s not just site visitors. What about your clients and their perspectives? I’ve had several clients who couldn’t see anything other than their own perspectives. They assume everyone consumes websites exactly as they do.
I have one client who refuses to add a contact form to his site, because he doesn’t like or trust them and won’t ever use them. He assumes everyone else views them the same way.
Just because my client can’t get past that perspective it doesn’t mean I have to be locked into it. While I’ve yet to get my client to change his mind (He’s very stubborn), I could try again by understanding him better and getting to the root of the issue. Why doesn’t he like forms? In his case it’s worry about spam.
He thinks anything that asks for an email address can only be a harvester adding his email to the list to spam. What if we added a form on his site with words like “we never spam” or “we never share your email address” or something similar. Would he let me add a contact form? Maybe I won’t change his perspective, but maybe I can get him to a agree to a better solution by understanding it.
Closing Thoughts
I’ve been a client, a customer, and in general I’m a person who appreciates the creation of things. I don’t think it’s a stretch if I say you are too. We can’t assume our tastes are universal, though. They aren’t. They’re ours. Your taste is yours and mine is mine. They might overlap in places, but they don’t have to.
Ideally we’ve both developed our taste more than typical, given the nature of the work we do. We might even do the work in part because of our developed taste. Still your taste is your taste and my taste is my taste.
Just because you like one operating system or one brand of smartphone, it doesn’t mean that OS or phone is best for everyone. That’s ignoring the perspective of others. Just because you like something in a design doesn’t mean everyone will or that it’s right or best for the design.
Someone listening to music you don’t like or looking at art you don’t get or reading a book you don’t care for isn’t automatically lacking taste. Maybe they do lack taste, but don’t assume it. Ask them why they like what they’re listening to or looking at or reading. Instead of judging, try to understand.
Try to appreciate a perspective not your own. If you have judgements to make after go ahead, but first try to understand. I think the world would be a better place if we all did this. If instead of being quick to judge we took the time to understand what we’re judging first.
As designers we should do everything we can to understand our client’s and their clients or customers. Instead of thinking every disagreement is solved by us educating our clients, why don’t we try to understand where our clients are coming from and maybe educate ourselves a little more.
Last week we looked at the srcset and sizes attributes and how browsers use the values we provide to determine which image is the best to display given the pixel density of image and screen or the size of the image and viewport.
One key point is that browsers make the decision. It’s based on your guidance, but it’s still the browser’s decision. In most cases that’s a good thing. Unfortunately browsers can’t tell when details are lost or when image hierarchy is changed. Sometimes we need to make the decision.
Enter the picture element, where we get to decide. Today I want to walk you through the picture element, it’s associated elements and attributes, and how to work with them. I’ll follow up with some thoughts for when to use srcset and when to use picture depending on your use case.
How the picture Element Works
As I mentioned above, when using srcset you provide browsers with information they use to make an informed decision. With the picture element you provide rules that the browser must follow.
That means the browser won’t be able to optimize things quite as well, but sometimes it’s more important to serve a different image regardless of any performance loss.
Here’s a simple example for how you might use the picture element to switch between three images.
There are three html elements in the code above. The picture element wraps a couple of source elements and an img element.
The img element is an ordinary img tag with src and alt attributes and nothing you haven’t seen before. This will be the default image that’s shown to browsers without support for the picture element and it’s the default condition for browsers that have support.
The source elements aren’t new. They come from the audio and video elements. In the code above each source element has two attributes. One, srcset, is exactly what we saw last week. In this code each srcset attribute is pointing to a single image, though it can point to more. The media attribute works like a media query.
The first source element in the code above sets the condition (min-width: 50em) for which large.jpg should be used. The second line is similar. It sets a different condition (min-width: 30em) for when to show med.jpg. If neither condition applies then small.jpg (the default) is displayed.
It’s important to note that browsers have to use the first source tag that matches. Say the above code was written as below with the two source tags presented in the opposite order.
With the code written this way, a browser open to 60em would use med.jpg because 60em is more than 30em and viewport width and condition match. The browser must use this source and it ignores the rest even though large.jpg is the better image to show. The decision to show the images comes with some responsibility.
Also note that an img tag with a src attribute needs to be included or none of this works. You can’t use source elements alone to cover all conditions.
To help browsers render pages a little quicker you can specify image dimensions for each media query in your css. This will help with performance as it’s one less calculation for browsers to make.
You can also style the picture and source elements, but be aware they may not do what you expect automatically. The image below is a screenshot of an example I created to test the picture code above with two source elements and an img tag.
I set a 3px border on each of the three elements, picture (olive), source (orange), and img (red). I added a little padding and margin to picture and source as well to make it easier to see the borders and I also set both the picture and source elements to display: block. This makes it easier to distinguish where one begins and another ends.
You can see that picture is wrapping both source elements and the img element. Even though the image you see displayed was chosen from one of the source elements (the second one), you can see it’s being displayed inside the img element. Keep that in mind when styling with css.
You might have noticed I haven’t yet explained the picture element itself. That’s because all it really does is contain the source and img tags. There’s not much more to the element.
You aren’t limited to a single image in each srcset. The srcset attribute works the same here as I described last week. You can add multiple images and specify their pixel densities as follows.
The code above directs browsers to choose an image from the source tag for devices up to 50em wide and to choose an image from the img tag when the viewport is wider. In either case browsers would then choose the more appropriate image based on the pixel density of the device and images.
The type Attribute
The source element can also take a type attribute to serve different image formats to different browsers. For example Google is promoting a new WebP image format, which is also supported by Opera. Other browsers don’t support this image type. Microsoft is promoting it’s own image format, JPEG XR (.jxr), which again other browsers don’t support
Here’s how you might set up the picture element to show different image formats to different browsers.
1 2 3 4 5
<picture><source type="image/webp" srcset="image.webp"><source type="image/vnd.ms-photo" srcset="image.jxr"><img src="image.jpg" alt="My type of image"></picture>
In the code above, browsers supporting WebP will use image.webp. Browsers that don’t support WebP, but do support vnd.ms-photo (JPEG XR) will use image.jxr All other browsers will use image.jpg.
You probably won’t be experimenting with new image formats just yet, but it’s not hard to envision a future where you might.
Do I want to serve different art depending on certain contextual factors?
Do I want to serve images with different mime types to browsers that support them?
The first two are easily handled by srcset and it’s the method you should generally use unless you answer yes to either of the last two questions, which require the picture element.
Most of the time you’ll want to let browsers decide on the image and so you’ll use the srcset attribute. Browsers can better optimize for performance that way. It also allows browsers to take user preferences and network connectivity into account.
Hopefully browsers will build in more sensors (with associated attributes we can set) so that we can provide more information to help with their decision. Even if they don’t give us attributes they can already do things like detect slow bandwidth and serve a lower resolution image, despite a pixel dense screen.
Art direction is the use case where you need to be in control of the decision. It’s the least common use case of the three, so you should be using the picture element in practice less often than srcset. In practice we’re going to use srcset and sizes more than picture, source, and type.
Closing Thoughts
Where the scrcset attribute helps browsers make an informed decision about which image to show, the picture element gives you control. You set the conditions for which image should load and browsers must obey.
The obvious pro is the control the picture element gives you. Sometimes you can’t leave the decision to browsers. Browsers can’t see the detail or lack of detail in an image. They don’t understand or attempt to maintain your image hierarchy across devices and conditions.
The downside is a performance hit. Browsers can optimize the decision when they make it so they can grab the “best” image quicker than when they have to do what you tell them.
These pros and cons suggest you want to use srcset most of the time. The majority of image switching you’ll do will likely fall into the use case of swapping high and low resolution images and srcset is better suited for that task.
In the case of art direction where you absolutely need a specific image to load under specific circumstances you need to use the picture element and accept any performance hit from doing so.
Next week I want to continue. In creating a demo (for the week after next), I started thinking about what makes a high resolution image, high resolution and while looking for an answer I discovered a few myths about resolution, dpi, and ppi. I also have some general thoughts about responsive images to share.
Do you take responsibility for your actions? All of them? Are you sure? How consistent are you with the things you believe and the things you do? They’re harder questions to answer than you might think. We’re all pretty good at finding ways to avoid responsibility when we want to. The thing is taking responsibility is the first step toward getting better and achieving success.
Last week I shared some thoughts about how we make mistakes to get better and how failure leads to success. One thing I didn’t stress enough is that it all by taking responsibility for your actions, especially your mistakes. In fact you can’t learn anything from a mistake until you accept you made the mistake.
Blame the Other Guy
You probably agree with the above. Perhaps it seems fairly obvious and yet so many of us are quick to talk about what’s wrong and move the blame on someone else. Rarely is what’s wrong something to do with us.
For example the government seems to be at fault a lot. Somehow it’s never our fault for voting the everyone into office. I should amend that. It’s usually not the entire government’s fault. It’s only the fault of the party you don’t belong to. Don’t worry, your political party is perfect. It really is only the other party’s fault.
I also see this with people who join my small business forum. They ask why they don’t have customers and receive suggestions. Then they tell you why none of the recommended changes will work. They’ll defend to the end that they’re doing everything right even as they’re asking why nothing seems to be working.
They’ll argue against change of any kind because they haven’t accepted responsibility for their mistakes and so have nothing they feel needs correcting.
As obvious as it may be that we should accept responsibility for our mistakes, we don’t seem to be very good at it. It’s much easier to blame someone else.
Taking Responsibility
As I did last week let me share my own experience with avoiding and then accepting responsibility.
Like a lot of people it’s easy for me to see what you did wrong and then tell you the right way to fix things and live your life better. What I find harder is applying the same right and wrong to myself. I think that’s true of many people. We can be inconsistent in what we believe and what we do.
For example it’s easy to believe in something like free speech. What’s not so easy to understand is that your belief means you have to grant that same freedom to everyone. Saying you believe in free speech while trying to prevent some from saying things you don’t like is inconsistent behavior.
Your belief in the principle means you have to grant that same freedom to others even if their thoughts and words are repulsive to you. If you don’t, you give up your right to complain when your free speech is taken away. You will have set the precedent that allowed your right to be taken from you.
When I started examining my actions and comparing them to the principles I believed in, I felt like a hypocrite. I could be quick to condemn anyone for not following my principles, even though I wasn’t following many of them myself.
I wasn’t applying the same standard to myself that I applied to others. Your principles and values can’t change from moment to moment for your convenience. They can’t change to favor what you want to do at a particular time. That’s not a value you hold. It’s a rationalization so you can can feel justified in everything you do. It’s you changing the rules so that whatever you do is right simply because it was you that did it.
I realized I needed more consistency between my beliefs and action. I was letting myself slide for convenience and it had to stop. I took a long, deep, and quite honestly, painful look at myself. I had to confront and break down the defense mechanisms that supported the inconsistencies.
Either the principles or the actions had to change. Mostly it was my actions that changed. I thought I wasn’t living up the ideal I set more than anything else. Here and there I revisited a principle I held strongly and upon examination gained new understanding and a different opinion. Mostly it was my actions that changed.
As a result I’m much more consistent now (though hardly perfect) in what I believe and what I do and it started because I took more responsibility for my thoughts and actions.
Working for the Man
Before I was working for myself. I bounced around from job to job a lot. I’ve never worked for anyone two years in a row. The longest I ever worked anywhere consecutively (other than my business) was 20 months. Ironically it’s the job I enjoyed least in my life, but that’s a story for another time.
When a job would end, usually due to me quitting, I could easily see all the reasons why my employers or coworkers were at fault. I could see how their actions made me quit, as ridiculous as that sounds.
A bit of introspection and it wasn’t hard to understand the only consistency across all those jobs that didn’t work was me. It’s hard to blame other people when you realize you’re the consistent thing across all the failings.
When I saw my failure as someone else’s responsibility, there was nothing for me to do differently and so I repeated my mistakes and found myself looking for work again. When I finally accepted that it must be my responsibility, even if I didn’t quite know what I’d done wrong, I was able to figure it out. It gave me permission to try different things and learn from them.
It didn’t happen quickly. I made plenty more mistakes after my realization. But having accepted the mistakes as mine I could begin to learn from them and improve the next time I tried.
It ultimately meant working for myself, but I never would have come to that point had I not accepted responsibility for my employment failures from the past. It didn’t happen overnight, but it did happen.
Take Responsibility to Learn From Your Mistakes
One thing I’ve discovered since I began working for myself is that my favorite part of having my own business is the responsibility that comes with it.
I don’t mean responsibility in the sense of having more to do, but in the sense of my success or failure being in my control. The business succeeds or fails because of me. That’s what taking responsibility does. It gives you control over the situation.
That means you have to take responsibility for the bad as well as the good. It can’t be you when things work and someone else when they don’t. Take responsibility for every aspect of your business, your career, your life.
The first step in recognizing mistakes as yours so you can learn from them is taking responsibility. Own up to your mistakes and accept that you made them. It’s a big step toward positive change. You take responsibility by accepting the consequences and not passing them off on someone else.
No one wants to deal with negative consequences, but suffering those consequences makes you never want to suffer them again. It motivates you far more than avoiding the things you don’t want to face. Assuming you don’t want to suffer the same consequences again, you quickly learn and correct your error. Otherwise you deal with them again the next time you make the same mistake.
Closing Thoughts
It’s easy to blame others when you fail or to blame the universe in general for causing your grief. It’s hard for us to admit our failures are nearly always of our own design. We develop self defensive mechanisms to keep us from accepting blame and ever acknowledging our culpability.
If you continue to do things the same way and keep ending up without success, you have to do something different. It starts by realizing the only consistent part of your failings was you and accepting it’s you that needs to change.
You’re the only consistent part of all the relationships you’ve been in from the romantic to the familiar. You’re the only consistent part of every job you’ve ever had. Face it, the only thing present in every one of your failures was you.
That doesn’t make you a bad person and it doesn’t mean you’ll inevitably fail at the next thing you try. It just means if the same results keep happening, stop looking elsewhere and look to what you can do to achieve different results
You can’t blame others for your failings, when you’re the consistent piece of the puzzle. If you do, you’ll protect your psyche in the short term, but you’ll continue to make the same mistakes and continue to require your psyche to toss out more and more self defense mechanisms in the future.
The first step in recovery is admitting you have a problem. By taking responsibility for your mistakes you allow yourself to correct them. By blaming someone else you correct nothing and inevitably do the same things which led to failure all of the previous times you tried.
One of the main challenges with responsive design is how to handle images. It’s not that we don’t know what we want to do. It’s that the ability to do it has been lacking. Fortunately the situation is starting to change for the better.
Like many designers, I’ve sat on the sideline waiting for responsive images to sort themselves out. In previous looks at how to solve responsive image problems, I walked away with the feeling that the solutions were usually more trouble than they were worth for myself and my typical clients.
For larger organizations it makes sense to put better solutions in place, but for most people, the benefits don’t justify the time, effort, and budget. Since neither my clients nor myself are large organizations, it made sense to wait out the spec and technology to see what they would bring.
The good news is the spec is finally coming together. After reading a recent post by Jason Grigsby about picture and srcset, I thought now would be a good time to revisit the topic of responsive images.
It turns out there was more to cover than I thought so this will be a multi-week topic. Today I’ll cover some background, history, and browser support, before digging into the srcset attribute and the associated sizes attribute.
In coming weeks we’ll look at the picture element and which method is best to use when. I have a demo planned as well as a few additional topics and general thoughts about responsive images.
A Bit of History
In case you aren’t familiar with some of the history behind responsive images, particularly in regards to new specifications in html to handle them, I’ll try my best to summarize.
Since the beginning there have been two camps with different approaches to switching images. Browser makers support srcset in large part for performance reasons. By allowing browsers to make the decision, browser can optimize them.
Designers and developers, on the other hand, have generally supported the picture element, because the syntax is more natural and because the picture element gives us control instead of leaving it with browser makers. Both approaches have their merits and as well as their difficulties.
The srcset attribute has more often been “winning” this battle and for a time it looked like the picture element would never arrive. In the end we’re getting both srcset and picture giving us tools to solve some of the basic issues around working with responsive images.
Browser Support, Polyfills, and Testing
At the moment browser support isn’t great, but support is coming and, given the importance, I’ve no doubt that very soon the latest versions of all browsers will offer support. As I’m writing this here’s how things break down.
The srcset attribute is supported in the latest versions of Chrome, Opera, Android Browser, and Chrome for Android. Safari offers partial support. It doesn’t support the sizes attribute, which can be used in conjunction with srcset. Firefox, Internet Explorer, and Opera Mini offer no support.
Things do seem to be moving quickly and I expect browsers to be supporting both srcset and the picture element sooner rather than later. Don’t let the current lack of support keep you from using srcset and picture, though. Scott Jehl maintains the picturefill polyfill on GitHub. It has support for srcset, the picture element, and associated tags and attributes.
One issue you may have is testing high DPI images. I know it’s an issue for me. My tablet and phone can handle @2x images, but the hardware is moving on to @3x. My laptop is @1x only. One method for testing is to visit stores selling the devices you want to test on, however there are some other approaches.
The developer tools in browsers have gotten quite good and some can be adjusted to let you test high pixel density images. Here’s some information I found for testing high density images.
I can’t honestly say they work. I only tried in Chrome and my developer tools looked different than these screen shots I saw.
I was able to work out testing in Chrome, though. Zooming to 200% and reducing the default font-size from 100% to 50% in my style sheet, effectively simulates @2x resolution. Matt Zeunert also has a nice article with general Cross browwer testing advice, including some thoughts about pixel density in browsers.
I’m not sure if Internet Explorer offers a similar way to set pixel density. The best I’ve been able to find is resetting the dpi scaling in Windows itself. If someone knows more please leave a comment so I can add IE testing here.
How the srcset Attribute Works
The basic idea behind the srcset attribute is you provide information to browsers to help them decide which image to display based on the pixel density of both image and screen. Letting browsers build algorithms to choose will make for faster choices in which image(s) to show.
You add the srcset attribute to an <img> tag like you see in the example below.
Other than the srcset attribute, it’s an ordinary <img> tag with src, width, and alt attributes. The src sets a default image, which will be used by non-supporting browsers (they ignore srcset) and may be used by supporting browsers depending on conditions.
The srcset attribute contains a list of images along with the display density of that image. Note that it’s a single attribute with a comma separated list of images and densities. If you create a @3x image, you’d add it to the end of the list.
Browsers then uses a little math to figure out which image to use. Say a device that’s 320px wide is loading the page in question. 600px (the image width) divided by 320px (the screen width) results in a value of 1.875. Ideally an image with this density is provided in the list, but since one isn’t, the browser would decide if a 1.5x or 2.0x image would be the better image to display.
That’s the simplest case, where the only thing that needs changing is the resolution of the image. However, with responsive design we know the sizes of those images will also change to fit within a changing layout. Enter the sizes attribute.
The sizes Attribute
The sizes attribute gives you the ability to tell browsers to select different images based on their size and how much of the viewport they’ll occupy.
The ideal would be to let browsers choose like they do for resolution differences, but the image dimensions that get used would require knowing the page layout first. Browsers can do this, but if we give them some information up front we can save them time and keep them from downloading more images than necessary.
The code above isn’t all that different from the previous example. Starting at the bottom, there’s a default image on the src attribute as well as an alt attribute.
The scrset attribute (above the src) is similar to the previous example in that it’s a comma separate list of images plus something else. Instead of 1.5x, 2x, 3x we now see 400w, 800w, 1600w. The w values are telling browsers this image is 400px wide, 800px wide, etc.
The sizes attribute (note the plural sizes) contains the information you give browsers so they can choose an image. In this code sizes has a single value of 100vw, which means an image should fill 100% of the viewport width. 100vw is the default, by the way, if no value is set.
Once again the browser does some math. Since the size is defined as 100% of the viewport it’s the same math as before (image width ÷ screen width = pixel density). Let’s say a device that’s 600px wide lands on the page.
400/600 = 0.67
800/600 = 1.25
1600/600 = 3.20
The browser would then choose the best image based on the above results and the pixel density of the screen. The sizes attribute may not seem all that exciting, until you realize you aren’t limited to a single size as an attribute value.
In the code above there are three possible sizes along with the srcset images and the default/fallback image. A browser open to 30em or less would use 100vw. A browser open more than 30em, but not more than 50em uses 50wv. Browsers wider than 50em will use 33vw. From there the math is the same.
Assuming 1em = 16px, imagine a viewport of 800px and 2x density is rendering the page. The viewport is 50em so it’ll use the second sizes value, which is 50vw. Half 800px is 400px, which gets used in the calculations.
200px/400px = 0.5
400px/400px = 1.0
800px/400px = 2.0
1600px/400px = 4.0
Since the screen has 2x pixel density, the 800px image would likely be chosen in this scenario.
Ultimately the sizes attribute allows more flexibility in what image(s) you want to display based on both viewport width and resolution, instead of resolution alone. However, you’re still letting browsers make the decision for which image to show.
Sometimes you want to make that decision yourself, which brings us to the picture element and next week.
Closing Thoughts
It didn’t take designers long to realize there were issues that needed to be solved when working with responsive images. Most of the solutions to this point have been too complicated, time consuming, and expensive for most people to implement. They’ve remained the domain of larger organizations with more resourcesfor the most part.
What many designers have been waiting for are new specs that make it easier to work with images in responsive layouts. It’s taken some time and lots of battling, but the spec is becoming clearer and browsers are beginning to support the srcset and sizes attribute along with the picture element.
The srcset attribute is a simple way to suggest different images to browsers based on their pixel density. In combination with the sizes attribute it can be used to suggest which image a browser should use based on image and viewport size as well as pixel density.
However, both leave the final decision up to the browser. That’s a good thing because it allows browsers to find and download the best image quicker, but sometimes we want to make the selection ourselves.
The picture element lets you do just that. Next week I’ll pick up this conversation with a look at the picture element and how it works. I’ll also talk about when to use srcset and when to use picture based on what you’re trying to do.
