Hey guys, been trying to step my game up as far as html/css development goes. I'm still kind of amateur, could you some help/pointers. Here's the website I'm working on: http://robbyk.com/demo/port2/ It works decent, but there's some problems... #1. I think I need a better way to handle the top bar/header image size. It works well when the browser windows simply shrunk, but when i start to play with zoom it's off at some percentages. What would you recommend? #2. I struggled with the whole vertically centered thing on the green section. I followed an answer on stackoverflow, regarding something similar. It just seems like there's extra markup. Any recommendations? If you see any other problems, room for improvement, let me know. I want to get it right before i start working on the other pages. Edit: Ohh yeah, I haven't added all the hover/transition effects, or styled that slide navigation thing yet, so don't worry about that.
The main problem I see so far is typography, it will look much better if you experiment with some more professional looking fonts for the titles and other text. Also add a lot more padding in each section so everything feels cleaner and has more whitespace. I add atleast 50PX top and bottom to each section.
Hi, thanks for the design critique, I'd agree with you, I definitely need to find a better font for all the headings, possibly the paragraph text as well. I'll try some new ones today. I'm more concerned with the way the site is coded though, if you see any problems let me know!
I wouldn't say fonts are an issue, but I hate goofy illegible webfonts; the webfonts you've used are simple and clean unlike a lot of the illegible artsy fartsy crap out there, but I'd probably just swing an axe at them altogether since they suck down too much bandwidth. A real issue I see is that you've still got illegible color contrasts in the menu and footer; dark grey on dark grey == /FAIL/. Likewise your responsive triggers could use some help since they let the page get WAY too narrow before they drop the columns. This is probably (at least here) because you've got EM metric fonts mixed width px metric media queries. If you're going to use dynamic fonts, you have to make the layout elastic -- particularly the media queries. Checking under the hood, you also seem to be using that stupid malfing 62.5% LIE, which will bite you in the backside sooner than later. Remember, EM fonts are DYNAMIC, that means they can automatically be bigger or smaller so trying to use 62.5% to make them correspond to pixels is a complete and utter waste of time, and WILL result in a broken layout for any of the users you'd be using %/em for in the first place! That's really another of those bits of nonsense that I meet whoever came up with it and started promoting it's use in a dark alley... I don't know what all that "sliding sidebar" scripting crap is, but I'd suggest swinging an axe at whatever that's going to do (since it doesn't seem to do anything yet). Unwritten rule of scripting -- "If you can't make the page work without scripting first, you have no business adding scripting to it." -- to which I usually append "and by the time you make it work without scripting, you might realize you don't need it." There are still design elements present I'd never put on a website in the first place, and it looks like many of them exist to make up for a lack of actual content on the page. The massive space-wasting green banner area, the equal height equal width subsections -- these are things that just seem to exist to make development harder, keeping page content fresh impossible, and making the page feel like it serves no real purpose. Spreading things out so much also encourages bounce since it's so spread out it doesn't look like there could be anything important present. Overall it's still got what I'd consider to be size issues. You've got 723 bytes of plaintext (about a third my minimum to bother making a page in the first place) with NO content images or forms, what's it wasting 221k in 13 files doing? (not even counting the goofy bandwidth wasting webfont!) -- 4 stylesheets for one media target, stupid bloated jQuery BS (which by itself is half my ideal target for an entire page template's HTML+CSS+SCRIPTS+IMAGES - I still fail to grasp why ANYONE would use that idiocy by choice)... and that's before looking under the hood. Your comments are redundant, and likely to trip rendering errors in some versions of FF and IE. This: <!-- ////////// Welcome Bar ////////// --> <div class="welcome"> Code (markup): Is just ... really? <div class="welcome"> is the start of the welcome bar? Never would have guessed... Much less it's between sibling elements. I NEVER use opening comments for a reason; if your class (though I'd consider making those ID for later use in a accesskeys/mobile/reader menu) doesn't convey what's being opened, there's something wrong with your class/id. As to that bug I mentioned, if a comment ends up between inline, inline-block, positioned (absolute, fixed or relative) or floated elements, IN IE and some different versions of gecko based browser you can have either the 'double render' bug, where things are drawn twice (The second time in a completely random location) or the 'disappearing content' bug where, well... the text inside a container fails to be drawn! That's why IF I'm going to use comments, I place them inside the element instead of between elements. Hence why if I want to say 'welcome bar' I suggest using this commenting format: <div id="welcomeBar"> content here <!-- #welcomeBar --></div> Code (markup): Avoids the possibility of those bugs since we don't need a starting comment thanks to the verbose ID, and the comment inside the element can never end up between siblings. I like closing comments to say what's being closed on semantically neutral tags like DIV, and notice I use a # to tell me that it's an ID being closed. Likewise, I'd get some form of image replacement on that H1 so it has actual text inside it. Gilder-levin FTMFW. I usually don't consider logo images to be content, and as such wouldn't put them in the markup as a IMG tag.
Yeah, the fonts take up a little bandwidth, but i think it's worth it to make the design a little more unique and nicer. Will up the contrast on the footer/text for sure. I thought the narrowness looked alright, it's not that i mixed up dynamic/metrics, but I'll play around with it. I do have a question about the elastic thing. Originally i coded it so it was completely elastic, assuming i understand the term correctly, then at the end I added a max-width to the width container so it wouldn't look weird and super large resolutions (like if each of those boxes is 600px wide it would only be a line or two of text). How would you go about this? Yeah the 62% thing didn't really make it simpler looking back, in fact it probably made things a lot more difficult to figure out. With the whole slide navigation bar, I plan on styling at the end. Sure I could have a multiline navigation bar appear up to for smaller resolutions, but i think the slide thing is a lot cooler way to do it, and it retains the original design a little better. As far as the design elements goes, maybe I think differently than you. This is going to be the landing page of my future portfolio. The green banner section is there to explain what i do in a short couple of sentences (I think they call it an elevator pitch), but maybe I could shrink it up a bit. Then the rest was just to include a little bit from all the other pages, to lead people to other pages. Maybe I should think about what to include on the landing page more, it does seem a little barren. The subsections are equal width, but they won't be the same height once i add actual content, its like that because i just copied the same dummy text paragraph. Ok, i put the comments in to try and look cool and professional, i'll drop them. I'll switch to image replacement, i wasn't sure which is better.
You make the max-width elastic. Elastic just means to use EM's so it's based on the font-size... so like how the fonts auto-enlarge/shrink, so does your max width. That's also why you would want elastic media queries, so your breakpoints also automatically enlarge or shrinkg with the users default font choices and/or OS settings... be it the 72dpi/12px *nix default, 96dpi/16px many people have been deluded into thinking everything uses, or accessibility sizes like 120dpi/20px or more. Just to make sure the terms are clear: fluid == auto adjusting to screen and content semi-fluid == as fluid, but constrained inside a max-width and possibly a min-width. (I usually set a min-width for non-media query browsers then undo it with a media query) elastic == values (fixed or semi-fluid) based off font-size, naturally the best way to do that is using EM's. Problem is the smaller the screen the less capable the device, and the less usable some goofy scripting solution is going to be... especially since all that scripting is just gonna suck the battery dry on the user -- see why many phone and tablet users LOVE script blockers like NoScript. That's mostly what I meant -- I really like to have the full content marked up (or at the very least a reasonable facsimile) before even starting to style a page. Usually I aim for 2k of plaintext minimum before I even THINK about applying markup, with 4k being a more ideal total. Good rule of thumb IMHO is that if you can't come up with 4k of plaintext for a page, said page probably doesn't belong as part of a website, or belongs as part of another page.
Hi, I noticed that you are closing the </head> tag before calling the jQuery and then you're closing it again after calling the jQuery and the title tags, you need to remove the one before the jQuery (Line 15). +1 for being responsive! Good Luck.
@ElMaZaGaNgI - good catch... though that's why one should also validate ... though really, I'd just axe the scripttardery, but that's because I'm not dumb enough to think jQuery serves a legitimate purpose on the majority of websites apart from making them slower and harder to use.