Fluid ResponsiveDesign Philosophy

First published by : July 2017

Applying a Fluid Responsive philosophy makes development easy and offers additional opportunities for a great user experience across devices, and across viewports; even within emerging ('mobile-first') development frameworks such as Google's Accelerated Mobile Pages (AMP) project*.

Screen-size isn't important?
cartoon of supervisor using a ten inch tablet checking in a designer carrying a heavy forty inch tablet

* For an AMP balance also read the Register's Kill Google AMP before it KILLS the web article.

Shared Learning

Flag this content to your friends, connections, and colleagues.

Fluid Responsive?

Responsive Web Design (RWD) is a great methodology that may increase your effort; all those breakpoints that no longer corellate to device screens!

Fluid Responsive design is an approach to RWD and an additional philosophy. As the description suggests, it presents HTML dynamically according to the live-width of the viewport. RWD may only respond to the programmed breakpoints.

Lore states that:

  • HTML is for Content
  • CSS is for Presentation
  • JavaScript is for Function

The Lore is straight forward, but the approach and philosophy may blur the boundaries. JavaScript functions should support responsive behaviour, but should not style it. For example, JavaScript should write CSS Classes to the HTML, but should not write in-line CSS selectors, attributes or values to it. (I recognise my own habit as a jQuery newbie, and I am working to change it.)

Fixed, Fluid, or Responsive?
Term Definition
Fixed Width Layout The presentation is of one fixed width. As the viewport shrinks to less than the width of the presentation, the presentation outside the viewport will no longer be in view.
Fluid Layout The width of the layout is determined as a proportion of the viewport width; most commonly as a percentage. As the viewport shrinks, the presentation "squeezes" to fit it.
Responsive Web Design (RWD) The layout responds to programmed breakpoints (media queries or scripts) that detect the viewport width and trigger a specified change in the presentation to fit the viewport.
Fluid Responsive Layout As for RWD, the layout responds to programmed breakpoints (media queries or scripts) that detect the viewport width and trigger a specified change in the presentation to fit the viewport.

Additionally, relative element widths enable the presentation to respond to a changing viewport even between the programmed breakpoints.

Fluid Responsive presentation is a part of our usable presentation strategy. The use of relative heights and font sizes completes it. More on relative font and height sizing later...

A Brief History

80% of Internet consumption is reported to be via 'mobile' devices. The phrase of choice is now, Mobile First.

Table layouts only became redundant when CSS2 (c2000) facilitated percentage widths. Fluid layouts were possible and RWD, too by adding JavaScript breakpoints.

CSS3 recommendations (c2012) introduced Media Queries (to specify breakpoints). Fluid Responsive design became possible without JavaScript.

Still, we see digital design in fixed frames and our users experience on mobile devices can be shoddy, at best. And this isn't only amateur work or from WYSIWYG website building platforms (for amateurs and professionals), but from global digital content publishers.

It's 2017! We should move on. There are so many great HTML and CSS toys to play with: grids, viewport height and width units, and more...

Mobile First Methodology (and Mobile Only)

As HTML presentation technology and now even HTML evolves, so some tired scripting habits should devolve or expire. Fluid Responsive philosophy is the immediate future. Add the Mobile First methodology, and investment in Mobile Only - even some mobile apps - is just a waste of effort.

Mobile-First design is an approach to coding that enables an equal user experiences across devices. It is not a design methodology or Fluid Responsive philosophy. It serves the presentation to the smaller viewport first, and then to subsequent viewport sizes using breakpoints. The designer's approach to the visual design is immaterial. It is the coding that is 'Mobile First'.

Designers and engineers tend to follow fashion without fully understanding it. Fashions are often behind the pace of browsing technology, which has accelerated to meet a competitive consumer market. RWD and fixed layouts should for the most part be out. Fluid Responsive design is should be the mantra.

Even today, dated debate about "mobile only" websites still takes place with, "Mobile Friendly" confused with Mobile First. There is no need for a separate mobile only website if Mobile First methodologies combine within a Fluid Responsive philosophy? Mobile "apps" could benefit the same.


Fluid Responsive design is reactionary. The presentation updates according to the width and, or height of the viewport.

Media queries can apply to any allowed media type but in the case of the popular "screen" type, it is often misunderstood to mean the dimensions of the presentation device screen. This is not accurate. It is the size of the viewport. We can use a script to detect the device type, size, and orientation to adapt our presentation, too.

Screen Size v. Viewport
Term Definition
Screen Size The width and height of the physical device screen. It's maximum presentation area.
Viewport Size The width and height of the presentation provided by a software and only constrained by the screen size.

These definitions are important for designers to understand. A viewport can be adjusted by our user or their device's software, where a screen size cannot.

In the CSS3 recommendations, Media Queries can prescribe the presentation according to the maximum or minimum width of a viewport. Any number of Media Queries can be used. The more media queries there are however, the less fluid the responsive strategy?

Media queries for specific devices

Following Apple's iOS 8 release, targeting a viewport by screen size is a risky practice. Software now enables multiple applications to run in multiple viewports even on smaller device screens. Designing for specific device screensizes is no longer wise. Catch up!

A Viewport-Dependent Responsive Design Demonstration

This is an illustration of responsive design on a tablet device with two browser apps displaying in the viewport. (If you use a larger viewport, then you will experience an emulation using iFrames.)

Screen grab from iPad with two browser apps sharing the screen

Demonstrating this site's responsiveness using iFrames to embed the page. Adjust the viewport width to observe the effects. In smaller viewports the presentation updates to an image to avoid Safari IOS issues. If your browser stalls, then refresh its display.

Adaptive JavaScript adjuncts

The detection of a "mobile device" is useful in some adaptive circumstances. JavaScript can test what user agent is present to conclude which "mobile device" is being used and to inject CSS classes or attributes "on the fly".

The use of a script enables a fluid-responsive presentation in "desktop" browsers using CSS media queries while adapting it on-demand in "mobile device" presentations.

This site's JavaScript used to detect presentation on a "mobile device"

This article's Feedback Form is within a fluid-responsive container in "desktop" browsers and two CSS media queries to affect its height. The Typeform plugin's presentation on "mobile devices" is simplified so needs less headroom.

I have used a JavaScript function to test for common "mobile device" user agents. If the test proves positive for a "mobile device", then the Feedback Form's container's height is updated with a CSS attribute.

Note: the ideal is to add or remove CSS classes. I mean to do better. Using a relative height attribute will be an improvement, too...

//(From https://jstricks.com/detect-mobile-devices-javascript-jquery/)
	var isMobile = {
		Android: function() {
			return navigator.userAgent.match(/Android/i);
		BlackBerry: function() {
			return navigator.userAgent.match(/BlackBerry/i);
		any: function() {
			return (isMobile.Android() || isMobile.BlackBerry() || isMobile.iOS() || isMobile.Opera() || isMobile.Windows());
	if(isMobile.any()) {


Move beyond the constraints of a device. Respond as well as adapt.

Fluid Responsive design philosophy goes beyond the constraints of a device's screen. Applications may have menu bars and other chrome that compress the available presentation space (the viewport) to much less than the device screen dimensions. Our user can often adjust the size of the viewport too, even on smaller devices. The viewport is a result of software, not the device's screen width.

The over riding philosophy of Fluid Responsive design is to offer a meaningful presentation to our user no matter what viewport they are experiencing.

Semantic Layout

Fluid Responsive design encourages semantic HTML. Although discussed largely as a visual presentation strategy, we must remain vigilant to the needs of non-visual users. Accessibility and usability are our primary concern.

Caution: moving elements out of the semantic content flow with CSS or scripts may result in non-visual browser users receiving a confused message.

Bandwidth and Data Considerations

The philosophy may be extended to include protecting our user's bandwidth and data use. We can serve only the files required for their viewport and optimise them for the bandwidth and the expense of data metering.

Mobile First: Methodology of Choice

The Mobile First methodology is likely the safest and most future-proof approach given 80% of Internet content is consumed over 'mobile' devices.

If your users use desktop monitors exclusively, then the Mobile First philosophy may not be for you? However, if for example their facilitators rely on the mobility of a tablet, then you should follow the Mobile First methodology. As with anything in design, it depends.

Mobile First is the methodology of choice!

Relative Units Complete the Picture

Fluid Responsive design and Mobile First methodology needs an understanding of relative units such as the "em" and percentages for accessibility and usability.

Relatively scaled fonts, when our user scales texts up or uses 'zoom', may overfill elements that have fixed widths, or a y-axis scroll bar will be added where the copy cannot avail of a line break. Using relative units means, when our user increases the size of the font, all the text containing elements adjust accordingly.

Fluid Responsive designs must consider relative units.

Demonstration: Follow the instructions inspired by Alice in Wonderland. (If your browser becomes overwhelmed, then refresh the page.)

Eat Me  Drink Me

Fluid Responsive Examples

Page Layout






Close The Accordions

Converting Legacy Products

With only a little work, we can convert fixed-layout digital products to a Fluid Responsive presentation using a formula attributed to Ethan Marcotte: target ÷ context = result

This formula enables us to take an element's width in pixels and convert it into a percentage of the parent container width. For example, the container is 96% f the viewport width. This is the Context. The existing element to convert is 698px. This is the Target. The Context percentage can be made "fixed" at 960px - a leap of faith, but follow along for now. So, target ÷ context = result translates now to 698px ÷ 960px = 0.72708333.

Move the decimal point two places right, and our percentage width is 72.7083333%. We don't round up the answer as computers like to be accurate.

There's a little more to adjusting the design than this, but it's not impossible. Only doubt and disbelief make it difficult. You can read more about this technique in Ben Frain's excellent book, Responsive Web Design with HTML5 and CSS3, PACKT Publishing. Find the Second Edition on Amazon.

There really seems no reason why any platform, website, or app would not be Fluid Responsive? Yet, they are still out there!

Is your digital work Fluid Responsive? (If not, then let me at it!)

Responsive Frameworks

There are some great fluid-responsive frameworks that offer a low engineering solution and relatively low learning overhead. It's so easy to create your own framework be certain you know why to use them. Remember, just because some big companies do something doesn't mean it's right for you.

Popular frameworks include:

Our Own Grid Framework

We can employ a 12-column Fluid Responsive grid in our own CSS, which should keep most layout-perfectionists happy. Here's an underused example grid from this site's CSS.

Note: the media query is written following the Mobile-First methodology (min-width).

@media only screen and (min-width: 1200px) {
/* For larger devices: */
.col-1 {width: 8.33%;}
   .col-2 {width: 16.66%;}
   .col-3 {width: 25%;}
   .col-4 {width: 33.33%;}
   .col-5 {width: 41.66%;}
   .col-6 {width: 50%;}
   .col-7 {width: 58.33%;}
   .col-8 {width: 66.66%;}
   .col-9 {width: 75%;}
   .col-10 {width: 83.33%;}
   .col-11 {width: 91.66%;}
   .col-12 {width: 100%;}

Strengths and Weaknesses

There's every strength in adopting a Fluid-Responsive design philosophy and, where appropriate to the business, a Mobile First methodology.


  • Adaptive presentation to match our users' viewport
  • Ability to hide or disclose content according to the viewport size
  • May entirely remove the need for a separate "mobile app" channel
  • Encourages semantic HTML architecture and therefore improves accessibility and usability
  • Benefits digital publishing Lore: HTML for content, CSS for presentation, and JavaScript for functions.
  • A Mobile First methodology can restrict demands for bandwidth over metered connections
  • The same philosophy can serve retina-ready devices with images optimized for their displays
  • Promotes improved digital design. Period.


There are no weaknesses with the Fluid Responsive design philosophy. It saves effort, saves time, and saves money. It benefits our users and is more likely to meet standards for accessibility and usability.

The only weakness is with the designers and engineers: poor visual styling for cross-device use and over engineering where simple techniques are simply better.

Using relative units can challenge particularly print-based designers. Their pixel-perfect layouts get "broken" and they loose control. They should be reminded, placing the presentation closer to our users' control can only benefit their experience. Visual designers will fear "fugly", but must be reassured and also learn that Fluid Responsive design can be beautiful only with their support.

Designers tend to over-specify the Media Queries or scripted break points required. This is not a bad thing, but it may cause more effort, affect performance, and complicate our user's experience.

Engineers want to script everything. Perhaps they feel threatened by the opportunities HTML5 and CSS3 have given non-engineers? Reassure your engineers that Fluid Responsive implementation needs engineers more than ever to enable our designers to add those little extra "somethings" that turn a fluid presentation into a joy to use. And there's always their "back end" to look after..."

The Digital Paradigm

I am impatient with poor quality output delivered by vendors within the direction of clients lacking insight into the inclusivity of the digital paradigm.

Managers must step away from citing their, "Section 508 compliance", which too often excuses poor accessibility, usability, learnability, or usefulness. I am hopeful that 'Section 508' will be upgraded to W3C WCAG AA+ standards next year. Maybe then our US cousins can finally start to work for our users inclusively, and the European fashion followers will promulgate the same?


As with most UI, it depends. Test your solutions.

Consider your users and your digital product's environment. There are many, many benefits in using the Fluid Responsive design philosophy within your business and by extension, a Mobile First methodology, but there are also applications where it may prove less useful than a fixed layout presentation? I just can't think of any that design cannot overcome.

Reference this article

Godfrey, P. (Year, Month Day). Article Heading. Retrieved Month Day, Year, from URL

❮ More Articles My Profile ❯

Contribute to this article

Please add your comments.

The Facebook comments plugin failed to load

Facebook comments plug-in.

Sponsored Ads