1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

I would appreciate your brief opinion

Discussion in 'Design' started by Vladimir Lisovets, Feb 23, 2015.

?

What's your opinion about it ?

Poll closed Mar 2, 2015.
  1. Very Good

    0 vote(s)
    0.0%
  2. Good

    0 vote(s)
    0.0%
  3. Ehm...

    0 vote(s)
    0.0%
  4. Could be better

    2 vote(s)
    40.0%
  5. Bad

    0 vote(s)
    0.0%
  6. Really Bad

    3 vote(s)
    60.0%
  1. #1
    Hello, It's nearly one of my first experiences with web design so I'm not sure if I'm doing it right.
    Well, I would like to have your honest opinion about it :
    http://bitspot.16mb.com/

    I would like to make it look better, any advice is welcome.
    I mind to use php, jquery and ajax.

    Best Regards, vladimir.
    Thanks in advance.
     
    Vladimir Lisovets, Feb 23, 2015 IP
  2. themes4all

    themes4all Well-Known Member

    Messages:
    662
    Likes Received:
    47
    Best Answers:
    6
    Trophy Points:
    100
    #2
    Hello there,

    if you are a beginner, so this is a good Start... but you will have to be more Creative.. now with the new CSS3 and HTML5 Features, jQuery effects.. you can make a new Flat Design... Dynamic clean Menu, Slider and so on... Think about this sides ;)

    Goodluck
     
    themes4all, Feb 23, 2015 IP
  3. Vladimir Lisovets

    Vladimir Lisovets Member

    Messages:
    30
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #3
    Y, I was also thinking that's quite trivial / banal design, I should check for design examples and think about what I can do.
    Thank you about the opinion, it was really relevant and usefull to me as a beginner .
     
    Vladimir Lisovets, Feb 23, 2015 IP
  4. ketting00

    ketting00 Well-Known Member

    Messages:
    772
    Likes Received:
    27
    Best Answers:
    3
    Trophy Points:
    128
    #4
    ketting00, Feb 23, 2015 IP
  5. Vladimir Lisovets

    Vladimir Lisovets Member

    Messages:
    30
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #5
    Totally agreed, I'll start using bootstrap. Taking a look on that, thanks.
     
    Vladimir Lisovets, Feb 23, 2015 IP
  6. #6
    Now... word of warning... I don't do "brief".

    It appears to be horrifically broken here -- like a menu item is stuck open overlapping the content, the content is illegible since it's black on dark blue, illegible fixed metric (px) fonts -- not sure what you are trying to accomplish, I'm just certain it's busted... badly. Just what browser does it work in as the answer seems to be "none" here.

    Under the hood, you've still got a LOT to learn about HTML; specifically what's usually referred to by the sick euphemism "semantic markup" -- or as it should properly be called "using HTML properly". You've got endless pointless DIV and classes for nothing, DIV doing H1's job, span doing H2's, job, made up fairy-tale tags that don't even exist (like <main>) in ANY HTML specification, closures for things that don't have closures (basically there's no such thing as </input>) nesting orders that don't make any sense, no media targets on your stylesheet <LINK>, using the same ID more than once on a page...

    ... and BIG piece of advice, until you know enough HTML, CSS and JS to do things without the stupid mouth-breathing halfwit framework BS, stay away from dumbass garbage like Bootcrap or jQueery; of course once you know enough HTML, CSS and JS to do things without them, you won't need them and will write more accessible smaller faster loading sites in LESS time -- since all that framework BS does is teach you to be a sloppy rubbish developer with no business coding jack **** for anyone. Take a page out of Nancy Reagan's book, and just say no to frameworks. They are NOT less work, they are NOT easier, they do NOT save time -- and anyone telling you otherwise doesn't know enough about HTML, CSS, JS, accessibility or the dozens of other related topics to be flapping their gums about it. Developers are dumber for that crap even existing.

    Just to show you what I mean, this is probably what you should have for markup on that:

    <!DOCTYPE html><html lang="en"><head><meta charset="UTF-8">
    
    <link
    	type="text/css"
    	rel="stylesheet"
    	href="screen.css"
    	media="screen,projection,tv"
    />
    
    <title>
    	Bit's'Pot
    </title>
    
    </head><body>
    
    <div id="top">
    
    	<h1>Title</h1>
    
    	<form action="search.php" method="get" id="topSearch">
    		<fieldset>
    			<label for="topSearchTerm">Search</label>
    			<input type="text" id="topSearchTerm" name="search" />
    			<input type="image" src="images/search.png" class="submit" />
    		</fieldset>
    	</form>
    
    	<ul id="mainMenu">
    		<li><a href="#" class="current">Menu 1</a></li>
    		<li><a href="#">Menu 2</a></li>
    		<li><a href="#">Menu 3</a></li>
    		<li><a href="#">Menu 4</a></li>
    		<li><a href="#">Menu 5</a></li>
    	</ul>
    
    	<div class="columnWrapper">
    
    		<div id="content">
    
    			<h2>Lorem ipsum dolor sit amet, consectetur adipiscing eli</h2>
    			<p>
    				posuere cursus suscipit. Nulla tempus, velit eu vulputate faucibus, arcu metus facilisis nisl, eget pellentesque orci ligula ac enim. In tortor lorem, porta ut sem id
    			</p>
    
    			<h2>Quisque imperdiet non neque ac interdum</h2>
    			<p>
    				Quisque ac facilisis tortor. Donec tempus rhoncus lectus, eu ullamcorper nisi facilisis nec. Ut at lectus ultrices, facilisis felis eu, lobortis lacus. Nunc dignissim dignissim dui ut elementum.
    			</p>
    
    			<h2>Pellentesque lobortis leo nisl. Maecenas commodo</h2>
    			<p>
    				Phasellus commodo, risus a gravida dignissim, tortor justo porttitor ante, vitae vestibulum lorem ante vel dui. Mauris volutpat sed eros dictum euismod. Integer vel aliquet quam, vitae mollis mi. Aenean auctor consequat ligula, eu volutpat mi mollis ut. Phasellus vehicula dictum consequat. Proin auctor finibus pulvinar. In pellentesque vestibulum nulla.
    			</p><p>
    				Pellentesque lobortis leo nisl. Maecenas commodo, magna vitae euismod dictum, velit augue dictum nibh, eget mattis est odio vitae dui. Praesent vel quam velit. Fusce fringilla neque leo, vel placerat tortor dignissim non. Praesent vitae scelerisque libero, a venenatis mauris. Maecenas tortor nibh, mattis ut iaculis a, interdum id enim. Integer dapibus augue et ornare lacinia. Aliquam tincidunt egestas sodales.
    			</p>
    
    			<h2>Phasellus commodo, risus a gravida dignissim, tortor justo porttitor ante</h2>
    			<p>
    				Etiam placerat ac nibh porta viverra. Suspendisse potenti. Vestibulum congue eu quam quis egestas. Nunc metus tortor, tincidunt ac malesuada a, dignissim non est
    			</p>
    
    		<!-- #content --></div>
    
    		<div id="extras">
    			<h2>I'd suggest describing what this is a menu of</h2>
    			<ul>
    				<li><a href="#" class="current">Sub-Menu Item 1</a></li>
    				<li><a href="#">Sub-Menu Item 2</a></li>
    				<li><a href="#">Sub-Menu Item 3</a></li>
    			</ul>
    		<!-- #extras --></div>
    
    	<!-- .columnWrapper --></div>
    
    	<hr />
    
    	<div id="footer">
    		Disclaimer and other info here
    	<!-- #footer -></div>
    
    <!-- #top --></div>
    
    </body></html>
    Code (markup):
    *NOTE* since I use the existing 4 strict semantic tags properly, HTML 5 structural tags serve NO legitimate purpose other than code bloat -- my advice is to write HTML 4 STRICT or XHTML 1.0 STRICT, and then if you want the handful of pointless redundant HTML 5 tags being shoved down our throat by the browser makers being jackasses (VIDEO, AUDIO) slap the 5 doctype on it last moment.

    Use just one stylesheet per media target, (like screen) with a meaningful name (like screen) instead of vague names (like "layout") -- more separate files you use the slower the page loads REGARDLESS of connection speed; but you want the CSS external so like appearance is cached across sub-pages and so you can preload appearance of same. Some browsers in fullscreen mode use "projection" instead of screen, and some screen type devices still report "TV" (like the Wii browser) so for screen layout it's best to say media="screen,projection,tv" to nab all of them.

    The outermost DIV is usually all you need to restrict width layout-wide, I give it the ID #top so that if you want to add "scroll to top" links you have a perfectly good one.

    H1 is the heading under which ALL CONTENT on the page is a subsection; this is why it only makes sense to have one H1 since it's the top-most heading. H2 indicates the start of a subsection of that H1, H3 means the start of a subsection of the H2 and so forth --- the same meaning heading levels have in professionally written documents. (which when TBL created HTML assumed anyone using it would already know!)... that's why skipping heading levels is gibberish, that's why pairing a h2 to a h1 or that stupid (now defunct) HGROUP tag is halfwit gibberish, and why 99% of the time keyboard and heading navigation is totally banjaxed on people's sites as far too many developers wouldn't know logical document structure from the hole in an Adobe product DVD. On that same note a HR means a change in topic/subject where a heading is unwanted/unwarranted, hence the one before the footer. You don't want it there visually, hide it with the CSS. It does NOT mean "draw a line across the screen" since again, if you are choosing your tags based on their default appearance, you are choosing all the wrong tags for ALL the wrong reasons.

    Using DIV or SPAN for headings is NOT what DIV or SPAN are for. If you use headings properly you have a structure for non-visual UA's (including search -- search engines don't have eyeballs and don't give a flying fig about your layout or style) and alternative navigation users to get around with. (which also is why HTML 5's NAV tag is redundant pointless BS).

    I also implemented a full and proper form. A form SHOULD have a fieldset, that's why in STRICT it's invalid for label or input to be direct children of FORM. A user input area that's text should have a LABEL, not that placeholder crap or the "let's play the goofy game of swapping the content with scriptttardery" that is popular with the artsy-fartsy PSD jockeys and nobody else.

    Good article I'd suggest you read on the pitfalls of things like placeholder/content swapping on inputs and other design "epic fails":
    http://baymard.com/blog/false-simplicity

    Usually when you have extra crap on a page it's better to put it after the content, not before it so that on mobile or when your fancy CSS style is blocked/unavailable/irrelevant (search, screen readers, braille readers) the user can get to what they ACTUALLY visited the page for -- the content! The outer 'columnWrapper' would allow the layout to be built semi-fluid, I would do so by making the 'extras' column a semi-fixed elastic width (em's) and allowing the content column of actual 'articles' be fluid, with #top having semi-fluid constraints. Given the nature of the stuff in #extras I was unsure if it should go before, after, or should be nested in the menu as a dropdown, so I guessed wildly.

    You REALLY weren't doing anything that warranted the extra DIV around each article, so I axed them. I the P are padded 0 1em 1em and the h2 were padded 1em all around, you'd still end up with that 2em gap between them which I assume is what you were aiming for. I don't dive for the DIV until after I've exhausted what can be done using the tags inside it.

    ... and notice that since we now have H2 and P, we no longer need classes or ID's on them; and again, you were using the same ID more than once, and you can't do that -- that's what classes are for -- though again if you use semantic markup and understand inheritance on the CSS side, you'll use a hell of a lot less classes, ID's, SPAN and DIV.

    I know that's a lot to take in, and sorry if that seemed a bit harsh -- but that's how one can ACTUALLY be helpful; since slapping the rose coloured glasses on your head and patting you on the back to take you down the garden path to sing kumbaya around a drum circle is NOT helping... no matter how good it might feel.

    Hope that helps and you can learn from it. If you like I could probably belt out some CSS to go with that after lunch since I'm basically spending today with my thumb lodged up my backside.
     
    deathshadow, Feb 23, 2015 IP
    malky66 likes this.
  7. Vladimir Lisovets

    Vladimir Lisovets Member

    Messages:
    30
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #7
    That's all I needed, Probably this thank won't equate with the whole clarification that you gave me ( I'll read it againa and again when get more time for its comprehension) . Well, as a programmer I perfectly had this ideia about using frameworks in web as using constructors in common programming isn't a good ideia, I refused to use gamemaker, netbeans, unity, etc, etc ... It brokes a programmer and every his notion of programming . Anyways I've exposed the same question in quora and got a pretty long answer (which made me think that he understands it), where he adviced to use bootstraps before making something from scratch. For some reason, my own programmer logic failed and Ok this could really be useful, I'll try why not ...
    As your answer can prove I've built that without any well formed understanding of html neither css.

    Oh hell, that makes me feel so bad, just a bad start as my nearly first web (front-end) experience.
    Your answer, well, these are type of answers formed by professionals, and here I would like to refer the crap programmers, because nowadays and so on there are appearing more fake programmers. That can be explained using the internet logic -> The more data there is, less accuracy and less quality it guarantuee.
    Pretty the same is happening while we proceed on computer generations, even between my collegeues...there are so many broken programmers.

    "Everything Should Be Made as Simple as Possible, But Not Simpler " - Albert Einstein
    That citation also refers exactly the way many people learn to program, the same people who won't spend time on the true meaning of learning, reading the documenation, implementation, definition and how it works from the deep. Instead of that, listen to promisses in learn networks in 2hours, php in 15min, etc,etc..bullshit.

    I know, this sounds a dealema when I'm talking about broken programmer logic just after I built that website try and neither used logic to do it.
    learn -> practice -> clarify -> learn -> do it -> learn more -> try again -> compare -> make it better -> etc
    f**k it, It makes me more passionate about coding and just confirms my theory.

    A week ago, I started to study php, cuz I'm on a project where I've to write some scripts in php. Well, I spent 8 hours, studying it from the very start, and still not finished the first topic.
    Then I was reading topics and wikis about how the brackets appeared in many programming languages, and while studying php I realized that:
    The first implementation of brackets were on BCPL in 1966-67, which originated CPL(something like a remake of BCPL, fully changed version of it where the Brackets survived), both influenced C (which took its name from BCPL(if I'm not wrong)). And well, it still just one php's designation (Curly Brackets Languages) from various.

    Oh well, got too envolved on this, sorry for making it that long, but I like really a lot to share my experiences and thoughs .
     
    Vladimir Lisovets, Feb 23, 2015 IP
  8. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #8
    First NEVER apologize for a long post; the TLDR crowd can piss right off and go back to circle-jerking each-other alongside the road to "epic fail" :D Feel the love.

    It sounds like you have your head going the right direction -- you mentioned that someone suggested a framework before scratch coding ran against your instincts -- TRUST THAT. Your gut reaction was NOT leading you astray.

    Likewise when you say: "the same people who won't spend time on the true meaning of learning, reading the documenation, implementation, definition and how it works from the deep. Instead of that, listen to promisses in learn networks in 2hours, php in 15min, etc,etc.." that's a significant portion of the people in web development right now, and the very usability and functionality of the web is being compromised because of it. Even the simplest of HTML concepts like semantics aren't taugh, aren't understood, and simple fundamental common sense concepts like "progressive enhancement" are outright attacked by the ignorant halfwits who say things like "use bootstrap" or "use jQuery".

    The laugh being that actual improvements to CSS thanks to things like media queries give us the tools to make properly accessible sites, but people think "mobile" instead of "all devices" and still cram their head up "appearance firsts" backside -- resulting in sites that are as bad or worse than what was being vomited up fifteen years ago; and generally perform worse than dialup was twenty years ago to do the SAME FREAKING JOB!

    Now, I said I'd toss together some CSS for that, just got back at the workstation and belted that out. It's pretty simple, here's a working demo:
    http://www.cutcodedown.com/for_others/VladimirLisovets/template.html

    The CSS for screen layout is here:
    http://www.cutcodedown.com/for_others/VladimirLisovets/screen.css

    The markup is pretty much unchanged from what I posted above.

    I took a few stylistic liberties as I was kind-of left guessing as to what you were actually aiming for on appearance, and added a few cutesy bits like hover/focus effects.

    I'll start in on a bit by bit breakdown explaining the CSS so you can learn from it. HTML is easy, CSS is hard, and there's a lot of tiny details on the how/what/why of the way I built it that you should probably learn.
     
    deathshadow, Feb 23, 2015 IP
    COBOLdinosaur likes this.
  9. Vladimir Lisovets

    Vladimir Lisovets Member

    Messages:
    30
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #9
    Thanks ! Just saved for a further exploration.
    "that's a significant portion of the people in web development right now", probably it happens due the illusion of vacuous of html, surely it's not that hard but still more than just nested tags.
    Honestly, it irritates me the way many people treat programming. Such a harassment for the other half who worked hard just to earn the title 'good programmer' that nobody see.
    the notions of programmer and good programmer are diverging, once being a programmer pressuposed to be a good programmer.
    Someday we'll get treated as a secretary, they are just taking the another half way down "SAME FREAKING JOB!". Btw, do you work in something else than web development ?
     
    Vladimir Lisovets, Feb 23, 2015 IP
  10. King-Servers

    King-Servers Greenhorn

    Messages:
    269
    Likes Received:
    6
    Best Answers:
    0
    Trophy Points:
    23
    #10
    I am sorry but the site looks really basic. As a beginner, no one would expect great designs from you but you need to be creative.
     
    King-Servers, Feb 23, 2015 IP
  11. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #11
    Alright, let's break down the CSS for you.

    I always start with a reset -- resets exist because the HTML specification does not actually say what anything should look like! -- and as such the default values for certain things like margins, paddings and borders cannot be trusted on some elements. A good reset gives you a consistent baseline across all browsers.

    There are larger resets like Eric Meyer's "reset reloaded", but fat bloated piles like that give the term a bad name. It is resets like that which makes a lot of developers scream "don't use resets". Simple fact is it's more of a framework than a reset, wasting time setting values you are far too likely to be changing anyways, or that don't need resetting in the first place -- or worse, nobody actually uses if they understand semantics. I can understand after seeing resets like that why some people would knee-jerk into thinking they are all rubbish.

    Likewise there are smaller resets, like the so-called "universal reset" of "* { margin:0; padding:0; border:0; }" -- but that can cause MAJOR headaches styling tables and form elements across browsers, doing more harm than good. It's short, it's cute for testing purposes, but I'd NEVER consider it for a production site as the first time you try to change the size of a input[text] you'll start ripping out your hair.

    The reset I use is in the middle; it's not even a quarter of a K in size,

    HR -- as I mentioned before, horizontal rules do NOT mean "draw a line across the screen", it means a change in topic or section where a numbered heading is unwarranted/undesired/inappropriate. A horizontal rule in layout can be conveyed in many different ways than a line across the page -- from a centered elipsis, to three to five asterisks or tilde's, to a page-feed. We WILL want HR in the markup for document structure so that there's something meaningful when screen layout is not applied, but when this stylesheet is in use we'll likely use some other means of indicating it, so we just hide these from displaying.

    @media (max-width:480px) -- the text-size-adjust values here address that older Safari and IE handhelds will try to change the font size regardless of what we declare on the assumption the website wasn't written mobile friendly. Thankfully there seems to be no devices that do this that report a width of more than 480px, so sending this gives those devices a good swift boot in the patoot without screwing up other browsers. IN THEORY we should actually be able to send those values to all browsers without the media query, if not for a bug in OSX Safari where -webkit-text-size-adjust breaks zooming; a patheticly stupid bug when iOS Safari has no such shortcoming. :/

    This is where the real layout parts begin. I always start out with the lowest common denominator; a LOT of developers seem to think that means mobile, but starting with mobile makes no sense since mobile is now what's smart and will obey media queries. Older pre IE9 browsers that don't obey media queries makes a HELL of a lot more sense as a starting point than mobile devices.

    body -- some padding so we have a nice pretty bit of background showing all-around regardless of screen width. I always set the default font values for 99% of the page content on BODY and then adjust from there. I use percentages for font-size so that it is based on the default size specified either by the browser or host OS. This is called "dynamic fonts" and allows us to also make an "elastic layout" -- where users with different default font settings (like myself) aren't stuck diving for the zoom. Rest of it is just colours.

    When declaring a change in font-size ALWAYS declare a line height. I prefer taller line-heights (150% for example) as it just seems easier to read as the lines get longer. Using the condensed font declaration that also declares weight, style and family in one line is just clearer what's going on... and laughably is pretty much the same number of character as saying "font-size" and "line-height" with their values separately.

    #top -- the outermost wrapping DIV we can use to set our page size. Using a max-width and min-width provides a "semi-fluid" layout expanding/shrinking between those two points, an ideal for our non media-query aware base design. Those widths are declared in EM's so when our default font is larger or smaller, those widths also enlarge/shrink. You'll find across this entire layout that's how I roll.

    Oh, and the auto margin of course centers it.

    * html #top -- "* html" is a hack that says this value is for IE6 and earlier. A lot of people will frown on these simple reliable hacks as being "wasteful code", but then piss all over the markup with IE conditional comments and separate files. I don't get the appeal of that when this works just fine and shows no signs of EVER breaking. The comment here says it all, shove a fixed width at older versions of IE -- many people wouldn't even bother with this anyways, but it's really no biggie to at least make the page useful for people stuck a decade and a half behind the curve.

    In fact, providing imperfect fallbacks and/or reduced appearance is one of the entire things CSS is supposed to be about -- it's called "graceful degradation"; when fancy bits are missing, try to still present something useful. Be it media queries, min/max-width, or even goofy things like rounded corners. Pre IE9 browsers don't get border-radius, OH WELL.

    h1 -- floating this left will make anything after it ride up next to it. I then just pad it and set the font size. YAWN.

    #topSearch -- floting this right does the same, resulting in the menu being ABLE to ride up between the two; by default we won't actually be doing that since the fallback may not do min-width/max-width properly, so instead we'll trigger that with a media query later.

    #topSearch label -- setting this to display:block puts it on it's own line providing more room for the menu. Some side padding just makes it purty at all sizes and placements.

    #topSearch input -- vertical-alignment on this prevents some oddities when the layout is re-arranged and makes our searchGlass character align nicely.

    #topSearchTerm -- fixing the width and stripping border off this, with added padding results in a fairly nice appearance. Don't need to play with this too much. Even though the width is fixed, it's also elastic since it's in EM's so larger base font == larger layout.

    #topSearch .submit -- the submit has a bit of a white-space gap we can remove with a negative margin. Making the font 150% larger with a 100% line-height makes it the same height as the normal line-height. The UTF-8 character for a magnifying glass only exists in certain fonts, and not all of those fonts are available on all platforms, so we chain out a stack of the known fonts that do support it. From there just strip off the background and border.

    #topSearch .submit:pseudo-states -- for the psuedostates provide the hand/pointer indicator so it's clear it's a button, and give it a color/glow effect while at it.

    The psuedo-states declared are as followed:

    :active is for when the element has been clicked on, but some older browsers use active instead of :focus.

    :focus is for when it has been selected by keyboard navigation

    :hover is when the mouse is over it.

    It's usually best to declare all three as the same hover effect instead of just :hover -- there are people out there who use more than just a mouse to get around; see me when my parkinsonism flares up full blast and I'm stuck navigating with a puffer stick.

    #mainMenu -- for our default layout we want the menu below the H1 and search, so we clear both floats. List-style kills the bullets, and we explicitly state the text-align for now so that should the layout switch media targets from a window resize things will still appear properly. From there just some simple padding.

    #mainMenu li -- setting these to display:inline strips a LOT of the formatting behavior off them, letting us avoid a particularly nasty IE bug known as the "staircase effect" -- whenever possible I try to avoid styling LI as they're just a pain in the ass in legacy IE. The padding here is to increase the gap between the buttons without resorting to margins, since margin collapse/failure to collapse is a headache best avoided when you can.

    #mainMenu a -- since the LI are inline, we set these to inline-block so we can declare top and bottom padding and have it obeyed. Both these and the parent LI have to be set to vertical-align:top or in some version of Opera, FF and IE they will "hop up and down" when hovered for christmas only knows what. :(

    The slightly off top/bottom padding is there to correct for the fact that most fonts do NOT center in their line-height perfectly. The bottom margin is there so if the menu items wrap they aren't right up against each-other. From there it's just border and colour.

    #mainMenu a.current -- different colouration for the current item. I always call it "current" instead of "active" as there's a pseudo-state called "active" -- which can be VERY confusing. Like in real programming languages, avoid using variable, procedure or class names that are identical to reserved words.

    #mainMenu a:pseudo-states -- again, just the navigation highlights.

    .columnWrapper -- another clear to be sure we're pushed past any and all floats, we also set it to "wrap" around floated child elements. This is a simple way to contain our floated columns. This is much the same thing as what people crap out like it's a decade ago with "clearfix" without putting a presentational class in the markup for no reason. I also have added a "bar" dividing the columns as generated content since border is a pain in the ass between floats to go full height. To position that bar we need this element to be position:relative so that any child elements base 0:0 on the upper-right corner of .columnWrapper instead of the upper right corner of the screen.

    The right padding makes room for the sidebar #extra to be floated into, we'll cover that bit of magic shortly. From there it's just border and colours.

    .columnWrapper:after -- this bit of generated content fakes a border between the columns. It's just an absolute positioned insanely tall item that gets chopped off by our overflow:hidden state. It's just easier than trying to do this with border, and we can easily hide it when we remove columns.

    #content -- here comes the magic. 100% width floated left leaves 0px free for something to float next to it...

    #extras -- Well, if we make this float 16em wide, a negative margin of the same width will make this element be treated as if it was "0px wide" in flow/layout. That's what negative margins do, shrink the size of the element "in flow" without changing how it's drawn. Doing it on the right slides the content right... since it's 0 width it magically pops up next to #content, and it rendering to the right places it over the right padding on .columnWrapper.

    It's a nifty trick that lets you easily place fixed or elastic columns on either side of a content area that remains fluid. Usually this beats the ever living tar out of attempts to use percentage width columns which most ALWAYS result in broken layouts.

    h2 -- padding, size, yawn. Note that 80% of 125% is 100%, so 0.8em of 125% font size is still the 1EM used on the rest of the page. That's the HARD part of using EM, is they're multiplicative...

    p -- ditto. I like to use padding instead of margin as it's more predictable (again margin collapsing or not collapsing can drive you nuts), and with the h2 providing padding all-around we can easily have that 1EM (0.8em at 125%) gap above it from the H2, and 2EM between elements provided by the 1EM of padding on the P and the 1em/0.8em top of the h2 after.

    #extras UL -- kill the bullets, pad it, yawn.

    #extras LI -- display:inline as before just to strip formatting off these to make them easier to handle cross browser. In this case if left as block in IE7 and sometimes in IE8 hovering them will make them change height for no fathomable reason looking like ass.

    #extras li a -- display:block so they're one per line and auto-expand to the available width, padding, margin between them, alignment, style... nothign too fancy.

    #extras li a:pseudo-states -- hover colouration, yawn.

    #extras li a.current -- inverse color. YAY!

    #footer -- padding, alignment. another yawn. Since .columnWrapper is float wrapping we don't even need to bother with clearing behaviors.

    ... on to the media queries to make the layout responsive!

    @media (min-width:48em) -- as the comment says you'll want to adjust this based on the production menu width and site title length. When the page is 48em or wider we turn off float clearing and align the menu center and poof, it pops up into place between the H1 and the form.

    @media (max-width:44em) -- this targets when the screen is smaller than 44em. First we lower the min-width to the lowest any mobile device is likely to use since media query capable browsers can "handle that". Stripping padding off the columnWrapper, hiding the generated divider, stripping floats, margins and width off #content and extras drops the layout to a single column, and then just for consistency we add a 3px top border to #extras to show that it's not part of the main content.

    @media (max-width:32em) -- as the screen gets smaller we want more room for things and less padding, so we do exactly that. Moving the menu and search into single columns is as easy as stripping off the floats and adding center alignment. Losing the side padding on body makes a lot more room, as does lowering the side padding on h2 and P. Finally without that padding the rounded borders on .columnWrapper looks like garbage, so get rid of that too.

    ... and that in a nutshell is an elastic semi-fluid responsive accessible layout; basically how things SHOULD be done.. or at the very least how I go about it.

    I know that's a lot to take in, take time, digest it, and any questions feel free to fire away.

    Jack of all trades, master of some. :D

    I've been programming since 1977, started out coding RCA 1802 machine language one bit at a time on toggle switches using a COSMAC ELF.. MOST of my programming career was spent creating double-entry accounting systems though I've done a little bit of everything along the way.

    System building, network traffic analysis, infrastructure installation... Game development and design both in computers and pen and paper. Was even vice president of IT at a major national insurance company that handed out vide presidencies the way most people do candy on halloween... all that before spending 2001 to 2011 managing a reasonably high profile high traffic gaming website and making enough money that in THEORY I never HAVE to work again by simply taking sites that were choking to death thousand dollar hosting plans and making them run smooth on $10 VPS -- usually by doing all those things I keep advocating and swinging an axe at any "gee ain't it neat" nonsense that got in the way of doing what's actually important on a website -- delivering content to users.

    I also for laughs do a lot of retrocomputing projects, writing games for Commodore 64 and DOS 2.0 because I can! -- a rewrite of my Pac Man ripo... uhm, homage is what's currently in the works as the underlying "engine" is meant for two other games I'm working on. Using a game I know the logic and system of to test new sound and video library code let's me focus on performance of said libraries instead of making the game playable... since I already have that part. Apparently I didn't get the memo... (unsolicited review of one of my games!!!)

    I'm actually retired now due to failing health, but I like to try and help people where I can as I hate the idea of having all this info in my head just sitting there rotting away. Laugh being when in full parkinsonism vegetable mode I can still seem to code faster blowing through a straw than most people do with both hands on a keyboard.

    Though I do keep my hand in, the free time has actually given me time to refine my craft even further without the annoyance of "clients" who usually don't know enough about websites to be allowed to throw money away on having one... or at least some free time when I'm not out Busking on the EWI at the local park or doing bicycle repairs for friends and neighbors out of the garage.
     
    Last edited: Feb 23, 2015
    deathshadow, Feb 23, 2015 IP
    malky66 likes this.
  12. Vladimir Lisovets

    Vladimir Lisovets Member

    Messages:
    30
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #12
    Sorry for the delay with the answer, I'm busy in a php+js project till friday, not sleeping several day last weeks to finish it. I'll read the code review in saturday and think about to read the book that you suggested. for the next year I'll be moving on html+php+js, still liking more php than anything else.
     
    Vladimir Lisovets, Feb 25, 2015 IP
  13. Vladimir Lisovets

    Vladimir Lisovets Member

    Messages:
    30
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #13
    and surely first Iºll need a full html coverage.
     
    Vladimir Lisovets, Feb 25, 2015 IP
  14. Vladimir Lisovets

    Vladimir Lisovets Member

    Messages:
    30
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #14
    I'm amused, I'd like to start porgramming your time , turn immortal to code forever as some kind of master sensei of computing.
     
    Vladimir Lisovets, Feb 25, 2015 IP
  15. Vladimir Lisovets

    Vladimir Lisovets Member

    Messages:
    30
    Likes Received:
    1
    Best Answers:
    0
    Trophy Points:
    43
    #15
    web dev is turning into a sort of pop art eheh I appreciate your generationg , it looks like many masters came from there. If I understood right you worked on security ? btw I mind to take ccna ciscos exam next year. And dreaming with the security one.
     
    Vladimir Lisovets, Feb 25, 2015 IP