Hello. I have a div( #main ) that i'm trying to split in two columns. As you'll see, #main has 1280px, the "left column" has 800px end the next one should use the rest. My problem is that i can't make the second column display on remaining space perfectly ( 480px ) and when i write in either div one of them goes down with a text row or something like that. I'll post some photos. Thanks in advance. Code: #main { position: relative; display: block; width: 1280px; height: 85%; min-height: 500px; margin-left: auto; margin-right: auto; padding-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; background-color: black; color: #242424; border-style: none; box-sizing: content-box; } #div_main_left_container { display: inline-block; position: relative; height: 100%; width: 800px; box-sizing: border-box; margin-left: 0px; margin-right: 0px; margin-top: 0px; margin-bottom: 0px; padding-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; background-color: red; word-wrap: break-word; } #div_main_right_container { display: inline-block; position: relative; height: 100%; width: 400px; box-sizing: border-box; margin-left: 0px; margin-right: 0px; margin-top: 0px; margin-bottom: 0px; padding-top: 0px; padding-bottom: 0px; padding-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; background-color: blue; word-wrap: break-word; }
Hi, please next time use JSfiddle, is much more easier for us to help you then. I've created a JSfiddle myself - http://jsfiddle.net/ooL3nbkL/2/ I went with 100% height of the children elements, who have also absolute positioning. Inside the main div, which has relative position, they will strech from top to bottom. Also, next time - I'd recommend reading some real basic tips on CSS. For example padding-left:0; padding-right:0; padding-top:0; padding-bottom:0; is the same as padding:0; Same goes for margins.
One major point -- you're using pixel widths and fixed widths, so whatever you are designing is inaccessible crap and a laundry list of how NOT to build a website. IF you have a fixed side column of a narrow width, the other column should be fluid... your outer container should be semi-fluid (min and max-width) so it can expand/contract to fit different size displays, and ALL of those measurements should be done in EM so it's based on the default font size instead of fixed pixels... Which is why if you are declaring your font-sizes in px that's inaccessible garbage too. You may want to read the WCAG, "Web Content Accessibility Guidelines". Fixed width is either broken crap on smaller displays, or crappy little stripes on large displays and is a poster child of everything WRONG with the people who call themselves "designers" whilst not knowing enough about html, css or accessibility to be designing jack ****!
We wanted to make the website to be 1280px width until it reaches 1279 when it'll become 1024px and after that, the mobile version will "pop out". I'm welcome to advices, and critics.
The thing is, why pixels? Are you aware of EM? Are you aware of why we're supposed to be using those and NOT pixels? IF you have dynamic fonts, the page should auto-size based on the browser or OS preference -- that's NOT zoom as images will remain their expected size. It's called "dynamic fonts" and basing layouts on it is called "elastic layout". It's one of the many stepping stones (alongside semantic markup, separation of presentation from content and semi-fluid layout) that one should have LONG before thinking about making a layout "responsive". Generally speaking I'd have to see the full code and the content (or a reasonable facsimile of the content) before commenting on what the correct code should be, but generally speaking fixed heights, min-heights, absolute positioning, inline-block instead of floats or flex, and a host of other things I'm seeing hints of in this thread is a laundry list of how NOT to build a website. But then I consider jsfiddle to be a useless pile of **** thanks to the uselessly tiny windows crammed into the browser, so what do I know? Assuming you'd have a full width header above those, want it to stretch to full height, with a footer below that, I'd be giving a content-first elastic+fluid float model a serious look even if it is DIV heavy -- and for the height I'd be looking at faux-columns for the columns and flex-box for the min-height. The min-height wouldn't kick in on legacy browsers, but the page would still be usable and have the column background "proper". I'm out the door, but when I get back around 5 I'll slap something together loosely based on my progressive approach as per this thread: https://forums.digitalpoint.com/threads/progressive-enhancement-design-from-the-inside-out.2759516/ ... and its associated demos: http://www.cutcodedown.com/progressive/ I'll also probably follow it up with some posts/breakdowns of the how/what/why of the coding choices I made in the process... since once you get min-height involved things can get a bit complex, particularly with flex.
@deathshadow: What is your opinion of using rem instead of em with a px fallback for browsers that do not support rem? I cannot stand the cascading nature of em. Modern browsers, including IE11 (for most things), support rem.
PX as a "fallback" is still broken nonsense -- while I can kind-of understand REM as a concept, I don't get what's so blasted hard about EM and the nested nature of it; unless you are dicking around with three or four dozen font-sizes across a page in an effort to utterly and completely piss users off, I just don't get how EM is so "difficult" in the first place -- even with how it inherits off parents. I mean really, set the most commonly used on BODY, set your headings, DONE. If you stick to easy sizes like 125%, 150% and 200% on font-size off what you set on body, it's not rocket science to keep paddings the same or at least "close enough for govt work" /* if body == font-size:100% */ font-size:200%; /* 0.5em == 1 REM */ font-size:150%; /* 0.66em == close enough to 1REM nobody gives a **** */ font-size:125%; /* 0.8em == 1 REM */ NOT honking rocket science. If you're dicking around changing it much more than that on single internal elements, you're probably doing something wrong like pissing all over accessibility or just making an eyesore. ONLY possible exception I could think of on that would be a tag-cloud. Though I watch the way people don't declare the most common size on body then throw it at tags like P or A and I'm just.... what the **** are people even THINKING?!? Though to be fair, I say the exact same thing about most people's use of illegible colour combinations in that traditional "WCAG, what's that?!?" mentality. Emphasis on the "mental". NOTHING drives me away from websites like major accessibility failings -- endless pointless changes in font-face and font-size for non-structural non-semantic reasons is most certainly on that list of "how to piss off visitors" artsy-fartsy garbage. Same reason I would NEVER use webfonts on flow content, and bother checking my colour choices for WCAG 2.0 AAA compliance. See, well... the site in your signature. Illegible orange on white, endless pointless font-face changes, seemingly random choices of font-size, serif fonts on screen, goofy illegible poorly rendering webfonts... -- edit -- also, starting in on that demo now.
Ok, here's how I would go about a two column fluid content first elastic side semi-fluid elastic outer responsive layout... There's a mouthful. http://www.cutcodedown.com/for_others/chetan_tudor/template.html As with all my examples the directory: http://www.cutcodedown.com/for_others/chetan_tudor/ Is wide open/unlocked for easy access to the gooey bits and pieces. As it uses flex-box to be min-height it won't stretch to full screen height in IE9/earlier -- OH WELL. So long as a page is still USABLE back to IE7, I no longer waste time dotting the t's and crossing the i's - people should be thankful pages are at least still FUNCTIONAL for them if they won't pull their head out of the last decade's backside. (normally I include IE5.5 usability testing, but this was a drive-by) I'll start work on a markup breakdown first, then a CSS breakdown to explain the how/what/why of it.
Alright, breaking down the markup: These days I still design as HTML 4 Strict, but I deploy as HTML 5 for brevety sake or should someone want to use the HTML 5 redundancies that are basically being shoved down our throats. I tend to put the opening HTML structure tags all on the same line since nothing should go between them. It's a gentle reminder that you shouldn't accidentally blindly paste anything between <html><head>, </head><body> or </body></html>. I also declare the character encoding up top since we want that as soon as possible should HTTP headers fail to set that. The viewport META I use fixes the scaling issues by telling mobile "Yes, we know what the **** we are doing" WITHOUT screwing over the ability to zoom. You'll see people throw other values in there like maximum-scale... I call these people mouth breathing halfwits who seem to have no honking clue what they are doing! The CSS link has the old media targets. 5's validator will bitch about projection and tv as being outdated, which is a laugh when supposedly 5 compliant browsers will still report themselves as such, everything from WII to Kiosks will report one of those values. Again, 5 validation is so meaningless it's why I test as 4 Strict FIRST, then swap out the header on deployment. Notice I use a MEANINGFUL filename on that css instead of some vague/pointless "style.css" -- herpafreakinderp people, of course it's style, it's a freaking stylesheet; what is that stylesheet FOR?!? When I wrote this I first started out making a logical document structure that went like this: http://www.cutcodedown.com/for_others/chetan_tudor/semantic.txt I ALWAYS start with the content or a reasonable facsimile of future content BEFORE I screw around worrying about the layout and style, since not all visitors are sighted, and search engines don't have eyeballs and could give a flying fig about your layout. The H1 being the topmost heading underwhich everything on the page is a subsection, the h2 indicating the start of those subsections, and the hr indicating another subsection that doesn't warrant it's own numbered heading (aka the footer) The DIV that I added are presentational hooks without saying what that presentation IS. That's what DIV and SPAN are for which is why they are called "semantically neutral" -- I don't need any of HTML 5's halfwit nonsense ALLEGEDLY semantic ARTICLE, SECTION, NAV, or ASIDE tags since the numbered headings and horizontal rules are already outlining the sections JUST FINE. To make the page stretch to full height cross-browser if the content is shorter than the window -- something I assume you were aiming for with those massively tall boxes -- our best bet for modern design is flex-box. There are other "100% min-height" methods but they typically involve knowing ahead of time how tall the footer will be as you either ride it up with a negative margin, or worse absolute position it. Flex IS deployable if you know what you are doing, and this code shows how. As such #top wraps the H1 for width constraint and background on the assumption you'd probably have more there than just the heading. In the CSS we'd want this to 'flex-shrink' to fit it's content. .columnWrapper will serve multiple purposes: width-constraint, float wrapping, AND flex:auto so that the content area will grow to push the footer to the bottom of the screen if the content is too short. .fauxColumn is a pretend background for the sidebar (DIV#extras) that we APO underneath the sidebar. This way we don't have to try and flex inside a flex (which IE and FF still choke on), screw around with possibly broken absolute positioning or garbage broken fixed height asshattery, etc, etc... TECHNICALLY if you don't care about legacy IE you could delete this DIV and use generated content in the CSS to make it, but I included the markup bloat for clarity sake. The double wrapping DIV .contentWrapper and #content around the main columns are there to allow content-first semi-fluid float layout. While there are techniques for doing this without that extra wrapping DIV, they tend to be fragile, unpredicatble, and an all around headache. For now let's just say I can live with one extra DIV (yes, Mr. always bitching about "div for nothing" is saying that). Oh, notice the commenting style? There's a bug in legacy IE and some versions of FF that can rear it's ugly head if a comment ends up between floated or positioned sibling-level elements. Moving the comment before the close means they can never be between siblings... I don't waste time with "Start content" comments since that's what <div id="content"> means; if you need a comment for that you probably shouldn't be writing HTML. It is handy to know WHICH DIV are being closed... notice I use CSS syntax on those to make it clear what's being handled. I call the sidebar "extras" because it's not always a sidebar. IT's just extra stuff on the page separate from the content (usually). Don't even get me STARTED about 5's halfwit ASIDE tag... Might as well go back to using CENTER 1990's style Close the columnwrapper, give the footer it's own DIV, done... That's the markup. Now for the CSS which will take a bit longer for me to document.
Alright, if you follow along with the CSS: http://www.cutcodedown.com/for_others/chetan_tudor/screen.css I always start out with a reset. There are smaller ones like the so called "universal" reset of * { margin:0; padding:0; border:0; } but that can cause MAJOR headaches with form elements. There are larger resets like Eric Meyer's "Reset Reloaded" but those are so massive they are damned near frameworks, and that's why as a rule of thumb they are what gives resets a bad name and why many developers will badmouth the very concept of it. (Usually making **** up about it making their code bigger to cover up their own ineptitude). The reset I use is a nice middle-ground. Wait, what's that? I see that look... What's a reset? Resets address the fact that originally it was NEVER the intent for any tag to have a consistent appearance across user-agents. (what today you would know as a browser -- all browsers are UA's but not all UA's are browsers). Because of that the longer a browser has been around (yes, FF and IE, I'm looking at you guys!) the more likely it is to be inconsistent in padding, margins, and borders around elements by default. To me a reset is just like variable initialization, a PITA, but usually something you can copypasta. At a quarter K the one I use is fast, simple, reliable and not large enough for anyone to bitch about as being bloat. The laugh is I've had people who smear bootcrap all over their sites and then take it to the jquery bar complain about resets... RIGHT... I should point out that when making a layout I start with the lowest common denominator first. A LOT of people seem to think that means mobile... and they'd be wrong sine we can TARGET any small screen device that matters with media queries. The lowest common denominator would be what we CAN'T target with queries -- and that means IE8 and earlier at desktop resolutions! I then hide all HR. Since HR means a semantic break/change of topic and we don't want to have it draw a line (the default appearance that has NOTHING to do with it's meaning) we just hide those. The -text-size-adjust are there to tell older IE and Safari mobile devices that have low resolution displays that we know what we're doing -- much akin to the viewport META. Thankfully I've never seen a device wider than 480px that needed this setting. html, body -- To have "flex-box" work right for min-height it's best to set both width and height on body to 100% for it to function properly. IF IE9/10 and "edge" were coded right we'd only have to do height. There's a rule of CSS some people can't quite grasp, and that's that if a element does not have a height applied to it or some form of flex or positioning, a child cannot declare a percentage height. So to min-height and flex, we need to set height on body and HTML. Thankfully as the top-most element HTML should always obey a percentage height. There's an old IE hack called the "holly hack" to trip haslayout that relied on this quirk of CSS. MOST of the time you can safely declare height:1% and it's ignored in modern browsers unless the parent has a height declaration... body -- We set up body as our flex-box container. We could remove a lot of the inner DIV by adding a width wrapping DIV (I know, sounds weird) except that IE 10, 11 and edge won't flex for height then. The flex-direction tells it we have a single column we want to fill, the flex-align (and the retarded browser specific crap) tells it that all child flex elements should center on that axis -- we should NOT have to set that but with the float inside .columnWrapper once again IE is being a ... No kitty that's my pot pie. Not kitty, that's a bad kitty. Mommy, Kitty's being a .... I set a min-width so non-responsive pre-css3 browsers won't go into a broken unusable layout. Said min-width is in EM so it's elastic. I also set the font size that 99% of my content is going to be on the page here. SOUM -- Set once, use mostly. Again the only legitimate reason for a face or style change should be to make sections/headings clear... I also like to use a taller than normal line-height as it just helps with legibility IMHO. This can vary depending on what font-face you choose. (some advice, avoid webfonts for 'flow text') Then finally the background to be shown when the max-width of the layout is hit... which brings us to: #top, .columnWrapper, #footer -- these all get the same max-width and margin centering. In THEORY we have flex-box so we shouldn't need that auto margin, but again IE is being stupid and we want legacy browser support. LAughably with this set we shouldn't need flex-align, but again IE is stupid so... For all their advances, IE 11 and "edge" are proving to be just as annoyingly inconsistent as everything that came before them. Across the stylesheet you'll see me put together selectors that share similar values. You do this, and nonsense like LESS or SASS with their "variable" garbage starts to look rather silly. #top, #footer -- these too also need to be told to go to width:100% as flex will try to shrink them to fit their content IN IE ONLY. We DO want these to shrink to fit their content height-wise though so the flex-shrink is for all browsers. Finally some colour so we can see them clearly. #top -- ooh, a bottom border... h1 -- just some padding and style. At 200% font-size inherited off body, 0.5em == 1EM of body scale padding. Centering, yawn. h2 -- similar scaling. 125% size means that 0.8EM == 1 body EM. p -- On all of these you'll notice I'm using padding instead of margin. Margin collapse issues are a pain in the ass, and I just find it easier to use padding instead when possible. You'll notice on those three I do not set a top padding. Since padding doesn't collapse I put 1EM of padding at the top of the parent elements these would contain. It's a cheap cheat to make sure undesired collapse (which can happen with floats and/or flex) doesn't make us go "WHAT'S GOING ON?!?" .columnWrapper -- relative positioning so we can absolute position the .fauxcolumn inside it. Overflow will trigger float wrapping in modern browsers, and I threw haslayout at it to do the same in legacy IE. Background color is nothing to write home about, and then we have our flex setting. The 1 means it can grow, the 0 means it can't shrink below content size, the auto means... oh damn, I admit it -- I just copypasta that as I'm still learning it too. It's too new and still VERY inconsistent cross browser. .fauxColumn -- apo bottom right, same width as the sidebar, full height of our parent .columnWrapper, color, border. .contentWrapper -- Here's where the magic happens. We float this left and set the width to 100% it leaves 0px free for something to float next to it. Remember that as, well... #content -- padding to space it from the edges, the margin-left makes VISUAL room for the elastic sidebar. #extras -- and here's the magic wand. Relative positioning will z-index this over #content and .fauxColumn thanks to source-order. We float it left and set our desired width, but then set a negative left margin equal to that width. Negative margins are strange and take a bit of "out of the box" thinking. Really you have to think of all elements as having TWO actual boxes -- the "render box" and the "flow box" -- that's my name for them, I've never REALLY seen it described or proper names attributed to this behavior. The "render box" is what's drawn, based either on the declared width or the content, whilst the "flow box" is how big other elements THINK it is and/or where it is on the page. Relative positioning for example if you use top and left will move the render box, but the flow box will remain in it's original position. In this case we're using a negative margin, which shrinks the size of the flow box without changing how big it's drawn... Net result? a width:20em element with a margin-left:-20em; declaration will have a zero width in flow... well, remember how above we said that 100% float left leaves 0 width free? Now our floated #extra fits and pops up into place OVER #content and .contentWrapper. (and .fauxColumn as well). IT's a cute trick and one of the few reliable ways at the moment to do a content first fluid column next to an elastic sidebar. You can take that even further using position:relative to make a layout that does three columns with two of the columns being elastic and the third one fluid. If you wanted the next "extra" section to be on the left, you'd just set margin-right instead of margin-left, and then left:-100%; Confused? It is a complex layout concept. Trust me, it works. #footer just some padding, alignment and a top border. Nothing fancy. ... and that's the desktop layout. At 50 browser em (50em * 85% font-size == 42.5em) I made a media query to swap out to single column. First it lowers the min-width on body to the smallest handheld size that's likely to be worth targeting. I then kill off the fauxColumn, pull the margin off #content, then set the width to auto on #extras pulling it's margins, setting a background, and adding some borders. ... and that is how one does a fairly simple and reliable acessible gracefully degrading semi-fluid elastic responsive layout. Hope all this helps, yes I know, it's a LOT to digest.