Responsive fluid multi-column layouts – with a responsive horizontal menu bar – IV

In the previous articles of this series

Responsive fluid multi-column layouts – the DIV order problem – I
Responsive fluid multi-column layouts – the DIV order problem – II
Responsive fluid multi-column layouts – the DIV order problem – III

I described how we can control HTML div order problems which may interfere with a simple, efficient approach to make a 3 column fluid layout responsive to the viewport width. I regard this topic as sufficiently covered: By planning the HTML code and its DIV order properly we can make responsiveness a matter of changing just a few CSS properties (like float) for defined viewport width ranges in our CSS code. Small CSS tricks restore the optical layout if we have to choose a special and unusual DIV order of (horizontally) floated or relatively positioned DIV containers in the HTML code for achieving a specific vertical element order after a responsive transformation.

Nevertheless, I do not want to close this article series about responsive layouts without looking into methods for a more suitable handling of the horizontal main menu. Actually, up to now we did not care about the main menu at all. The floated menu points just move downwards over several rows if the viewport width gets to small to display the menu in just one line.

Some people may find such an approach uneconomical, looking weird and not at all a professional solution for small viewport widths, e.g. on a smartphone. For a real responsive (horizontal) menu the wide spread expectation is that the whole menu collapses at small viewport widths – in parallel to the vertical reordering of major page areas.

In this and the next article we shall have a look at some options how to achieve a better responsive menu control – without and with Javascript.

Objectives for an originally horizontal main menu at small viewport widths

In the second article of this series we defined 3 viewport width ranges. “Range I” stands for small viewport widths which may be typical for smartphones. In this range the main menu would only be interesting if the user really needs it – otherwise it consumes too much of the limited screen area and may enforce unnecessary scrolling.

Therefore, it is reasonable to collapse the horizontal menu to a button (with a reasonable menu symbol) within Range I. This is exactly what e.g. many wordpress designs and other web tools do: Below a certain width threshold menus are reduced to symbols with button functionality. A click on such a button would open the main menu – now with vertically listed menu points as we do not have much width available. A second click on the button – and/or other actions which we need to discuss – would close the menu again.

This description seems to imply that Javascript [JS] is required for a convenient handling of a collapsed menu. More precisely: for a convenient dealing with user induced GUI-events for some specific elements of our web page. Therefore the following question is of major interest: What alternatives do exist for users who have deactivated Javascript?

In this article we concentrate one a JS-free approach. Some readers may not find the suggested solution convenient enough; but the efforts in this article to build a flexible horizontal menu which gets collapsed are not at all in vain – all HTML and CSS code can and will be used almost unchanged in a JS-based solution. See a forthcoming article for this.

Restructuring the horizontal menu on the HTML level

The
horizontal menu as we described it in the previous articles was set up in a most simply way: It was just a list with floated elements – positioned on the left side in its container “div#head” due to defaults. The CSS statements offered no options to center the menu or put it on the left or right side of the page. However, such options – in the form of easily changeable CSS properties – may be important in certain web layouts. In addition we need a “menu button” which shall be displayed for small viewport width. Two good reasons for restructuring the main menu a bit …

The new HTML code for the container “div#head” appears much more complex than in the previous articles – but you will understand the advantages of the DIV nesting in a minute.

HTML code for the horizontal main menu

<body onload="init_page();">
<div id="all">
	<div id="head">
		<div id="main_menu_cont">
			<div id="bg_hor_menu"></div>
			<div id="menu_cont">
				<a id="hmen_but" title="main menu" href="#"></a>
				<div id="hmen_cont" class="hmen_cont">
					<div id="bg_ver_menu"></div>
					<ul id="menu_lst">
						<li><div class="hmen_pkt"><p><a href="#">h-menu 1</a></p></div></li>
						<li><div class="hmen_pkt"><p><a href="#">h-menu 2</a></p></div></li>
						<li><div class="hmen_pkt"><p><a href="#">h-menu 3</a></p></div></li>
						<li><div class="hmen_pkt"><p><a href="#">h-menu 4</a></p></div></li>
						<li><div class="hmen_pkt"><p><a href="#">h-menu 5</a></p></div></li>
						<li class="hm_li_right"><div class="hmen_pkt"><a id="but2" href="#"></a></div></li>
						<li class="floatstop"></li>
					</ul>
				</div>
			</div>
			<p class="floatstop"> </p>
		</div>
	</div>
....
....
</div>
....
....

 
We encapsulate our menu now inside the main container “div#main_menu_cont” and supply a background element “div#bg_hor_menu” which allows for a full control of background and opacity effects in a “horizontal header line”.

Note: In the following CSS strategy this horizontal header line which comprises the menu outside width range I will still be shown when we collapse the menu contents.

To decouple the menu itself from the “header line” we introduce a second inner container “div#menu_cont”. It shall server 2 purposes:

  • It will help us to gain control about centering the menu – a list of points – inside the horizontal menu line despite a missing explicit definition of the menu width.
  • It is also required to control the interaction of the user with the menu for small viewport widths when Javascript is not available. This will become clear in some minutes.

“div#menu_cont” encloses the real content stuff of the menu for all width ranges. Among its new elements is a “menu button” – more precisely: a block A-tag “a#hmen_but” – which up to now has no functionality – and shall only be visible in viewport width Range I. As a matter of fact, in the JS-free solution we do NOT assign any functionality to this button – but instead to its container “div#menu_cont”! See below.

The container “div#hmen_cont” encloses in addition

  • a relatively positioned list “ul#menu_list”, which contains the floated menu points (LI-tags)
  • and an absolutely positioned “div#bg_menu” for controlling background effects (color, opacity) for the possibly horizontally centered and later on vertically displayed menu.

Note that in our test example the width of the menu list and also of “div#hmen_cont” will not be defined explicitly for viewport widths outside of Range I: The browser has to evaluate the menu width from the widths of its listed elements.

Centering the menu in the header line

The following CSS excerpt makes clear how we achieve a centering of the menu list in the header line.

....
....
/* The header region */	
/* *******************/

div#head { 
	position:relative; 
	width:100%; 
	min-height: 3.0rem;
	z-index: 6; 
}

/* The main contents container */
/* *************************** */
	
div#outer_cont { 
	position:relative; 
	width:100%; 
	min-height: 10.0rem;
	margin-top:1.0rem;
	z-index: 1; 
}
....
....	
/* Support elements */ 	

p.floatstop {
	clear:both;
	height:0;
	margin:0;
	line-height:0;
	padding: 0;
	font-size: 0;
}


/* contents of the upper horizontal menu */
/*-------------------------------------- */

div#main_menu_cont {
	display: block; 
	position: relative;
	width: auto;   
	margin-left: 1.0rem; 
	margin-right: 1.0rem; 
	min-height: 3.0rem;
}

div#bg_hor_menu {
	display:block; 
	position: absolute; 
	top: 0;
	bottom: 0;
	left: 0; 
	right: 0; 
	border-radius: 0.8rem;
	background-color: #FFF; 
	opacity: 0.75; 
	z-index: 1; 
}

div#menu_cont {
	display: block; 
	position: relative;
	float:right; 
	width: 100%;  
	min-height: 3.0rem;
	z-index: 2; 
	
	/* helps to center its enclosed container */
	text-align: center; 
}

a#hmen_but {
	display: none; 
	width: 4.6rem;
	height: 2.2rem;
	margin-top:0.2rem; 
	background-color: #A90000;
	border-top: 0.2rem #CCC solid; 
	border-right: 0.2rem #CCC solid; 
	border-left: 0.2rem #AAA solid; 
	border-bottom: 0.2rem #AAA solid; 
}

div.hmen_cont {
	position: relative;
	
	/* display: block; */  
	
	/* makes horizontal centering possible despite undefined width */
	display: inline-block; 
	
	min-height: 3.0rem;
	
	/* A second method of centering - optically determined by the viewport width */
	/*
	width: auto;
	margin-right:0.8rem;
	margin-left:0.8rem;
	*/
	
	border-radius: 1.0rem;
	
	/* centers the enclosed list ! */
	text-align: center; 
}

div#bg_menu {
	display:block; 
	position: absolute; 
	top: 0;
	bottom: 0;
	left: 0; 
	right: 0; 
	border-radius: 0.8rem;
	background-color: #FFF; 
	opacity: 1.0; 
	z-index: 1; 
}

div.hmen_cont ul {
	position: relative;
	
	/* makes horizontal centering possible despite undefined width */
	display: inline-block;
	list-style-type: none;
	/*width: 100%;*/
	margin: 0;
	padding: 0;
	padding-left: 0.4rem;
	padding-right: 0.4rem;
	z-index:2;
}

div.hmen_cont ul li, 
div.hmen_cont ul li.hm_li_left,
div.hmen_cont ul li.hm_li_right {
	float: left;
	padding: 0.2rem 4.0rem 0.2rem 4.0rem;
	margin:0; 
	margin-top:0.2rem;
	height: 2.2rem;
	/*border-left: #ffffff 1px solid;*/
	border-right: #a90000 0.2rem solid;
	min-height: 2.0rem;
	font-size: 1.6rem;
}

div.hmen_cont ul li.hm_li_left {
	border-left: #a90000 0.2rem solid;
}	
div.hmen_cont ul li.hm_li_right {
	border-right: 0; 
}	
	
div.hmen_cont ul li.floatstop {
	float:none;
	clear:both;
	height:0; 
	min-height: 0;
	margin:0;
	line-height:0;
	padding: 0;
	font-size: 0;
	border:0;
}

div.hmen_cont ul li a, 
div.hmen_cont ul li a:visited  {
	text-decoration: none;
 
	color: #000; 
}

div.hmen_cont ul li a:hover {
	color: #A90000; 
	background-color: #FFFFBB; 
}

a#but2 {
	display: block;
	width: 1.6rem;
	height: 1.6rem;
	background-color: #A90000;
	border-top: 0.2rem #CCC solid; 
	border-right: 0.2rem #CCC solid; 
	border-left: 0.2rem #AAA solid; 
	border-bottom: 0.2rem #AAA solid; 
}

 
Note that the new layer “div#menu_cont” is floated in its enclosing container “div#main_menu_cont”. This was done due to convenience reasons. In course of the transition to Range I we shall reduce the width of “div#menu_cont” and position it on the right side of the horizontal menu line. This is easily achieved by floating. If we wanted it to collapse to the left side in Range I we would just change the float direction. Thus floating “div#menu_cont” gives us a bit of positioning freedom whenever we should need it. As long as we set the width to “100%” outside Range I we do not need to take care of any centering of “div#menu_cont” there.

Note that we blend out the menu button (via “display:none;”) – as long as we are not in Range I (see below). The dimensions of the block A-tag will become important in Range I.

How exactly do we do the centering for the menu contents?
As the width of “ul#menu_lst” is undefined, we cannot use the usual trick with “margin-left:auto; margin-right:auto;”. Instead we need declare the block-element “ul#menu_lst” as an inline element via “display: inline-block;”. After this the CSS property “text-align:center;” of the enclosing container “div#hmen_cont” does its job.

Now the UL-tag is centered in its container. But “div#hmen_cont” has no defined width either. We therefore extend and cascade this type of centering one level higher – and declare also “div#hmen_cont” itself to be an “inline-block” element in its container “div#menu_cont”.

However, there are other possibilities to center dynamically on this outer tag-level:
One possibility could be to declare “div#hmen_cont” as a normal block element, but to set both its “margin-left” and its “margin-right” property to one and the same value. Then the visible width of “div#hmen_cont” and its background element “div#bg_menu” would become independent of the width of “ul#menu_lst”. Instead, the viewport width would determine the visible menu width. Such a centering would, however, not obstruct a further inner centering of the UL-tag within a wider “div#hmen_cont”! Try it out!

Note that instead of centering we could also move the menu containers to the right or left in their enclosing containers by using the property “text-align”. A bit of abstraction and combining different options on the 2 container levels will give us even more options to adapt to different optical layouts requested by our customers. The introduced intermediate containers open up for variety of centered and non-centered layouts of the horizontal menu.

For our next discussion points we shall only follow the line of a full centering. An impression of the resulting menu in Range III can be seen on the following picture.

responsive7

A transitional option to handle the horizontal menu

What about viewport widths between a typical desktop width of more than 1000 pixels and small viewport width around 400 to 500? In such an intermediate width range it is reasonable to first use the available space a bit better than just collapsing the menu directly. How you would adjust the width of each menu point depends of course on the way how you distributed them:

In our test example the original width of the horizontal menu was defined
by some “padding“-definitions for each the floated “LI”-tags in the horizontal menu (see the CSS above or in the last article). Therefore, an intermediate step could be to reduce the values for horizontal padding substantially when the viewport width shrinks below a threshold:

/* @media screen decision and settings for the horizontal menu */
@media screen and (max-width : 860px) {
	div.hmen_cont ul li {
		padding: 0.2rem 1.2rem 0.2rem 1.2rem;
	}
} 

In our test case this actually helps until the final transition to smallest viewport widths of Range I occurs:

responsive8

and

responsive9
 
Some warnings:
What looks nice in the pictures actually depends in real web layouts on a proper choice of the width threshold for the transition to smaller padding-values – we want to shrink the padding-values only when the menu width gets too big for the available viewport width. But the menu width in our example depends in turn mainly on the font settings for the page, e.g.:

@CHARSET "UTF-8";

html {
	font-size:10px;
}

body {
	margin-left:0; 
	margin-right:0;
	margin-top: 0; 
	background-image: url(../image/hg_straa_mp.jpg);
	background-repeat:no-repeat; 
	background-position:top center;
	
	font-family: Arial; 
}

p { 
	font-size: 1.4rem; 
	line-height: 1.6rem;
	margin: 0;
}

 
Therefore, setting a proper width threshold for which the responsive transition to smaller padding-values shall occur also depends on the chosen font – and under worst circumstances also on font settings for the user’s browser. You see: some effort and testing for different fonts (especially for Google fonts if Android devices are the target client) is waiting for you. (At least if you do not want to depend on Javascript. JS would give you many more possibilities to analyze the situation dynamically.)

As a side effect we again see that a container policy with expandable containers in height is extremely important in responsive designs …. (we followed such a policy so far): If a browser replaced our carefully chosen fonts by some strange font and the available horizontal space got too small then we still had a fallback: We would display the menu with several rows without disturbing the rest of our page. The next pic shows a provoked situation of this type:

responsive10

You should at least follow the rule: Always set the threshold width for shrinking the distance between menu elements with some safety margins in mind! Already some slight differences in the display of fonts may lead to different behaviors of different browsers! Always test your responsiveness for a font which is set with relatively wide letters (like Verdana) first to be on the safe side.

Furthermore: In more realistic cases than our test example you may need additional thresholds and related successive padding- and/or margin-adjustments. Note that due to automatic margin-/padding-settings for list elements
in some browsers you may have to set margin-values explicitly in addition to controlling the menu width.

How to make a horizontal menu responsive ? Some general alternatives …

The general choices for dealing with a horizontal menu in responsive layouts are in my opinion:

  • Solution 1:Allow for horizontal menus with two or more lines in a certain viewport width range.
  • Solution 2:Adjust the width of the menu elements of a horizontal main menu – by reducing padding/margin-definitions or by introducing percentage widths of the menu elements – below certain viewport width thresholds.
  • Solution 3:Collapse the horizontal menu to a button below a defined viewport width threshold (without or with Javascript support for mouse interactions with the button).
  • Solution 4:Change from a horizontal to a vertical menu and position it properly.

The first solution was shown in the last articles. The second solution was briefly presented above.

At some point of the viewport width, however, you probably want and need to collapse the whole menu. The resulting menu button would then be attached to a vertical menu area whose visibility is controlled by mouse interactions with the button. This means that solution 3 is directly connected with solution 4. However, option 4 could in some cases (i.e. for Javascript free solutions) also be used as a totally independent solution.

After this overview we now concentrate on a collapse solution with a button in our defined viewport width “Range I” – without making use of Javascript [JS].

Collapsing the main menu to a button without Javascript support

A JS free solution may be useful for people who have JS deactivated. Although, without click-events on a button-like element it may be a bit more difficult to control the touch screen interaction with smartphones and tablet-PCs.

Fortunately, the browser developers for smartphones have understood this. E.g. both Firefox and Chrome for Android translate “rollover” events into something very similar to pure “click”-events. Therefore, the following solution should work even in browsers for (Android) smartphones:

CSS statements for a collapsing menu with remote rollover

/* @media screen decision and settings for the horizontal menu */
	
@media screen and (max-width : 860px) {
	
	div.hmen_cont ul li, 
	div.hmen_cont ul li.hm_li_left,
	div.hmen_cont ul li.hm_li_right
	 {
		padding: 0.2rem 1.2rem 0.2rem 1.2rem;
	}
} 
.....
.....

/* @media screen decision and settings for range I */
/* ----------------------------------------------- */

@media screen and (max-width : 539px)  {
....
.....    
	/*
	* Treatment of the horizontal menu 
	*/
	
	div#bg_hor_menu {
		opacity: 1.0;
	}
	

	div#menu_cont {
		margin-right: 4.0rem; 
		width: 5.0rem;  /* button size ! */
		height: 3.0rem;
	}
	
	a#hmen_but {
		display: block; 
	}


	div#menu_cont:hover div.hmen_cont {
		visibility: visible; 
	}
	
	
	div.hmen_cont {
		position: absolute;
		visibility:hidden; 
		top:3.0rem;
		right:0; 
		min-height: 3.0rem;
		
		width: auto;
		min-width: 18.4rem;
		max-width: 25.0rem;
		
		margin-right:0rem;
		margin-left:auto;
		
		padding: 0.8rem; 
		
		background-color: #DDD;
		border-radius: 1.0rem;
		
		text-align: left; 
	}
	
	div#bg_menu {
		background-color: #DDD;
		opacity: 1.0;  
	}
	
	
	div.hmen_cont ul {
		position: relative;
		list-style-type: none;
		width: 
auto;
		margin: 0;
		padding: 0;
	}
	
	div.hmen_cont ul li, 
	div.hmen_cont ul li.hm_li_left,
	div.hmen_cont ul li.hm_li_right {
		float: none;
		padding: 0.2rem 0.4rem 0.2rem 0.8rem;
		width:auto;
		/*border-left: #ffffff 1px solid;*/
		border-right: #a90000 0.0rem solid;
		min-height: 2.0rem;
		font-size: 1.6rem;
	}
		
	div.hmen_cont ul li.floatstop {
		float:none;
	}

	div.hmen_cont ul li p {
		margin-top:0; 
		line-height: 1.6rem; 
	
	}

}    

/* extreme case - reached e.g. by Ctrl + */
@media screen and (max-width : 260px)  {
	div#menu_cont {
		margin-right: 4.0rem; 
	}
	
	div.hmen_cont {
		right: -4.0rem;
		width: auto; 
		min-width: 0; 
	}
	
	div#bg_menu {
		background-color: #DDD;  
	}
	
}	

 
The horizontal menu line “div#main_menu_cont” and the enclosed background DIV “div#bg_hor_menu” remain visible in all viewport width ranges. But with the transition to Range I we give up the centering and collapse the menu instead. This is done by a sequence of measures:

  • In Range I we make the menu button “a#hmen_but” visible. (In our example just a simple red button).
  • The dimensions of “div#menu_cont” are collapsed down to the size of the menu button. The (floated) container is moved a defined distance away from the right border of its container by setting a right-margin.
  • The menu container “div#hmen_cont” is optically hidden (via: “visibilty:hidden;”)
  • The menu container “div#hmen_cont” gets an absolute position, a minimum and a maximum width. The maximum width is required to enforce line wrapping for long menu points and is adjusted to a further viewport shrinking via an additional width threshold condition.
  • Color and opacity of the menus background layer are adjusted such that the menu region will clearly be visible above other layers. In z-direction the visibility on top of other layers is already guaranteed by the high z-index value assigned to div#head (see above).
  • Floating of the list elements is stopped. This gives us a vertical list of menu points.
  • We define a further width threshold and adjust properties of “div#hmen_cont” for extremely small viewport widths.

Note: The situation of an extreme small viewport width can be provoked in 2 ways in a browser:

  • Firstly by reducing the physical width of the browser window.
  • Secondly via a relative rescaling of the basic font size and adjusting all elements. This happens “Ctrl +” is used in a browser – i.e. by the zooming functionality of the browser in connection with our “rem” CSS-scaling of all dimensions. Everything is recalculated then with relative factors. And relative to the increased font-size the viewport width goes down. So the browser initiates the defined transitions.

The second possibility is the reason why we have to guarantee a reasonable behavior of our web page for even extreme small viewport widths. This explains our final safety transition: @media screen and (max-width : 260px) {}.

The next picture shows our “collapsed” menu in form of a pure button in viewport width Range I:

responsive11

Triggering the visibility of the menu after the collapse to a button – without JS

The reader may have asked already: How shall a user get access to the new vertical menu which is set to “visibility:hidden;
” in Range I? To achieve this we use a simple “trick” called “remote rollover”:

We move the mouse over an element and another element at a very different position reacts to this rollover. Our “div#menu_cont” and its logically enclosed “div#hmen_cont” provide a typical example:

div#menu_cont:hover div.hmen_cont {
		visibility: visible; 
	}

 
The pseudo class “:hover” of an container element may trigger CSS properties of an enclosed (absolutely positioned) element at an optical different position. In our case the hover triggers the visibility of its enclosed and now absolutely positioned container div.hmen_cont. The hover actually occurs on all visible elements of the container – independent of where they are located. So, if we could move the mouse from the area of “div#menu_cont” directly into the visible area of “div#hmen_cont” without moving outside one of these containers the triggered visibility of “div#hmen_cont” will sustain. Firefox and Chrome realize this CSS feature properly – so we can use it here.

The next picture gives you an impression of the “rollover” effect:
responsive12

Exactly what we wanted to achieve. You may also test in Firefox or Chrome that the button and the vertical menu really are vertically “connected” despite the little optical vertical gap between them:

You can move the mouse from the button vertically down into the menu below without loosing contact and visibility. Once visible the lower area remains so if we move the mouse vertically downward in a channel of the button width. This is due to the fact that the upper edge of “div#hmen_cont” seamlessly touches the lower edge of “div#menu_cont”. [If you really wanted or needed a major and visible vertical distance between the two Divs: This can be achieved by introducing a transparent, properly dimensioned and absolutely positioned bridge element, i.e. an additional more or less transparent and absolutely positioned DIV inside “div#menu_cont”.]

However, as soon as the mouse in our example leaves either the area of the button or the area of the still visible menu then the visibility of the menu is lost. So, to make the menu disappear again the user just has to move the mouse outside the connected visible areas of the “menu button” and the menu itself.

What happens in a smartphone browser? See the picture for an Android 5 smartphone in horizontal orientation with relatively low resolution.

IMG_quer

OK – range II is chosen. Now what about the button behavior? We rotate the smartphone:

hoch_ohne_menu

At least in FF or Chrome you can just press your finger (similar to a “click”) on our menu button – and our vertical menu region will appear.

hoch_mit_menu

Then you can “click” on any menu point – the menu remains visible. To make the menu disappear the user just
has to “click” – i.e. press the finger – on some page area outside the button or the displayed menu. Nice, isn’t it?

Again a warning:
Although this is a fully functional solution a normal user will find it unusual or even frustrating that a second click on the red button does not hide the menu again. Without JS we unfortunately have no remedy for this. And the page gets not unusable.

Still: We have reached our main objectives. So far, we have only used CSS – no Javascript at all. Nevertheless we have realized a menu collapse with a rollover functionality throughout our responsive viewport width transition.

Of course you can use all the little tricks discussed above also for (left sided) submenus. We come back to this point in a later article of this series.

Alternatives?

There is always the trivial alternative for users who have deactivated JS to transform the menu into a permanently visible vertical menu – but with a “position:relative;” inside the then expanding header line. Such a solution would be very similar to what we did with the left sided menu in the last article. We do not need to show code examples. Such a solution would, however, consume even the same or more space at the top of the web page than a simple floating solution with several menu lines. Its only advantage over a floating solution is that it may look a bit more organized.

A supplemental hint regarding scrollbars

All our main relatively positioned containers scale with the viewport width due to a setting of “position:relative; width: 100%;”.
This may not be the case in realistic layouts. If you have a layout where the main page elements do not expand with the viewport above a certain width threshold, but have a maximum width instead, you should always use the following CSS setting

width: 100%;
max-width: your_max_width_value;

and not just

width: your_max_width_value; /* above the threshold */

for all outmost containers inside the body and where necessary also for enclosed elements. Do not forget to do this also for images which shall be scaled below a width threshold set for the named max-width of the elements.)

This type of setting is required to give the browser a chance to deal in a reasonable way with vertical scrollbars and a restructuring of the page elements when the scrollbar is displayed. Note that the viewport width includes the width scrollbar to be displayed. I.e. the scrollbar is part of the viewport. So changes of page elements during responsive transitions may only occur when the distance between the left browser edge and the right outer (!) edge of the scrollbar fits to the viewport width threshold value. So some elements may be covered and hidden by the scrollbar before the CSS statements below the width threshold get operative.

Therefore, if you just switch the CSS properties for containers to “width: 100%;” below the width threshold a vertical and an additional (superfluous) horizontal scrollbar may appear. If you instead use the given definition above only the vertical scrollbar will appear because the browser then can rearrange the displayed contents as soon as the vertical scrollbar appears and even when it moves inside the width threshold.

Conclusion

Even without JS a solution is achievable with a collapsed menu at small viewport widths. It is fully functional though maybe not exactly how the user may expect it.

In the forthcoming article


Responsive fluid multi-column layouts – main menu control with JS/jQuery and font-size adaption –
V

we shall discuss how we introduce some simple Javascript functionality into the menu handling.

Responsive fluid multi-column layouts – the DIV order problem – III

In the previous articles of this series

Responsive fluid multi-column layouts – the DIV order problem – I
Responsive fluid multi-column layouts – the DIV order problem – II

we discussed a problem that may arise when you want to make a fluid design responsive.

In order

  • to both use a fluid design with multiple content columns in horizontal direction and
  • and to control the vertical heights of optical background elements for the different columns

you need to encapsulate floated page elements in a container.

Such floated content elements could be a vertical navigation column, a main information block with text and a right column with teaser text elements. In your HTML code you would define and describe the tags of the floated container elements in just this natural sequence. The CSS properties of the containers require no special attention – everything is straightforward. However, the natural tag order may lead to conflicts when you want to reposition the column like page elements in a fluid and additionally responsive approach to our multi-column layout.

Typically, in a responsive approach you rearrange the content columns into a vertical order instead of the original horizontal sequence, because you want to make use of a maximum of the view port width for each of the information and navigation containers. For reasons of coding efficiency the vertical rearrangement of previously horizontally distributed containers should be achieved just by changing some CSS properties like “position”, “margin” or “float” when the view port gets smaller than some predefined values. Under normal circumstances you do NOT want to create major HTML block elements twice and switch them alternately on and off just to become responsive.

For getting the right vertical ordering effect you would e.g. make use of the automatic handling of floated elements by the browser for situations when the horizontal viewport space gets too small for displaying all floated elements in just one row. In such a situation, however, the last tag (of the sequence of floated elements) in the code represents the element which is moved downwards in the browser’s viewport first.

In the second article of this series we therefore discussed a special situation for which we required a specific vertical reordering of existing elements. We showed how we could re-nest and rearrange the DIV-container tags into the required code order – without changing the original optical and fluid layout. Of course we had to compensate by more complicated CSS definitions.

Among other things we used negative margin definitions to optically place floated elements where we needed them to be on the screen – despite an unusual tag position in the HTML code. With a bit of abstraction the discussed recipe will in general allow for any required tag order for the DIV-containers in the code. What we have achieved is that by using some compensating CSS tricks we can now choose a certain – unusual, but in a responsive context required – tag order in the HTML code without destroying the optical features and the fluidity of our multi-column page layout.

We have demonstrated how to handle a first responsive transition in viewport width by moving one of the columns downward and adapt our content areas in width – without loosing fluidity. In the last article we also discussed some additional, conventional measures to make the different content column blocks appear as separate optical elements floating above a common background (picture).

We have, however, not yet shown how to manage a second – and more
important – transition to a range of significant smaller view port widths. For small view port widths we would like to move our left sided vertical menu directly below the text area – an objective we had already defined in the first article and which will be met by the measures discussed in the present article.

We shall see in this article that our achievements now allow for almost trivial measures to gain the correct aspired responsiveness: You just need to change a few “float” and “margin” properties.

To make everything a bit more challenging we shall also show how one can add transparent background layers to each column of the original fluid layout and how we manage such transparency layers together with responsive width adaptions of the web page.

Extending the HTML code by tags for transparency layers

We firstly define DIV containers which serve us as transparent background stripes of all column elements of our fluid design. To be able to keep up the transparency during a later responsive element reordering we need to insert such background layer (DIV) elements

  • into the defined outmost container “div#outer_cont” and the additionally introduced internally nested container “div#main_cont”,
  • and as well as into each of the floated DIV-elements representing the text column blocks.

Due to some simple CSS rules already presented in the previous articles the absolutely positioned background layers will adapt automatically to the height of their encapsulating DIV containers (via “position: absolute; top:0; bottom:0;” settings).

The height of the encapsulating containers is in turn dynamically defined by the maximum height of their enclosed relatively positioned, but floated text containers – i.e. according to the available horizontal space, the text content length and the height of other enclosed inner elements.

The modified HTML code is here:

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>fluid standard 2</title>
<link href="css/fluid_standard2.css" rel="stylesheet">
</head>

<body>
<!-- 3 spalten layout -->
<div id="all">
	<div id="head">
		<div id="hmen_knapp_cont" class="hmen_knapp_cont">
			<a id="hmen_knapp"></a>
		</div>
		<div id="hmen_cont" class="hmen_cont">
			<ul>
				<li><div class="hmen_pkt">h-menu 1</div></li>
				<li><div class="hmen_pkt">h-menu 2</div></li>
				<li><div class="hmen_pkt">h-menu 3</div></li>
				<li><div class="hmen_pkt">h-menu 4</div></li>
				<li><div class="hmen_pkt">h-menu 5</div></li>
				<li><div class="hmen_pkt"><a id="but2" href="#"></a></div></li>
				<li class="floatstop"></li>
			</ul>
		</div>
	</div>
	
	<div id="outer_cont">
		<div id="bg_left0"></div>
		<div id="bg_right0">
			<!-- do not remove ! -->
			<div id="bg_right_inner0"></div>
		</div>
		<div id="bg_info0"></div>
		
		<div id="float_cont">
			<div id="main_cont">
				<div id="bg_left1"></div>
				<div id="bg_info1"></div>
				
				<div id="info_cont">
					<div id="float_info">
						<div id="bg_info2"></div>
						<div 
id="info"> 
							<p>Lorem ipsum .....</p>
							<p> </p>
							<p>Lorem ipsum ....</p>
							<p> </p>
							<p>This is the end, my friend<br> </p>
						</div>
					</div>
					<div id="left_nav">
						<div id="bg_left2"></div>
						<div id="left_inner">
							<ul>
								<li><p><a href="#">sub menu point 1</a></p></li>
								<li><p><a href="#">sub menu point 2</a></p></li>
								<li><p><a href="#">sub menu point 3</a></p></li>
							</ul>
						</div>
					</div>
					<p class="floatstop"> </p>
				</div>
			</div>
			
			<div id="right">
				<div id="bg_right2"></div>
				<div id="right_inner">
					<p>Some stupid text - just to show something</p>
					<p> </p>
					<p>Some stupid text - just to show something</p>
					<p>Some stupid text - just to show something</p>
				</div>
			</div> 
			
			<p class="floatstop"> </p>

		</div>
	</div>
</div>
</body>
</html>

 
Note: If you want to test our example in some smartphone do not forget a reasonable meta-tag like

<meta name=”viewport” content=”width=device-width, initial-scale=1″>

to the header of the HTML file. You may adapt the metatag given in the above code to your needs. For more information see e.g.:
https://css-tricks.com/snippets/html/responsive-meta-tag/

The reader may have noticed that we have changed some element names in comparison to the HTML code discussed in the last article – but this not be a big obstacle as we kept up the basic tag nesting structure.

The multiple defined internal background layers (bg_left0, bg_left1, bg_left2, bg_info0, bg_info1, bg_info2, bg_right0, bg_right2) MUST be switched/on off at certain width values for the viewport. See below.

Extending the CSS definitions to cover a second transition of the view port width – and transparency effects

We need to adapt the CSS definitions to handle the transparency layers properly – for all view port width transitions. In the 1st article we had defined 3 ranges of view port widths – therefore we have to cover 2 transitions. In the last article we have shown the definitions for the first transition from Range III to Range II.

In addition, we now need to take care of a second width transition from Range II to Range I. At this second transition we want to move the left sided menu area downwards – right below the main text area and on top of the originally right column area (see the 2nd article). All 3 text areas ( i.e. our original columns) shall use all the width of the view port – we only leave small border areas transparent.

You find the necessary, adapted CSS definitions here:

@CHARSET "UTF-8";

html {
	font-size:10px;
}

body {
	margin-left:0; 
	margin-right:0;
	margin-top: 0; 
	background-image: url(../image/hg_straa_mp.jpg);
	background-repeat:no-repeat; 
	background-position:top center;
}

p { 
	font-size: 1.6rem; 
	line-height: 1.4;
	margin: 0;
}
	

div#all { 
	position:relative; 
	width:100%; 
	padding-bottom: 1.0rem;
	padding-top: 1.0rem;

}

/* The header region */	

div#head { 
	position:relative; 
	width:100%; 
	min-
height: 3.0rem;
}

/* The main contents container */
/* *************************** */
	
div#outer_cont { 
	position:relative; 
	width:100%; 
	min-height: 10.0rem;
	margin-top:1.0rem;
}
	

/* some elementary width definitions */
/* --------------------------------  */
div#left_nav, 
div#bg_left0, 
div#bg_left1  {
	width: 14rem;
}

div#left_nav {
	margin-left: 1.0rem;
	
}

div#right,
div#bg_right0 {
	width: 27%;
}


/* background elements for all columns in range I */

div#bg_left0, 
div#bg_left1,
div#bg_left2,
div#bg_right0,
div#bg_right_inner0,
div#bg_right2,
div#bg_info0,
div#bg_info1,
div#bg_info2  {
	position: absolute;
	top:0;
	bottom:0;
	border-radius: 0.8rem;
}

div#bg_left0 {
	left:1.0rem;
	background-color: #FFF;
	opacity: 0.5;
	border: 0px solid #F00;
	z-index:1;
}

div#bg_info0 {
	position: absolute;
	left:16.0rem;
	right:27%; 
	background-color: #FFF;
	opacity: 0.85;
	border: 0px solid #00F;
	z-index:1;
}

div#bg_right0 {
	right: 0;
	border: 0px solid #F00;
	z-index:1;
}

div#bg_right_inner0 {
	left: 1.0rem;
	right: 1.0rem;
	background-color: #FEEEBB;
	opacity:0.80;
}



	
/* The float container and its basic elements */	
/* ****************************************** */

div#float_cont { 
	position:relative; 
	width: 100%; 
	border: 0px solid #FF0000;
	z-index:5;
}

/* floated left main container and 
 * its background elements for range II*/

div#main_cont { 
	position: relative;
	float: left; 
	width:100%;
	min-height: 2.0rem;
	border: 0px solid #009900;
	z-index:1;
}


div#bg_left1 {
	display: none;     
	left:1.0rem;
	background-color: #FFF;
	opacity: 0.75;
	border: 0px solid #F00;
	z-index:1;
}

div#bg_info1 {
	display: none; 
	left:16.0rem;
	right:1.0rem; 
	background-color: #FFF;
	opacity: 0.9;
	border: 0px solid #00F;
	z-index:1;
}



/* The main column */
/* --------------- */


div#info_cont {
	position: relative; 
	width:100%; 
	border:0px #F00 solid;
}

div#float_info { 
	position:relative; 
	float:left;
	width: 100%; 
	/*background-color: #99e;*/ 
	border: 0px solid #FF0000;
	z-index:2;
}


div#info { 
	position: relative; 
	margin: 0 27% 0 16rem;
	width:auto;
	/*background-color: #0f0;*/ 
	padding:0.8rem;
	/*height:200px;*/
	z-index: 1;
}

div#bg_info2 {
	display: none; 
	left:1.0rem;
	right:1.0rem; 
	background-color: #FFB;
	background-color: #FFF;
	opacity: 0.95;
	border: 0px solid #00F;
	z-index:1;
}




/* left column */
/* ----------- */

div#left_nav { 
	position:relative; 
	float:left;
	border: 0px solid #009900;
	margin-left: -100%;
	padding-left: 1.0rem;
	z-index:5;
}

div#left_inner {
	position: relative; 
	width:auto;
	padding: 0.8rem;
	z-index: 2; 
}

div#bg_left2 {
	display: none;     
	left:1.0rem;
	right:1.0rem; 
	border: 0px solid #F00;
	background-color: #FFF;
	opacity: 0.9;
	z-index:1; 
}



/* right column */
/* ------------ */

div#right { 
	float:left;
	position:relative; 
	margin-left: -27%;
	min-height: 2.0rem;
	/*min-width: 15.2rem;*/ 
	/*background-color: #eee;*/ 
	border: 0px solid #009900;
	z-index:2;
}

div#right_inner {
	position:relative;
	width:auto;
	margin-left: 1.0rem;
	margin-right: 1.0rem;
	padding: 0.8rem;
	z-index: 2;
}

div#bg_right2 {
	display: none;     
	left:1.0rem;
	right:1.0rem; 
	border: 0px solid #F00;
	background-color: #FEEEBB;
	opacity: 0.85;
	z-index:1; 
}



/* Support elements */ 	

p.floatstop {
	clear:both;
	height:0;
	margin:
0;
	line-height:0;
	padding: 0;
	font-size: 0;
}



/* contents of the upper horizontal menu */

div.hmen_cont {
	display: block; 
	position: relative;
	min-height: 3.0rem;
	width: auto;
	margin-right:0.8rem;
	margin-left:0.8rem;
	background-color: #EEE;
	border-radius: 1.0rem;
}

div.hmen_cont ul {
	position: relative;
	list-style-type: none;
	width: 100%;
	margin: 0;
	padding: 0;
}

div.hmen_cont ul li {
	float: left;
	padding: 0.2rem 4.0rem 0.2rem 4.0rem;
	/*border-left: #ffffff 1px solid;*/
	border-right: #a90000 0.2rem solid;
	min-height: 2.0rem;
	font-size: 1.6rem;
}
	
div.hmen_cont ul li.floatstop {
	float:none;
	clear:both;
	min-height: 0;
	margin:0;
	line-height:0;
	padding: 0;
	font-size: 0;
}

div#hmen_knapp_cont {
	display: none;
	position: absolute;
	right:0;
	top:10px;
	width: 50%;
	height: 2.4rem;
	border: 1px #A90000 solid;
}

a#hmen_knapp {
	display: block;
	width: 100%;
	height: 100%;
	background-color: #009999;		
}

a#but2 {
	display: block;
	width: 1.8rem;
	height: 1.8rem;
	background-color: #A90000;
	border-top: 0.2rem #CCC solid; 
	border-right: 0.2rem #CCC solid; 
	border-left: 0.2rem #AAA solid; 
	border-bottom: 0.2rem #AAA solid; 
}



/* contents of the left vertical menu */

#left_inner ul {
	width:100%;
	min-height: 2.2rem;
	list-style-type: none;
	padding: 0;
	margin: 0;
}

#left_inner ul li {
	width:100%; 
}

#left_inner ul li a, 
#left_inner ul li a:visited {
	color: #990000;
	
}
#left_inner ul li a:hover {
	color: #FFF;     
}
    
    
/* ---------------------------------------------- */    
    

/* @media screen decision and settings for range II */

@media screen and (min-width : 540px) and (max-width :828px) {
    
	div#info { 
		margin: 0 2.0rem 0 16rem;
		background-color:transparent;
	}
   
	div#right { 
		float:left;
		margin-top:1.0rem;
		margin-left: 0;
		margin-right: 0; 
		width:100%;
	 }
    
	div#right_inner {
		margin-left: 1.0rem; 
		margin-right: 1.0rem;
		width: auto; 
		/* background-color: #FEEEBB; */
		border-radius: 0.8rem;
	}
    
	/*
	 * Switch OFF backgrounds after 1st viewport width transition 
	 */
	div#bg_left0 {
		display: none;  
	}
	div#bg_info0 {
		display:none;  
	}
	div#bg_right0 {
		display: none; 
	}
    
    
	 /*
	  * Switch ON backgrounds after first viewport width transition 
	 */
	 
	 div#bg_left1 { 
		display: block; 
	 } 
	   
	 div#bg_info1 { 
		display: block; 
	 }
	 div#bg_right2 { 
		display: block; 
		opacity: 0.9;
	 }

}


    
/* ---------------------------------------------- */    
    

/* @media screen decision and settings for range I */


@media screen and (max-width : 539px)  {
    
	
	div#info { 
		margin: 0 1.0rem 0 1.0rem;
		/* background-color: #FFB; */
		border-radius: 0.8rem;
	}
	
	
	div#left_nav { 
		margin-top:1.0rem;
		margin-left: 0;
		width:100%;
		padding:0;
	}
	  
	div#left_inner {
		width:auto;
		padding: 0.8rem;
		margin: 0 1.0rem 0 1.0rem;
		/*  background-color: #DDDDDD; */
		border-radius: 0.8rem;
		z-index: 2; 
	}
	
	div#right { 
		float:left;
		margin-top:1.0rem;
		margin-left: 0;
		margin-right: 0; 
		width:100%;
	 }
	
	div#right_inner {
		margin-left: 1.0rem; 
		margin-right: 1.0rem;
		width: auto; 
		/* background-color: #FEEEBB;*/
		border-radius: 0.8rem;
	}


   
	/*
	 * Switch OFF backgrounds after 2nd viewport width transition 
	 */
	
	div#bg_info0 { 
		display: none; 
	 }
	div#bg_info1 { 
		display: none; 
	 }
	 
	div#bg_right0 {
		display: 
none;  
	}
	 
	div#bg_left0 {
		display: none; 
	}
	div#bg_left1 { 
		display: none; 
	}   
	
	/*
	 * Switch ON backgrounds after 2nd viewport width transition 
	*/
	div#bg_info2 { 
		display: block; 
		opacity: 0.95; 
	}
	div#bg_left2 { 
		display: block; 
		opacity: 0.95; 
	}   
	div#bg_right2 { 
		display: block; 
		opacity:0.9; 
	}

}    

 

Before we discuss some details let us look at the visual results:

Range III: Starting point
responsive1

Range III: Fluidity when reducing viewport width
responsive3

Range II: Move the rightmost column to the bottom
responsive4

Range I: Move the leftmost column right below the text box and over the initially right column
responsive5

A closer look may reveal that we changed the transparency a bit during the transitions between the viewport width ranges.

Some CSS hints

We switch some of the transparency layers off and on during the range transitions by using the “display” property. This is somewhat saver than just changing the visibility.

As soon as a major content element is moved downwards during a responsive action we switch off the corresponding background element in its encapsulating container. Instead, we switch on the respective background layer in that container which becomes relevant for the correct height of the background layer after the vertical repositioning.

Thus, in Range III bg_left0, bg_info0, bg_right0 are the active background layers. In Range II, however, we use
bg_left1, bg_info1 and bg_right2. In Range I we activate the innermost layers bg_left2, bg_info2, bg_right2.

The height of these absolutely positioned background containers layers is defined by the height of their outer encapsulating container. The height of the latter is defined by the highest of its inner relatively positioned content containers. This type of indirect height control of absolutely positioned layers via relatively positioned boxes on the same code level inside one and the same encapsulating container is basic CSS2.

The transition between Range II and Range I is done by mainly 2 adaptions in the section

@media screen and (max-width : 539px) {}

of the CSS code:

  • We adapt the margins of “div#info” to a full extension over the viewport width -i.e by setting both “margin-left” and “margin-right” to small values. ( Small values to keep some optical distance of the contents to the viewport edges …). This change of margins is already enough to vertically reposition “div#left_nav” if we at the same time change the property “left-margin” of “div#left_nav” (from -100%) to zero.
  • n

  • We set the width of “div#left_nav” to 100%.

Pretty simple, isn’t it?

All the rest is cosmetics. Note, that the opacity values are adapted during the transitions, too. Such an adaption may be helpful if elements of the background image started to disturb the readability of your text during the repositioning of the web page’s text containers.

What if we had wanted to move the left sided navigation column above the main text box in Range I?

This is a relevant question. But after what we have learned so far the answer is extremely trivial. So, I leave this up to the reader.

Addendum 25.08.2015:
As I got a question regarding this point I give a hint. The most simple solution builds on the following steps: Change the tag order of the floated “div#left_nav” and “div#float_info” in the HTML code. Adapt the margins of div#left_nav (no loner a negative margin-left, but a negative margin-right!). Change widths and margins – also margin-top – at the responsive transition as required.

Note that turning “div#float_info” a right floated div would not help much. The tag that is the last one in the code for floated elements of a container represents the first element which is moved downwards by the browser as soon as the widths of the floated elements collide. By performing such an experiment we would again see that the div-order in the code is of major importance. However, we are now able to adapt such an order quickly to our requirements regarding the final responsive outcome.

What about “inline-block” instead of floated elements?

Also a good point. With inline block elements [CSS property “display:inline-block;”] we can indeed replace floated elements in their containers. However, the tag order plays the same role for the behavior of inline-block elements as for floated elements when the space for a horizontal presentation becomes insufficient. The last tags are moved downwards. So we would have to work with the same type of tricks as discussed in this and the last article.

What is still missing?

Although we have harvested

  • control over the DIV order in the code required for an easily manageable responsiveness,
  • control over responsive adaptions of the position and width of content containers and their transparent background layers

there are of course still things to improve. E.g.:

  • The upper horizontal main menu could be collapsed to a button with a switch ON/OFF functionality on the upmost area of the web page.
  • The vertical navigation sub-menu could also be collapsed to a kind of button available on the left side of the viewport.

A full “Switch ON/OFF” functionality for such menu button requires Javascript. However, there is a well defined – though limited – solution also for users which have Javascript deactivated. These new objectives will be topics of forthcoming articles.

In the next article of this series

Responsive fluid multi-column layouts – with a responsive horizontal menu – IV

we shall describe a handling of the horizontal main menu line at small viewport widths – without involving Javascript.

Responsive fluid multi-column layouts – the DIV order problem – II

In the last article of this series

Responsive fluid multi-column layouts – the DIV order problem – I

I discussed a standard 3 column fluid design. HTML and CSS codes for a simple example were presented. Our solution depended on a certain order of DIV tags in the HTML code. The tag of the DIV container for the main content “div#main_content” got the last tag position and the CSS property “position:relative;” inside our outer container “div#float_cont”, where the container for 2 of the visible outer left and right “columns” were floated. By setting proper margins for the main content container we gained fluidity and at the same time automatic control over the apparent visual heights of all containers.

In this second article we make a first step towards a responsive design. We assume that the reader is already familiar with the definitions of the major DIV elements of our example page. As in the first article we shall identify the DIVs by their CSS ID representation.

We shall need to overcome some obstacles whilst getting responsive. Because this is a Linux blog we do not care if older and not W3C compliant MS IE browsers can reproduce our suggested CSS recipes for a solution. Code examples given below were tested with Firefox for Linux.

Responsiveness based on viewport width intervals

To start with responsiveness we first define some view port width intervals, for which we want to rearrange major (HTML) elements of our test page. We choose the width intervals a bit arbitrarily below. You may adapt them for your needs:

  • Range III: width range beyond 800px and larger
  • Range II: width range between 540px and 800px
  • Range I: width range below 540px

What are our objectives for the page layout in these ranges?

I shall set up some requirements and conditions for which the DIV order problem gets obvious. What I want to show is that when you deal with responsiveness you may have to align your initial standard HTML/CSS layout with what you want to achieve in view port ranges below certain width thresholds. Some people claim that one should always start designing for the narrow view port situation. My point of view is that with fluid layouts you need to consider both ends of your ranges right from the beginning.

Objectives for Range III:

In range III we just use our (or an improved) initial fluid design.

Objectives for Range II:

In range II the left column shall remain where it is. However, we remove the information in the right column to get more space for the main contents. Instead of omitting “div#right” completely we want to move it to the bottom of the page – and change its width at the same time to 100%. The optical and real height of “div#right” shall be determined by its contents. The “div#main_cont”, however, should keep its position, but use all the space being available at the right of the left column to the right edge of the view port. At the same time “div#main_cont” shall determine the optical (not necessarily the css) height of its own and the left column – if it is the longest. Otherwise the contents of the left column shall determine the height of the upper part on the page.

Objectives for Range I:

We set up an even more complicated scenario for range I:
The “div#main_cont” originally positioned in
the middle shall become dominant now and take the whole width offered. In addition we want to move the left side menu (div#left_nav”) from its original position. To make things tricky we want it to move to the bottom of the expanded DIV container “div#main_cont)” and give it a 100% width, too – so that if someone read and scrolled to the bottom of the “div#main_cont” he would see the available link options. The originally right column “div#right” shall move further down below the repositioned “div#left_nav”.

In addition we want to stop a further shrinking of the displayed main DIV container by a minimum width of 200px.

Later on

  • we shall in addition take care of a better treatment of the horizontal menu placed at the top of our test page in range I
  • and offer additional options to deal with the side menu originally placed left with vertical orientation.

Additional assumptions and requirements:

To make things really difficult, we want to achieve the transitions between Range III and Range II as well as between Range II and Range I without changing the HTML code defined for Range III. In addition we want to avoid Javascript/jQuery involvement to change the node order in the HTML tree during transitions. The reordering of the DIV containers defined above shall be achieved by CSS measures only.

Objective of this article – let us cover range II

We take these challenges step by step. For this article our goal is to cover Range II correctly – we do not care about Range I, yet. Already this limited objective will require some fundamental changes of our initial HTML code for Range III – and some interesting CSS tricks. But it will result in a solution which can also be used for Range I later on.

The order of the DIV tags prevents the repositioning of the DIV containers

We shall of course try to add some width dependent statements to our CSS file:

@media only screen and (min-width: 540px) and (max-width: 800px) { … }

But, what CSS directives could help us to move the container “div#right” to the bottom, i.e. below “div#main_cont” – without loosing our design achievements described in the last article? The frustrating result of many trials and errors was:

Given our assumptions above: none, actually. At least I was too stupid to find a reasonable solution.

You may play around a bit yourself. Even if you introduced some additional (floated) helper DIVs which would only be displayed in range II: Whatever you do to move the “div#right” – some of our requirements would be broken and/or the flow of the text in “div#main_cont” would be affected.

The first ugly thing is the following:
If we floated all major elements of the “div#float_cont” container “left” or “right” the final visible vertical order would not be correct. “div#main_cont” comes at the bottom of the original HTML code – so it moves to the bottom – whatever else happens. The same thing would happen if you turned off floating completely and used only relative positioning. You do not get the final order right.

So, what if we moved “div#main_cont” in our original HTML code and floated it instead of working with margins? Well, you cannot just float “div#main_cont” after (!) “div#left_nav” and keep up the adaptivity to any further width reduction of the viewport. This is mainly due to the fact that our left column container shall keep up a fixed width! You could solve
the adaptivity by changing “div#main_cont” to “position:absolute;” (and use “left:16rem; right:0;”) but then again you would loose any height control for “div#float_cont” and its external DIV containers. A loss of height control would also happen if you changed “div#info” to “position:absolute;” or if you floated it.

Now, you may think about additional floated helper DIVs which you switched on in the background of “div#main_cont” only after you passed a width threshold. But such a background floated DIV would have an impact onto any text written in “div#main_cont” ! Now, you could solve this by moving the text to an absolutely positioned inner container – and again loose height control. And so on, and so on …

What do we need?

From all my own experiments I could conclude 2 things which one needs to meet the adaptivity scenarios posed above:

  1. You need the HTML tag of “div#main_cont” as the first one inside the “div#float_cont” tag – more precise: before the other floated DIVs, which define the other columns.
  2. You sooner or later need “div#main_cont” to float itself.

However, as we have already seen at the end of our last article: Just moving the “div#main_cont” tag to the top and keeping up “position:relative;” will not work. However, if we floated it we would loose width adaptivity and/or would not get “div#left_cont” at the correct position with a fixed width. Is the last statement really true?

Negative margins to the rescue

We need to dig a bit deeper in our box of dirty CSS tricks. Let us assume that “div#main_cont” really were the first element of “div#float_cont”:

<div id="outer_cont">
	<div id="nav_left_bg"></div>
	<div id="right_bg"></div>
	<div id="info_bg"></div>
	<div id="float_cont">
		<div id="main_cont">
			<div id="info"> ... </div>
		</div>
		<div id="left_nav">
			<div id="left_inner"> ... </div>
		</div> 
		<div id="right">
			<div id="right_inner"> ... </div>
		</div> 
		<p class="floatstop"> </p>
	</div>
</div>

And let us further assume that we really floated “div#main_cont”. How could we regain width adaptivity and our text of “div#info” at the right position? Actually, this is pretty easy:

div#main_cont {
	position: relative; 	
	float: left;
	margin: 0; 
	width:100%;  /*adaptivity to the port view width!*/
}
div#info {
	/* height control: the contents defines the height of all parents */ 
	position: relative; 
	margin: 0 27% 0 16rem;
	padding: 0 0.8rem 0 0.8rem;
}

Note the “width:100%;” definition! It guarantees width adaptivity despite floating! To reserve enough pace at the left and right side of the main contents, we just use the same margin trick for “div#info” inside its container which we previously used for “div#main_cont” itself. Nice!

But, how do we get “div#left_nav” to its left position, now? We could use “position:absolute;” for this element. But, by doing this, we could no longer control container heights in case that the left column due to more contents ever became the longest of all columns. However, if we floated “div#left_nav”, it would move it downwards because “div#main_cont” already consumes all of the view port’s width.

Wait a second: What if we used negative margins? This could lead to a solution, because successive float elements can move across and over each other.
So, lets try it:

div#left_nav { 
	position:relative; 
	float:left;
	width: 14.2rem;
	margin-left: -100%;
}
div#right { 
	position:relative; 
	float:left;
	margin-left: -26%;
	width: 26%;
}

Some experiments with your browser would prove that this really works! After corresponding changes to the HTML and CSS codes we find that we more or less have come back to our original fluid scenario – but now the initial order of the HTML tags has changed fundamentally. Everything is floated – but by applying some tricky margins to our central containers we achieved the requested fluid layout again. How can we make use of the new tag order and the floating in range II ?

Elementary settings for range II

As soon as we reach the view port width threshold for range II, only some minor CSS changes are required for our new basic HTML/CSS layout:

@media only screen and (min-width: 540px) and (max-width: 800px) {
	div#right {
        	margin-left: 0;
		margin-top:1.0rem;
		width:100%;
		background-color: #FEEEBB;
	}
	div#info { 
		margin: 0 0 0 16rem;
	}
	div#right_bg {
		visibility: hidden; 
	}
	div#info_bg {
		right:0;
	}
}

This is pretty cool, isn’t it? We use our 100%-width of “div#main_cont”, change only one “left-margin” statement – and we have moved the “div#right” down. In addition we change the “right-margin” of “div#info” to use the total (adaptive!) width to the right for our main text information. The rest of the CSS changes just repairs some small gaps in the “optical appearance”:

fluid4

How to improve the optical appearance in Range III and Range II substantially?

As a developer, I thought I had achieved something and deserved a beer. However, I met strong criticism from my wife, who cares much more for optical design aspects than me. She pretty soon detected a major drawback of my HTML/CSS design:

The repositioned “div_right” still extends the height of the container “div#float_cont”. Thus, the heights of our colored background stripes “nav_left_bg”, “info_bg” and “right_bg” get bigger, too. The horizontally enlarged and moved “div_right” just overlaps and hides the background stripes.

Note, that we defined a “margin-top:10px;” for the repositioned “div#right;” in the CSS code above. Nevertheless, you see that our background stripes stretch down without any visible gap. As a result, I was confronted with a new requirement:

New additional requirement

What if you wanted to decouple the repositioned “div#right” from the 2 floated DIV containers above throughout Range II – in a clear optical way by a vertical gap – and also in the sense of HTML? And provide a region or stripe of transparency in between – i.e. in the gap opened by the margin-top definition)? Transparency, to allow the user e.g. to look at a background image of the whole page?

This requirement gave me some headache. But I understood the related objective very well. Web pages with seemingly floating areas (with rounded corners) above background images do look fancy, true enough. The eventual solution required additional changes to our initial HTML setup. I had to implement a kind of repetition of our new basic approach in a more convoluted way. Decoupling inevitably leads to more
containers …

Before looking at the code, let us first have a look at the result. As a starting point the new page appearance within Range III:

fluid5

A comparison with the next picture provides an impression of “width fluidity” in Range III:

fluid6

Now, let us have a look at the transition to Range II:

fluid7

And the width fluidity again:

fluid8

Even my wife accepted this – though, of course, she did not like the chosen background colors and the spacing of my test example. But related changes are within the reach of her work domain, now.

The new HTML code

Here are the resulting HTML and CSS codes for our test example. In comparison to our first article the statements may look a bit more complex. But, we only apply already discussed recipes at additional nested tag levels:

New HTML code:

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>fluid standard 2</title>
<link href="css/fluid_standard2.css" rel="stylesheet">
</head>

<body>
<!-- 3 spalten layout -->
<div id="all">
	<div id="head">
		<div id="hmen_knapp_cont" class="hmen_knapp_cont">
			<a id="hmen_knapp"></a>
		</div>
		<div id="hmen_cont" class="hmen_cont">
			<ul>
				<li><div class="hmen_pkt">h-menu 1</div></li>
				<li><div class="hmen_pkt">h-menu 2</div></li>
				<li><div class="hmen_pkt">h-menu 3</div></li>
				<li><div class="hmen_pkt">h-menu 4</div></li>
				<li><div class="hmen_pkt">h-menu 5</div></li>
				<li><div class="hmen_pkt"><a id="but2" href="#"></a></div></li>
				<li class="floatstop"></li>
			</ul>
		</div>
	</div>
	
	<div id="outer_cont">
		<div id="nav_left_bg"></div>
		<div id="right_bg">
			<!-- do not remove ! -->
			<div id="right_inner_bg"></div>
		</div>
		<div id="info_bg"></div>
		
		<div id="float_cont">
			<div id="main_cont">
				<div id="bg_left"></div>
				<div id="bg_info"></div>
				
				<div id="info_cont">
					<div id="float_info">
						<div id="info"> 
							<p>Lorem ipsum dolor .... </p>
							<p> </p>
							<p>Lorem ipsum dolor .... </p>
							<p> </p>
							<p>This is the end, my friend<br> </
p>
						</div>
					</div>
					<div id="left_nav">
						<div id="left_inner">
							<p><a href="#">sub menu point 1</a></p>
							<p><a href="#">sub menu point 2</a></p>
							<p><a href="#">sub menu point 3</a></p>
						</div>
					</div>
					<p class="floatstop"> </p>
				</div>
			</div>
			
			<div id="right">
				<div id="right_inner">
					<p>Some stupid text - just to show something</p>
					<p> </p>
					<p>Some stupid text - just to show something</p>
					<p>Some stupid text - just to show something</p>
				</div>
			</div> 
			
			<p class="floatstop"> </p>

		</div>
	</div>
</div>
</body>
</html>

 

You see that I took the decoupling of the left navigation area and the main contents container from the “div#right” container seriously. Actually, we reproduced the very same solution found above – but now inside an additional container “div#info_cont”, which itself resides inside the now floated container “div#main_cont”. Note, that by applying “position: relative;” for the container “div#info_cont” we can keep up full height control. Of course, in addition the floating inside the new additional float container “div#info_cont” has to be stopped to guarantee the dynamical propagation of height information to the outer enclosing DIVs.

As you can see, we placed some new and additional (colored) background DIVs inside the (now floated) “div#main_cont”. But throughout Range III we keep these elements hidden! However, in Range II we hide the original background stripes and activate the new ones instead.

The positioning of the container “div#right” works exactly as before – as log as we arrange for proper margins of “div#info”. To get a really nice padding of the background stripes in both ranges and to keep a constant distance of the contents of “div#right” to the contents of “div#info”, we need to include some more internal DIV containers – “div#right_inner_bg”, “div#left_inner”, “div#right_inner”. They provide some required “optical cosmetics”.

The new CSS code

The required new CSS statements for our example are the following:

   
@CHARSET "UTF-8";

html {
	font-size:10px;
}

body {
    margin-left:0; 
    margin-right:0;
    margin-top: 0; 
    background-image: url(../image/hg_drm_ap_7_1.jpg);
    background-repeat:no-repeat; 
    background-position:top center;
}

p { 
	font-size: 1.6rem; 
	line-height: 1.4;
	margin: 0;
}
	

div#all { 
	position:relative; 
	width:100%; 
	padding-bottom: 1.0rem;
	padding-top: 1.0rem;

}

/* The header region */	

div#head { 
	position:relative; 
	width:100%; 
	min-height: 3.0rem;
}

/* The main contents container */
	
div#outer_cont { 
	position:relative; 
	width:100%; 
	min-height: 10.0rem;
	margin-top:1.0rem;
}
	

/* some elementary width definitions */

div#left_nav,
div#nav_left_bg,
div#bg_left {
    width: 14rem;
    margin-left: 1.0rem;
}

div#right,
div#right_bg {
    width: 27%;
}


/* background elements for all columns in range I */

div#nav_left_bg, 
div#right_bg,
div#info_bg,
div#bg_left,
div#bg_info,
div#right_inner_bg {
    position: absolute;
    top:0;
    bottom:0;
    border-radius: 0.8rem;
}

div#nav_left_bg {
    position: absolute;
    left:0;
    
background-color: #DDD;
    border: 0px solid #F00;
    z-index:1;

}

div#info_bg {
    position: absolute;
    left:15.8rem;
    right:27%; 
    background-color: #FFB;
    border: 0px solid #00F;
    z-index:1;
}

div#right_bg {
    right: 0;
    border: 0px solid #F00;
    z-index:1;

}

div#right_inner_bg {
    left: 1.0rem;
    right: 1.0rem;
    background-color: #FEEEBB;
}


	
/* The float container and its basic elements */	

div#float_cont { 
    position:relative; 
    width: 100%; 
    border: 0px solid #FF0000;
    z-index:5;
}

/* floated left main container and 
 * its background elements for range II*/

div#main_cont { 
    position: relative;
    float: left; 
    width:100%;
    min-height: 2.0rem;
    border: 0px solid #009900;
    z-index:2;
}


div#bg_left {
    visibility: hidden; 
    position: absolute;
    left:0;
    background-color: #DDD;
    border: 0px solid #F00;
    z-index:1;

}

div#bg_info {
    visibility: hidden; 
    left:16.0rem;
    right:27%; 
    background-color: #FFB;
    border: 0px solid #00F;
    z-index:1;
}


/* The main column */

div#info_cont {
    position: relative; 
    width:100%; 
    border:0px #F00 solid;
}

div#float_info { 
    position:relative; 
    float:left;
    width: 100%; 
    border: 0px solid #FF0000;
    z-index:2;
}

div#info { 
    position: relative; 
    margin: 0 27% 0 16rem;
    width:auto;
    padding:0.8rem;
    min-height:2.0rem;
    z-index: 1;
}


/* right column */

div#right { 
    position:relative; 
    float:left;
    margin-left: -27%;
    min-height:2.0rem;
    border: 0px solid #009900;
    z-index:2;
}

div#right_inner {
    position:relative;
    width:auto;
    margin-left: 1.0rem;
    margin-right: 1.0rem;
    padding: 0.8rem;
}


/* left column */

div#left_nav { 
    position:relative; 
    float:left;
    border: 0px solid #009900;
    margin-left: -100%;
    padding-left: 1.0rem;
    z-index:5;
}

div#left_inner {
    width:auto;
    padding: 0.8rem;
}


/* Support elements */ 	

p.floatstop {
	clear:both;
	height:0;
	margin:0;
	line-height:0;
	padding: 0;
	font-size: 0;
}



/* contents of the upper horizontal menu */

div.hmen_cont {
	display: block; 
	position: relative;
	min-height: 3.0rem;
	width: auto;
	margin-right:0.8rem;
	margin-left:0.8rem;
	background-color: #ccc;
	border-radius: 1.0rem;
}

div.hmen_cont ul {
	position: relative;
	list-style-type: none;
	width: 100%;
	margin: 0;
	padding: 0;
}

div.hmen_cont ul li {
	float: left;
	padding: 0.2rem 4.0rem 0.2rem 4.0rem;
	border-right: #a90000 0.2rem solid;
	min-height: 2.0rem;
	font-size: 1.6rem;
}
	
div.hmen_cont ul li.floatstop {
	float:none;
	clear:both;
	min-height:0;
	margin:0;
	line-height:0;
	padding: 0;
	font-size: 0;
}

div#hmen_knapp_cont {
	display: none;
	position: absolute;
	right:0;
	top:10px;
	width: 50%;
	height: 2.4rem;
	border: 1px #A90000 solid;
}

a#hmen_knapp {
	display: block;
	width: 100%;
	height: 100%;
	background-color: #009999;		
}

a#but2 {
	display: block;
	width: 2.0rem;
	height: 2.0rem;
	background-color: #EEE;
}


/* @media screen decision and settings for range II */

@media screen and (min-width : 540px) and (max-width :800px) {
    
    div#info { 
        margin: 0 1.0rem 0 16rem;
        background-color:transparent;
    
    }
   
    div#right { 
        position:relative; 
        float:left;
        margin-top:1.0rem;
        margin-left: 0;
        margin-
right: 0; 
        width:100%;
     }
    
    div#right_inner {
        margin-left: 1.0rem; 
        margin-right: 1.0rem;
        width: auto; 
        background-color: #FEEEBB;
        border-radius: 0.8rem;
    }
    
    
    div#right_bg {
        visibility: hidden; 
    }

    div#info_bg {
        right:0;
    }

    div#nav_left_bg {
        visibility: hidden; 
    }

    div#info_bg {
        visibility: hidden; 
    }
    
    div#bg_left { 
        visibility: visible;
    } 
  
    div#bg_info { 
        visibility: visible;
        right: 1.0rem;
    }
}

 
Of course, you should replace the background image by your own.

Whilst studying the CSS statements, you may find that we extended the width of the right column to 27% of the view port width (instead of 26% before). Thus, physically “div#right” now connects directly to “div#info” at its left side. We did this to build up a seemingly constant (and not percentage dependent) visual distance between the middle and the right container contents. This may sound contradictory at first – but by using the additional inner DIV containers mentioned above and by applying proper margin/padding definitions we do achieve this objective.

At the bottom of the CSS file you find the necessary “@media screen” decisions and settings for range II. Because we set the negative left margin for “div#right” to zero this container moves down. The display of its contents requires some cosmetics; but the related CSS statements are very elementary.

One of the more interesting tricks is that we obviously hide the original (absolutely positioned and colored) background stripe containers and activate the new inner colored background stripe containers instead as soon as we perform the transition to Range II. This allows for a transparent gap between the visible upper part and the lower part of the web page in Range II – without loosing any height control for the visual columns in the upper part.

What have we achieved for our view port Ranges III and II?

Actually, all we wanted. We keep up optical height control where necessary in Range III and II. The CSS height of each of the container DIVs which represent the columns is completely determined by its contents (which we could change at any time, e.g. by a CMS). The longest of the three columns stirs the apparent visual height of all three columns in Range III.

In Range II we detach “div#right” and move it to the bottom of the page. Although we now create a gap between “div#right” and the upper part of the web page, full height control remains in place both for the floating 2 upper DIVs containers and their enclosing containers.

Fluidity is completely fulfilled in accordance with our objectives both for Range III and Range II.

The transition between Range III and Range II requires only some minor and obvious CSS changes. We did not have to change the HTML code at all during transition. We did not involve any Javascript so far.

Enough for today. We have not done anything, yet, to cover the objectives for Range I. I shall describe some appropriate measures in the next article:

Responsive fluid multi-column layouts – the DIV order problem – III

A good question the reader may consider in the meantime is:
What needs to be changed if we wanted to move the third column of Range III upwards instead of downwards during the transition to Range II?