How's my code? Improved or not?

Hello guys.

I've been doing some exercise. Please review on my codes, especially CSS. I'd want to sharpen my samurai sword of HTML & CSS.

I helped some guy on this forum with this.
http://mrjunior.my/rolodex/e/

Happy reviewing!

 

Now, take this in the spirit it's offerred... there's just NO getting around it or putting this nicely: The design itself is inaccessible crap!!!

Fixed width, px metric fonts, illegible color contrasts (cyan on white). The trifecta of /FAIL/ that seems more and more common. Is there some book or idiotic tutorial out there basically telling people to vomit up sites this way?

Even the main menu looks like it's labels for the search, not the menu... That's BAD.

Under the hood it's problematic too... H3's inside LI on what probably shouldn't even BE lists? Here's a tip, if it's big enough to HAVE a numbered heading, and since numbered headings indicate the start of a subsection of the higher order (lower numbered) heading before it... wouldn't that make the UL/LI redundant to the numbered headings? Why yes, yes it does.

It also suffers from tables for layout on elements that are NOT tabular data... inside them you have mulitple paragraphs around a word or two apiece, far short of a phrase, much less a sentence or paragraph. There is NO reason for those to be inside P... or a table.

You didn't close your LI, which while 'optional' in 4/5 crap, is often unclear and leaves the browser to pretty much GUESS. Guessing usually sucks. Likewise the FORM is probably NOT a menu item, so it doesn't even belong in the list... and don't hide the blasted LABEL!

You probably also don't need to say 'end' on your closing comments since that's what </div> means... and it might be nice to know if it's a class or a ID being closed. You are also using an image replacement method on the H1 (display:none on a nested span) that pretty much defeats the entire point of using image replacement in the first place!

You're also using a framework sized train wreck of a reset, HTML 5 doctype around what appears to be 4 tranny, (not that there's a huge difference in my mind), your media stack is incomplete, and the name "design" for the CSS file is just a little... vague. The PX metric fonts in the CSS are bad, particularly on content elements, something made even worse by your failing to restate the line-heights when you chance the font-size, which is why things are spaced rather oddly on 120dpi systems.

I also don't know what the blue blazes is up with the oddball/goofy indenting style in the CSS... That's just a confusing mess.

I mean, you've seen what it does CSS off, right? Always, ALWAYS write for non-CSS layout without formatting first.

 

looking good but need more design to make visitor came and came back

 

First of all, here's the link to the initial work — http://vfgergegrge.com/dd.html
I help him restructure.

@deathshadow. I really appreciate your time reviewing, and I really love your feedback, but having you ranting like this, I can't fathom. Let me get this straight.

1 - Fixed width layout (How do you make fluid? I read about 960, is that not best practice?)
2 - px metric fonts—I just read your article on this. I'm trying to get the grasp of it.
3 - Color contrast—I have to fix my screen and my know-how on the colour codes.
4 - Main menu confusion—I guess I shouldn't follow his design, I thought of the same, too.
5 - H3—I guess that makes sense with ordered list.
6 - Table—It is actually for tabular data. The table is going to be filled with information from a database. It's just a placeholder. If I can't have P inside it, what should I use? I saw on your sites you're using it.
7 - Closing Li's. I guess I didn't read your posts clearly, or maybe I got it wrong. Is it about the p that doesn't require closing tags?
8 - Forms shouldn't be in list, ok, but why shouldn't I hide the labels? I thought it was like a hidden H1 span?
9 - I lost you at the image replacement's purpose.
10 - Now, now. This doctype. Which doctype serves the best?
11 - Indenting styles? I also lost you at this one.

I created this one with plain HTML first. When it appears to be OK plainly, I wrote the CSS. I will improve.

Thank you for reviewing my codes. But as I know it, I have improved from the last version, divs heavy, and whatnot. You'll be seeing me again, maybe not samurai sharp, but it's good enough to belong in the hotel's kitchen, god willing.

 

Lemme go through these:

Fluid is easy - stop setting widths on the outermost container and the content area. Fluid CAN have problems with really long lines, which is why I prefer a mix of elastic and semi-fluid. Elastic means declaring sizes in EM so things like column widths and maximum width are

A typical declaration for that would be something like:

#pageWrapper {
	/* percent width to show some body background at sides */
	width:95%; 
	/* min-width for browsers like IE7 & 8 that don't do media queries */
	min-width:768px;
	/* max-width in EM to auto-size entire page based on default font size */
	max-width:68em;
	/* and center it */
	margin:0 auto;
}

Code (markup):

768/960/976 or any other 'fixed width' is accessibility trash -- it does not auto-expand with the fonts, often forces the use of px metric fonts, and it fails to shrink for smaller/lesser devices... and no matter what people have said the past twenty years, there will ALWAYS be smaller/lesser devices... and larger devices that need a larger default size. Fixed width is just sloppy inaccessible site design... admittedly there are a LOT of things people put on websites that are NOT compatible with fluid layouts. Full width image banners or "three across equal width" elements for example -- which is why I don't put those on my sites and actively discourage their use!

If the fonts are decalared in %/em they default off the browser default font size - which in turn, particularly for Windows users, can vary in size greatly... this is on purpose so that the user can set a comfortable size and have everything adjust to it automatically. Not all computers/browsers default to 96dpi aka 1em = 16px... I've run large fonts/120dpi (20px) since Windows 3.1 -- now it's called "Medium", with Win 7/newer calling large "144dpi" -- that's 24px... and my media center PC I've got set to XL, a whopping 192dpi / 32px. Using these settings one no longer has to dive for the zoom assuming a page is coded properly. This is why the WCAG says use %/em to the exclusion of all other sizes; I'm not THAT strict about it since I realize there are things like image replacements or fancy background images that force you into it -- in which case I consider 12px the smallest acceptable size for all-caps and really get squirrelly below 14px... but there's NO excuse for most headers or flow text to be anything but dynamic size (% or EM) other than bad intentionally inaccessible design.

... and beware that % or EM are based on the size declared on a parent element, so if you did something like "font-size:12px;" on BODY, any %/em used across the entire page is pointless. There's "REM" is based on the browser default, but browser support for it is still missing/nonexistant.

The big trick is to know the math.

L = 0.3R + 0.59G + 0.11B

Take the red, green and blue values for your foreground and background, plug them into that formula, and figure out the difference. Anything less than 50% (128 on a scale of 0..255) has major usability concerns (possibly invisible to half the population!), at 60% the number drops to only around 20% having issues, and really the ideal should be 70% or more (192). Also beware that small fonts that render narrow/thin require even more contrast on systems like Microsoft cleartype or the freetype engine used by *nix than they do on Apple's blurry everything is bold renderer.

So that white is easy, that's still 255... but the cyan/blue comes out to only 124, for a difference of 130, pretty close to that 50%! If you screencap it you'll find the color declared isn't even getting sent -- the majority of vertical lines are way down at #69A9ED or brighter once rendered in cleartype, which works out to a luminance of 157 for a contrast of only 98 -- that's only 38% contrast; far, far below accessibility minimums.

In the end, the math is what should be used.

Yeah, that just felt funky.

It's a common practice to slap lists around EVERYTHING once people start thinking "is this a list" -- but the question isn't "is this a list" it's "is this a short list of bullet points or other short statements". Good rule of thumb is if you feel the need to use a paragraph tag, multiple paragraph tags, or numbered headings inside it, it's not a list item. Numbered headings in particular as then you just have redundant markup.

Your not treating it as tabular data -- tabular data has rows and columns where the data has obvious headings (TH) and associations (SCOPE)... Treating it as tabular data would be something like this:

<table class="films">
	<thead>
		<tr>
			<th scope="col">Poster</th>
			<th scope="col">Title</th>
			<th scope="col">Category</th>
			<th scope="col">Rating</th>
		</tr>
	</thead><tbody>
		<tr>
			<td><img src="image.jpg" alt="Poster" /></td>
			<th scope="row"><a href="/c/movies/view/183">Bullet to the Head</a></th>
			<td>Action</td>
			<td>6.7</td>
		</tr>
		<!-- etc, etc, etc... -->
	</tbody>
</table>

Code (markup):

You are not using it as tabular data so it has no business being in a table. Tabular data has clearly defined rows and columns where a row is a record, and the columns are separate fields - like on a spreadsheet. If you are stuffing multiple values into each and every TD, you're not treating it as tabular data you are using tables for layout.

It's also not that you can't have P (though P being appropriate inside a table is REALLY rare) but that said data ARE NOT PARAGRAPHS... that's BR's job. (though don't use double breaks like the original, that's padding's job!)

In many ways the original is better on this for using DIV. Even though these are small items, I'd be tempted to make the title/anchors be h3.

In SOME doctypes some tags don't require closes, I think that's just stupid which is why I LIKE XHTML so everything is clearly closed. Wouldn't have been anythign I wrote that would have told you to omit closings on LI or P.

You shouldn't hide the span inside a h1 either, doing so on H1 means there's no images off graceful degredation... so not sure where you got that idea... likewise labels are there for a REASON, to explain what the devil the input IS; don't hide them, why would you WANT to hide them (unless the client has a raging chodo for inaccessible forms because it's "cleaner" looking... In which case the client is an idiot)

Image replacements are there so that when images are turned off there's still useful text there.

http://www.cutcodedown.com/for_others/rolodex/problem.jpg

Images off, you have no H1... Also display:none is objeyed by many screen readers like JAWS, another reason it's bad practice.

I like XHTML 1.0 STRICT -- it's one of the two most recent recommendations (the other HTML 4.01 Strict), forces you to use clearer code thanks to making you close everything, and has other rules in place to make for more 'proper' coding methodologies... HTML 5 is still draft, and frankly so far as I'm concerned with it's endless idiotic redundancies and loosening of structural rules should be shitcanned before anyone even thinks about finalizing it. But as I keep saying apart from ignorance, apathy or just plain wishful thinking, I cannot fathom how anyone would WANT to use HTML 5.

Your CSS is all over the place on indentaion for no logical/sensible reason. It's a mess.
http://www.cutcodedown.com/for_others/rolodex/mess.jpg

Multiline but closing on the last line WITHOUT indents?!? Stuff stuffed onto single lines... even the comments are pointless:

/* HEADER */
#header{

NO, REALLY?!? that's the start of the HEADER, I'd never have guessed :/

There's an article I always link people to on that subject:
http://www.ibm.com/developerworks/linux/library/l-clear-code/

It's meant for C coders, but the lessons apply to all languages. I'm particularly fond of the "Oh, now we're done?" part.

I also just noticed you are using attribute selectors -- aka "input[type="text"]" -- those really aren't real-world/cross browser deployable yet. Unlike CSS3 visual effects which aren't a big deal if they're ignored, the selectors are still problematic at best.

I actually find that a bit hard to believe, but that's likely because the semantics are a bit wonky.

If I have time later I'll toss together a quick rewrite just to show you the how/why of what I'd do different.

 

Clear and great explanation. Thank you very much. You have been very kind and generous. Maybe call you Death Teacher instead. Death Shadow doesn't fit you.

 

LOL With 70 best answers, I wouldn't doubt.

@rolodex: How long have u been coding if you don't mind me asking.

 

About 4 years. How's my writing for a 4 years-old?

 

For four years, not so good. But, you probably aren't to blame; yet. You were taught the wrong way. If you continue, though, ds having told you the right way to do it, it will be your fault. Most of the old-timers at html learned table layouts by necessity. Some are lazy or incompetent and have stayed with pre-1997 methods, but still think they have a clue. They share their ignorance in vainglory with any tyro who will listen.

ds discussed indention, which you asked about. When writing code, whether its, Lisp, C or html and css, always format for readability. The computer doesn't care (except for Python or some other indent sensitive language) how you format it, but it's a human that has to read the code for debugging and maintenance.

First, and there are those who will argue with me, do not use the tab unless your editor converts tabs to spaces on save. Why? Because different editors and viewers (e.g. view source in the browser) have different tab widths. Most seem to default to eight equiv spaces per tab. That's way too much. Five levels of nesting will put the line's start half way across the page. Instead, use two or three spaces per tab. I prefer two spaces for html and three for php and javascript. CSS, I indent four spaces since it's a single level only. I want the selectors to stand out as I scan down. I do not want them to get lost as they do in your faux nesting.

In html, indent two spaces for each level of nesting, and insert a blank line between sibling elements. The object is to let your eyes see the structure of the document as they scan down the code. (Btw, a missing closing tag stands out like a preacher in a brothel using this formatting.)

In css, indent the rules. Insert a blank line between rule sets. Put each property on its own line. It's not a bad idea to put each comma separated selector on its own line also.

If these seem to be micro-managed, consider that I've never been that much of a developer; my job was fixing broken pages. Believe me when I say that good formatting means easier debugging and maintenance; not to mention fewer bugs to begin with, since the formatting helps you spot errors while they're fresh.

Regarding the table. That is, indeed, not a table unless each movie is a record with its title, genre and rating fields. I'd structure it as an unordered list containing the image and a definition list. The dl because you essentially have a hash list or associative array. A table is a positionally related structure. If you can re-order in either direction, and you can, it's not a table.

ds and I disagree on the use of the paragraph tag. He defines a paragraph as a grammatical element, whereas I use the typographic structural definition since html is a structural markup language. In the end, it probably doesn't matter a whole hill of beans whether you do it ds's way or the right way. So, yer pays yer money and ye takes yer cherce.

cheers,

gary

 

You're right, I learned this the wrong way—by reading only on the surface. It's not my profession, I'm in the F&B industry. Now I have DP to turn to, it's building up my confidence.

This is great tip. Never thought of that. I indented it as such to help me understand which belongs to which. I've never work in a group before, so now I understand. Thanks.

This table thing—Noted!

I'll better myself in my next code. Thank you so much for taking your time to review such ugly code. I appreciate this.

 

I'm one of them -- keep your tabs as FARKING tabs, that way the next poor slob who tries to deal with your code isn't stuck with YOUR preference on how wide a tab should be... some people like 5, some like 3 (unixtards), I prefer two (I'm old school borland) -- and no matter how good the editor you are using is at converting leading spaces to tabs, they most always make a total mess of it.

TAB, easy -- one character, always works... and if you have a GOOD editor you can block indent and block de-indent by just selecting and hitting TAB or shift-tab... something that ALSO turns into a total train wreck of asshattery if you save as spaces.

Much less the two for one deal, or three for one deal... or even ten to one deal depending on one's preferences.

Typography is layout, layout is presentation, presentation has NO MALFING BUSINESS in the markup. That's what semantic markup is about, saying what things ARE, NOT what they look like -- and what is typography again? You think structure in terms of typography -- which means LAYOUT. I think of it in terms of layoutless document structure / grammar -- saying what things ARE.

Particularly since paragraphs pre-date moveable type, making typography's relevance exactly nil.

But we've had that discussion before; though methinks my arguments against have been refined in the five or six years since we had a go-around on the topic

 

That also depends on the editor - Notepad++ has no problem with that. Let me see what else I have installed...

Netbeans - no problem
conTEXT - no problem
htmlkit 292 - block indentind/de-indent works, but on a single row, only indent works

 

Said I was gonna do a rewrite... took me a bit as I had a couple people ahead of you, but here's what I came up with.

http://www.cutcodedown.com/for_others/rolodex/movies/template.html

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

is wide open for easy access to the bits and pieces.

Semantic markup, logical heading orders, dynamic fonts, elastic + semi-fluid + responsive layout, gave it a few cutesy bells and whistles with CSS3. Another reason not to use a table -- check out as the width changes the number of columns changes, and of course when it gets too narrow the sidebar is moved to the bottom.

Works 100% proper in IE9+ and all modern browsers, does a semi-fluid without responsive on IE 7 and 8, and a crappy little stripe for IE6 since it doesn't know how to do fluid, and these days it's not worth wasting the expressions to fake it. Shockingly, it even works as a crappy little fixed width on IE 5.5

Of course, the cutesy CSS3 bits like the rounded corners, text-shadows and box-shadows don't appear in IE8/lower -- OH WELL. I advise against wasting time bending over backwards to give those browsers a 'optimal' experience, instead as long as the layout is intact and functional, CLOSE ENOUGH. As it is, it's just crazy that it is USABLE all the way back to 5.5 without issue... I mean, who does that? (ok, me)...

Sometime over the next few days if I have the time I'll toss together a section by section breakdown of the HTML and CSS so you can follow along and I can explain how it works.

 

Wow. This is detail. Thanks. I know you said you were gonna give breakdowns and all, but I got to ask before I lose it, some padding/margin you use px, some you use em. Why is the difference?

 

Can you share it with us as well?

 

I'll be posting it in here. Warning, these are going to be long posts -- even for me.

 

Just as with fonts, px is used when there's an image interaction or to deal with things like the px sized borders when elements overlap them. See the H1 for example, it uses gilder-levin image replacement; placing the span over the text to hide it (so images off the plaintext shows up)... therein it's total height needs to be pixels, so it's padded with pixels, as does the negative margin to remove it from flow so the menu and search overlap it. Same for the menu since it's stuck there. I was able to place the search using dynamic fonts by declaring a really large line-height (big enough to fit 200% the default size/192 dpi), but it too needs px padding so it stays the remainder of height left over by the fixed height header.

You'll notice most everything that's actually content is in %/em. That's the 'important' part. The only px padding you'll find there is the gap for placing the images in the gallery. I remove them from flow and use min/max-width on them so they can be different aspect ratios if need be, but still be 'forced' to fit.

The rule of thumb is that when it's 'content' without image interactions (particularly background-image) you should use % or em for accessibility. The moment you have images involved, you are quite often forced into using PX if text has to interact with it -- otherwise that auto-enlarge EM provides ends up blowing out of the image. (either out from underneath as gilder-levin, or out from over it as background-image).

 

Ok, let's break down the HTML... First off I tend to start from the following template for all pages. The rewrite quite obviously uses this:

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

Let's break that down first so we don't have the content parts in the way.

First off, notice my formatting style. I like (unless an element is REALLY short) to put my attributes and value pairs on their own lines. Makes it easier to scan top to bottom to make sure what attributes are shown (since reading accross doesn't provide that), makes it easier to comment/delete just one of them (^y, ^Z) or to select them since, you just click on the line number or hit home followed by shift-end (since stuffed on all one line doesn't provide that). It also plays well with 'empty' elements in XML since it's pretty clear that /> is the end of an element.

I think some people just have crappy little displays or something -- I'd much rather have easy/clear division of attributes so I can scroll up and down, than to try and make sense of the gibberish mess it can turn into as one long line. This is REALLY true of certain META and CSS as a whole. Said practice REALLY works great when you've got screen real-estate to burn, and is part of why I think tabbed editors are a step BACKWARDS in functionality.

Admittedly, I've got a bit more robust a workstation setup than most others:
http://www.cutcodedown.com/images/desktop2013.jpg

Two 1920x1200 in the wings, 2560x1440 center.

But you can see from that how nice it is to be able to edit the HTML and CSS side-by-side; which is why even during prototyping I NEVER put ANY CSS in the markup... why write crappy inlined code you should be removing when finished anyways, when you could have them in separate files in separate windows side-by-side so you can look at the markup you're writing CSS for at the same time! Even on a single display putting them side-by-side can be a huge advantage.

Certainly better and more productive than sucking down screen space for some stupid 'project management' crap like most IDE's seem to want to waste time on.

I always work in XHTML 1.0 Strict -- It's pretty well known by now my opinion of HTML 5, so until HTML 6 comes along and deprecates all the redundancies, I have no plans to migrate past it. The "You must close empty tags" and stricter formatting rules drill good coding practices into you, making it less likely to make mistakes. STRICT of course also means that validation means something -- unlike HTML 3.2 masquerading as 4 tranny, or HTML 5's lip-service.

Most of the META should be familiar -- content-type and content-languae are nothing to write home about. I now ONLY deploy in UTF-8 for the sheer simplicity of dealing with non-english languages as needed; where possible though I try to restrict myself to the bottom 7 bits of ASCII for the template. (ASCII7 also working well with CSS since that's all thats valid IN CSS, no matter what you set with @charset)

The viewport meta tells mobile browsers not to automatically rescale, and instead act like a mobile browser. Most webkit and IE based mobile browsers will try to automatically adjust the zoom as it doesn't expect a website to actually be built with mobile in mind -- pain in the ass when you are actually building wiht it in mine!

The LINK to the CSS isn't anything fancy either, apart from the media type targeting "screen,projection,tv" -- many Kiosks (Opera and older versions of FF) only obey projection, and there are STILL people out there using webTV type devices (shocking as that is) which only obey TV. There is NO reason for most websites to waste time (and handshakes) on having more than one stylesheet per media target... particularly true since there's usually little legitimate reason to have more than 48k of CSS for an entire CMS or forums per media target FOR ALL PAGES COMBINED! apart from the ineptitude of the developer. ...and never underestimate that one, see all the idiots using HTML/CSS frameworks

Notice I put <html><head>, </head><body> and </body></html> on the same line. I do this not so much to save a byte or two (what most people assume), but as a reminder that NOTHING should EVER go between those tags apart from whitespace. (at which point why include the whitespace). Too often you see people stuffing code in there; I did it by accident a LOT when I was starting out a decade and a half ago (To my shame in Nyetscape composer) -- so I started doing this as a reminder and to break myself of the habit.

Also check the commenting style. (ignore the comments on the HR, those are removed from production code) There is a bug where comments between floats or positioned elements can make some versions of FF (seems like every other release there's a regression) and most versions of IE prior to 9 (or if you get stuck in compat mode) have some really annoying rendering bugs -- the worst of which being "disappearing content" and "double render" -- I've seen people throw endless CSS hacks in to try and avoid this, when the answer is simple; get rid of or move the comments.

You'll often see comments like:
<!-- start content -->
<div id="content">

No shit sherlock! Opening a div with the ID "content" is the start of the content?!? I never would have figured that out! No reason to even HAVE that comment.

Then you have these:
</div><!-- end content -->

Really, a </div> is the end of something? You don't need to say end... BUT, knowing what's being closed is handy, but having it after the element means it could end up between sibling floats. Solution?

<!-- #content --></div>

Will NEVER trip the bugs, and is even clearer since we're saying we're closing the ID. There's an article on IBM's Linux Developer site about clear coding I always link to when this topic comes up -- it's written from the point of view of a C programmer, but the lessons apply to most all forms of code, even markup. I'm particularly fond of the "Oh, now we're done? part.

http://www.ibm.com/developerworks/linux/library/l-clear-code/

Notice I also maintain strict consistent indentation using tabs. Just like any REAL programmer in a REAL programming language would. There's no reason not to apart from crappy editors or just plain being lazy. Doing so often saves time in the long term as it's easier to see what's opened, what's closed, and just have everything line up. Can be the difference between validating with no errors on the first try and having dozens of errors reported just because you missed closing a DIV.

I also where possible follow "rule 76" -- which is where if anything in your code that is CODE would break past 76 characters wide, split it into multiple lines. Notice that I do NOT do this on content, which if you have a GOOD editor that indents word-wraps with graphic indicators of such (like flo's notepad2 does) It's a lot cleaner/easier to deal with. See this screencap for example:

http://www.cutcodedown.com/images/textWrap.jpg

Notice how on #footer the editor does a nice job of the wordwrap on the content text. If it's code, force it to stay inside 76px, if it's flow text, let flow do it's job. Also means wordwrap off it's easier to see just the code part.

Ok, onto the meat:
DIV#pageWrapper - outermost wrapper used to set widths or for min-height layouts.

H1 -- As the structurally/semantically most important header (which does not mean "important important" -- there's a difference) under which EVERYTHING on the page is content or a subsection, there should only ever be one and where possible it should be the FIRST content-holding element on the page. Because there should only ever be one it NEVER needs classes or ID's. (Well, ID is acceptable if you want to target it with a hash in the URL). Think of the H1 as the same as in a book or newspaper where at the top of EVERY page is the title of the book or paper. (remembering that the TITLE tag is not a content element and doesn't count for this!). It might appear larger on the front page or cover, that does NOT mean that structurally/grammatically/semantically it isn't a topmost header on all pages of which the content of a page is ... well... content of.

H1 SPAN -- a image replacement sandbag for gilder-levin. This element could be removed and :after or :before with generated content being used in the CSS instead, but IE7 makes a right mess of that as it refuses to depth-sort generated content OVER sibling text.

HR -- the comments on these should be deleted when you start work and understand what they are for. Horizontal rules in semantic markup (and HTML 5 comes right out and says this, one of the few nice things I can say about 5) is NOT for drawing a line across the screen, it semantically indicates a change in topic where a numbered heading is unwarranted/unneeded/not wanted. Remember, numbered headings break content into subsections -- so do HR. Basically, treat it as a H2 without content... Because we might not want that default appearance for screen.css users, we hide them in the CSS.

DIV#contentWrapper and DIV#content -- this double wrap of the main content is done so as to make having a fluid center column easy. There are 'holy grail' layouts that go nutters hacking away at CSS to do the same thing avoiding the one extra DIV -- but being it's so few characters extra, DIV have zero semantic meaning, and much more reliable/simple to just use the extra DIV... I just use the extra DIV.

DIV#extras -- Basically the sidebar. More complex three column laoyuts I'd put two classed subsection DIV inside this (.firstSection and .secondSection) so I could split one column into two (for three total), but in this case we don't need to do that.

DIV#footer -- Gee, I wonder what this is. Again semantically DIV mean nothing, hence the HR before it to make it clear that the footer is NOT a subsection of anything before it.

Close out #pageWrapper and we're done.

So, what happens once content is plugged in? Follow along with the source for:
http://www.cutcodedown.com/for_others/rolodex/movies/template.html

META{keywords} -- right now it's a placeholder, I'm mentioning it because I want to re-iterate that keyWORDS should be a comma delimited list 7 or 8 single words (the exception being proper names like "New Hampshire" or "Free Pascal") totalling less than 128 characters - said words MUST exist as plaintext between <body> and </body>! Keywords IS NOT IGNORED by search engines even when they claim it is! It IS IGNORED when you stuff it full of redundant phrases and dozens of words, don't use commas as the delimiters, and go over that size. It's called keyWORDS -- NOT keyphrases, NOT keysentences, but keyWORDS!!!

Lands sake people it's not THAT hard! -- the abuse of this tag is WHY it's ignored. Use it for what it's meant for, following the actual rules of using it, and it still works! Of course, I think they should actively slap down the rankings of sites that use it wrong; but that would probably pimp-slap 90% or more of websites out there.

META{description} -- another placeholder on the template, this should be a natural language description of the page; the entire reason this meta exists is for the text you want shown after the TITLE tag's content on a SERP. When I say SERP I don't mean it's ranking on the search, I use the ACTUAL meaning which is "search engines result page" -- so when I say "on the SERP" I mean what your search result LOOKS LIKE -- NOT it's placement on it. Pisses me off the SEO retards who don't even know how to use their own terminology!

Keep in mind DESCRIPTION being a non-content element should NOT be weighted by the search engine, which is why keyword stuffing it is abuse that while it may temporarily work, changes to the engine could get you slapped down if you overdo it.

The first thing that gets added in BODY are the extra menu items -- no big deal. We then have:

FORM#topSearch -- There's the search. Right after the menu, has a proper label, proper use of ID and name, in a fieldset so it's all nice and accessible.

DIV#columnWrapper -- a float container also used to apply some padding, this was added during the skinning process to simplify things. Clearing the floats for the footer had some unusual interactions, as did trying to clear the header on #contentWrapper. Sometimes you do need that extra DIV, but only add it when you are 100% sure you have to.

DIV#subSection -- used multiple places on the page, it's there to group together elements that are recieving similar styling, WITHOUT SAYING WHAT THAT STYLING IS -- again, saying what the styling is is presentational, and as such has ZERO business in the markup.

DIV#subSection H2 -- the heading for this subsection.

DIV#subSection DIV.pagination -- This needs a div since "pages" is not a list item, it's kind-of the header for the list. It's NOT enough of a header to warrant a heading tag in my mind, and it's easier to style if kept inline anyways.

DIV#subSection DIV.pagination ul -- The list. I used a span to indicate the current item so as to make it easier to target since LI can be... problematic in some versions of ID, particularly when you want everything on one line. A GOOD pagination system should include 'first','previous','next' and 'last' as options to ease navigation, naturally hiding first/previous if you're on the first page and hiding next/last if you're on the last page.

P.showing -- I gave this paragraph a class when I was adding the responsive layout. Really doesn't need it at wider resolutions, but it's handy to hook it for centering at narrow widths; on the assumption that not all paragraphs on a page are going to be centered on subpages.

UL.gallery -- an image gallery is typically a list of items. It's not a table since the data is not being presented in a tabular fashion.

I wrapped the entire item in an anchor so it can ALL be clicked en-masse and share a hover state. The IMG tag is easy. I added a span to fix the height of the content so we don't have oddball float drops. The BOLD tag is correct in that I'd make the title bold, but NOT because it's getting "emphasis" or "more emphasis" -- which is why STRONG would be semantically incorrect! B and I still exist for a reason -- like say the name of a company, title of a book (when not being cited), etc, etc. From there we have the inner span just to apply different colors and font-weights, without implying any meaning at all.

There's an example a friend on another forums came up with some time ago that more clearly explains B, I, STRONG and EM's purpose than anything else:

<i>GURPS</i>, <b>Steve Jackson Games'</b> flagship roleplaying game, was first released in 1985. Several licensed adaptations of other companies' games exist for the system, such as <i>GURPS Bunnies and Burrows</i>. However, <b>SJ Games</b> has no connection with <b>Wizards of the Coast</b>, producers of the <i>Dungeons and Dragons</i> RPG. <em>No <i>GURPS,</i> content is open-source.</em> <strong>Do not plagiarize <b>SJ Games</b> work!</strong>

Notice that it IS semantically correct to put I inside EM and B inside STRONG since SEMANTICALLY they mean entirely different things!

Moving on... after some 25 of those we finally get to DIV#extra's content:

DIV#browseFilters.subSection -- the .subSection part is the styling hook, the ID is for targeting unique values and for targeting with a hash should one want to add an accesskeys menu to it. Again, simple H2, H3's indicating the start of subsections of the H2 (which is H3's job), and of course some simple lists. On a 'real' site I'd assume there would be more categories than you'd show on those menus, so I'd likely throw anchors on those H3 to that end.

Closing that out we have the footer, which doesn't warrant a heading so we keep that HR before it to say "this is NOT part of <h3>By Name</h3>" or any other header before it apart from the H1.

... so that's the markup; I'll start work on a breakdown of the CSS - which is gonna take a bit longer. (probably longer than it took to write the HTML and CSS)

 

Alright, with the CSS... Break it down... Degenerate into something fool. I just got tired, of doing what you told me to do, that's the breaks boy... yeah, that's the breaks little man. Break it down.

Just like with the HTML, I do have a starting point for my CSS:

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

First up is a simple reset. The simpler 'universal' reset of * {padding:0; margin:0; } can cause problems with sizing form elements what with Firefuxxors and Internet Exploder both having padding around inputs SEPARATE from the padding you can control (and in different metrics too) which is why I try to leave styling inputs alone as much as possible. Likewise there are fat bloated resets like Eric Meyer's "reset reloaded" which is damned near a framework unto itself. I highly advise against the use of that train wreck that wastes more time on setting things to values I probably won't use anyways.

The reset I use (that Dan Schulz gave me five or six years ago and I've barely needed to tweak since) is a nice middle ground. It nulls just the elements that need nulling, and strips border from the two elements that are inconsistent cross-browser.

I hide HR, and I usually leave in the comment explaining WHY. It's included for semantics/CSS off users, NOT screen.css users, so hide it from screen.css users.

Next up you'll see a media query that sets a 'text-size-adjust' value for webkit and IE. On mobile those browsers will start playing with your font sizes to try and make desktop only websites behave -- AGAIN, if you are designing FOR mobile this makes a right mess of things. We have to do this inside a media query because if you do this on desktop, Safari (like the retard it is) will refuse to zoom if these values are set. Since it's only desktop Safari one can hope nobody on desktop will be browsing at 480px or narrower. Good to set it for all browsers in case some other webkit based browser up and decides that re-re behavior is something to emulate. Donja just love how not all webkits were created equal? I do not believe in the equality of ALL things...

Body is just the global font size. 85% in a sans-serif seems correct in most cases and to be the best from a usability standpoint, just as 100% is better for serif (since you need more pixels to render the serifs legibly)... I most always use that font stack on ALL my sites because it has the least legibility issues and is most predictable across rendering engines. NEVER set PX fonts on BODY as that shtups the use of %/EM across the entire page!

I also start out with a semi-fluid #pageWrapper. These are the values I've found are best for two column layouts in non-media query aware browsers. If I was opening up to three columns I would go 10 to 18 more EM max-width, but I do that from the media queries... Notice the min/max-widths are elastic (EM) so the layout will auto-enlarge with the auto-enlarged fonts from the browser or OS preferences. The 95% width is just to add some side padding and reveal some background on narrower widths -- at really narrow widths that would get stripped off. Naturally the auto margin is for centering.

A word about design -- I usually as my first layout build for two columns non-media query, because the largest of the 'non media query' crowd is going to be IE8 and lower on desktop. A lot of people say "build for mobile first" -- to me any mobile worth designing for is going to know media queries by now; designing for older incapable crap makes LESS sense than designing for IE 5.5! When the majority of your incapable backwards re-re's is going to be IE 6 through IE8, design for those FIRST. THEN use media queries to strip off formatting for smaller widths or add more for bigger widths.

Ok, so let's look at the 'real deal':
http://www.cutcodedown.com/for_others/rolodex/movies/screen.css

We end up with the following changes and additions:

BODY -- I set text-align:center so IE 5.5 will center #pageWrapper -- might seem silly to still target 5.5 (especially with what I said a paragraph back about still designing for 5.5), but given that IE6 didn't arrive on Windows Mobile 6 (Windows CE 5.0) until 2008 (what, did you miss the "6 on 6" party? That's ok, so did everybody else!) there are still a good number of handhelds and micro-notebook form factor windows CE devices in use that have 5.5 or 6.0 in ROM. (so it's not like they're upgrading the firmware any time soon). One line of 18 characters mixed with a few simple practices to have a modern responsive site that still works in IE 5.5 is a bargain not easily refused. Kind of like an inch of satin for a machine gun nest taken out...

Naturally the background is loaded on body as well, and always include a color for when images are disabled!

A,
A:psuedo -- Anchors I set some default colors for the entire page up front, and I also set some CSS3 transitions just to make it a bit prettier on modern browsers. Doesn't work in older browsers, OH WELL. Do NOT waste your time worrying about things like transitions or other effects like rounded corners/shadows in older browsers; waste of time, waste of code to do so. They get square corners, hovers that occur instantly and no shadows, BIG HONKING DEAL!

#pageWrapper -- Adds a text-align:left to our starting point so we're back to 'normal' after our IE 5.5 fix. I also widened the min-width because the two column layout falls apart narrower without media queries to adjust it. IE 7 and 8 will still get an acceptable semi-fluid with these values since 48EM at 85% default from the 16px/96dpi default works out to 652px -- entirely acceptable.

* html #pageWrapper -- the classic CSS hack for CSS, I prefer this to bloating out the markup with IE conditionals since really I rarely use it more than twice in an entire stylesheet, and CSS is cached across pages. In this case we're forcing IE6/earlier to use a fixed width, since I6 predates min/max-width.

The above combined with media queries is how we get semi-fluid with responsive on modern browsers, semi-fluid on IE 7 and 8, and still have a fixed width layout that works for IE 5.5 and 6. Best of all worlds in a handful of minor code. Combine this with the reset and some simple practices like avoiding declaring height/width the same time as padding or border as much as possible, and any cross browser headaches just fade away.

H1 -- again, since in the end there can be only one we don't need classes or ID's on it. The relative positioning is so we can APO (absolute position) the span inside it over the text. I pad it and set text as close to the image's appearance as possible for a nice images off graceful degredation, the entire point of using a image replacement in the first place. The negative bottom margin equals our total height (padding + line-height, avoiding stating the height and as such dodging some cross browser issues) basically removing it from flow so the menu and form can overlap it. This means we can put the black background and bottom red border right on the H1.

H1 span -- our Gilder-levin image replacement sandbag. Get's APO over the text. Really simple... though it means using a non-transparency version of the logo:
http://www.cutcodedown.com/for_others/rolodex/movies/images/h1Logo.png

You were using alpha transparency -- big tip, Alpha transparent .png are great for designing the appearance, but should NOT be used on deployment as they tend to be 25 to 200% larger than a non-alpha transparency file, legacy IE hates them without some goofy fixes, and in most cases it's unnecessary bloat as you can do the same thing by pre-compositing (rendering it and then screencap/clip it out) or using a method called "close enough anti-aliasing". (A more advanced technique we can get into at a later time... Hmm... Maybe I should write an article about that one!)

#mainMenu -- depth sorting over a negative margin element can at times be a bitch; position:relative SHOULD do it, but don't rely on it. In this case I needed to use a float to even get it to show up in Opera and FF (though IE and Chrome were fine). It's ok, we wanted it on the right anyways! Strip the bullets off it, push it away from the edge, and set a PX font size. Because we have that image to the left, we need this to stay a predictable size and not auto-enlarge; 16px is large enough in Arial, particularly when bold, that even high DPI users are unlikely to bitch about it.

#mainMenu li -- IE7 has this bug called the 'staircase effect' that can be a pain in the ass, and it's ALL related to trying to style LI. To keep this simple we can dodge that bullet by stripping formatting off the LI by setting it to display:inline;

#mainMenu a
#mainMenu a:psuedo -- funny thing, if you float:left elements inside a float:right, they'll still stack to the right. A LOT of developers miss that little detail and jump through all sorts of hoops to do this.

Floats are inherently display:block in behavior, and nothing you set display to (apart from NONE) can change that... but IE8/earlier has this funky bug where it will double margins between sibling level floats -- for some reason while display:inline is ignored by all browsers - even IE - for padding/border/relational behavior, it trips some sort of bugfix for legacy versions of IE that removes that unwanted margin doubling!

From there it's simple padding of the buttons, margin between them, and styling. Colors are set different from the global defaults, but we do pick up those nice transitions from them.

#mainMenu li:first-child a,
#mainMenu li:last-child a -- just sets the rounded corners without any extra classes. Normally it's hard to use first-child and harder to use last-child since older browsers don't know either, but since we're using them to set CSS3 values that won't appear on those browsers anyways, it's perfect! Again, a lot better than adding classes in the markup for this.

#topSearch -- relative positioned and floated to appear over the h1, clearing the right float so it appears under the menu instead of next to it. Again, margin fix display:inline, and legacy IE was having issues that the zoom:1 haslayout trigger fixed.

I should explain haslayout... To make IE faster than Netscape before we even had CSS, Microsoft came up with the idea that some elements didn't need their values recalculated on every page reflow. If it's not going to change, don't waste time recalculating it... made sense. Elements that needed to be recalculated are called "haslayout".

CSS comes along, and they tried to do the same thing, and it was fine when using the DRAFT implementation of CSS that IE 5.5 implemented. Problem is the changes to CSS2 from draft to recommendation made a lot of things just not work right -- in the HTML they used the presence of a doctype to say if it should use the broken "draft" behavior (now called "quirks") or the recommendation (now called "standards")... This still didn't fix everything in standards.

There are many things that trip "haslayout" -- width, height, etc... zoom is one of the easiest to use, even if it is invalid CSS. Zoom also can fix layout issues unrelated to haslayout in IE7/earlier, not even Bill knows why.

NOTICE I said it's invalid CSS. A lot of 'purists' get their panties in a wad over this, but in this day and age with all the stupid malfing vendor specific prefixes (-webkit, -moz, -o, -ms) being accepted practice, and those ALSO being invalid CSS, who gives a flying purple fish about using some OTHER vendor specific property. (a real laugh when the people bitching about using "zoom" see no problem with saying -webkit-transition and -moz-transition and -o-transition and -ms-transition and and and...)

There's no legitimate excuse apart from laziness or typo's for invalid markup, but invalid CSS - particularly with CSS3 still being in draft but too useful not to actually deploy - is now pretty much a way of life.

ok, back to #topSearch -- Setting the width is needed for IE8/earlier which seems to want to split the inputs into separate lines, so we set enough room for those. The top and bottom padding combined with the line-height equals the total height of the H1 when added to the menu's height. I use a really tall line-height to center the text inside it, while providing enough room to still use dynamic fonts on the form up to 200% the 'normal' 96dpi/16px font. Actually provides even more since we're starting at 85%/14px.

#topSeachData -- I like to widen the input a bit. I do this in PX since in EM's it can end up too wide for the media queries.

#columnWrapper -- clear the floats to make sure we're past the header stuff, set it for float-wrapping with overflow and haslayout, and pad the top so all our columns are pushed away from the header. Margins on the form or this element might collapse or have other issues, so it's easier to just use padding.

#contentWrapper -- this is where the trick for making content first fluid columns comes into play. We make a container that's 100% width and floated, leaving 0px free for a side column to fit.

#content -- then we make padding on the content area to make a empty space for our elastic column to go into, plus a bit of extra for padding between the content and the sidebar.

#extras -- and here's the magic. We float the same direction and set an elastic width. Negative margins shrink an elements size in "flow" but not how it renders. I like to think of it as two separate boxes for an element, the "flow box" and the "render box" -- flow being how it interacts with other elements, "render" being what it looks like. By shrinking it's "flow size" to 0px, it now fits next to the 100% width float -- and sure enough all browsers will 'pop' that up into place OVER the padding.

You'll notice I use negative margins A LOT. Keeps things 'in flow' for sizing and positioning, making it superior to a lot of other methods of doing this stuff.

Seems a bit complex, it actually isn't, and it's rock solid reliable.

.subSection -- again set some float wrapping, this is mostly as a precaution. Background and border are nothing fancy. .subSection and everything inside it allow easy consistent styling off a single shared class.

.subSection h2,
.subSection h3,
.subSection p,
.subSection ul -- just styling. Again, nothing fancy.

#browseFilters ul -- strip bullets, pad them in. Again, nothing fancy.

.subSection .pagination -- floated to make it pretty inside subsections. I choose to do this inside .subSection since some different container might want some other positioning.

.pagination ul -- strip the bullets, set it to inline so that it rides up next to the "pages:" text. I also shorten the line-height to make sizing the buttons easier.

.pagination li -- again, don't even waste time on trying to do anything more with these.

.pagination a,
.pagination span -- these share a lot of styling, so put their like values together. Inline-block is so they accept top/bottom padding, strip off the underlines, center the text inside them (shouldn't be necessary, but IE can be a bit stupid at times), color, border, radius... simple.

.pagination a -- and then the unique values, which is just a inset box-shadow to make them look more button-like.

.pagination span -- the unique properties for this amount to just some different coloring.

.pagination a:psuedos -- coloration for the mouse and keyboard 'hover' states. We also pick up transitions from the global A declaration.

.gallery -- strip the bullets, clear any floats (since it's after a floated pagination), center it's contents... the 10% font-size shrinks the gap between our contents... this also makes the bottom margin be 1/10th what is declared.

.gallery li - you should know the drill on LI by now, if not read the other LI above!

.gallery li a - relative positioning cleans up some behavioral bugs in Opera and IE8/earlier. inline-block lets us set top/bottom padding and widths, which we then do. The 128px top padding is to make room for the image. Setting the font-size to 1000% might seem absurd, but it just returns us to a normal size after the 10% on it's parent.

.gallery li img -- display:block makes it easier to position, the auto side margins centering it regardless of size and the negative top margin sliding it up into the padding. This removes it from interfering with the nested span after that we need to set a fixed height on so all our gallery boxes are the same size. The use of max-width and max-height along with forcing the width and height to auto makes the browser auto-scale whatever the image is to fit into our content box as desired. It's sneaky, but it works... in IE7/newer...

* html .gallery img -- which is why we use the * html hack to force the image to a fixed size for IE6/earlier. Again, it will work, might not look all that great if you had a landscape image -- OH WELL, again... IE6 users should be thankful we even bother THINKING about them anymore. Apart from that, they get what's coming to them!

.gallery li span -- also inline-block so we can set height. Set it to overflow:hidden so that should the content be too big, our floated boxes don't end up screwed up/all over the place.

.gallery li span span -- we have to 'undo' the values set on the outer spans for the nested ones, and then set up that styling we wanted. Doing it this way means we don't need classes in the markup, so while we might have 48 extra bytes in the CSS, we end up with anywhere from 14 to 32 less bytes on EACH AND EVERY SINGLE GALLERY ITEM! -- with 25 of them on a page that's anywhere from 350 to 800 bytes in the markup. Not a hard choice at all.

.gallery li b -- again inline-block, again fixed height with overflow to chop off if the movie title is too big.

.gallery li a:psuedo b -- I don't use focus here because it causes oddball behaviors in IE with changing the overflow state. Changing the overflow to auto on hover or keyboard nav gives it scroll bars so people can see any text that was cut off if desired.

.gallery il a:pseudo -- I force the default color to stay the same overriding the global element behavior, then set the opacity as our hover state. Since we're over white, changing the opacity making it slightly transparent makes everything 'lighter' on hover. Again we pick up the transition from the global value -- which is why I included opacity as a transition type. I also include the legacy IE filter version so they at least get a visual effect, even though they won't get the animation. (again, OH WELL)

#footer -- pad it, center it... nothing to write home about.

... and that's the 'default' / lowest common denominator two column layout. So now we need media queries to strip off formatting and make adjustments.

@media (max-width:50em) -- this just strips off the float from pagination and centers both it and the P.showing. There's not enough room for them to look nice side-by-side. Just makes it pretty at that width.

@media (max-width:44em) -- at an even narrower width I set up the smallest mobile size ahead of time, this will pick up on all narrower resolutions. The reason I set this here and not on the original #pageWrapper is that IE8/earlier don't know media queries, and as such needs a bigger min-width.

The H1 and it's span get changed into taking up the full width, then menu has it's float stripped and is centered, and is also switched to dynamic fonts... again using the font-size trick to make the inline-block elements go closer together.

The search is also float stripped, set back to block (from the IE display:inline bugfix) and set to center it's elements with some minor appearance tweaks.

Likewise all headings and the browseFilter list are centered.

#content, #columnWrapper, #contentWrapper and #extras are stripped of floats, paddings, widths and margins so the column layout is removed.

.subSection has it's padding and borders removed so we don't waste any precious screen real-estate on the smaller display.

.subSection h2 I added a top border to make it prettier.

.pagination ul and it's anchors also get some minor tweaking for a nicer appearance.

Then #footer also gets a top border added as it just looks nicer with the body background showing through.

@media (max-width:28em) -- our narrowest trigger has to make even MORE changes.

On the menu we change the padding and the font-size so that they are spaced apart, and change the padding and border radius to something that allows it to split into multiple lines. If you add more menu items you may want to make this transition at a wider max-width media query.

I then break the search into multiple lines with display:block, and set the actual text input to a % width of the screen.

... and that's it. If there was more sub-information or sidebars I would be adding another media query to break the single side column into two separate ones at really large widths, but that's just not needed on such a simple page.

*PHEW* -- Hope all this is of use to someone out there, and gives you an idea of what it is I'm doing and why I say all the things I do.

 

Oh, and a little tip about inline-block -- in older versions of IE it only works on inline-level elements (A, SPAN, B, etc). If you try to set it on a block-level element (DIV, P, UL, LI) it will be ignored. This is another reason for setting LI to display:inline and then styling a child element like an anchor on things like menus or pagination lists.