Why my website contents does not resize

Hey there,

I am little stuck on how to get the elements on my website to resize. I am using Dreamweaver and it seems to all be at a fixed size rather than anything dynamic. Is there something wrong with the code behind-the-scenes?

http://powermodegames.com

Thanks

 

Hi OliverSB,

You may want to look into fluid elements using CSS. Link below might be helpful (it was one of the first links in google).

http://ansciath.tumblr.com/post/7347495869/css-aspect-ratio

Hope it helps.

 

Thanks I will take a look.

 

You mean resize as in responsive stuff?

 

I mean at least to get the size to resize based on the window size. Not particularly optimizations for mobile.

 

Hi OliverSB,
Perhaps you are using fixed size for the elements. Like width: 300px;
Try using percentage based width. For example- width: 60%;

 

Parentage is the best way to fix your problem.

Please use width: 65%;

 

Use twitter - bootstrap. just only u need to get used to ids and classes. reset has been done by them..

Or else you should re size all with @media-screen option...

 

Now, word of warning; what I'm about to say might seem a bit harsh, but keep in mind I'm trying to help. You've been led down the garden path by broken, outdated, or just plain nonsensical methodologies and that's what's biting you in the backside. A lot of the problems is you've fallen into a number of the same traps a lot of people starting out do.

For starters the ONLY thing you can learn from the bloated overpriced steaming pile of manure known as Dreamweaver is how NOT to build a website. This is doubly true of you are using the WYSIWYG.

The very notion of WYSIWYG/drag and drop for websites is outright idiotic nonsense. Simple fact is that with a well written website what you see is NEVER what anyone else gets! The entire purpose from day one of HTML is to say what things ARE, NOT what they look like; we got away from that during the browser wars but HTML 4 STRICT with CSS was created to drag us kicking and screaming back to that purpose.

... and because the point of HTML is to say what things ARE, how the devil are you doing that using the design view in DW?

This is why your markup is 90% rubbish. DW's stupid malfing "comments designed to create errors" for it's idiotic DWT template crap, static CSS in the markup, no MEDIA targets on your CSS LINK tags, endless pointless DIV for nothing, needlessly vague and pointless classes like "span12", tables for layout, attributes like ALIGN, BORDER and BGCOLOR that have NO business on any website written after 1997, paragraph tags around non-paragraph elements, horizontal rules without changes in topic, gibberish use of numbered headings (even taking the ****tarded HTML 5 rules into account), and of course, your inaccessible fixed width layout.

Which is why my advice is to throw any books/manuals you have for Dreamweaver in the wood stove to help heat your home, make microwave art out of the DVD's, and forget ANY of that idiocy even exists. As a dearly departed friend of mine used to say, the only thing about Dreamweaver that can be considered professional grade tools are the people who promote it's use -- the same can be extended to 99% of sleazeball halfwit shortcuts to web design like FrontPage, Web Expression, or any other system that has you dicking around with what it looks like before you have semantic markup of content of value.

You have been further led down the garden path to failure by the mouth-breathingly stupid steaming pile of 100% grade a farm fresh prarie pies known as bootcrap. Do yourself a favor and find a stick to scrape that off with -- though you DON'T seem to actually be using it, it would appear that DW is plugging that in for you

About the only good thing I can say about what you have so far is at least your flow paragraphs are in paragraphs, but that seems to be a side effect of EVERYTHING getting wrapped in <P> whether it should be or not!

The PROPER process for building a page is to first get a flat text editor; Flo's Notepad2, EditPlus, Notepad++, Win32pad, Crimson Editor... there are dozens if not hundreds of perfectly good tools for the job. You then plug in your content or a reasonable facsimile of future content in a logical order as if HTML never even existed.

Once you have it all nice and neat, you mark it up semantically -- which means you add your HTML tags to say what things ARE with ZERO concern for what it looks like. As I've said a thousand times the past decade, if you are choosing your tags based on their default appearance, you are choosing the wrong tags for ALL the wrong reasons. P for actual flow paragraphs (not just something that happens to be text and sure as shine-ola not around things like images), H1 as the heading under which EVERYTHING on the page is a subsection, h2 marking the start of subsections of that SINGLE H1, H3 marking the start of subsections of the H2 and so forth... HR meaning start a new subsection Of course being why HTML 5's "SECTION" tag is pointlessly redundant bull... lists for lists -- you get the idea. Since DIV and SPAN have no meaning (aka "semantically neutral") you have no business adding them until the next step:

STyling it -- and that's CSS' job. You should leverage as many of the existing tags as possible before adding DIV, SPAN or classes unless you are REALLY sure of what you are doing. It's called separation of presentation from content. You use the CSS to make your MANY layouts -- first using the MEDIA attribute on your LINK tag to separate all the different types of target like Screen, print, etc... then within your stylesheets using "media queries" to target sub-devices of those categories by capability (like width).

Then and ONLY then do you hang your non-content images on the working layout and/or add any JavaScript to further enhance it -- keeping in mind the most basic rule of JavaScript being "If you can't make the page work without scripting FIRST, you likely have no business adding scripting to it."

... all of which being what's wrong with what you have so far and why my advice would be to throw that entire mess in the trash and start over from scratch.

The first step would be to fix the markup. Since you have a few general ideas there for layout I can make some early assumptions -- I do free rewrites for people from time to time here (been a while since I've done one), and I'm gonna do one for you here as a precursor to making the layout properly semi-fluid, elastic and responsive.

Semi-fluid means expanding and contracting between two points -- you have a minimum width so that the page doesn't break when the screen is too small (on pre-CSS3 browsers) and that the layout doesn't end up so wide that long lines of text are hard to follow.

Elastic means the entire layout scales based on the default font size. Different computers have different defaults, and users can CHANGE the default to their preferences; this is why declaring font-sizes in pixels is idiotic halfwit bull and should be avoided for anything except where fixed image interactions are involved. If you declare all your font sizes in EM's or %, and then declare all your layout widths in % (or not at all, letting flow do it's job) the whole layout will auto-scale to the default font size -- which is NOT the same thign as zoom and allows users to have the layout scale to their needs WITHOUT diving for the zoom.

... and of course there's the new kid, responsive layout. Which simply means you use "media queries" to test things like the width of the browser window to change your layout to best fit what's available.

Why some halfwits out there think you need some idiotic rubbish bloated "framework" like bootcrap to pull that off? No clue apart from them not knowing enough about HTML or CSS to be building websites in the first damned place. Generally speaking 99.9999999~% of the people who say "use bootstrap" or "use jQuery" needs a quadruple helping of sierra foxtrot tango uniform.

As a start, this is probably all that's needed for markup - EVERYTHING else belongs in the external stylesheet.

<!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; height=device-height; initial-scale=1.0"
/>

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

<title>
	PowerMode
</title>

</head><body>

<div id="top">
	
	<h1>
		<a href="\">
			PowerMode
			<span><!-- image replacement sandbag --></span>
		</a>
	</h1>
	
	<div id="mainMenu">
		<a href="#mainMenu" class="showMenu"></a>
		<a href="#" class="hideMenu"></a>
		<ul>
			<li>
				<a href="index.html">Home</a>
			</li><li>
				<a href="download.html">Download</a>
				<ul>
					<li class="winblows"><a href="#">Windows</a></li>
					<li class="quack"><a href="#">Mac</a></li>
					<li class="linsux"><a href="#">Linux</a></li>
				</ul>
			</li>
			<li><a href="../buy.html">Buy Now</a></li>
			<li><a href="http://docs.powermodegames.com">Documentation</a></li>
			<li><a href="http://forum.powermodegames.com">Forum</a></li>
			<li><a href="http://blog.powermodegames.com">Blog</a></li>
		</ul>
	<!-- #mainMenu --></div>
	
	<div class="mainSection">
	
		<ul id="pageMenu">
			<li>
				<a href="#future">
					<img src="img/html5.png" alt="HTML5 Logo" /><br />
					Future Technologies
				</a>
			</li><li>
				<a href="#theskyisthelimit">
					<img src="img/no limitations.png" alt="Infinite Loop Icon" /><br />
					Infinite possibilities
				</a>
			</li><li>
				<a href="#quick">
					<img src="img/quick startup.png" alt="Clock Icon" />
					Quick startup
				</a>
			</li><li>
				<a href="#amazing">
					<img src="img/amazing results.png" alt="Target" />
					Amazing results
				</a>
			</li>
		</ul>
		
		<p>
			PowerMode gives you amazing <strong>intuitivity</strong>, <strong>power</strong> and <strong>productivity</strong>! Game development has never been this easy or quick than with PowerMode.
		</p><p>
			PowerMode uses an amazing; drag &amp; drop, point &amp; click programming system. This makes beginners and proffesionals feel like they have real control!
		</p><p>
			Within minutes, you can learn the basics of PowerMode and build your first game. I will regularly post new content on my blog that gives you hints, tips and tutorials to aid you in game development with PowerMode.
		</p><p>
			Deploy your apps to the web, reaching out to many millions of people.
		</p><p>
			PowerMode is currently free and in the early alpha stages of development. PowerMode will soon be opening up for feedback. So simply click the download button to try PowerMode today at <strong>no cost</strong>!
		</p>
		<ul class="linkList">
			<li><a href="#">Download</a></li>
			<li><a href="#">Watch Video (COMING SOON) &raquo;</a></li>
		</ul>
	<!-- .subSection --></div>
	
	<div class="subSection" id="future">
	
		<h2>
			<img src="img/html5.png" alt="HTML5 Logo" class="leadingPlate" />
			Future Technologies
		</h2>
		
		<div class="logos">
			<img src="img/WEBGL.png" alt="WebGL Logo" />
			<img src="img/html5.png" alt="HTML5 Logo" />
			<img src="img/PhaserLogo.png" alt="Phaser Logo" />
			<img src="img/PixiLogo.png" alt="Pixi Logo"  />
		<!-- .logos --></div>
		
		<p>
			PowerMode compiles games that take advantage of future technologies including <strong>WebGL</strong>, <strong>HTML5</strong>, <strong>Phaser</strong>,<strong>Pixi </strong>and <strong>SoundJS</strong>.
		</p><p>
			It is no secret that PowerMode takes advantage of these great existing technologies!
		</p><p>
			PowerMode uses Phaser to power most of the core game technologies of PowerMode while extending it work with SoundJS seamlessly. The PowerMode engine is written in Javascript and designed to operate the code generated by PowerMode. The reason why I chose to use Phaser is because it is free, robust and well supported.
		</p><p>
			While Phaser has it's own sound engine built-in, it is not as powerful as SoundJS. The whole of PowerMode's sound capabilities are built on top of SoundJS.
		</p><p>
			Phaser specialises in being a game framework but also runs on top of a graphics framework called Pixi. Pixi is an amazingly fast, cross platform and robust web renderer. Pixi takes advantage of WebGL and HTML5 really well!
		</p><p>
			There is a lot of great things I could say about the technologies which power the PowerMode game engine. If you want to find out more, you can go and check out these pages for more information:
		</p>
		
		<h3>WebGL</h3>
		<a href="https://www.khronos.org/webgl/">
			https://www.khronos.org/webgl/
		</a><br />
		
		<h3>HTML5</h3>
		<a href="http://tympanus.net/codrops/2011/11/24/top-10-reasons-to-use-html5-right-now/">
			http://tympanus.net/codrops/2011/11/24/top-10-reasons-to-use-html5-right-now/
		</a><br />
		
		<h3>Phaser</h3>
		<a href="http://www.phaser.io">
			http://www.phaser.io
		</a><br />
		
		<h3>PIXI</h3>
		<a href="http://www.pixijs.com/">
			http://www.pixijs.com
		</a><br />
		
		<h3>SoundJS</h3>
		<a href="http://www.createjs.com/#!/SoundJS">
			http://www.createjs.com/#!/SoundJS
		</a>
		
	<!-- #future.subSection --></div>
	
	<div class="subSection" id="theSkyIsTheLimit">
		<h2>
			<img src="img/no limitations.png" alt="Infinite Loop Icon" />
			Infinite possibilities
		</h2>
		<p>
			With PowerMode, the possibilities are endless. Think outside the box and see what you can do with it. You might make the next hit game!
		</p>
	<!-- #theSkyIsTheLimit.subSection --></td>
	
	<div class="subsection" id="quick">
		<h2>
			<img src="img/quick startup.png" alt="Clock Icon" />
			Quick startup
		</h2>
		<p>
			PowerMode is one of those programs where you run through an easy installer, open it and you are ready to go! Installing and setting up PowerMode is no fuss. The dirty work is done for you.
		</p><p>
			PowerMode has a project management system which allows you to quickly name your new project and then get started. Your project files are saved in a pre-defined directory for convinience but you have full control over where each project is saved.
		</p><p>
			PowerMode does not hassle you to open seperate programs to optimize spritesheets. You just import the individual frames of animation and built-in spritesheet generator does the work for you. Saves you another step.
		</p><p>
			Soon PowerMode will have a built-in sprite editor. This will mean you can draw and edit the your frames of animation without leaving PowerMode. At PowerMode's current alpha stage, the sprite editor is incomplete, buggy and unpolished. Soon, this will not be the case.
		</p><p>
			PowerMode uses simple graphs to define the behavour of objects in your game but soon you will be able to write code for your game. PowerMode will have its own programming language. I want to create my own programming language so that I can make writing code as beginner-friendly as possible. I also want to make it perfect for experienced developers too.
		</p><p>
			PowerMode has a built-in scene editor. This allows you to drag and drop objects around a scene. You can use this to design your levels.
		</p><p>
			PowerMode has a built-in asset management system. PowerMode conviniently saves you the hassle of fiddling around with that scary command prompt thingy. Objects, sprites, scenes and sounds are all defined in PowerMode!
		</p>
	<!-- #quick.subSection --></div>
	
	<div class="subSection" id="amazing">
		<h2>
			<img src="img/amazing results.png" alt="Amazing Results" />
			Amazing results
		</h2>
		<p>
			PowerMode is designed to be beginner-friendly. PowerMode does not give you an overwhelmingly complicated interface, yet it gives you an exciting and powerful way to develop games!
		</p><p>
			I plan to develop quality documentation, tutorials, blog posts and more; to give you the best learning experience.
		</p>
	<!-- #amazing.subSection --></div>
	
	<hr />

	<div id="footer">
		PowerMode &copy; Oliver Scott-Brown 2014
	<!-- #footer --></div>
	
<!-- #top --></div>

</body></html>

Code (markup):

When/if I have time later I'll toss together some CSS for that implementing a semi-fluid elastic responsive layout for screen media... and then I'll write up a section by section breakdown of the how/what/why of the code so you can learn from it. Really it's not rocket science to work direct from the code -- though a lot of people seem to try to turn it into such either out of ignorance, ineptitude, or just plain wishful thinking.

... things like WYSIWYG editors being WAY too much wishful thinking when it comes to building a website. Though given the TOPIC of said site, I may end up having a hard time convincing you of that...

 

Sorry for the delay, ended up spending the afternoon with a ladyfriend and didn't get back to this until about twenty minutes ago, but here's that rewrite:

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

As with all my examples the directory:
http://www.cutcodedown.com/for_others/OliverSB/

Is wide open for easy access to the bits and pieces. I also tossed a .rar of the whole shebang in there for you.

I'm pulling a fast fade (been awake some 20+ hours now) but tomorrow night (since I'll most likely be snowed in) -- or sooner if insomnia kicks in -- I'll start in on doing a section by section breakdown and explanation of the how/what/why of the rewrite and how it works. For now notice that it's semi-fluid and elastic, and if you test the browser default font sizes it's elastic as well. It uses EM fonts on all flow text, only resorting to px for the image replacement header -- which axes the fancy image to show the text at smaller display sizes. As you have a lot of PX based content (images) it uses both EM and PX based media queries to target the different element types.

It also pulls the normally stupid "hide the menu for mobile" stunt but does so WITHOUT any scripttardery and with text to explain what the **** is going on instead of the uselessly vague "three bar button" garbage most people use. I also implemented the dropdown you had some code commented out for.

As I pretty much followed the procedure I outlined in my previous post it also gracefully degrades CSS off, images off, or a combination of the two. I went through and optimized the images and since it axes all the pointless framework bloat, it's less than a third the total filesizes and half the file-count. Low total file count is a really good thing to try for as each extra file past the first eight can take anywhere from a fifth of a second to a full second in handshaking regardless of connection speed. On that front I would possibly consider

Also I switched to non-transparent PNG instead of the alpha transparencies you were using as those files are larger and take longer to render. It also allows for lower palette depth which pays off even better in file sizes.

Some layout liberties were taken to try and "clean it up" a bit appearance wise -- evening out paddings and margins, and making better use of available space with your "cascade" of icons in one of the subsections. Likewise the images/icons were resized for better consistency of layout.

Hope this helps, illustrates what I was talking about, and I'll post up a more detailed breakdown sometime over the next day.

 

... and apologies for the delays on a rewrite, I'm dealing with everyone running around like chickens with their heads cut off over a "blizzard" that's SO nasty I would be hard pressed to call it flurries. This is Keene NH, not Texas! There's 4" out there (We were SUPPOSED to have 2 feet by now) -- the plow drivers should still be in bed instead of racing up and down our street!

In any case, let's get you a HTML breakdown.

I start out with XHTML 4 Strict. I use XHTML because I prefer it's clearer/cleaner/more consistent structural rules where you have explicit closures of "empty" tags. Keep in mind that when the specification says "empty" tag they mean a tag that cannot have content, NOT tags that don't have content. Even though <div></div> is 'empty' it is NOT what the specification means when it says 'empty'.

I use the STRICT flavor as TRANSITIONAL means "In transition from 1997 to 1998 coding practices" and as such the validator will bitch at me if I try to use anything that has no business on a new website any time after 1997. (No matter what the HTML 5 jacktards with their bleeding edge of 1997 coding practices say).

<rant>
I do not use HTML 5 for a host of reasons -- a lack of support in IE8/earlier being one, not trusting scripted polyfills being another, and in general it offering ZERO REAL WORLD IMPROVEMENTS OVER 4 STRICT / X1.0 STRICT being the most important. The ONLY reason to deploy as HTML 5 being if you need one of those stupid malfing media tags (AUDIO, VIDEO) that are being shoved down our throats by Apple being a bunch of jackasses. The rest of the specification does NOTHING for improvements and simply re-introduces redundancies that HTML 4 STRICT was trying to get rid of!

Honestly, I can't fathom how anyone who understands what HTML is and what it is for would voluntarily choose HTML 5 --- but to be fair I say the same thing about ****tarded code bloat BS like Turdpress, jQueery and Bootcrap.
</rant>

You'll notice I use a lot more carriage returs and tabs than most -- I'll take code clarity over the re-re "stuff everything onto one line" idiocy that does nothing but encourage errors. You'll see this more in my CSS. I never understood how anyone finds stuffing all their attributes onto single lines was usable/legible/easy to follow -- that most people who do so usually accidentally declare the same property more than once or fails to notice even their own code setting thigns supports the notion that stuffing it into a single line is stupid.

You'll also notice that for commenting I don't waste time saying "start content" since, well, <div class="content"> should be pretty damned obvious what it is -- if you dont' understand that and need a comment for it, you probably shouldn't be making websites. Likewise I DO use closing comments so I know what class or ID is being closed thus:

<!-- #future.subSection --></div>

There is NO reason to waste time saying "end" or "close" since that's what </div> means. I put it before the closing tag as in some versions of FF and IE having a comment between sibling-level tags can trip some nasty and painful to diagnose rendering bugs like "double render" or "disappearing content". You put the comment before the close it can never end up between sibling-level elements.

Moving on, the first unusual bit is our viewport META. This tells mobile / small display browsers that we know what we are doing so do NOT attempt to "auto-scale" or ignore our CSS font sizes. I set both height and width as some Android browsers report height as width when rotated. (that one can drive you nuts to diagnose since a LOT of rubbish 'frameworks' don't set that value!) There are other values some frameworks and developers set there which are utter and complete bull since typically all they do is break the ability to use zoom. See "maximum scale" which you should NEVER set there, but thousands of developers do out of ignorance.

The keywords META should be seven or eight words that exist as CDATA between <body></body> that you want a slight uprank on, totaling less than 128 characters. You go outside of those restrictions it's nothing more than a waste of bandwidth as it WILL be ignored. Many people say it's ignored outright, but that's just their ignorance on how it is supposed to be used in the first place.

The description META is for text to be shown below the contents of your TITLE tag on a SERP. (search engine results page) -- that is ALL it's for.

NEITHER is a place to 'blindly stuff keywords' like most of your SEO halfwits will try and tell you with their hoodoo-voodoo scam artist BS.

The LINK for the screen media CSS has two things one should always be doing that most people seem to skip. The first is an actual MEDIA target set -- in this case screen, projection and TV. They are all basically screen target devices with many browsers in KIOSK mode reporting themselves as projection and there still being TV browsers in circulation (like the Wii which runs a flavor of Opera 10). The second thing is a meaningful filename saying what the CSS is for instead of some uselessly idiotically vague name like "style".

I use a single monolithic CSS file for a reason -- first it's less "handshakes" as the more separate files you use, the slower the page will load regardless of connection speed. Second, if ALL of our style for ALL of our pages is in the monolithic CSS file we are pre-caching sub-page appearance, meaning navigation to secondary pages will use less bandwidth, loading and rendering faster. Anyone telling you to use the STYLE tag, to break it into separate files, or to skip having a MEDIA attribute probably doesn't know enough about HTML to be flapping their gums on the subject, and are in desperate need of a quadruple helping of sierra tango foxtrot uniform.

The title tag I dropped the "- Home" part since there's no real reason to say that on the home page. For subpages I'd put the subpage title BEFORE the site title as it's more useful that way when telling pages apart as tabs. Remember that TITLE exists for the sole purpose of identifying the window or tab, and to be the text inside the anchor on a SERP.

I always put <html><head>, </head><body> and </body></html> together on the same line as a reminder that NOTHING should EVER, EVARR!!! be put between those tags other than whitespace. IF the only thing valid between them is whitespace, and that whitespace is ignored, why put anything there in the first place?

I put in a #top wrapper since we're aiming for a semi-fluid layout and BODY can't be trusted for that. I call it "top" so you can target it with a hash in anchors if so desired at some future point. (Like if you wanted that stupid scripttard "back to top" floater.) I wrapped all content in it so that we can set any desired width properties for the whole layout there.

H1 -- a H1 is the heading under which all other headings indicate the start of a subsection. Unless you are using 5-tard bull with the idiotically redundant SECTION tag crap you really should only have one H1 for the entire page. We make it a link to the root of the site, put text inside it, and a span for a image replacement sandbag since all you had in the head was that image. It's usually a safe bet with the H1/Logo that there will be some form of image replacement.

DIV#mainMenu - normally I'd say there's no legitimate reason to have a DIV around the UL, but with smaller displays it often helps to hide the menu behind click-able links. I put those links empty in the markup and use CSS to implement it. The "normal" approach most people are using these days involves a bunch of pointless mouth-breathing scripttardery and a uselessly vague "three bar" icon. Me, I use text, but we'll plug that in when we get to styling it.

The UL inside it is simply a normal nested menu. I re-implemented the dropdown for your downloads (which was commented out) so as to show how to implement that without any scripttardery either.

DIV#mainSection - your main sections and subsections seem to get a lot of the same styles, but I used two different classes for it so any major differences could be targeted. These DIV are just wrapers for style and provide no semantic meaning.

UL#pageMenu - this is basically a menu so I made it a list of choices to provide proper semantic block level wrapping.

From there the various paragraphs of flow text remain mostly unchanged. That was one of the few things that were RIGHT in your original.

ul.linkList - smaller local links also seemed like a list of choices, the block level LI making it clear that they are separate entities and not a run-on sentence -- since "Download Watch Video" is pretty much gibberish. That's why running multiple A back to back without block-level containers is just ignorant nonsense unless they are empty / scripting / CSS content elements. (see .showMenu and .hideMenu in #mainMenu for when it IS allowable)

.subSection - the subsections of the page each get a unique ID so you can target them from #pageMenu, but also so any unique style can be applied, while the class lets you target them for like values.

.subSection .logos - I put the various logos in a DIV so they could be en-masse styled as a single column if desired. There is NO reason to be using TABLE for these as this is quite obviously NOT tabular data.

.subSection .content - a wrapper so that we can target just the content of the subsection for styling; the most common such use being to prevent float de-indent after the logos.

.subSection H2 - the H2 indicate the start of a separate subsection of the H1. That's what it MEANS. (and why HTML 5's SECTION tag is pointless redundant bull!).

.subSection H3 -- just as H2 is the start of a subsection of the H1 before it, a H3 is the start of a subsection of the H2 preceding it. It's semi-debatable if it's actually proper given the lack of content after each H3 (a single link), but I'd allow it as it's not really abuse.

You had paragraphs inside their own TD for what I made headings -- meaning you had "no logical document structure" leaving things like search engines, screen readers and non screen-media targets wildly trying to guess what those bits of text actually were.

HR -- horizontal rules DO NOT MEAN DRAW A LINE ACROSS THE SCREEN!!! They mean the start of a subsection of the page where a numbered heading is unwanted or unwarranted. The most likely candidate for such placement would be to separate the footer from content before it when there are no numbered headings in the footer. In professional writing a horizontal rule could be anything from a line, to a double-line, to three asterisks, to an ellipsis, to a row of ellipsis, to just about anything that says "this is a new section of the chapter".

#footer -- this DIV exists solely for styling purposes of that content. As said content isn't part of the article/site topic and is barely a complete thought, it does NOT warrant a paragraph around it as it is NOT a paragraph.

Close out #top, BODY and HTML and that's it for the HTML.

I'll get on writing up a CSS breakdown.[/b][/b]

 

On to the CSS:

When I build my screen layouts, I like to start with the lowest common denominator and then add responsiveness to it. MOST people seem to think that lowest common denominator is mobile -- but honestly that approach usually just ends up a giant middle-finger to people on desktops or older systems. I prefer to use non media-query capable desktop browsers as the starting point, since then you have proper graceful degradation on anything that doesn't know media queries. You'd think that would be common sense, but really sense isn't all that common these days.

The first thing I do in my CSS is use a small reset. Browsers do NOT start out with the same default appearance on all elements, and a proper reset will make those elements behave mostly the same.

There are larger resets like Eric Meyers stupid "Reset reloaded" which is so massive as to be a framework unto itself. What makes said resets so stupid is that they are four to eight times larger than need be and screw around setting values that are NOT inconsistent cross browser and you are most likely to end up changing anyways.

There are smaller resets like the so called "universal reset" of "* html { border:0; padding:0; margin:0; }" but that can really make working with certain form elements painful thanks to Firefuxxors and Interdebt Exploder having their heads wedged up their asses on how INPUT, TEXTAREA and SELECT recieve padding and line-height.

The one I use is a nice safe middle ground, and at a quarter of a K is a non-issue size-wise for the peace of mind it brings when it comes to declaring paddings, margins and widths on elements.

hr -- I turn off HR for screen media as usually there will be other visual queues as to the change in topic/section. As such HR in my markup are there for all NON-Screen targets and semantics. (in other words, using HTML properly)

@media (max-width:480px) { * Safari and IE on mobile will tend to still try to screw with our declared font sizes despite our viewport META telling them not to on really small devices. As such we basically have to bend them over the table and make them our ***** by once again telling them to leave the font sizes the hell alone. I put this in a media query for small displays since sending this to desktop Safari breaks the ability to zoom. Yet it doesn't break zooming on iOS Safari, which is, well... really jacktarded BS; but did we mention that's an Apple thing? Most EVERYTHING they do is jacktarded BS that makes even M$ look good!

body -- I set the font size and family I'm going to use on 99% of page content here, since everything will inherit from this element. Simple. Declaring the font size in % means it is based off the browser default size which can be different from system to system as that's a user settable preference. I also use the condensed property so I can set that tall 160% line-height. I find taller line-heights easier to read, and as a rule of thumb if you change the font size redeclare your line-height. You CANNOT trust inheritance of line height. Some halfwits out there are saying you can "omit the metric" to have proper inheritance -- "line-height:1.6;" -- for example, but that does NOT work properly in all browsers despite their wild claims to the contrary. To the point that if you call them on it and link them to screencaps of it broken, they'll use it as an excuse to kick you off their forums instead of admitting it doesn't work...

The text-align I threw in for laughs so as to make the page center in IE 5.x. You could probably lose that, but I wanted to show how easy it is to make a website that has modern methodologies but still works all the way back to browsers from 1999. Laughably much of CSS3 is stuff IE 5.x could do. Some CSS3 properties were even introduced in IE 5 some seventeen years ago!

#top -- that semi-fluid elastic layout I mentioned? Here it is. 95% width allows some border to show at intermediate resolutions, the EM based min and max width bases the limits on the default font size.

* html #top -- * html is a 'css hack' for targeting IE6/earlier. The comment itself explains what it's for:

	/*
		legacy IE knows not min/max width, so shove a fixed width
		at them. OH WELL, they should be thankful we bother thinking
		about them at all at this point!
	*/
	width:768px;

Code (markup):

A LOT of developers wouldn't even bother with that much at this point. To me it's force of habit and not a big deal since everything else I do will still gracefully degrade in those outdated browsers. After all that's what CSS is supposed to be for, if the fancy bits don't work it's still supposed to deliver a useful page!

h1 -- the position:relative is so we can absolute position the span over the text. When an element has positioning (fixed, relative, absolute) any child element bases it's x and y positioining off that parent instead of the window.

Positioning the span over the text is called "gilder-levin image replacement" and is one of the few ways to have fallback text behind an image so that search engines, screen readers and other non-screen "user agents" have something to look at.

As there is a image interaction this is one of the few times it is acceptable to decalare font sizes in pixels. The line-height plus padding is equal to the 256px height of that image, so we don't have to declare height on it. Generally speaking unless working on a image itself declaring height on ANYTHING is a bad idea! Same reason positioning flow elements / major content areas with absolute positioning is rubbish!

h1 a - style, yawn.

h1 span -- as mentioned, we absolute position the span over the text, setting the width and height to the image and loading the image as it's background. Poof, text disappears but will show styled when images are disabled.

#mainMenu .showMenu,
#mainMenu .hideMenu -- these are for mobile/small screen, hide them for now. We'll show them when appropriate in the media queries alter. I set the background on them now for... well, because I can.

#mainMenu -- Legacy IE miscalculates the span vs. content size on the H1 so it overlaps the menu. Setting position:relative makes sure the menu depth-sorts over that miscalculation 'erasing' it. Know how I said fixing the height was a bad idea? Here's the exception. We'll be building the menu with floats, which could break if it goes multi-line and won't let us position our subsections after it right. Since we'll have media queries to re-arrange when the window is too small, we can just fix the height and be done with it rather than dicking with float containment.

#mainMenu ul -- turn off bullets on the list, fix it's height as with #mainMenu so as to draw the background at the desired height, set our line-height to an even measurement, and from there just add our various outer styles.

#mainMenu li -- the relative positioning is much like on the H1, but in this case lets us position our dropdown menus (if any). Floating them pops them all onto one line. The display:inline technically shouldn't do anything as floats are always "block" behavior, however in IE it trips some sort of weird bugfix for margins. The zoom:1 fixes the dropdown posititioning in IE7/earlier as there's this pain in the ass called "haslayout" in those browsers; elements lacking "haslayout" failing to report their size and position properly to anything inside them. Likewise the vertical-align:top; helps prevent IE7 from screwing up at certian widths with the so called "staircase" and "3px jog" bugs.

The overflow:hidden is the real magic. Absolute positioned child elements do not report their size to parent elements, so if it is positioned outside the element, it will be hidden/not shown... basically that's what overflow:hidden does, is it chops off/hides anything outside the non-positioned parts of the element and/or it's declared size. That's why our next element:

#mainMenu li:hover -- exists, when the mouse is 'hovered' over the LI, the menu gets shown. Clean, simple, easy, works in IE7/newer. IE6/earlier doesn't get the dropdown, OH WELL, that's why your parent anchor for that dropdown should link to a page that has links to the same thing as the dropdown... if you REALLY care about IE6/earlier you could add something like peterNed's CSShover3.htc to the page.

It's one of the cleanest and easiest ways of implementing a menu.

#mainMenu a -- we also float these to avoid IE8's dreaded "staircase bug" and to implement block behavior so that top/bottom padding is obeyed. (display:inline behavior, the default for anchors is supposed to ignore top/bottom padding!) -- from there it's just style and color. To implement those separators without extra markup elements I just used a border and a white box-shadow.

#mainMenu>ul>li:first-child a -- set the border radius on the first one to match the container. Otherwise on hover you'd see a square bit poking out of the container. I use the adjacent sibling selector ">" so as to target JUST the first LI and not any of the nested ones.

Used to be we said don't use the adjacent sibling selectors as older browsers don't know it, but since what's being targeted is border-radius which older browsers don't know either, that argument holds water like a sieve.

#mainMenu ul ul li:first-child a,
#mainMenu ul ul li:last-child a -- as the dropdowns have rounded corners, we need to round off the corners of the first and last elements inside them.

#mainMenu ul ul - the list inside our list is our dropdown. By absolute positioning it down 2.5em, same as our parent UL's height, it gets chopped off by the overflow:hidden until you hover. The left:50% with a fixed width and a negative margin equal to half that width centers the dropdown on it's parent anchor. From there it's just colors, borders and other styling.

#mainMenu ul ul li,
#mainMenu ul ul a -- unsetting the float and setting them to display:block makes them display as a column instead of a row.

#mainMenu a:active,
#mainMenu a:focus,
#mainMenu a:hover -- colour them when you hover them. YAWN. It's a good idea to use :active and :focus in addition to :hover so that people using keyboard navigation aren't left out in the cold. (it's a shame there's no :focus for non-user input elements). :focus is SUPPOSED to be for when the element has 'focus' by keyboard navigation, but some older browsers ignore that and use :active instead... :active means it's the last thing clicked on which is why sometimes if you hit "back" in the browser it will remain lit up. Small price to pay for accessibiliy IMHO.

... and that's the whole menu with it's dropdowns for larger displays.

.mainSection,
.subSection - values these share like padding, margins, borders, etc. I do a clear:both just to be sure we're past the floats in the menu. The overflow:hidden in this case wraps any floated elements (like the logos) instead of ignoring their height in modern browsers, and the zoom:1 trips the same behavior in legacy versions of IE that ignore overflow for that purpose again thanks to haslayout. In another laughably pathetic bit of implementation, IE 7 and 8 only recognize overflow:hidden for float wrapping because they made it a haslayout trigger!

#pageMenu - those large images you had as links. For now we just turn off bullets and center these elements.

#pageMenu li -- setting these to display:inline basically strips formatting off them. For some reason IE7/earlier can't vertically center the child elements by size if the parent isn't aligned top -- REAL browsers ignore that vertical-align.

#pageMenu a -- making these inline-block lets us set width on them and have bottom padding obeyed. I set 24% width as inline-level elements usually leave 0.4em "whitespace" between them, and it leaves a bit of extra padding left and right on them. Rest of it is just FaC. (fonts and colours)

#pageMenu img -- I added padding-bottom for when they wrap at smaller display sizes.

#pageMenu li a:active,
#pageMenu li a:focus,
#pageMenu li a:hover -- colour when hovered. YAWN.

#pageMenu li a:active img,
#pageMenu li a:focus img,
#pageMenu li a:hover img -- making them slightly transparent when hovered makes the gray underneath show through to make it look like they are lighting up. Simple but cool effect to help make it clearer that "these are links".

p -- I like to use padding on just one side of my paragraphs so I don't have to worry about things like margin-collapse. That's why the .subsection also have shorter bottom-padding.

.subSection .content -- again overflow:hidden for float behaviors, but in this case it's to prevent what's called "float de-indent" after the floated logos. Without this the text would wrap underneath the .logos sections.

.subSection h2 -- simple style for those level headings. I use the full condensed property for the declaration since it's damned near the same number of characters as saying "font-size", "font-weight" and "line-height" -- at which point you might as well make it clear EVERYTHING that's being set.

... and before anyone asks, 250%/120% the first number is font-size, second number is line-height based on that font-size. Shocking how many allegedly experienced developers don't even know that.

.linkList -- those blue links you had. Again we first kill bullets and pad it nicely.

.linkList li -- then set the LI to inline so they're all on one line.

.linkList a -- then inline-block the anchors so we can pad all sides and apply the desired styling. I tried to replicate what you had there using CSS3 without resorting to the slow and often painful to implement "linear-gradient". The method I used also made the hover states really easy by just swapping out the background color as as the box-shadow colour is transparent.

Oh, on the subject of CSS3, you'll notice I only now use the -webkit prefix and the actual CSS3 value without -moz, -op or -ms. This is because in the latest versions only Safari needs the vendor specific version to do the new CSS 3 properties. Even Chrome has given the vendor prefixes a giant middle finger -- and the world is a better place for it.

.logos -- float 'em, pad 'em. Done wit' 'em.

.logos img -- display:block puts them all on their own line, margin to space 'em apart.

#footer -- bottom padding, since the .subSection before it pushes #footer down with its bottom margin.

... and that's the non-media query default layout. On to the queries:

the first two queries are declared in pixel. USUALLY I say 'don't do that" but these target images and anchors around images -- things that are by definition based in pixels. You target pixel elements, you use pixel queries. You target font elements, you use font size based queries.

**** @media (max-width:660px) ****

#pageMenu img -- shrink the images 50% so they still fit as a single line.

**** @media (max-width:480px) ****

#pageMenu a -- make them fit two per line instead of four per line since we're just too tiny to do anything else with them.

The rest of the media queries are based in EM since they adjust actual content elements.

**** @media (max-width:40em) ****

h1 - reduce the padding and align the text.

h1 span -- so we can hide the image and show a nice clean text header instead.

#top -- switching to auto width so as to use as much of the available screen space as possible, and narrowing the minimum width to the smallest mobile device we are likely to encounter.

This next part is just plain cool.

#mainMenu .showMenu,
#mainMenu:target .hideMenu -- when #mainMenu is not the current "target" of a hash, we show ".showMenu" and hide the ".hideMenu" anchors.

#mainMenu:target .showMenu -- while if it is targeted, we hide .showMenu

#mainMenu .showMenu:after,
#mainMenu .hideMenu:after -- we set up some generated content's appearance.

#mainMenu .showMenu:before,
#mainMenu .hideMenu:before -- and even more appearance, this is for some text generated icons which will show on the right thanks to being floated.

#mainMenu .showMenu:before -- generate a down-triangle icon

#mainMenu .hideMenu:before -- an up-triangle.

#mainMenu .showMenu:after -- text saying "show menu"

#mainMenu .hideMenu:after -- text saying "hide menu"

#mainMenu ul -- menu hidden being the default state, we strip the large screen style off it and hide it with display:none;

#mainMenu:target ul -- while if the URI ends in #target, show the menu.

... and boom, the fancy show/hide menu thing with a clear text label, useful icon, and not one bit of scripttardery needed.

#mainMenu,
#mainMenu ul -- we also strip off a bunch of large screen styling for the smaller displays.

#mainMenu li,
#mainMenu a -- and make sure that the menu appears as a column instead of a row.

#mainMenu ul ul instead of having the dropdown be a dropdown or flyout which sucks on touchscreens, it's simple enough to just show it inline and pad it in on one side.

#mainMenu a -- normally if you have to resort to !important to override ALL instances there's something wrong with your selectors, but in this case it's far simpler than declaring all those first-child and last-child with every single selector chain we had above. One of those very special exceptions to the rule.

.mainSection,
.subSection -- since we have less screen space to work with let's strip off all that excess whitespace so we can fit more of what's actually important -- THE CONTENT -- on the page.

.logos -- which means adjusting the spacing around the logos since we changed the space above and left of it.

.subSection h2 -- and shrinking the text size and padding on the headings doesn't hurt either.

#footer -- likewise we need to change out the footers padding to match.

**** @media (max-width:30em)) ****
.subSection .logos -- you get down this tiny and there's just no way to fit those massive images. Since they are more decoration than they actually are content, just get rid of them entirely as serving no real legitimate purpose.

... and that's the how/what/why of it. I know that's a lot to take in, but go through it, any questions fire away. That's how things SHOULD be done... and rarely are.

No stupid WYSIWYG, Dreamweaver, off the shelf BS frameworks or idiotic "preprocessing" needed.

 

Excellent Post! ANYONE who reads this will learn something.