Alternative to Media Queries

Media Query Use

Nowadays it's almost required to have the layout of a web page change to accommodate different devices. And it may be nice too to make the the web page layout adjust instantly to device changes (such as rotating from portrait orientation to landscape orientation). Changing on the fly like this requires quick changeovers to alternate chunks of CSS. Techniques for making web pages adapt to different devices coalesce under various rubrics: liquid layout or fluid layout or adaptive design or responsive design. When pointing different environments to different chunks of CSS, likely all that's needed is the CSS feature Media Queries.

Several different detailed strategies for handling varying devices are possible. Some strategies are mainly concerned with the size of the physical screen, while others are mainly concerned with the size of the logical viewport. Some strategies tightly restrict (or even try to eliminate) the viewport, while others control it only loosely (or even leave it entirely unconstrained). Regardless, all such strategies are likely to be implemented using Media Queries.

In theory, Media Queries can handle everything. The conventional wisdom seems to be that Media Queries are the best thing since sliced bread.

Problems With Media Queries

But when I started to use Media Queries extensively in real life, I discovered that as a practical matter they bring along quite a few issues. Media Queries can work quite well in environments -such as some corporate intranets- where the audience is either restricted to only the latest standards and browsers or is uniform (or both). But when websites are visited by the general public using a very wide range of browsers that should all be well supported, Media Queries become problematic.

Problems with Media Queries include:

• Older browsers (and even many fairly new browsers ...hello IE up through version 8) don't support Media Queries at all.
• Quite often instead of Media Query support being all-or-nothing, browsers support some individual Media Query statements but not others. For example some browsers support the window dimension queries (max-width, etc.), but not the screen dimension queries (max-device-width, etc.).
• Browser support for a query may even depend on which unit is requested. For example Media Queries for (min-resolution: Ndpi) may be supported while the very similar (min-resolution: Ndppx) is not.
• Support often depends on context. Some browsers support Media Queries in HTML (on on the <link tag and the <style tag) but not inside a single style sheet (on the @media ... statement), while some other browsers support Media Queries on @media ... statements but not in HTML.
• Dimensions can be quite misleading, mainly because of vastly different pixel densities. (This isn't a problem with Media Queries per-se, which are just reporting what they're told. The problem is it's very easy to be misled by naive Media Queries, and so produce a hodge-podge that works for some but not others.) A couple examples: some newer smartphones report higher dimensions than some older tablets, and some newer tablets report higher dimensions than most older desktops! Even after using meta...viewport... to constrain the viewport, Media Queries should usually include density as well as dimensions.
• Support for newer CSS units is spotty. For example vw has recently been defined throughout CSS as the viewport width in pixels. But just because a browser supports (min-width: Npx) doesn't mean it also supports (min-width: Nvw).
• There's no straightforward way for code to determine on the fly whether or not a particular Media Query is supported by the browser.
• Property names are not formed consistently. For example some browsers require property names of the form (-vendor-max-property: ...) while others require the form (max--vendor-property: ...) for the same thing.
• If a Media Query contains any error -including not only a gross misspelling of a property name but even a single character typo- the whole query fails silently, making the error rather difficult to pinpoint.
• Media Queries are inconsistent about whether a closely related query has a different property name or a different unit. For example, when moving from window to screen, the property name changes (min-width to min-device-width). But when moving from window to viewport, the units change (Npx to Nvw).
• Media Query tests inevitably overlap. The min test always implements greater than or equal ( >= ) while the max test always implements less than or equal ( <= ) - so a device right on the dividing line will follow the equals paths into both categories. (This problem can be finessed for those units -such as pixels- that only come in whole numbers. But the problem remains for other units -such as inches- that come with some unknown number of significant digits after a decimal point.)
• If the size is modified by a meta...viewport... statement, it's not always clear whether Media Queries work on the unmodified size, the modified size, or sometimes one sometimes the other depending on the timing.
• Media Query syntax is more variable than I would wish. Many browsers will accept things like (min-width: 80px), but some browsers require the same thing to be spelled out more precisely like only screen and (min-width: 80px).
• There's an awful lot of vendor-specific variation in the names of properties to be tested. For example some browsers respond only to queries of vendor-defined properties like (-webkit-min-pixel-ratio: 1), some respond only to queries of standardized properties like (min-resolution: 1dppx), and some respond to both.
• The number of significant digits after the decimal point is not clear. For example, is 1.543cm different from 1.54cm, or not?
• Some browsers are finicky about whether the specified number is a single number with a decimal point (like 1.5) or a ratio of two integers (like 3/2), possibly depending on whether or not the property name includes the word ratio.
• If a Media Query is present where a browser doesn't support it, it's not always clear what the default action will be. (Usually in HTML unsupported Media Queries are simply ignored as though they were always true, while the exact same Media Queries inside a style sheet usually exclude whole blocks of CSS as though those Media Queries were always false.
• The verbose Media Query syntax makes complex decisions so difficult to express they're often just avoided.
• When Media Queries are used to enable the relevant CSS and disable the rest of the CSS, all the CSS must be downloaded, even though much of it will never be used. This is true no matter whether there are separate style sheet files, or a single style sheet with @media {...} blocks. (This is not caused by the Media Queries, but it is something to be aware of.)
• Media Queries don't help at all to clean up the density mess. The difference between dpi and dip can be important, and Media Queries don't change that. It's often muddled whether the d in a unit stands for a dot or a device-independent pixel, and Media Queries don't change that. The behavior of the non-standardized viewport feature varies quite a bit, and Media Queries don't hide that variability (although they may help to cope with it). The definition of device pixel ratio is not well standardized (for example since density 1 is referenced to 160 dots per inch, many desktops -which typically have only about 96-120 dots per inch- should in theory be considered low-resolution devices and reported as having a device pixel ratio of 0.75, but in fact the usual convention is for browsers to report 1 rather than 0.75 for all desktops), and Media Queries don't change that either.

(This was written in Fall 2012. Technology has marched on. Some of the problems listed above [largely related to browser support] have gone away, and current programming practices easily avoid many others.)

An Alternative Approach

I find trying to deal with all these issues with only the non-procedural specifications of HTML/CSS awfully frustrating. I'm confident that if I could just write a program, I could skirt the majority of these problems. If only I could move my CSS decisions into some procedural language (i.e. any computer language with at least a conditional statement and a looping construct).

But that sounds like a tool that's already in use on most websites: Javascript! Instead of different <link statements each being enabled or disabled by Media Queries, Javascript could create just the one <link statement that was exactly right for each situation, then insert it into the webpage using ordinary DOM manipulation techniques.

This alternate approach of using Javascript rather than Media Queries is more than just simple to implement. It's very flexible, and it can handle complex logic that would be quite difficult to express as Media Queries.

Several Media Query equivalent shims written in Javascript to support browsers that don't have the needed Media Queries are readily available. But my experience is these are sufficiently limited and obscure that in the long run support is broader and maintenance is easier if you just create your own Javascript tailored to your own environment.

An obvious problem with this alternative approach is visiting browsers that don't support Javascript or that have Javascript turned off. Given the relative ubiquity of Javascript support in browsers, the widespread use of AJAX, and the ready availability of security precautions more sophisiticated than just completely disabling Javascript for all sites, it's probably safe to assume that almost all visitors provide Javascript. Still, it's prudent to arrange your CSS in such a way that if the code doesn't run at all and the visitor gets only the base CSS, the website will still be readable and usable. This arrangement of CSS is somewhat more important if you're using Javascript than if you're using plain old Media Queries, but you will have already arranged your CSS this way anyway if support for smaller older (i.e. slow and dumb) handhelds is important to you.

A Detailed Specific Example

Here's a specific example. Please note that:

• The goal of this code is to first determine the actual physical size of the screen, and then provide an appropriate layout.
• This code is intended to function on a very wide variety of browsers.
• This code builds on CSS that was already sectioned so every device used at most two style sheets - the common stylesheet plus just one size-specific stylesheet, with handheld devices and the fallback/default using only the base common style sheet.

The general approach of using Javascript rather than Media Queries to get the right CSS to each browser will always remain, even though the specific code for other environments may appear quite different.

This particular example is concerned exclusively with the size of the physical screen (not the logical or virtual or viewport size). This particular example assumes the viewport feature has already been controlled (probably by particular parameters on a meta...viewport... statement). However the general approach (depending on Javascript rather than Media Queries) does not depend on this assumption; it applies equally to other strategies, such as those mainly concerned with the unconstrained viewport size.

This example code neither requires nor interferes with the possible use of cookies.

The specific densities, dimensions and aspect ratios hard coded in this example code are all magic numbers, determined by methods not discussed here. Supposedly they do a good job of distinguishing different categories of device. You may or may not wish to use these same specific numbers.

Several tricks for supporting the widest possible range of browers are embedded in this example code but not discussed in any detail. Also, this code may have been optimized to the point of not being immediately fully comprehensible. So depending on what your goal is, you may wish to analyze this example code rather closely. Of course, it's assumed that for actual production use, similar code will be minified and compressed.

Although I have not actually tested either the defer or async attributes of the <script tag with this example code, I expect they would not work reliably with some browsers.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>...</title>
<meta name="viewport" content="width=device-width">
<!--   ...   -->
<link href="common.css" rel="stylesheet" type="text/css">
<script type="text/javascript">
	/* our ultimate goal here is to determine the physical size of the device, 
	    so we can then specify different layouts for the different sizes 
	    HOWEVER doing this is somewhat tricky, because:
	    a) even after the logical "viewport" has been controlled,
	       two devices of the same physical size can have wildly different
	      "px" dimensions because of different densities
	    b) the CSS "inch" metric is _not_ useful for this purpose, as the
	      "CSS inch" is _defined_ as 96 pixels, and so may be very different
	      from what one would measure with a ruler
	   so to determine size with any accuracy, we first need to determine density,
	    either as "dots per inch" (a physical metric, 
	    closer to what a ruler would report than "pixels per inch"), 
	    or as the density ratio of "dots per inch" to "pixels per inch" 
	   then we can go on to determine the size
	   and finally specify loading of the one needed CSS file for that size
	*/


	function formatvalue(numerator, denominator, propertyname) {
		/* this routine formats a value either as a real (decimal) number with 
		    finite precision, or as a ratio (fraction) of integers,
		    as appropriate to the query
		   its parameters must be in terms of a ratio of integers, 
		    because converting ratio->real whenever necessary is simple, 
		    but converting real->ratio whenever necessary would be more difficult
		*/
		/* (this function works quickly and lightly by assuming that the 
		    "propertyname" argument is all lower case - if "propertyname" 
		    contains upper case characters, it may not work right)
		*/
		/* both numerator and denominator assumed always non-zero,
		    else another line of code would be needed 
		    to return correct results no matter what */
		if (propertyname.indexOf('ratio') >= 0) return(numerator + '/' + denominator);
		else return((numerator/denominator).toFixed(2));
	}


	var i, j = 0, k, l = 0;
	/* indices for loops etc., 
	    in the end these encode the intermediate and final results
	   note we _assume_ these are never out of range nor negative when read,
	    which will be true in the code that follows, but may not be true 
	    and so cause bad behavior if portions of this code are transplanted 
	    without sufficient care
	   i == index which density resolution test works, reversed (0 => no usable query supported):
	    resolution(dppx), resolution(dpi), -webkit-device-resolution,
	    -moz-device-resolution, -o-device-resolution, none 
	   j == resolution as determined, reversed (0 => could not determine density):
	    2+/xhi, 1.5/hi, 1/med, 0.75/lo, ?/no
	   k == breakpoints:
	    minimum px for unknown size, minimum px for size tablet, 
	    minimum px for size desktop, minimum px for size widescreen,
	    minimum px for size widescreen if aspect ratio is clearly elongated
	   l == determined size category (0 => no additional CSS file needed):
	    handheld/default, tablet, desktop, widescreen
	*/

	/* try to get devicePixelRatio either by calculating it from Javascript vars (if possible),
	    or taking it directly from a Javascript variable (if available),
	    or else from the matchMedia(...) function (if available)
	    (the relatively new matchMedia(...) function provides easy access
	    to arbitrary Media Queries from within Javascript) */ 
	if (screen.deviceXDPI) {
		var dPI = screen.deviceXDPI;
		/* dPI is just a shortcut temporary variable with a very short name */
		j=1;
		/* just the existence of any non-zero screen.deviceXDPI variable
		    sets the default density to "lo-res" (rather than "no-res") */
		if (dPI > 120) j = 2;
		if (dPI > 200) j = 3;
		if (dPI > 280) j = 4;
	} else if (window.devicePixelRatio) { /* density-from-Javascript variable exists and is not zero */
		/* ("screen.devicePixelRatio" seems more sensible than "window.devicePixelRatio"
		     ...but we have to play the hand we're dealt */
		/* "i" is not set on this path, as we don't need it to determine "j" this way */
		var dPR = window.devicePixelRatio;
		/* dPR is just a temporary variable to avoid retyping a long name several times*/
		j = 1; 	
		/* just the existence of any non-zero window.devicePixelRatio variable
		    sets the default density to at least "lo-res" (rather than "no-res") */
		if (dPR >= 1) j = 2;
		if (dPR >= 1.5) j = 3;
		if (dPR >= 2) j = 4;
		/* note order of statememts above is intentional/necessary, 
		    as higher density resolutions overwrite lower
		    so the result is the highest density class that matches */
		/* also note all values >2 (such as 2.25) will be treated as 2 */
	} else if (typeof window.matchMedia === 'function') {
		/* find out which query is supported by asking silly questions
		    that we know always have positive answers, so we can confidently
		    interpret a negative answer as "query not supported"
		   exit loop on first hit 
		    (more important/common queries are tested first) */
		var properties = [ '', '-o-min-device-pixel-ratio', 'min--moz-device-pixel-ratio',
		 '-webkit-min-device-pixel-ratio', 'min-resolution', 'min-resolution' ];
		var scales = [ 0, 1, 1, 1, 160, 1 ];
		/* variable "scales" pre-converts queries from "dpi" to "dppx" */
		var units = [ '', '', '', '', 'dpi', 'dppx' ];
		/* the above three arrays together (they make no sense separately)
		    define possible media queries we might use 
		    (just one identical index is used into all three) */
		for (i=5; i>0; --i) {
			if (window.matchMedia('only all and (' + properties[i] + ': ' +
			 formatvalue(scales[i], 10, properties[i]) + units[i] + ')').matches) break;
		}
		/* if no hit, i will be 0 when loop exited */
		if (i) {
			/* find out device density resolution by executing several queries,
			    combining the supported property name we found above with different values */
			var numerators = [ 0, 3, 1, 3, 2 ];
			var denominators = [ 1, 4, 1, 2, 1 ];
			/* the above two arrays together (they make no sense 
			    separately) define the conventional device density 
			    resolutions (0, 0.75, 1, 1.5, 2) as fractions */
			for (j=4; j>0; --j) {
				if (window.matchMedia('only all and (' + properties[i] + ': ' +
				 formatvalue(scales[i]*numerators[j], denominators[j], properties[i]) + units[i] + ')').matches) break;
			}
			/* if no hit, j will be 0 when loop exited */
		}
		/* the case of (!i) [i===0] is already handled by having initialized j = 0 
		    so the default value is already right in this case */
	}

	/* density -> breakpoints */
	k = [ [493, 987, 1481, 1281], [296, 592, 888, 769], [493, 987, 1481, 1281],
	 [740, 1481, 2221, 1921], [987, 1974, 2962, 2562] ][j];
	/* the above breakpoints are specified by the user to provide the 
	    desired behavioral results ...they are not calculated here, 
	    and they don't make any sense in any "abstract" way */
	var scrwid = screen.width;
	var scrhit = screen.height;
	if (window.outerWidth && window.outerHeight && (window.outerWidth <= (scrwid/2)) && (window.outerHeight <= (scrhit/2))) {
		/* apparently "meta...viewport..." exists but isn't applied yet
		    and so the screen dimensions are incorrect,
		    but correct screen dimensions are available elsewhere anyway */
		scrwid = window.outerWidth;
		scrhit = window.outerHeight;
	}
	var scrasp = (scrwid/scrhit).toFixed(2);
	/* use our specified breakpoints to figure out the index of the size category
	    (i.e. of the required CSSfilename) 
	   (the tests below are in essence the logic of "our media queries"
	    ...except expressed in a more succinct way and as Javascript) */
	if (scrwid >= k[0]) l = 1;
	if (scrwid >= k[1]) l = 2;
	if (scrwid >= k[2]) l = 3;
	if ((scrwid >= k[3]) && (scrasp >= 1.67)) l = 3;

	/* create the correct HTML and insert it into the DOM
	    (this could also be done with the old -obsolete?- "document.writeln") */
	if (l) {
		var headEls = document.getElementsByTagName('head');
		var newEl = document.createElement('link');
		if (headEls && newEl) {
			/* if the DOM is not fully supported, we can't do this so easily,
			    so instead just fail silently and present the "default" style */
			newEl.type = 'text/css';
			newEl.rel = 'stylesheet';
			newEl.href = ['','tablet','desktop','widescreen'][l] + '.css';
			headEls[0].appendChild(newEl);
		}
	}
</script>
</head>
<body>
<!--   ...   -->
</body>
</html>

Caveat - Unchanging Properties Only

Some of the properties that Media Queries can test may change as the user manipulates the browser. For example window size and device orientation (portrait or landscape) may change. Other properties that Media Queries can test don't ever change on a given device. They are properties of the device itself. For example screen size and pixel density never change.

The above specific example (and probably this whole technique) is applicable only to properties that never change (i.e device properties). Since it works only with unchanging properties, it can correctly be done only once before the page displays, then never done again.

Media-Query-like tests of properties that might change must be redone every time the browser signals a possible shift (i.e whenever it fires the onresize event). It's not immediately clear how to modify the specific example above so it can be redone. In fact, it's not even clear this alternative to Media Queries can be used at all with properties that might change.

(I don't find this to be a significant limitation, becase in my opinion responsive design should only be testing and responding to unchanging/device properties anyway. I personally think if the page layout changes when the user grows or shrinks the window on the same device, something is wrong. But not everyone shares that opinion. And no such limitation is intrinsic to the way CSS Media Queries are specified or implemented.)

Sequence of Events

The desired sequence of events, where each step completes before the next one begins, is:

1. Execute Javascript to select CSS.
2. Load and/or activate the selected CSS.
3. Go through the HTML <body>, parsing it, laying it out, constructing the DOM tree, and painting (displaying) it on the screen.

To force events to hew to this sequence, yet not reduce performance terribly, requires a few tricks. These are all done by the specific example above, but that may not be immediately obvious:

• Put the Javascript code that selects the CSS in the <head>. (For best performance most Javascript is placed in the <body> ...even at the very end of the <body>. But the Javascript that selects the CSS will not work right if placed there.)
• If at all possible, specify the Javascript that selects the CSS inline rather than as a separate file. If you must specify the Javascript in a separate file, at least do not use the defer attribute.
• Insert the DOM element to download the correct CSS at the end of the <head>.
   (This assumes the <head> portion of the DOM can be safely manipulated by Javascript code also in the <head> as soon as it's parsed, even before the full DOM tree is ready. This assumption is apparently true for all versions of all known browsers that support DOM manipulation at all.)
   (A possible alternative to adding a DOM element is to include a dummy <link... element in your HTML that loads an empty CSS file, then use Javascript to change the href= attribute of that element.)

(Note that a few alternate sequences of events will seem to more or less work anyway. These cases are ultimately undesirable and should be avoided because the user will see a flash of unstyled or incorrectly styled content when the page first loads.)