With each passing month, the priority to provide responsive layouts grows. Every new project I find myself bumping responsive views for mobile devices higher on the priority list, which means I’ve had the chance to evolve my approach.

Lately my favorite approach is to build responsive device-based layouts at the same time I build the normal desktop layout. I focus on a singular view or flow, and design each of the responsive layouts at that point in time. This is in contrast to building the entire application for one specific layout type (e.g. desktop min-width 1024px) then starting over again with the next layout type, and so on.

For example, I will take the login process and design/build all responsive layouts at the same moment before I move on to the reset password flow.

My main reasoning is catalyst. It forces me to think of responsive options and build them right away instead of telling myself I’ll come back to it. I do come back—I’m not lazy per se—but I tend to forget some of the deep thoughts and learning moments I had when designing the first layout option.

But I admit that may not be the optimal reason to decide on a responsive approach. I’m eager to learn more and watch my perspective evolve. So far my latest projects have been of the personal nature. I have yet to approach responsive layout design at a production level. My perspective may change due to code optimization concerns and speed of development. My colleagues might have insights or needs that alter my approach too. Perhaps after a while, I’ll discover something better.

Within D3.js, you can customize axises fairly effortlessly by using the SVG Axis methods. I found them to be ineffective when trying to format the X axis for a stacked bar graph, however. I later realized it was because the SVG Axis library will not target ordinal scales, but only linear scales.

While scouring Stack Overflow, Google Groups, and whatever my search queries would produce, I found nothing but custom work-arounds. So Matt Stockton and I had to come up with our own. We went with targetting the .text() method of an SVG element. By accessing the data (d) and loop iteration (i), we could write a heuristic that customizes frequency and format similar to SVG Axis.

Often times a heuristic like that is an excellent work around.

I’m going to walk through a curious bug IE has had for quite some time relating to relatively positioned parents. Upon retrospect, this is a solved problem. Brunildo has two good examples. I wanted to work through the problem by myself, though, to make sure I understood its implications.

In short, this bug exists when one attempts to position an absolute element inside of a relative parent. This trick has existed a very long time. Simply make the parent relatively positioned, and the child will position itself absolutely to it, rather than the body (or any other parent with position relative).

With older versions of Internet Explorer, the child doesn’t act as expected. In the image below, I have three divs structured like so:

/* css */
#container {
	position: relative;
}
#main_col {
	margin-left: 100px;
}
#sub_col {
	position: absolute;
	top: 0;
	left: 0;
	width: 100px;
}

<!--html-->
<div id="container">
	<div id="sub_col">sub</div>
	<div id="main_col">main</div>
</div>

The sub div is not in the upper left of the container. Odd behavior.

This relates to hasLayout, an important understanding about IE. Learn about it here.

So let’s try adding hasLayout to the two inner divs. Our updated CSS:

/* css */
#container {
	position: relative;
}
#main_col {
	margin-left: 100px;
	height: 100px;
}
#sub_col {
	position: absolute;
	top: 0;
	left: 0;
	width: 100px;
	height: 50px;
}

The result:

The result did not change. The real fix is adding hasLayout to the containing, relatively positioned parent. Our updated CSS:

/* css */
#container { 
	position: relative;
	height: 150px;
}
#main_col {
	margin-left: 100px;
	height: 100px;
}
#sub_col {
	position: absolute;
	top: 0;
	left: 0;
	width: 100px;
	height: 50px;
}

And the final image:

Height isn’t necessarily the route to go to fix the parent’s woes. Many other hasLayout tricks exist, so it’s up to you to work with what’s best for your project.