Questions about Paul O's Max-Min Layout

Paul,

I’ve decided - for this hour at least?! - to try and adopt your Elastic Max-min Layout that you suggested in this thread.

I have been reading your code and related articles (e.g. Negative Margins) but I am really lost on how the floats and negative margins work?! :frowning:

In the last link above, I was able to follow this code…


	.float{
			float: left;
			background: #ffffcc;
			height: 350px;
			margin-right: -200px;
		}

	.one{
			width: 100%;
		}

	.one p{
			margin-right: 210px;
		}

	.two{
			background: red;
			color: yellow;
			width: 200px;
			height: 90px;
			margin: 0;
		}

where float one basically took up the entire screen, and then float two was allowed to overlap it due to the negative right margin.

(This made particular sense because float one came FIRST and there is had “squatter’s rights” on the entire viewport width!!)

However in your Elastic example, you have this code…


#middle {
	float: left;
	width: 100%;
	margin-right: -300px;/* width of left and right columns */
}
/* #content is the only extra html we need to add to achieve this layout*/
#content {
	margin-right:300px;/* width of left and right columns */
}
#left {
	width:150px;
	float:left;
	font-size:11px;
	background:#ccc;
}
#right {
	width:150px;
	position:relative;
	float:right;
	z-index:2;
	font-size:11px;
	background:#eee;
}

But in this second example, the Middle column did NOT come first.

Your HTML has the order…


	<div id="left"></div>
	<div id="middle">
		<div id="content"></div>
	</div>
	<div id="right"></div>

With that being said…

1.) Why doesn’t the Left column take up the leftmost space on its own? It was in the HTML code FIRST and it is a Float Left?

2.) How can a right negative margin of 300px possibly allow the Left Column and Middle Column to overlap without the text overlapping as well?! (I am totally lost on this point!)

3.) If the floats go Left, Middle, Right then why doesn’t the Middle float butt up against the Left float by default?

I would think all you would need is a right negative margin on the Middle column of 150px to allow the Right column to fit within the viewport.

I would expect having a right negative margin 300px to all the Right column into the viewport, BUT to then have an extra 150px blank space to the right of the Right column.

Yet, somehow, this extra 150px is miraculously moving over the the far left for who knows what reason?!

Here is hoping you can explain all of this, because I’d really like to use this layout and get down to build my website!

Thanks as always,

Debbie

All three elements are floated left and we have 100% width to play with.

  1. The left column is floated first in source and takes up 150px width. We don’t need to do anything special here as it is just a normal floated element with 150px width.

2)The middle column is floated left but we give it 100% width to fill up the whole line which results in it dropping below the left column. In order to allow the middle column to sit next to the left column we need to reduce its width.

We know that the left column is 150px and we also know that eventually our right column will also be 150px width so to fit between these side columns the middle float must be 100% wide minus 300px (100% - 150px - 150px).

The actual dimensions of an element in CSS are made up of its width + padding + borders + margins. There is no such thing as a negative width, nor negative padding nor negative borders; but there is such a thing as negative margins.

Therefore we can allow an elements width to be defined by the sum of its parts as shown above.

150 + (100% -300) + 150 = 100%

That allows all floats to sit on one line because effectively they are only 100% wide now.

However the negative right margin on the middle float causes the right float to actually sit on top of the middle float. To solve this problem we nest an inner div inside the middle element and give it a margin-right of 300px. This inner div holds the content and keeps it clear of the right float.

We now have floats all on one line and no overlap.

2.) How can a right negative margin of 300px possibly allow the Left Column and Middle Column to overlap without the text overlapping as well?! (I am totally lost on this point!)

The content is kept clear by the inner nested element which has a 300px positive right margin

3.) If the floats go Left, Middle, Right then why doesn’t the Middle float butt up against the Left float by default?

The middle float would butt up against the left float as long as it was not wider than the space available. Once a float is too wide to fit it drops to another line.

I would think all you would need is a right negative margin on the Middle column of 150px to allow the Right column to fit within the viewport.

No the middle float needs a width.

You cannot have a widthless float that holds fluid content like text because it will always stretch to be 100% wide. The middle float must have a width and that width must therefore be 300px short of the total space available because that’s how much space is taken up by the fixed width columns.

I would expect having a right negative margin 300px to all the Right column into the viewport, BUT to then have an extra 150px blank space to the right of the Right column.

The 100% width (combined with the negative margin) on the middle column does make the middle column extend outside the right side of the viewport by 150px which is why we need overflow:hidden on #inner to hide the scrollbar.

You can think of a negative margin on a float as sucking the content adjacent to it inside.

That only applies to the opposite margin though. For a left floated element a negative right margin will suck in the content from its right by the amount of the negative margin. However a negative left margin on a left float simply moves the whole thing to the left (and therefore vice versa for right floats etc.)

I have attached a rough drawing that may explain it all better :slight_smile:

WHEW!!! This is tough stuff!! :blush:

Check.

2)The middle column is floated left but we give it 100% width to fill up the whole line which results in it dropping below the left column. In order to allow the middle column to sit next to the left column we need to reduce its width.

Check.

We know that the left column is 150px and we also know that eventually our right column will also be 150px width so to fit between these side columns the middle float must be 100% wide minus 300px (100% - 150px - 150px).

The actual dimensions of an element in CSS are made up of its width + padding + borders + margins. There is no such thing as a negative width, nor negative padding nor negative borders; but there is such a thing as negative margins.

Therefore we can allow an elements width to be defined by the sum of its parts as shown above.

150 + (100% -300) + 150 = 100%

That allows all floats to sit on one line because effectively they are only 100% wide now.

Here is where things get confusing…

So the negative margin doesn’t “shrink” the 100% down to say 80%, it just allows the lonely Right margin to shift over to the left 300px - overlapping the Middle column - but thus allowing all three columns to “fit” inside the viewport, correct?

However, we still have this ugly problem of the “bossy” 100% Middle column’s rear protruding way out to the right - well beyond our viewport, correct?

So to counteract this, we use…

	overflow:hidden;

…in our #wrapper DIV to “hide” this ugly growth from our users?!

How does that sound?! :smiley:

However the negative right margin on the middle float causes the right float to actually sit on top of the middle float. To solve this problem we nest an inner div inside the middle element and give it a margin-right of 300px. This inner div holds the content and keeps it clear of the right float.

Why is the Right column floating (i.e. higher Z-Index) above the Middle column?

Why can’t we just use Right Padding on the Middle column to counteract the overlap?

We now have floats all on one line and no overlap.

The content is kept clear by the inner nested element which has a 300px positive right margin

The middle float would butt up against the left float as long as it was not wider than the space available. Once a float is too wide to fit it drops to another line.

No the middle float needs a width.

You cannot have a widthless float that holds fluid content like text because it will always stretch to be 100% wide. The middle float must have a width and that width must therefore be 300px short of the total space available because that’s how much space is taken up by the fixed width columns.

[b]Another counter-intuitive item…

You would think that with a Floated Left Column in place, that “100%” would mean "100% of the remaining available space in the Viewport (i.e. 100% - 150px)?![/b]

The 100% width (combined with the negative margin) on the middle column does make the middle column extend outside the right side of the viewport by 150px which is why we need overflow:hidden on #inner to hide the scrollbar.

Who creates these rules?! :nono:

You can think of a negative margin on a float as sucking the content adjacent to it inside.

That only applies to the opposite margin though. For a left floated element a negative right margin will suck in the content from its right by the amount of the negative margin. However a negative left margin on a left float simply moves the whole thing to the left (and therefore vice versa for right floats etc.)

Check.

I have attached a rough drawing that may explain it all better :slight_smile:

That diagram needs to go in a SitePoint book pronto!!!

(You should update your tutorial/code because I bet a lot of people have similar questions/confusions!)

So, could you also just play with the Middle column’s width (e.g. 90%, 85%, 80%, 75%,…) until you got things right and then you could use a more logical Right Negative Margin of 150px and eliminate things hanging out like a sore thumb right of your viewport?

WOW! As always, Paul, THANKS for the explanation and clarification!!

Sincerely,

Debbie

Non positioned elements later in the source will overlap those earlier in the source assuming all other rules are equal. IF you want to control the order of the overlap then you need to position the element and apply z-index. For a static element this would mean adding position:relative.

Why can’t we just use Right Padding on the Middle column to counteract the overlap?

Because padding is part of the box model and adding padding just makes the element wider.

[B]Another counter-intuitive item…

You would think that with a Floated Left Column in place, that “100%” would mean "100% of the remaining available space in the Viewport (i.e. 100% - 150px)?![/B]

Floats and absolutely placed elements are “shrink to fit” elements and their width if not defined is determined via their content. Static elements on the other hand expand to full the available space in their containing block by default.

We need this behaviour for both sorts of elements in order to accomplish all the layouts we need. If we had one without the other then we would be limited in what we can do. It’s this depth of css that gives it so much power but at the same time makes it harder to grasp until all the principles are understood.

Who creates these rules?! :nono:

Computer scientists a lot smarter than me :slight_smile:

So, could you also just play with the Middle column’s width (e.g. 90%, 85%, 80%, 75%,…) until you got things right and then you could use a more logical Right Negative Margin of 150px and eliminate things hanging out like a sore thumb right of your viewport?

No you can’t change the middle columns width at all. It has to be 100%. It’s the main parent that actually determines the width of the page so if you wanted an 80% width the outer would be set to 80% width.

The middle float is just filling the space between the two side floats. There is no need to alter its width as that would make no real sense (and an 80% width would mean that we had a 20% gap somewhere along the line). What we are in effect doing is creating a fluid width column in the middle.

If it was a static div we would do this simply by giving it a margin-right of 150px and a margin-left of 150px and no width. This is the effect we create by giving our float 100% width and then negative margins of 300px to reduce it. If we said 80% width then we would have a calculation that could never be reconciled as everything in that row must eventually add up to 100% or it falls apart.

i.e. 80% + ??px = 100%. (we can’t reconcile this)

The only calculation that works is:

100% - 300 + 300 = 100%

I think you’ve grasped the fundamentals though and in the end it’s just a mathematics equation.

Paul,

So it appears that I got your layout working - guess it always worked - and now I basically understand it.

My next challenge is inserting a Top Menu into where the id=header goes.

I am realizing that if I use a Max-Min layout, that could serious mess up my menu, right?!

Was all of this trouble to attain “elasticity” for not?! :frowning:

My Top Menu currently has 7 categories - which could change - and I believe each one is 140px wide.

What am I supposed to do now?

(I don’t mind if the prose within the Main div adjusts its size, but I’m not really crazy about a menu that is loosey-goose!)

Debbie

Hi Debbie,

Yes that’s the challenge when producing a fluid or elastic layout. :slight_smile:

You have to think ahead at every step and plan the way your elements are to work.

You will need to make your menu fluid also which means not using fixed widths and perhaps using percentage widths so that it fits within the space and scales up and down. This may take some trial and error and blood and sweat but it is possible. The only other alternative would be to create the menu that fits the min-width you have set and then just center it within the space.

It all depends what your menu looks like of course and how complicated it is. A series of simple text links is going to cause no problems but something highly graphical and element dependent may be awkward.

Or put it on one side, and put something else on the same line on the opposite side – something I do a good deal with them – just have a blank bar between the two sides.

One of the keys to understanding the negative margin IMHO is to think of every element as having two separate boxes – the “flow” box, and the “render box” – render is what the user sees, flow is what the browser uses to compute an elements size.

Margins control flow WITHOUT changing render, just as top/bottom/left/right when combined with position:relative changes the position an element is rendered at without changing it’s “flow” position.

Negative margins just shrink the size of an element ‘in flow’ without changing how big it is being rendered. This is why a negative margin makes an element appear to slide over/under (depending on your depth sorting) elements around them – it’s being rendered the same size, it’s size in “flow” is being shrunk.

Now Paul – don’t take offense, but MEIN GOTT what the deuce is that mess of IE conditional nonsense with multiple scripts and a resize trap supposed to be accomplishing… much less the “or IE8+” nonsense?!? Though admittedly I’ve never ONCE seen the “speed issue with expressions” you hear people pissing and moaning about (though I DO see it with alpha .png’s which everyone goes ahead and uses anyways) That’s one hell of a mess that doesn’t even degrade gracefully when scripting is disabled OR compensate properly for browser chrome – for what I’ve been doing for seven years with just:


* html #wrapper {
	width:752px;
	width:expression(
		(document.body.clientWidth>1280) ? "1232px"	: (
			(document.body.clientWidth>800) ? "auto" : "752px"
		)
	);
}

The initial fixed width being what people with scripting disabled in legacy IE get.

While I kind-of like the .l and .r div’s, the rest of it? The layout kind-of shows why I favor the middle-column first approach – not the least of which being that said layout IS BROKEN here in IE6. On the whole it feels needlessly complex for something fairly simple if you just swap around who’s on first, and who’s playing catcher and who’s pitching. (aka nesting orders).

Gimme a few minutes I’ll throw together what I mean.

No offence taken :slight_smile:

Yes the extra IE8 comments were the old version of my sticky footer that used display:table and are not in the newer version. I never got around to updating it but will do no harm. I really should update the page but can never find the time:)

The css expressions with scripting though do make a dramatic difference and turn a very sluggish IE6 into something much smoother.

Just see what simply moving your mouse around on Steve Souders test page does and you can see that expressions overload the page almost immediately. It’s a cut and clear case for me.

I could have done the min and max width using no scripting but it would mean extra divs for everyone which it too high a price to pay and also complicates the code. Better just to give IE6 the extra code and script and even if js is disabled the page is still usable.

I prefer the more logical approach of having columns 1, 2 and 3 in the order of 1, 2 and 3 although source order can be changed easily with that design anyway.

Everyone has their favourite ways of doing things so I don’t say that this is better than anyone else’s but just my approach. Which of course I would revise if something better came along.

I’m just not getting how adding six times more code than necessary WITH the overhead of a function call is supposed to alleviate/make better the process? Of course that example the only one that seems to have lag is “example 1” and that’s NOT the expressions doing it, it’s the counter update changing the dom! Much less the getElementByID on EVERY iteration… Which is what’s REALLY dragging it under, NOT the actual width calculation expression.

Though yes, replacing the expression with onresize would be better; at that point DON’T PUT IT IN THE CSS IN THE FIRST PLACE! If you’re going to use a real script instead, use a real script instead. I think that’s really my problem with it, pick one, not both?

… and maybe not call the exact same evaluation twice in a row? Just seems needlessly complex for something simple.

Something simple like:


function setMinWidth() {
	idPageWrapper.style.width=(
		(document.body.clientWidth>1152) ? "1104px"
			: ((document.body.clientWidth>800) ? "95%" : "752px")
	);
	idFooter.style.width=idPageWrapper.style.width;
}
var idPageWrapper=document.getElementById('pageWrapper');
var idFooter=document.getElementById('footer');
setMinWidth();
window.onresize=setMinWidth;

For example would git 'er done. Include it before </body> and it will apply the changes before CSS is loaded without CSS overriding it. (strange, but it works)… and without the “jump” that can occur if you wait for onload (which is probably why the wierd ‘load it from CSS’ approach was taken).

Of course I’d put that in an external file and make the script load inside a IE conditional – funny how I rage against IE conditionals when used for CSS but have no problem with them when used for scripting… OH WAIT, that’s because they’re UNNECESSARY FOR CSS and a WASTE OF BANDWIDTH in most cases.

I’m going to apply that to my ‘rewrite’ I’m tossing together.

Here’s my suggested approach to that same layout.

http://www.cutcodedown.com/for_others/DoubleDee/template.html

as with all my examples the directory:
http://www.cutcodedown.com/for_others/DoubleDee

…is unlocked for easy access to the various files. I broke out the .js and CSS since it’s easier for me to work with separate files than it is one giant endless pile of mush… but I’m the guy who considers tabbed editors a technological step backwards since it’s very hard to see two separate files side-by-side or to have four or five separate files on three or four separate displays unless they are in separate windows! :smiley:

Tested working FF 3.5 and 3.6, IE 5.01, 5.5, 6 and 7 (under XP), IE8 and 9 beta (under win7), and the latest flavors each of Opera, Saffy and Chrome. Valid XHTML 1.0 Strict and Valid CSS2.

Did we mention it works flawless even on IE 5.01?

I think it’s a bit clearer/simpler an approach to the layout since it’s NOT relying on overflow to handle any of the positioning, does NOT need any extra div#inner for that overflow chopping, does NOT need z-index to place things one over the other thanks to code order AND understanding how position:relative works, and relies on a much simpler javascript solution for legacy IE WITH a scripting off fixed width present.

I changed the text to document this approach and put a good deal of comments in the CSS to clarify the more… unusual bits.

Hope this helps clarify things and/or give you more ideas/methods. Can never have too many different ways of doing things as the more ways you know of doing it, the better you can make choices on which one to use and when.

Yes that’s pretty clean as I would expect from you Jason and well documented:)

The only quibble I have is that your JS does cause a considerable jump from fixed to fluid as the routine kicks in (my pc is pretty old and slow). That doesn’t happen at all in my version due to the expression. However your JS is a simpler cleaner method and may be easier for Debbie to handle

Thanks for knocking up a demo as its good to get alternatives and different ways of thinking as your approach is usually different to mine and always interesting.

I’ll play devil’s advocate for a sec. Debbie. Those layouts are perfect in every way obviously. But there is also nothing wrong with a fixed width layout. If you did make a fixed width layout your questions from a-z would be at least half that of the fluild one. If you simply want to learn and enjoy the challenge then good go for it. But if you want less of a headache now and in the future then fixed is a whole lot easier. The layout is one thing. Its all the things you have to think about when you put stuff in the layout that makes things a bit more tricky (eg the menu, floated imgs, text, long text, etc, etc).

There is EVERYTHING wrong with fixed width layouts as it’s the biggest IDIOCY online. PERIOD!!!

Given the unending array of screen resolutions, system font metrics, and user preferences fixed layouts are crappy little stripes usually made by your PSD jockeys who typically could give a flying fig about things like accessibility in the first place.

There’s a REASON they’re called “crappy little stripes”… and why the number of fixed width sites I visit on a regular basis can be counted on one finger.

Or as Dan used to say, “enjoy your bounce rate”

That shouldn’t happen as CSS is hung waiting for the script to execute. Never encountered a system that did that before.

… just went down to the garage and tested on my K6/2-450 retrogaming system (voodoo 5 man…) and I’m not seeing it… and the only computers I have slower than that would be my Coco and my Tandy 1000 – and those don’t have browsers.

Ok, so you could call it with the expression by just wrapping the two commands I’m running flat thus:

JS:


function setMinWidth() {
	idPageWrapper.style.width=(
		(document.body.clientWidth>1152) ? "1104px"
			: ((document.body.clientWidth>800) ? "95%" : "752px")
	);
	idFooter.style.width=idPageWrapper.style.width;
}

var idPageWrapper=document.getElementById('pageWrapper');
var idFooter=document.getElementById('footer');

function initMinWidth() {
	setMinWidth();
	window.onresize=setMinWidth;
	return idPageWrapper.style.width;
}

Leave the <SCRIPT> in place where it is in the markup so it can grab the two elements from the DOM as globals without the extra declaration – and then in the css do:


* html #pageWrapper,
* html #footer {
	width:752px;
	width:expression(initMinWidth());
}

You know… Hmm… We could do BETTER on that… though the script would grow slightly it would be easier to ‘configure’ from the CSS. I’m gonna play with that when I get up tomorrow. Would be nice if it could be made to ‘chain’ off each declaration while passing the desired widths to it.

… or not… starts to rub up against my “simple is better” mentality, much less my “stop filling up a page with unneccessary scripting” rants.

I have to disagree with the use of expression for calculating the min-width. If we keep fixing IE presentation with JS like it’s 1997 all over again, I guess the separation between CSS and JS layers is becoming a concept that never ever had a chance.

One VERY good example of this promiscuity is css3pie. It’s a lie, it’s not progressive it’s regressive :wink: Thinking like this, CSS3 was born long before CSS 2.1 was even a draft.

And so is JS min-width: a lie. It doesn’t make it whiter the fact that we need it for IE, or because it’s in a conditional. Taking the same approach, a fluid 5cols layout with a sticky footer and a fixed nav is achievable by 10 lines of CSS. And a jQuery include :slight_smile:

And yes, the most promising new flexible box model layout is also JS-capable right now. No need to wait. And so on, and so forth.

Correcting features that are wrong in some CSS implementations, by JS, is not progressive enhancement. At all. But, if it serves your purposes, I guess you can jump the fence and call it that :wink:

As always, the truth is somewhere in the middle. You just can’t build ∞ sites.

The “fixed width layout” site needs to be semi-fluid, to some regard, much like your so called “fluid layout” is, in fact, a semi-fixed width layout.

And there are occasions when a fixed width layout is actually called for. Like the Pure HTML/CSS SPF Content :wink: I am using a fixed layout for this one :slight_smile: Good thing ds60 is not a judge, I guess :lol:

Ha. Oh yeah when ever I hit a fixed width site I’m like “I’m out of here!”. Not. Well all hand helds (and like) are much smaller than the min-width so they are not part of this decision. So “mainly” your concern would be computer monitors and tv’s and the majority of those are 1024 and over so there you have it. The new tablet type (ipads) are going to be a bit smaller. I think those are around 800 on average but they are quite used to scrolling from left to right on those so once again not that big o deal. There is obviously plenty to be said for a fluid width site but a fixed width site is not a crime against nature as you imply.

I came to that realization before bed at 3:00 a.m. this morning. :frowning:

If you did make a fixed width layout your questions from a-z would be at least half that of the fluild one.

It sorta feels that way.

If you simply want to learn and enjoy the challenge then good go for it. But if you want less of a headache now and in the future then fixed is a whole lot easier. The layout is one thing. Its all the things you have to think about when you put stuff in the layout that makes things a bit more tricky (eg the menu, floated imgs, text, long text, etc, etc).

I admit that I’m not sure if I am ready for “fluid” layout yet. And I am questioning even if I am ready for Paul’s “elastic” layout yet. :bawling:

This much I do know, no working website equals no visitors and no $$$.

Obviously I am trying to do things the best way possible, or else I wouldn’t be here at SitePoint?! (And using Windows, ASP, HTML tables, TONS of JavaScript, etc.) :wink:

At the same time, I have nowhere near the level of experience as a lot of the resident gurus here on SP. sigh

The website I am trying to build should be pretty simple. (I plan on getting visitors and make $$$ on content more than anything.)

So while I do want to take into account the downfalls of a static design, this is not about pure design.

About my website (or at least home page)…

1.) Company Name at top left

2.) Top Menu with either a Dropline Submenu or a Dropdown Submenu

3.) Fixed Right Column for advertising for my own business

4.) Possibly a Fixed Left Column to display other important items

5.) Middle Column for content - either Article Summaries or the Articles themselves

6.) Generic Footer

My Thoughts

  • The Right (and Left) Column needs to be fixed width.

  • The Middle column can be fluid

  • The Menu/Submenu probably needs to be fixed width, but could co-exist in a “fluid” setting, I suppose.

Can I get some direction here, PLEASE!!!

Was implementing Paul’s 3-Column Min-Max layout not right for me?

(If I could just get some help getting my Top Menu working, I think it looks pretty good.) :frowning:

Thanks,

Debbie

It’s better to use something when you understand the need for it. If you aren’t, at this point, needing a fluid layout, make a fixed one.

The basics: the min-width, max-width are there to help your layout. It’s not to squeeze it like a lemon or help extend it like a bungee. Rather, it’s for making it act like silicon. It has a normal state, and you can only squeeze it that much or extend it that much without breaking it.

Lately, mobile scene made it difficult to follow the above. Still, you are presented with three options:

  1. Media queries

  2. A “…/mobile” version

  3. A flexible layout

I’d say the later sounds the most reasonable, possible and consistent implementation. That’s why you should consider a flexible layout like Paul’s.

The mobile scene, it seems, added a “layer” to CSS. Now, what are the current steps for building a web site, according to some:

  1. HTML markup: semantic.

  2. Basic CSS, for devices that cannot understand media queries and have limited display capabilities.

  • probably adds some “for hooks” HTML markup.
  1. Advanced CSS, for devices that have extended capabilities and/or understand media queries.
  • probably adds some more “for hooks” HTML markup, some proprietary CSS and some hacks for older and misunderstood browsers.

That is the question…

Do I really need a “fluid” or an “elastic” layout?

According to this link (http://www.hobo-web.co.uk/seo-blog/best-screen-size/), none of the Top 10 most popular screen sizes are below 1024 width.

Furthermore, the site says, “In 2009… Interestingly, only 653 visitors (1.16%) used 800×600 screen size.”

Yes, I have a current client still using IE6, but I am wondering if it makes sense to spent 80% of your time developing for 5% of the population?! :rolleyes:

I don’t have a problem with a fluid middle column achieved via Paul’s elastic layout, but I think it isn’t practical to have a Fluid Top Menu with Submenu unless someone has any suggestions?!

The basics: the min-width, max-width are there to help your layout. It’s not to squeeze it like a lemon or help extend it like a bungee. Rather, it’s for making it act like silicon. It has a normal state, and you can only squeeze it that much or extend it that much without breaking it.

I compared my layout to some other sites, and it seems like if I upped the minimum to 960px it might be more manageable. (But then does that defeat the purpose of the Elastic setup??)

Lately, mobile scene made it difficult to follow the above. Still, you are presented with three options:

  1. Media queries
  2. A “…/mobile” version
  3. A flexible layout

What are “media queries”?

Honestly, I’m not concerned about mobile users at this stage… (I just don’t want people with older PCs or smaller monitors throwing their hands up in disgust at my website!)

Debbie