How to make responsive design and what is difference between simple design and responsive design?

Now day by day in world smart gadget users are increase so responsive design are best option to beat competition and get more business. My question is how to make responsive design and what is difference between simple design and responsive design?

 

Responsive design is when a web design or a website changes the look or size or layout depending on the size of the browser window or device. eg: a mobile layout.

a responsive design doesn't have anything to do with being 'simple' or not.

well that's from my own understanding.

hope I helped.

here's more info about it: http://blog.teamtreehouse.com/beginners-guide-to-responsive-web-design

 

Responsive design is when the website responds depending on factors like browser size and so forth. For example, take this site - http://thejamespaterson.com/. If you resize the browser window, you can see that the website adjusts. the navigation goes from rows of three to a single colum, the intoduction at the top disappears, the content panels increase their width.

This is done using a media query and using fluid width. Fluid width means converting px and cm (Fixed width measures), into % and em, fluid measures. Use % for the size of containers, and em for the size of text. Normal text should be set as 1em. This allows the containers to ajust their size depending on the content that is filling them.

Media queries are CSS rules that come into affect when a condition is met. For example, the above site has the query:

/* Smaller Layout */
 
@media screen and (max-width: 500px) {
 
h1{
font-family: Helvetica, Tahoma, Sans-Serif;
font-size: 4em;
color: #FFF;
}
 
h4 {
font-size: 2.5em;
}
 
ul li {
width: 83.5%;
background-color: #FFF;
float: none;
margin: 0.5em auto;
border-radius: 5px;
height: auto;
padding: 1em;
}
 
#description {
color: #FFF;
display: none;
}
 
.footer {
line-height: 1em;
padding: 0.5em;
}
 
.page {
width: 95%;
}
}

HTML:

This specifies that the rules below will come into play when the condition (max-width: 500px is met. This condition specifies that when the browser screen comes below 500px, to apply the next set of CSS rules to the content.

 

JamJar919 covered the basics of doing it. CSS media queries are the key part, where you change your layout using them based on the available screen area.

In many ways responsive layout is just the next logical evolutionary step in accessible design. For those of us who've been building websites with fluid or semi-fluid layout, dynamic font sizes, using semantic markup, separation of presentation from content, and a whole host of other 'proper' site building techniques as outlined by things like the WCAG changing sites over to responsive is almost a non-issue... while for the folks who continue to sleaze out HTML 3.2 slapping 4 tranny or 5 lip-service around it, starting from some goofy fixed size picture of a website resulting in inaccessible fixed width layouts, all the fonts declared in pixel sizes, with nothing remotely resembling semantics we might as well be talking an alien language.

The approach I advocate is to first create semantic markup of your content (or something remotely resembling your content) before you even start THINKING about your layout. The reasoning behind this is that the entire point of HTML is to say what things ARE, NOT what they look like! -- said attitude works well with responsive layout since it opens the door to changing how ANY element on the page is being presented.

For this reason attributes like STYLE or ALIGN alongside long deprecated presentational tags like FONT, CENTER or BORDER -- Well, for the most part have NO BUSINESS in your markup at this point! There are a few standard DIV and SPAN you might know you're going to use ahead of time once you get some experience, but on the whole you should be focusing on tags with meaning BEFORE YOU EVEN THINK ABOUT LAYOUT! DIV and SPAN are semantically neutral, they do not change the meaning of their contents and as such really shouldn't be used at this point either unless you REALLY know what you're gonna do ahead of time.

You should have a plain, semantic logical document structure to which your style can be applied. This can often result in a fairly attractive if plain page without the CSS -- which is also important since that's what things like screen readers, braille readers, search engines and other data scrapers get.

From there you start in on your layoutS --YES, PLURAL! Add DIV and SPAN when and ONLY WHEN needed, bending the markup to your will with CSS. A lot of folks advocate building for mobile first, but I dislike the approach as it often leaves the desktop experience... wanting, and browsers that don't know media queries should be the lowest common denominator -- so I like to make my 800 friendly layout first, with the intent of feeding that to IE8/lower since that's who is likely to be the largest non-media query group I'd give a flying purple fish about.

From there you have a easy baseline for using media queries to strip away extra columns for narrow displays, or even split existing columns into multiple ones on larger displays.

If you look at one of my sites:
http://www.ewiusb.com/

... and try it at all sorts of different widths, you can see the responsive layout in action. It strips off columns and makes other adjustments as the screen gets narrower. The site is also built with semi-fluid layout so as to best use the available screen space, and dynamic fonts...

Starting out with the semantic markup and no CSS:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNoCSS.jpg

Moving on to the 800 friendly desktop layout at normal DPI:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom800Wide.jpg

To what it does at narrow width (640/smaller):
http://www.cutcodedown.com/images/ewiUSB/ewiUsbCom640wide.jpg

To what it does at really tiny (admittedly it's a bity long, but at least we're not treating mobile as second class citizens)
http://www.cutcodedown.com/images/ewiUSB/ewiUsbTinyMobile.jpg

To it's maximum width:
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal96.jpg

To maximum width with a different font metric (120dpi/windows large) so people (like me) aren't diving for the zoom when we shouldn't have to.
http://www.cutcodedown.com/images/ewiUSB/ewiUsbComNormal120.jpg

That's responsive elastic semi-fluid layout in action.

If I have time later tonight I'll toss together a working example with one of my famous 'line-by-line' breakdowns of the how/what/why of doing it. Been meaning to make one of those anyhow.

 

Nowaday, if you want to have a website, you'll want to make it responsive. Why, you ask? Because a responsive website can display on any of your devices, it can adjust itself to fit the resolution.

 

Sorry folks for the delay, got waylaid by life... I'm starting in on the code for an example now.

 

Ok, markup complete. Usually I write the complete markup some ~1% away from the final result first...

We start with a stock baseline, I use this:
http://www.cutcodedown.com/for_others/template.html

Since for most websites those elements are pretty much going to be present. The double-wrapper around content is for content-first columns without any goofy hacks or tricks... the H1 is the heading under which ALL other headings (and their content) are subsections, so naturally that's the page title. (just as every page of a newspaper has the name of the paper at the top). I choose XHTML 1.0 STRICT as the most recent doctype I'm willing to use to deploy code; partly because I think HTML 5 is bloated pointless manure, partly because I prefer XHTML's clear/cleaner structural rules, and of course STRICT means I won't be tempted to use any of the crap like TARGET, ALIGN, BORDER, CENTER, FONT that have no business on ANY website written after 1997.

You'll notice some HR in there. Horizontal rules (and even HTML 5 agrees with this -- one of the few things I can say good about 5) indicate a change in topic / start of a new subsection where a numbered heading is unwarranted on undesired; hence the comments about removing them if there are numbered headings present in the section that follows.

Also there's a META[viewport] in there... and this is where our responsive layout begins. The first value inside it, "width=device-width" tells mobile browsers to NOT lie about their resolution... as much. Most low-dot pitch devices like early/cheap droid and iPhones/iPads will obey this and make width actually equal the device width, as opposed to the 800px they normally 'claim' to be regardless of their actual resolution. Higher dot pitch devices like Apple's new "retina display" devices will still lie about their resolution claiming to be half what they really are -- this is acceptable since they generally have twice as many dots per inch anyways.

The second property, "initial-scale=1.0" tells it not to zoom in or out any by default.

The need for the viewport meta arose from mobile browsers trying to treat all websites like they are NOT designed for mobile... They lie about their resolution to try and make normal layouts work; the result leaves a lot to be desired and just makes our life harder. Mobile is one of those environments where GOD FORBID they actually obey what we try to tell it to do for widths, heights and font-sizes by default.

Some people include other values here, but those tend to do more harm than good -- see "maximum-scale" which breaks zooming in.

On the LINK for the CSS, pay attention to the full MEDIA stack. Many kiosks and browsers in full-screen operation use projection instead of screen, and our responsive layout should be able to adjust to best use the available space. Likewise there are still some devices that use the TV media type that generally speaking should get the same style as screen.

I advise against EVER using "all" as a media type since it makes no sense to send your screen layout to print, braille, teletype, etc, etc... I advise against ever omitting the MEDIA attribute for the same reason, and as a nitpick, FOR *** SAKE PEOPLE GIVE YOUR STYLESHEETS MEANINGFUL NAMES!!! -- screen.css for example tells us what it's FOR, as opposed to the uselessly pointlessly cryptic "style.css" half the garbage tutorials seem to suggest.

Another tip, you'll notice most of my comments are like this:
<!-- #extras --></div>

There's a reason for that -- comments between sibling-level tags, particularly floats or positioned content can result in rendering bugs in some versions of FF and IE. People will load up on IE specific conditional comment idiocy or hacks to compensate for what could be fixed by either removing pointless comments or moving useful comments INSIDE elements instead of between them. To that end the comments on all the HR should be removed on production code, they are just there for the baseline I start from as a reminder.

Likewise you'll notice I put <html><head>, </head><body> and </body></html> on single lines. This is a reminder to myself and others that NOTHING should EVER go between those elements. It's shocking how many people screw that one up.

Now, moving on to content - let's say we are making a website called "Monochrome" about web development. What do we want on the page? We know the site title and menu are pretty much as written, just toss in a few more menu elements... for the main content of the home page let's say there's going to be the three most recent news items and an about us section. Each of those will start inside div#content with a H2. H2 indicate the start of a subsection of the H1 before it... We'll put a DIV.subSection around each of those as a simple common styling hook, and give each of them a unique ID so we can target them individually if desired with CSS, scripting or URI hashes.

Under News we'd have articles, let's give each of those a DIV.article since we're pretty sure they'd have their own styling, and each article will start with it's own heading, in this case a H3 since each article is the start of a subsection of <h2>Latest News</h2>. This is called using numbered heading tags PROPERLY and why 90%+ of people are doing it ALL WRONG. ...and why HTML 5's "SECTION", "ARTICLE" and "NAV" tags are a bunch of idiotic NON-SEMANTIC bloated BS!

Just to get fancy, each article likely also has a date, since the date is easily considered part of the heading, we'll put them in span inside the heading tag. The SPAN will let us target them for any fancy styling we want to add without changing it's meaning or semantics.

So #latestNews.subSection would go something like this:

		<div id="latestNews" class="subSection">
			<h2>Latest News</h2>
			
			<div class="article">
				<h3>
					<span>5 May 2013</span>
					Launch Soon
				</h3>
				<p>
					Skinning is proceding apace as is the back-end code, so we will soon be launching this site. Stay tuned for when we go live, and thanks to all those who have devoted their time to this project.
				</p>
			<!-- .article --></div>
			
			<div class="article">
				<h3>
					<span>2 May 2013</span>
					HTML is simpler than you think!
				</h3>
				<p>
					... and yes, that qualifies as news to most people. They take thier markup and overcomplicate it with <strong>hordes of unneccesary wrappers</strong> just for presentation that in many cases could just as easily be applied to the elements directly, or resort to classes on generic containers like <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code>, or presentational elements like <code>&lt;font&gt;</code> or <code>&lt;center&gt;</code> when all they really need are headings and paragraphs properly grouped by a single <code>&lt;div&gt;</code>.
				</p>
			<!-- .article --></div>
			
			<div class="article">
				<h3>
					<span>29 April 2013</span>
					... and so it begins
				</h3>
				<p>
					Initial site layout for <em class="siteName">Monochromatic</em> has begun. We'll be using <strong>minimalist semantic markup</strong>, proper <strong>separation of presentation from content</strong>, and a whole host of other headache saving methods...
				</p><p>
					Which is not to say our site will be devoid of styling or graphical goodies by the time we are done.
				</p>
			<!-- .article --></div>
			
			<a href="#" class="readMore">Read more news items in our archive</a>
			
		<!-- #latestNews.subSection --></div>

Code (markup):

#aboutUs.subSection is even simpler since it would just be a H2 and some P.

		<div id="aboutUs" class="subSection">
			<h2>About Us</h2>
			<p>
				<i class="siteName">Monochromatic</i> was developed to promote the use of cleaner <em>consistant markup</em>, <em>formatting</em>, <em>styling</em> and <em>separation of presentation from content</em> through the use of techniques that we have come to call <em>minimalist semantic markup</em>. These techniques were developed by <em>web developers</em> with over a decade of experience not just in <acronym title="Hypertext Markup Language">HTML</acronym> and <acronym title="Cascading Style Sheets">CSS</acronym>, but a whole array of <em>programming languages</em>.
			</p><p>
				Our intent is to promote pages that meet <em>accessbility minimums</em>, provide <em>graceful degradation</em> in less capable browsers, work well at doing "white hat" <em>search engine optimization</em>, <em>reduce bandwidth</em> and <em>lower hosting costs</em>, <strong>while not skimping on things like eye candy!</strong>
			</p>			
		<!-- #aboutUs.subSection --></div>

Code (markup):

For our #extras / sidebar let's say we'd have a 'recent articles' section, some advertisements, and a box of links. These would all start with H2 and then either P or Lists as appropriate. I would also add two more div to break them into two groups so if need be we can split the one column into two. Normally I'd not add that until I was making the STYLE, but I'm adding it up front because I want to show how to do that...

		<div class="firstSection">
	
			<div id="recentArticles" class="subSection">
				<h2>Recent Articles</h2>
				<ul>
					<li>
						<a href="#">
							Using Tables Properly
						</a> -
						They are not evil, they are not a 'hack' unto themselves. Only their abuse is the real problem.
					</li><li>
						<a href="#">
							Eight Corners Under One Roof
						</a> -
						How to make a image styled borders in dynamic height and width from only one image.
					</li><li>
						<a href="#">
							Friendly URL's
						</a> -
						More than a fad, the ability to pass data to PHP requests in a 'user/search friendly' manner can also be used to add security
						and simplify creation of new CMS systems.
					</li><li>
						<a href="#">
							CSS "Sprites"
						</a> -
						While 'sprites' is technically inaccurate, this method of recombining images can greatly reduce the number of handshakes on a page, speeding how fast it loads and pre-caching images before you need them on subpages.
					</li>
				</ul>
			<!-- #recentArticles.subSection --></div>
			
		<!-- .firstSection --></div>
		
		<div class="secondSection">
		
			<div id="advertisements" class="subSection">
				<h2>Advertisements</h2>
				<a href="ad1" title="dummy advertisement #1">
					<img
						src="images/dummy120x240.gif"
						alt="Advertisement placeholder"
						width="120"
						height="240"
					/>
				</a>
				<a href="ad2" title="dummy advertisement #2">
					<img
						src="images/dummy120x240.gif"
						alt="Advertisement placeholder"
						width="120"
						height="240"
					/>
				</a>
			<!-- #advertisements.subSection --></div>
		
			<div id="links" class="subSection">
				<h2>Links</h2>
				<ul>
					<li>
						<a href="http://www.digitalpoint.com">
							Digital Point
						</a>
					</li><li>
						<a href="http://www.techtalkin.com/">
							TechTalkin
						</a>
					</li><li>
						<a href="http://www.deathshadow.com/">
							Deathshadow's Madness
						</a>
					</li><li>
						<a href="https://developer.mozilla.org/en-US/">
							Mozilla Developer Network
						</a>
					</li><li>
						<a href="http://sourceforge.net/">
							SourceForge
						</a>
					</li><li>
						<a href="http://www.howtoforge.com/">
							HowToForge
						</a>
					</li>
				</ul>
			<!-- #links.subSection --></div>
		
		<!-- .secondSection --></div>

Code (markup):

Finally the footer content is likely just a disclaimer. I dislike putting redundant links down there as if those actually serve a legitimate purpose, there's probably something wrong with the main menu or the design itself. I'd use span to split any sentences in half so some tricks can be played with the styles, adding a class to any that end in periods to give us multiple break-points. You'll see the reasoning for this when we get to the CSS.

So, my starting markup complete ends up thus:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<meta
	name="viewport"
	content="width=device-width; initial-scale=1.0"
/>

<link
	type="text/css"
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
/>

<title>
	Monochromatic
</title>

</head><body>

<div id="pageWrapper">

	<h1>
		Monochromatic<br />
		<small>Doing Things a Better Way</small>
	</h1>

	<ul id="mainMenu">
		<li><a href="#">Home</a></li>
		<li><a href="#">News</a></li>
		<li><a href="#">Articles</a></li>
		<li><a href="#">Forums</a></li>
		<li><a href="#">Links</a></li>
	</ul>

	<div id="contentWrapper"><div id="content">
	
		<div id="latestNews" class="subSection">
			<h2>Latest News</h2>
			
			<div class="article">
				<h3>
					<span>5 May 2013</span>
					Launch Soon
				</h3>
				<p>
					Skinning is proceding apace as is the back-end code, so we will soon be launching this site. Stay tuned for when we go live, and thanks to all those who have devoted their time to this project.
				</p>
			<!-- .article --></div>
			
			<div class="article">
				<h3>
					<span>2 May 2013</span>
					HTML is simpler than you think!
				</h3>
				<p>
					... and yes, that qualifies as news to most people. They take thier markup and overcomplicate it with <strong>hordes of unneccesary wrappers</strong> just for presentation that in many cases could just as easily be applied to the elements directly, or resort to classes on generic containers like <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code>, or presentational elements like <code>&lt;font&gt;</code> or <code>&lt;center&gt;</code> when all they really need are headings and paragraphs properly grouped by a single <code>&lt;div&gt;</code>.
				</p>
			<!-- .article --></div>
			
			<div class="article">
				<h3>
					<span>29 April 2013</span>
					... and so it begins
				</h3>
				<p>
					Initial site layout for <em class="siteName">Monochromatic</em> has begun. We'll be using <strong>minimalist semantic markup</strong>, proper <strong>separation of presentation from content</strong>, and a whole host of other headache saving methods...
				</p><p>
					Which is not to say our site will be devoid of styling or graphical goodies by the time we are done.
				</p>
			<!-- .article --></div>
			
			<a href="#" class="readMore">Read more news items in our archive</a>
			
		<!-- #latestNews.subSection --></div>
		
		<div id="aboutUs" class="subSection">
			<h2>About Us</h2>
			<p>
				<i class="siteName">Monochromatic</i> was developed to promote the use of cleaner <em>consistant markup</em>, <em>formatting</em>, <em>styling</em> and <em>separation of presentation from content</em> through the use of techniques that we have come to call <em>minimalist semantic markup</em>. These techniques were developed by <em>web developers</em> with over a decade of experience not just in <acronym title="Hypertext Markup Language">HTML</acronym> and <acronym title="Cascading Style Sheets">CSS</acronym>, but a whole array of <em>programming languages</em>.
			</p><p>
				Our intent is to promote pages that meet <em>accessbility minimums</em>, provide <em>graceful degradation</em> in less capable browsers, work well at doing "white hat" <em>search engine optimization</em>, <em>reduce bandwidth</em> and <em>lower hosting costs</em>, <strong>while not skimping on things like eye candy!</strong>
			</p>			
		<!-- #aboutUs.subSection --></div>
		
	<!-- #content, #contentWrapper --></div></div>

		
	<div id="extras">
		
		<div class="firstSection">
	
			<div id="recentArticles" class="subSection">
				<h2>Recent Articles</h2>
				<ul>
					<li>
						<a href="#">
							Using Tables Properly
						</a> -
						They are not evil, they are not a 'hack' unto themselves. Only their abuse is the real problem.
					</li><li>
						<a href="#">
							Eight Corners Under One Roof
						</a> -
						How to make a image styled borders in dynamic height and width from only one image.
					</li><li>
						<a href="#">
							Friendly URL's
						</a> -
						More than a fad, the ability to pass data to PHP requests in a 'user/search friendly' manner can also be used to add security
						and simplify creation of new CMS systems.
					</li><li>
						<a href="#">
							CSS "Sprites"
						</a> -
						While 'sprites' is technically inaccurate, this method of recombining images can greatly reduce the number of handshakes on a page, speeding how fast it loads and pre-caching images before you need them on subpages.
					</li>
				</ul>
			<!-- #recentArticles.subSection --></div>
			
		<!-- .firstSection --></div>
		
		<div class="secondSection">
		
			<div id="advertisements" class="subSection">
				<h2>Advertisements</h2>
				<a href="ad1" title="dummy advertisement #1">
					<img
						src="images/dummy120x240.gif"
						alt="Advertisement placeholder"
						width="120"
						height="240"
					/>
				</a>
				<a href="ad2" title="dummy advertisement #2">
					<img
						src="images/dummy120x240.gif"
						alt="Advertisement placeholder"
						width="120"
						height="240"
					/>
				</a>
			<!-- #advertisements.subSection --></div>
		
			<div id="links" class="subSection">
				<h2>Links</h2>
				<ul>
					<li>
						<a href="http://www.digitalpoint.com">
							Digital Point
						</a>
					</li><li>
						<a href="http://www.techtalkin.com/">
							TechTalkin
						</a>
					</li><li>
						<a href="http://www.deathshadow.com/">
							Deathshadow's Madness
						</a>
					</li><li>
						<a href="https://developer.mozilla.org/en-US/">
							Mozilla Developer Network
						</a>
					</li><li>
						<a href="http://sourceforge.net/">
							SourceForge
						</a>
					</li><li>
						<a href="http://www.howtoforge.com/">
							HowToForge
						</a>
					</li>
				</ul>
			<!-- #links.subSection --></div>
		
		<!-- .secondSection --></div>
		
	<!-- #extras --></div>
	
	<hr />
		
	<div id="footer">
		<span>Contents of <i class="siteName">Monochromatic</i> unless otherwise noted are</span>
		<span class="end">&copy; Paladin Systems North and Jason M. Knight.</span><br />
		<span>Permission for re-use is allowed so long as proper</span>
		<span class="end">credit is given for the work to it's original authors.</span>
	<!-- #footer --></div>

<!-- #pageWrapper --></div>

</body></html>

Code (markup):

A few more notes about the semantics -- B, I, STRONG, EM and CITE all have different meanings, do not confuse them -- do NOT believe the lies being spread the past decade about B and I being deprecated or strictly presentational. EM and STRONG mean 'emphasis' and 'more emphasis'. CITE is for when you are QUOTING or referring to a reference. If I said something like:

"I read <i>Wizard's First Rule<i> by <b>Terry Goodkind</b> last month." <em>I am not citing the book, or the author</em> -- <strong>nor are they recieving emphasis!</strong>

See what I did there? That's the difference. B and I have a semantic meaning, that meaning being when they WOULD be bold or italic in writing for a reason like a referenced proper name or title. Not that they SHOULD or even must receive that presentation given the target device might not even be capable of that! <strong>There is more to writing HTML than the screen the 'designer' happens to be sitting in front of!</strong>

It's a subtle difference lost on many.

Alright, that's the markup, I'll get started on belting out some simple CSS to show responsive layout and media queries in action.

 

On to the style.

I've uploaded a working copy here:
http://www.cutcodedown.com/tutorials/responsiveLayout/monochromatic/

Follow along with the stylesheet:
http://www.cutcodedown.com/tutorials/responsive/monochromatic/screen.css

With all my stylesheets I generally start out with a reset and some stock values, much like with the markup. My current 'baseline' can be found here:

http://www.cutcodedown.com/for_others/screen.css

In that you'll find at the start a simple reset of margins and paddings on elements that have different values cross browser. Resets exist because the HTML specification doesn't actually say what the defaults for anything should be -- and like in most cases where the spec doesn't say, the browser makers all up and decide to go off in their own directions. There are smaller resets like the "universal reset" of "* { padding:0; margin:0; }" but that can cause headaches styling form elements thanks to FF and IE being retarded... FF thanks to it's Nyetscape heritage, IE because, well... It's Microsoft.

There are larger resets too, like Eric Meyer's "reset reloaded" -- but that massive bloated wreck is generally what gives resets a bad name. It borders on being a framework, NOT a reset, and as such I wouldn't advise it's use. In fact, most of the larger ones cause more problems than they solve.

The one I use was designed by Dan Schulz some five or six years ago.

It's a wonderful middle-ground between the two, and at a quarter of a K generally saves you more code than you'd ever waste including it.

After the reset you can see I hide all HR. I include HR for semantics and non-screen targets. They serve no purpose in a screen layout and are removed for that reason.

The -text-size-adjust is sent for the same reason we have a viewport meta. The named version of "none" is more reliable than the 100% most people are advocating since it actually works on the devices I own (Android 4.0 tablets) unlike most other values people plug in. Basically this tells the user agent (browser) NOT to screw with the font sizes as we know what we're doing!

On BODY I have a default stack as a starting point. This is declared in percent so the entire page is dynamic since if you're going to build responsive, you might as well not smear dung all over it from an accessibility standpoint by declaring all your fonts in pixels.

Finally the outer wrapping div gets our semi-fluid layout applied to it... semi-fluid means having a minimum and maximum width, so things like long lines don't get too hard to read and so the layout doesn't fall apart at narrow widths. As I declared the min and max widths in EM's, it is ALSO an elastic layout; it will automatically enlarge to match the users default font-size -- again so users like myself don't have to dive for the zoom when we shouldn't have to!

On the production CSS there are few if any changes. I do add the prefixless text-size-adjust these days since that's what BLINK will be using... the real changes are on BODY and #pageWrapper

body -- I tossed the text-align on it for IE 5.5 just to prove you can do all this nice modern stuff and STILL quite easily be useable on legacy browsers. The page is nice even in IE6 even without the rounded corners, transparencies and gradients, and isn't too bad in IE5 even if it's tossing a wobbly about background colors. I did that mostly out of blind luck and good practices -- as well as thumbing my nose at the people who say supporting legacy IE is "too hard". Maybe if folks dind't load up their pages with useless "gee ain't it neat" scriptard nonsense and image trickery they wouldn't have these problems.

The top/bottom padding on body is more reliable than trying to use margins on our content elements since padding doesn't collapse, and the background

#pageWrapper -- I added an overflow state to contain margins and floats if need be. I decreased the max-width to what seemed 'best' for this layout when it's stuck without media queries because again, that's our starting point; what we want displayed when media queries are NOT available. Rest of it is just colors and style -- though pay attention to the black border, we'll get to that in a while.

* html #pageWrapper -- The comment really explains it all - IE6/earlier can't do min/max width. Back in the day I'd have faked it with an expression, but these days people stuck in the 1990's can suck it up and deal with a crappy inaccessible fixed width. As the comment says, they should be thankful anyone even bothers still thinking about them at all.

Most of the rest of the elements that follow are just style -- nothing to write home about until we get to #contentWrapper


#contentWrapper -- the 100% width and float:left leaves zero px free for anything to float next to it. Remember that!

#content -- The overflow and zoom are just for float and margin wrapping -- the large padding on the right side makes a 'empty' space that our sidebar is going to end up OVER.

#extras -- and here's the magic. Remember how I just said there are 0 px free next to the floated #contentWrapper? Well, negative margins reduce a elements size in 'flow' -- how it's positioned. By using a negative margin equal to or smaller than the element, it is zero px or less in size and will 'pop up' into floated position next to #contentWrapper. It's a sneaky trick, very powerful, and in my experience a bulletproof way to make reliable "content first" columns where that first column (#content) has a fluid width. It's also powerful enough to add any number of columns in ANY order. We could put two side columns on the left, two on the right, or one on each side, a combination, or strip all columns off easily. We'll be doing a lot of that when we get to the responsive code.

... and again the rest of this is pretty much just normal styling, though I'd like to touch on:

#footer span -- setting these to nowrap forces them to their own lines when there's not enough room. This is going to be part of our responsive layout.

You'll also notice I hide the BR in the footer -- those are there for CSS off, and also will be leveraged for our really wide width.

So, here come the media queries, and this is where the real 'magic' happens.

There are two major types of media queries that deliver the most utility-- min-width and max-width. min-width means anything larger than what you declare will get the style, max-width as you can probably guess means the opposite, only when the window is narrower than that does it kick in.

@media (min-width:1px) -- just to show that we can strip off styling for ALL modern browsers quite easily. In this case I pull the border off #pageWrapper so that it's only shown on browsers that don't know media queries... Which still looks attractive even if they also don't get any of our CSS3 niceties.

I no longer bother worrying that older browsers don't show fancy nonsense like rounded corners, transparencies, etc, etc... it's a serious "OH WELL" in my book, and sure beats the living tar out of bloated slow buggy javascript polyfill garbage like "CSS3 Pie" that often breaks layouts doing far more damage than the cutesy stuff is worth. Without those it's just gracefully degrading -- which I had thought was one of the reasons we were supposed to be building with progressive enhancement, semantic markup and separation of presentation from content in the first place!

@media (max-width:34em) -- at this size the heading becomes too big to fit, so I shrink the font down to manageable sizes. I give this it's own breakpoint as we often have different points at which different things need to be changed. Don't think you have to nab all your changes at all the same points!

@media (max-width:48em) -- we lower the min-width since we know we can go smaller. The reason we have a min-width so high on the normal code is again that's for browsers that don't know media queries. Stripping off all the extra padding, margins and the floats on the columns axes the multi-column layout changing it to a single clean column, ideal for smaller displays. I also axe the rounded corners and unneccessary borders to make better use of the available screen space, and finally set the span in the footer to normal white-space making it compress so that the user agent can determine the line-breaks.

@media (min-width:64em) -- just as for the small screen layout we dropped the min-width to phone size, for larger displays we up the max-width since we can make better use of the available space by splitting our one column into two.

To do that, we double the padding space the column is in, double the width of our #extras area, and set both our subsections to floating at half that (with 1 extra EM between them).

You'll also notice I set the "#footer br" to display:block making them show and force a newline, since both of our sentences can now easily fit.

... and that's what's involved in making a simple flat cookie-cutter responsive elastic semi-fluid layout. (and I do mean cookie cutter since that's what most of my sites end up looking like now for layout)

Hope this helps some folks out there.

 

One of the most relevant, comprehensive guides out there. I'd put this in your sig with the rest of your tips, that really helped me.

 

If you lack the desire to start from scratch with a responsive design then you can use Wordpress and a responsive theme (I got one from elegantthemes.com)

 

It definitely does, nice pile of dung you left here Sir!

I was looking for exactly this, a simple but in-depth explanation of what is a good way to code a modern website. I want to upgrade my current site from a semi-responsive layout plus a jquery-mobile version to a html only version for all devices.

 

Simple design is that we use from the start of internet.
Responsive Design : Now a days every one want to make there website in responsive design. Responsive design means to display your website on different screen in different layout. Its very easy now a days there are many web site give you responsive design code in free. You can download bootstrap for responsive design from this URL getbootstrap.com .

 

Wow, that's gibberish.

If you want a sleazy shortcut filled with buggy broken halfwit bull that defeats the entire point of using HTML and CSS in the first place.

 

My goodness, what's this?

I have been working with Monochromatic for a couple of days now and I like it a lot. But I have stumbled across a problem that I'm not able to understand.

Today I tried my layout in IE8 and discovered that the second column always ends up below the first column. This also happens in your original template. I am working on a 1032x746 resolution, I have no wider screen. It also happens in Safari for Windows. I have been playing around with different widths, paddings and margins but can´t find the reason for why things work this way in those browsers.

I use respond.js to make IE8 recognize media queries.

Any ideas, apart from not bothering about an almost extinct browser?

Greetings!

 

I'm unable to recreate that at all here at any width. It should be inherently impossible since it is using the negative margin content first column method, which is pretty well proven to work. THOUGH:

Never heard of it, never tried it, NEVER would. Oh noes, IE8 doesn't get media queries.

All these 'shim' and 'polyfill' usually do more harm than good -- I would NEVER use them and instead rely on graceful degradation as originally intended. IE8/lower doesn't get the media queries, OH WELL.

What method are you using for testing IE8 -- I've tried both IE11's compatibility mode and a native IE8 install under a XP VM, and neither does what you describe with my original; when you say "original template" are you talking the copy on my site, or have you made changes like adding that stupid polyfill?

 

Respond.js is pretty nice, I never noticed any collateral damage due to it's presence. It only targets IE8 and lower and only makes it respond to min max media queries.

Anyways, I test your template as is, I grabbed it from your site, upload it to my server and open it in IE8 on XP. Neither in compatibility mode nor in "normal" view the two columns appear where they are supposed to, side by side next to #content. #Extras .firstSection shows next to #content, #Extras .secondSection stays below #Extras .firstSection.

When I lower screen resolution everything stays in place, nothing changes position.

Even opening your file in your repository straight in IE8 things are as commented.

I test this without adding anything, no funny scripts, no code changes.

 

Uhm... what you described is what it's supposed to do... on non-media query browsers it gives you a two column layout instead of a three column one. Lowest common denominator since we have no clue how wide an IE8- screen is, we feed them the middle version. The three column layout is media query only... just as the one column layout is media query only... the two column is for 'everything else'.

+-----------------------+-----------------------+
| #content              | #extras.firstSection  |
|                       |-----------------------+
|                       | #extras.secondSection |
+-----------------------+-----------------------+

Code (markup):

Is what you should be seeing in IE8... basically everything in #extras as a single column next to #content. The three column layout is made by this media query:

@media (min-width:64em) {
	#pageWrapper {
		max-width:88em;
	}
	
	#content {
		padding-right:43em;
	}
	
	#extras {
		width:41em;
		margin-left:-42em;
	}
	
	#extras .firstSection {
		width:20em;
		float:left;
		display:inline; /* prevent IE margin doubling */
		margin-right:1em;
	}
	
	#extras .secondSection {
		float:left;
		width:20em;
	}
	
	#footer br {
		display:block;
	}
}

Code (markup):

So no media queries, no three column layout.

I wouldn't trust it as far as I could throw the USS IOWA -- waste of time and effort.

 

I see, but, in Safari for Windows the same thing happens, except for the fact that on narrower resolution things both columns pop under #content.

When using respond.js IE8 responds to other media queries using your code base, it shows basically the same behaviour as Safari on Windows.

I'm not at all keen on using additional scripts. One thing I like of your template is it's absolute simplicity, html and css and that's it. At the most I add some simple and very basic javascript to do some nice thingies and nothing else.

**EDIT**

Lowering the min-width from 64em to 62em things started working on Safari and on an IE8 on dope.

As the respond.js is only fed to IE8 I feel comfortable using it. It don't hurt me so it can't be that bad!

Greetings, thanks for your code and time.

 

Odd I'm unable to recreate that here at all in either Compat view or real IE8 at any width at any font size at any zoom. I'd kind of like to see this problem live in a browser so I can figure out what (if anything) is triggering the problem.

Though... didn't they stop making/updating Safari for Windows like six years ago? At this point isn't testing that a bit like testing IE 5.2 for Mac?

-- edit -- My bad, it was only two years ago... seems like longer than that. I just know I don't test it, I test real safari on Snow Leoptard inside VirtualBox... well, in addition to iOS Safari using xCode's emulator.

 

Your code works in IE8 as it does in real browsers when using respond.js, without it there's no joy.

Yes, Safari for Windows is pretty ancient, I doubt anybody uses that thing nowadays and I guess up-to-date Safari on Apple has got little to do with that dinosaur.

When I have the new version of my site presentable I'll pass a link.