One Size Fits Some: A Guide to Responsive Web Design Image Solutions

As mobile and tablet devices come closer to achieving final world domination, web design and technology is in a race to accommodate the ever-growing number of screen sizes. However, devising tools to meet the challenges of this phenomenon brings a whole new set of problems, with one of the latest buzzwords to emerge being “responsive web”. This is the challenge of making the web work on most, if not all, devices without degrading the user’s experience. Instead of designing content to fit desktop or laptops, information has to be available for mobile phones, tablets or any surface connected to the web. However, this responsive web design evolution has proven to be a difficult and sometimes painful one.

While it can be almost trivial to accommodate textual information, the tricky part comes when we put into consideration content like responsive images, infographics, videos, an so forth, which were once designed with only desktops in mind. This not only brings up the question of displaying the content correctly, but also how the content itself is consumed using different devices. Users on smart phones are different to users on desktops. Things like data plans and processing speed have to be considered as well. Google has started to highlight mobile-friendly sites on its search results, with some speculating that it will lead to a substantial pagerank boost to such sites. Earlier solutions addressed this by deploying mobile-only subdomains (and redirects) but this increased complexity and fell out of fashion quickly. (Not every site has the ability to afford this route.)

On the Quest for Responsive Web Images

Responsive web design images simply must scale to fit common devices in the modern age.
Responsive web design images simply must scale to fit common devices in the modern age

At this point, developers and designers have to ensure their website load is optimized to meet the users who are on mobile sites. Over 20% of web traffic is now mobile users, and the number is still rising. With images taking among the largest shares of page content data, it becomes a priority to reduce this load. Several attempts have been made to simplify responsive design image resizing, including, both server-side and front-end solutions. To discuss these responsive image solutions, we need to first understand the current image linking shortcomings.

The tag has only the source attribute linking directly to the image itself. It has no way of determining the correct type of image needed without any add-ons.

Can’t we just have all the image sizes included in the HTML, and use CSS rules to display:none for all but the correct image? That is the most logical solution in a perfect logical world. This way the browser can ignore all the images not displayed and, in theory, not download them. However, browsers are optimized beyond common logic. To make the page render fast enough, the browser pre-fetches linked content before even the necessary stylesheets and JavaScript files are fully loaded. Instead of ignoring the large images intended for desktops, we end up having downloaded all images and resulting in an even larger page load. The CSS-only technique only works for images intended as background images because these can be set within the stylesheet (using media queries).

So, what’s a website to do?

Back-End Responsive Image Scaling Solutions

A back-end solution can be perfect for handling image size in a responsive web design situation.
A back-end solution can be perfect for handling image size in a responsive web design situation.

Barring mobile-only sites/sub-domains, we are left with sniffing user-agent (UA) and using it to serve the correctly sized images back to the user. However, any developer can attest how unreliable this solution can be. New UA strings keep popping up all the time, making it strenuous to maintain and update a comprehensive list. And of course, this doesn’t even take into account the unreliability of easily-spoofed UA strings in the first place.

Adaptive Images

However, some server-side solutions are worthy of consideration. Adaptive Images is a great solution for those preferring a back-end responsive image fix. It does not require any special markup but instead uses a small JavaScript file and does most of the heavy work in its back-end file. It uses a PHP and nginx configured server. It also does not rely on any UA sniffing but instead checks for the screen width. Adaptive Images works great for scaling down images, but it’s also handy for when large images need art direction, i.e. image reduction by techniques such as cropping and rotation – not merely scaling.

Sencha Touch

Sencha Touch is another back-end responsive design image solution, although it is better to refer to it as a third-party solution. Sencha Touch will resize the image accordingly by sniffing the UA. Below is a basic example of how the service works:

There is also an option to specify the image sizes, in case we do not want Sencha to resize the image automatically.

At the end of the day, server-side (and third party) solutions require resources to process the request before sending the correct image back. This takes precious time and in turn slows down the request-response trip. A better solution might be if the device itself determined which resources to request directly, and the server responding accordingly.

Front-End Solutions

Front-end responsive design image scaling solutions can be a great option to optimize website loads.
Front-end responsive design image scaling solutions can be a great option to optimize website loads.

In recent times, there have been great improvements on the browser side to address responsive images.

The <picture>  element has been introduced and approved in the HTML5 specification by the W3C. It is currently not widely available on all browsers but it will not be long before it is natively available. Until then, we rely on JavaScript polyfills for the element. Polyfills are also a great solution for legacy browsers lacking the element.

There is also the case of the srcset attribute that is available for several webKit based browsers for the element. This can used without any JavaScript and is a great solution if non-webKit browsers are to be ignored. It is a useful stop-gap for the odd case where other solutions fall short, but should not be considered a comprehensive solution.

Picturefill

Picturefill is a polyfill library for the element. It is one of the most popular libraries among the front-end solutions to responsive image sizing and scaling issues. There are two versions; Picturefill v1 mimics the element using span while Picturefill v2 uses the element among the browsers that already offer it and provides a polyfill for legacy ones (for example, for IE >= IE9). It has some limitations and work arounds, most notably for Android 2.3 – which incidentally is an example of where the img srcset attribute comes to the rescue. Below is a sample markup for using Picturefill v2:

To improve performance on users with limited data plans, Picturefill can be combined with lazy loading. However, the library could offer wider browser support and address the odd cases rather than relying on patches.

Imager.js

Imager.js is a library created by BBC News team to accomplish responsive images with a different approach to the one used by Picturefill. While Picturefill attempts to bring the element to unsupported browsers, Imager.js focuses on downloading only the appropriate images while also keeping an eye out for network speeds. It also incorporates lazy loading without relying on third-party libraries. It works by using placeholder elements and replacing them with elements. The sample code below exhibits this behavior:


The rendered HTML will look like this:

Browser support is much better than that of Picturefill at the expense of being a more pragmatic solution than a forward thinking one.

Source Shuffling

Source Shuffling approaches the responsive image problem from a slightly different angle than the rest of front-end libraries. It resembles something out of the “mobile first” school of thought, whereby it serves the smallest resolution possible by default. Upon detecting that a device has a larger screen, it swaps the image source for a larger image. It feels like more of a hack and less of a full fledged library. This is a great solution for chiefly mobile sites but means double resource downloading for desktops and/or tablets is unavoidable.

Some other notable JavaScript libraries are:

  • HiSRC – A jQuery plugin for responsive images. Dependency on jQuery might be an issue.
  • Mobify.js – A more general library for responsive content, including images, stylesheets and even JavaScript. It ‘captures’ the DOM before resource loading. Mobify is a powerful comprehensive library, but may be overkill if the goal is just responsive images.

Summary

At the end of the day, it is up to the developer to decide which responsive web design image approach suits the user base. This means data collection and testing will give a better idea of the approach to take.

To wrap up, the list of questions below can be helpful to consider before deciding the appropriate responsive image solution.

  • Are legacy browsers an issue? If not, consider using a more modern approach (e.g: Picturefill, srcset attribute)
  • Is the response time critical? If not, go for a third-party or back-end solution.
  • Are the solutions supposed to be in-house? Third-party solutions will obviously be ruled out.
  • Are there lots of images already on a site that is trying to transition to responsive images? Are there concerns about validation or semantic tags (or rather non-semantic tags)? This will require a back-end solution to route the image requests to something like Adaptive Images.
  • Is art direction a problem (specifically for large images with a lot of information)? A library like Picturefill will be a better solution for such a scenario. Also, any of the back-end solutions will work as well.
  • Is there a concern about lack of JavaScript? Any of the front-end solutions will be out of the question, which leaves the back-end or third-party options that rely on UA sniffing.
  • Is there a priority for mobile response times over desktop response times? A library like Source Shuffling may be more appropriate.
  • Is there a need to provide responsive behavior to every aspect of the site, not just images? Mobify.js might work better.
  • Has the perfect world been achieved? Use CSS-only display:none approach!

This article originally appeared in Toptal

Responsive Design Is Not Enough, We Need Responsive Performance

Recently I’ve been running into a lot of responsive websites with a lot of performance issues. On most of them, the issues are so evident that they’re almost useless on anything besides the latest generation of smartphones. Considering the fact that responsiveness as a concept is intended to reach a wider audience, this seems rather counterproductive.

The greatest contributor to this issue is the still prevalent desktop-first design paradigm. Thinking from the perspective of mobile-first seems to address the issue, but that alone does not guarantee satisfactory performance. We all seem to rely far too much on more or less graceful degradation. We rely on shims and polyfills to enable missing functionality. We rely on libraries to enable rapid development and to have our back when browser compatibility is an issue.

Phone killers on the loose, disguised as responsive websites
Phone killers on the loose, disguised as responsive websites

“Why worry?” you might ask. “Most of our visitors have high performing smartphones running their latest OS versions. They can handle our sites. The analytics tell us so.”

I’m sorry about the straw-man argument, but I think it deserves stating out-loud that the people who can use your site will be the majority of your users. If you don’t see Android 2.3 in your analytics, does that mean that there are no users with those devices? Or does it mean your site has nothing to offer those users? Consider that a lot of devices of that generation are still on the shelves, being bought brand-new even today. You shouldn’t dismiss it outright as a yesteryear technology.

Therefore, I would like to talk about the ideal cases and actual goals of web development. And about practices and paradigms that get us closer to those goals.

Brick-First Design Paradigm

A significant portion of annual phone sales are still taken by feature phones. An even larger portion of population is not buying phones every year, but nevertheless have some web capable device in their possession. Add to those numbers last generation smartphones still in use, add the kindles and other web semi-capable devices (WAP devices, TV’s, toasters, t-shirts and bricks). Add them all up and you might reach a staggering sum.

You won't see them in your analytics unless it works there
You won’t see them in your analytics unless it works there

Consider the use cases for this audience. They’re not going to read long articles, browse, and research on their devices. But they might go through the horrors of trying to type in a URL on the numeric keyboard and navigating the page using directional keys to get to a phone number or double-check an address on the fly.

How hard is it then for us to implement a sub-mobile-first layout that will provide only that information to the devices below a certain threshold of capabilities and performance?

Graceful Improvement

With graceful degradation as a minimum best practice, we’ve created a catch-all principle that (to some extent) obstructs thinking beyond it. Once graceful degradation is in place we can surely say our job is done, and done well. More and more often we don’t even have to think about it as it is already covered by the various frameworks and libraries in use. And finally polyfills and shims completely remove the need for functionality degradation in some cases.

As this functionality becomes more and more readily available, the need for thinking about it (let alone beyond it) becomes more and more remote.

From the standpoint of this article it could be broken down like this:

Ungraceful degradation: If a feature is not readily available, the implementation fails in such a way that it becomes unusable or usable in a prohibitively impractical way.

Graceful degradation: If a feature is not readily available, it fails in a way that still enables acceptable usability.

Ungraceful improvement: If the feature is not readily available it is emulated by a polyfill or shim.

There, problem solved.

Well unless you consider the performance of those same low end devices.

Lacking the processing power and data capabilities of their younger siblings, they are asked to carry a much greater load. Taking polyfills as a solution creates an illusion that all modern functionalities are now available on all devices and can be used without concern.

And so you implement modernizr and polyfill everything just in case. The least competent device ends up loading the greatest amount of data, and performing the greatest amount of processing. Thus ensuring the “best” end user experience.

Shiv, shim, and polyfill? Thank goodness most smartphones do not support Flash!
Shiv, shim, and polyfill? Thank goodness most smartphones do not support Flash!

The idea of graceful improvement would reverse the concept by starting with the lowest feature requirements and loading upgrades until the performance-usability balance is optimal based on device capabilities. Thus the data traffic and processing requirements would be moved to the devices best suited to handle them.

Sure, at the moment the concept is prohibitively complex: it is unsupported by most of the frameworks and libraries, it is mostly undiscussed, and references to such practices are few, far-apart, and localized to micro-functionalities. But at some point it was that way with all concepts and functionalities.

It Can, But Does It Have To?

Another best practice with web development is checking if a feature is available on a device before activating it.

However, take into account that you can install the latest version of Google Chrome on your years-old Android phone, and it will claim that it can run CSS animations, WebGL, background parallax effects, and many other functionalities. But it really, really, can’t. So much so that the browser will crash, and the entire device will become unresponsive to a point that it will have to be rebooted to regain control.

This issue has lately started affecting Android applications in a big way (from a user standpoint). One of the most noticeable degradations in this sense has affected Google Talk/Hangouts app upgrade that has turned their service from the most lightweight chat application available to an almost unusable application due to performance issues on older devices. (Just to stress this point once more: “older” here means that you can still buy it off-the-shelf, brand-new in almost any store). The same issue affected the YouTube app and the Twitter app (in my experience) and apparently many others.

So, take a moment at some point during your planning phase to evaluate the value of a high performance core feature over cutting-edge makeup. Or at least leave the last generation of your app/service/content available in some form for the legacy users. Speaking of which…

Let the Users Opt-Out from the Bleeding Edge

Have you ever found yourself trying to use Gmail from an old device, or over a poor connection? That “load basic HTML” link sure comes in handy.

Why doesn’t your cutting-edge, responsive, animated, touch-oriented online storefront have that functionality?

Think about it: you requested that it be responsive so you can reach more potential customers. You made it cutting edge to leave the best first impression. And as a result, less potential customers can reach even the basic information about you and your services. If graceful improvement is too costly a concept for you, why don’t you at least offer your visitors the option to access a text only version of your content if the “WOW” version is too much for their devices.

Do You Really Need the Whole Library?

Finally, the last best-practice I’d like to see pushed a bit beyond the standard is “use it or lose it”. Keeping track of which libraries and modules are actually in use and including only them is sometimes tedious, but keeping your entire toolset on every page is just sloppy.

Common lie of 21st century: just a few seconds remaining
Common lie of 21st century: just a few seconds remaining.

Recently, I’ve taken to keeping track of how much functionality I actually use once I include a library. And the tool I use most often is jQuery. Often I find that I’ve used just one or two functionalities (such as $.extend or $.ready), or even worse, that I’ve used it just to get elements by class or ID. Sometimes I leave it like that, other times I go back through the code to remove or decouple the dependency.

Wouldn’t it be neat if you could automatically analyze what and how much of a library has ended up being used and losing weight based on the results?

A lot of libraries and applications offer the option to customize the loadout before you start using it. But I keep having this feeling that it shouldn’t be too far out of our reach to standardize an automated “use it or lose it” build architecture in our libraries.

I have an allergy for the “include everything” approach. But using it in conjunction with such a functionality might turn the approach to something similar to a prototyping board: an overly flexible development tool that gets minified not only in syntax, but in actual functionality itself.

What would be required is a development only version of the library that would, through a unit test of dependant functionality, enable tracing of used features and outputting the minimal dependency or at least scale of utilization (such as asking have I included jQuery for 8% of its functionality or 80%). The dependency output could then be used to cherry-pick, aggregate, and minimize the output for production.

But What Can I Do About It?

First of all, engage the issue. Think about it, discuss it with your peers, and try to spot the issue in real world scenarios.

Try it out. Dig out that last-gen phone that you have stashed away in a drawer somewhere. Try using it on your own websites and check if the content is even remotely usable. Go visit some behind-the-times relatives out in the country and try being a tech evangelist to them. See if their lag in tech adoption is actually facilitated by accessibility issues.

If you’re a buyer commissioning a website, make sure to ask for (at least) a low level support on this issue. Remember: the goal is not to create a full port of all your features to low level devices. All that’s being asked is that those users get your contact information instead of their device crashing.

Set aside actual resources for this: the simplest solution for the issue shouldn’t take more than a day or two and some forward thinking. Do keep in mind the most basic reasons for making the website in the first place (let alone making a responsive site).

If you’re a package developer working on a library, framework, bundle, or any other embeddable software: you’re the one who can make the most difference here. If you can facilitate or incorporate these concepts into your platform, you’ll be affecting the whole landscape of web development. If you do incorporate it into your package design, let me know and I’ll evangelize for you.

And finally, **if you’re a developer or a designer**, don’t just stop at best practices. Always try to look just a little over that horizon. The hard work is on you to push these concepts that no one yet asked for, that are unsupported and undocumented for the benefit of your clients and users.

This article originally appeared in Toptal

Introduction to Responsive Web Design: Pseudo-Elements, Media Queries, and More

Nowadays, your website will be visited by a wide variety of devices: desktops with large monitors, mid-sized laptops, tablets, smartphones, and more.

To achieve an optimal user experience as a front-end engineer, your site should adjust its layout in response to these varied devices (i.e., to their varied screen resolutions and dimensions). The process of responding to the form of the user’s device is referred to as (you guessed it) responsive web design (RWD).

Why is it worth your time to study responsive web design examples and shift your focus to RWD? Some web designers, for example, instead make it their life’s work to ensure a stable user experience across all browsers, often spending days on end addressing small issues with Internet Explorer.

This is a foolish approach.

Some web designers spend days on end addressing small issues with Internet Explorer and leave their mobile users as second-hand visitors. This is a foolish approach.

Mashable called 2013 the year of responsive web design. Why? Over 30% of their traffic comes from mobile devices. They project that this number could reach 50% by the end of the year. Across the web in general, 17.4% of web traffic came from smartphones in 2013. At the same time, Internet Explorer usage, for example, accounts for just 12% of all browser traffic, down about 4% from this time last year (according to W3Schools). If you’re optimizing for a specific browser, rather than the global smartphone population, you’re missing the forest for the trees. And in some cases, this can mean the difference between success and failure—responsive design has implications for conversion rates, SEO, bounce rates, and more.

The Responsive Web Design Approach

What’s commonly glossed over about RWD is that it’s not just about adjusting the appearance of your webpages; instead, the focus should be on logically adapting your site for usage across different devices. For example: using the mouse does not provide the same user experience as, say, the touchscreen. Don’t you agree? Your responsive mobile vs. desktop layouts should reflect these differences.

At the same time, you don’t want to be completely rewriting your site for each of the tens of different screen sizes on which it might be viewed—such an approach is simply infeasible. Instead, the solution is to implement flexible responsive design elements that use the same HTML code to adjust to the user’s screen size.

From a technical point of view, the solution lies in this responsive design tutorial: using CSS media queries, pseudo-elements, flexible set grid layouts, and other tools to dynamically adjust to a given resolution.

Media Queries in Responsive Design

Media types first appeared in HTML4 and CSS2.1, which enabled the placement of separate CSS for screen and print. In this way, it was possible to set separate styles for a page’s computer display vis-à-vis its printout.

or

In CSS3, you can define styles depending on the page width. As page width correlates with the size of the user’s device, this capability thus allows you to define different layouts for different devices. Note: media queries are supported by all major browsers.

This definition is possible through the setting of basic properties: max-width, device-width, orientation, and color. Other definitions are possible as well; but in this, case the most important things to note are minimum resolution (width) and orientation settings (landscape vs. portrait).

The responsive CSS example below shows the procedure for initiating a certain CSS file with respect to the page width. For example, if 480px is the maximum resolution of the current device’s screen, then the styles defined in main_1.css will be applied.

We can also define different styles within the same CSS stylesheet such that they are only utilized if certain constraints are satisfied. For example, this portion of our responsive CSS would only be used if the current device had a width above 480px:

“Smart Zoom”

Mobile browsers use so-called “smart zoom” to provide users with a ‘superior’ reading experience. Basically, smart zoom is used to proportionally reduce page size. This can manifest itself in two ways: (1) user-initiated zoom (for example, tapping twice on an iPhone screen to zoom in on the current website), and (2) initially displaying a zoomed-in version of a web page on load.

Given that we can just use responsive media queries to solve any of the problems at which smart zoom might be targeted, it’s often desirable (or even necessary) to disable zoom and ensure that your page content always fills the browser:

By setting initial-scale to 1, we control the initial page zoom level (that is, the amount of zoom upon page load). If you’ve designed your web page to be responsive, then your fluid, dynamic layout should fill the smartphone screen in an intelligent way without requiring any initial zoom.

In addition, we can disable zoom completely with user-scalable=false.

Page Widths

Say you’re looking to provide three different responsive page layouts: one for desktops, one for tablets (or laptops), and one for smartphones. Which page dimensions should you target as your cutoffs (e.g., 480px)?

Unfortunately, there’s no defined standard for the page widths to target, but the following example responsive values are often used:

  • 320px
  • 480px
  • 600px
  • 768px
  • 900px
  • 1024px
  • 1200px

However, a number of different width definitions exist. For example, 320 and Up has five default CSS3 Media Query increments: 480, 600, 768, 992, and 1382px. Along with the given example in this responsive web development tutorial, I could enumerate at least ten other approaches.

With any of these reasonable sets of increments, you can target most devices. In practice, there is usually no need to separately handle all of the aforementioned examples of page widths—seven different resolutions is probably overkill. In my experience, 320px, 768px, and 1200px are the most commonly used; these three values should be sufficient for targeting smart phones, tablets/laptops, and desktops, respectively.

Psuedo-Elements

Building on top of your responsive media queries from the previous example, you also might want to show or hide certain information programatically based on the size of the user’s device. Luckily, this too can be accomplished with pure CSS as outlined in the tutorial below.

For starters, hiding some elements (display: none;) can be a great solution when it comes to reducing the number of on-screen elements for a smartphone layout, where there’s almost always insufficient space.

But beyond that, you can also get creative with CSS pseudo-elements (selectors), e.g., :before and :after. Note: once again, pseudo-elements are supported by all major browsers.

Pseudo-elements are used to apply specific styles to specific portions of an HTML element, or to select a certain subset of elements. For example, the :first-line pseudo-element lets you define styles solely on the first line a certain selector (e.g., p:first-line will apply to the first line of all ps). Similarly, the a:visited pseudo-element will let you define styles on all as with links previously visited by the user. Clearly, these can come in handy.

Here’s a simple responsive design example in which we create three different layouts for a login button, one apiece for desktop, tablet, and smartphone. On the smartphone, we’ll have a lone icon, while the tablet will have the same icon accompanied by “User name”. Finally, for the desktop, we’ll also add a short instructional message (“Insert your user name”).

Using just the :before and :after pseudo-elements, we achieve the following:

Psuedo Elements

This responsive CSS example depicts three versions of pseudo-elements.

For more on the magic of psuedo-elements, Chris Coyier has a good write-up on CSS-Tricks.

So, Where Should I Start?

In this tutorial, we’ve established some of the building blocks for responsive web design (i.e., media queries and pseudo-elements) and laid out some examples of each. Where do we go from here?

The first step you should take is to organize all of your webpage’s elements into various screen sizes.

So Where Should I Start

These responsive web design examples show the layout on different devices.

Take a look at the desktop version of the layout presented above. In this case, the content on the left (the green rectangle) could serve as some sort of main menu. But when devices with lower resolution are in-use (e.g., a tablet or smartphone), it might make sense for this main menu to be displayed in full width. With media queries, you could implement this behavior as follows:

Unfortunately, this basic approach is often insufficient as your front-end grows in complication. As a site’s content organization is often differs significantly between mobile and desktop versions, the user experience eventually depends on the use of not only responsive CSS, but also HTML and JavaScript.

When determining responsive layouts for different devices, several key elements are important. Unlike desktop versions where we have enough space for the content, smartphone development is more demanding. More than ever, it’s necessary to group specific contents and hierarchically define the importance of individual parts.

For a smartphone, it’s more important than ever to group specific contents and hierarchically define the importance of individual parts.
The various uses of your content are also important. For example, when your user has a mouse, they can set the cursor above certain elements to get more information, so you (as the web developer) can leave some information to-be gathered in this way—but this won’t be the case when your user is on a smartphone.

In addition, if you leave buttons on your site that then render on smartphones as smaller than a typical finger, you’ll create uncertainty in the usage and feeling of your site. Notice that in the image above, the standard web view (on the left) renders some elements completely unusable when viewed on a smaller device.

So Where Should I Start 2

Responsive design elements have to be usable with both mice and touch screens.

Such behavior will also increase the chances that your user makes an error, slowing down their experience. In practice, this can manifest itself as decreased page views, fewer sales, and less overall engagement.

Other Responsive Design Elements

When using media queries, one should keep in mind the behavior of all page elements, not just those that are being targeted, especially when using fluid grids, in which case (as opposed to fixed dimensions) the page will be fully filled at any given moment, increasing and decreasing content size proportionally. Since widths are set in percentages, graphical elements (i.e., images) can get distorted and mangled under such a fluid layout. For images, one solution is as follows:

Other elements should be dealt with in similar ways. For example, a great solution for icons in RWD is to use IconFonts.

A Few Words on Fluid Grid Systems

When we discuss the process of full design adaptation, we often look at optimal viewing experience (from the user’s perspective). Such a discussion should include maximum facilitated usage, element importance (based on visible page regions), facilitated reading, and intuitive navigation. Among these categories, one of the most important components is content width adjustment. For example, the so-called fluid grid systems have set elements, i.e., elements based on relative widths as percentages of the overall page. In this way, all elements in the responsive web design system automatically adjust with the size of the page.

Although these fluid grid systems are closely related to what we’ve been discussing here, they’re really a whole separate entity that would require an additional tutorial to discuss in detail. Therefore, I will just mention some major frameworks that support such behavior: Bootstrap, Unsemantic, and Brackets.

Conclusion

Until recently, website optimization was a term exclusively reserved for customization of functionality based on different web browsers. Alongside the inevitable struggle with different browser standards that we face today, this term now assumes adapting to devices and screen sizes with responsive web design as well. To cut it on the modern web, your site must know not only who’s viewing it, but how.

This article originally appeared in Toptal