If there's one thing that there've been an ample number of articles telling front end developers they must unequivocally adopt in the last five years, it's responsive images. We're all aware that more and more users are viewing our websites on mobile devices, and standard definition image assets simply won't do for today's retina displays. Thankfully, the W3C and WHATWG standards bodies have done a great job of taking feedback to give front-end developers simple but powerful tools to begin handling serving images at a wide range of resolutions for all the devices we now have to target. However, while eager web developers have been pushing everyone to add these new tools to their toolkit, recent projects have taught me that there are quite a few caveats that the considerate developer should be aware of before they start serving responsive images.

Firstly, let's discuss what tools currently exist and when to use them. The two main responsive image solutions added in HTML5 are img srcset and the <picture> tag. <picture> is a container for a set of image <source>s, where each source provides a srcset attribute with a path to the image you want to show and a media attribute with a standard media query breakpoint. You can list as many <source>s as you wish to have images, and each can also choose between a 1x or 2x size image for retina screens. Finally, there's a normal <img> tag at the end of your <source>s with all the standard src and alt attributes that you'd normally include. Regardless of what resolution you're viewing the page at, the <img> tag is actually the only rendered element, and all the <source>s do is swap out the src attribute in the <img> tag. Also, in the case that the browser doesn't support responsive images, the <img> tag is a safe fallback. If you're going to do any extra styling on your picture, just apply it to the <img> tag.

The web utilizes a rapidly increasing number of programming languages, but HTML, the first and most basic building block of the web, is not one of them. Most developers would say with some condemnation that HTML is not a programming language, and while they are correct that it is not programming, it is a language. A programming language can provide instructions using computer analogues of all the basic constructions of human language: nouns, verbs, descriptors, punctuation, and rules of grammar. A markup language, which are the last two letters in HTML to give you a hint, is like a written language that consists solely of adjectives. It only describes the context of another language. To illustrate, HTML tags are the adjectives that go before, after or between the English-language content that makes up a complete webpage. The tag, <a> describes  that the following piece of text is a link, and the tag property, href, further describes where that link leads to. So, for example, the line: 

<a href=“http://www.google.com”> Clicking this text will take you to Google </a>

is HTML’s way of ascribing a purposeful intent in the text that goes on the webpage. The dictionary for HTML contains 109 adjectives in its most recent publication, and the job of every current browser is to read the meaning of them in as close to the same way as possible, though each browser infers the intent of those words slightly differently. However, unless your goal in life is to learn all the ins and outs of HTML, there is no reason to cover any more of these fundamentals.

Instead, I’d like to talk about the parts of HTML that make me enjoy my job. This is the part of HTML known as semantic markup. It’s a purposeful effort by the people who use and design HTML to make their adjectives give better context to what they actually describe. For example, the tag <b> has been the method for describing text which should be bold since the very early days of HTML. However, <b> is poor vocabulary to use in the context of text, because it doesn’t actually give meaning to the words that it is describing. Instead, if you wanted to describe the importance of the text, you should use the tag that describes it as <strong>. <strong> is functionally identical to <b>, but de-couples the function from the intent. After all, the text that you want to stand out as strong may not actually appear bold in your design, so why describe it that way?

Subscribe to RSS - html5