Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 10 of 10

Thread: Help with DIVS

  1. #1
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    6
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Help with DIVS

    Hello,

    I've currently got this website i've made, it has 2 divs one being a parent one being a child and it has another 2 of the same on the right. I've used float to get them aligned like this. However i'm trying to add a padding to the parent div but the child div is also getting that padding. I've tried taking the child div out of the parent div and the layout messes up. I've attached some images and the code so it's clearer what i mean. I basically want the 'Page Navigation' and 'Main Content' title divs to be seperate from the 'leftcontent' and the 'rightcontent' divs so i can style them independently.

    -untitled-png

    HTML:

    Code:
    <!doctype html>
    <html>
    <head>
    <meta charset="utf-8">
    <title>MB Diagnostics Centre</title>
    <link rel="stylesheet" type="text/css" href="style.css">
    </head>
    
    <body>
    <div class="container">
      <div class="header"><img src="images/test/header.png" width="800" height="182" alt=""/></div>
      <div class="nav"><?php include 'navbar_inc.php'; ?></div>
      <div class="main">
      <div class="leftcontent">
        <div class="lefttitle"><b>Page Navigation</b></div>
         <?php diagStats(); ?>
        </div>
        <div class="rightcontent">
          <div class="maintitle"><b>Main Content</b></div>
          <?php echo $maincontent; ?>
        </div>
        </div>
        
      </div>
      <div class="footer">© 2019 MB Diagnostics Services</div>
    </body>
    </html>
    CSS:

    Code:
    .container {
    	width: 800px;
    	margin-right: auto;
    	margin-left: auto;
    	overflow:hidden;
    	background-image:url(images/test/bg_container1.png);
    }
    .header {
    	width: 800px;
    	height: 182px;
    	margin-left:auto;
    	margin-right:auto;
    	margin-bottom:-15px;
    }
    .nav {
    	width: 800px;
    	height: 26px;
    	margin-right: auto;
    	margin-left: auto;
    	padding-top:4px;
    	text-align:center;
    	background-image:url(images/test/bg_nav1.png);
    }
    .main {
    	width:750px;
    	margin-left:auto;
    	margin-right:auto;
    	overflow:hidden;
    	margin-top: 10px;
    }
    .leftcontent {
    	width: 250px;
    	height: 200px;
    	margin-left: 15px;
    	float: left;
    	border: 1px #000000 solid;
    }
    .rightcontent {
    	width: 450px;
    	height: auto;
    	margin-left:15px;
    	margin-right: 15px;
    	float: left;
    	border: 1px #000000 solid;
    }
    .footer {
    	width: 800px;
    	height: 73px;
    	margin-right:auto;
    	margin-left:auto;
    	padding-top: 20px;
    	text-align:center;
    	background-image:url(images/test/bg_footer1.png);
    	background-repeat:no-repeat;
    }
    .lefttitle {
    	height: 20px;
    	width: 250px;
    	margin-left:auto;
    	margin-right:auto;
    	background-color:#666666;
    }
    .maintitle {
    	height: 20px;
    	width: 450px;
    	margin-right: auto;
    	margin-left: auto;
    	background-color:#666666;
    }
    body {
    	background-image:url(images/bg_body.png);
    	background-repeat:repeat-x;
    	margin-top: 0px;
    }
    Thank you

  2. #2
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,329
    Thanks
    4
    Thanked 479 Times in 467 Posts
    Why are you using DIV+classes to do numbered heading's structural job? Should that first image even be in the markup instead of a H1+text and a image replacement method? What's with the pixel metric layout are you just TRYING to tell users with accessibility needs to BOHICA?

    Though as to your "problem", padidng gets added to width breaking the layout, which is why you pad/margin the content not the outermost container. What's the markup for what's going into those DIV look like? You might need a extra DIV if there's no actual semantics on your content to target.

    Another trick is to NOT declare widths and floats on everything, leave at least one column fluid so that the one float (usually the smaller one) gets an elastic (em) width. (Not fixed aka px measured!) whilst the rest of the content auto-expands to fit.

    Oh, and this is 2019 not 2009, you can stop saying "type="text/css" on your stylesheet LINK. If you get JS involved you also no longer have to say type="text/JavaScript" on the script tags anymore either.

    ... and where's your MEDIA target on your stylesheet LINK?

    Also depending on if you care about accessibility your content column should TRY to come before your 'extra navigation' in the source-order. This likely means using the new CSS grid layout module, or the old negative margin float layout 'trick'. I would use the latter for maximum legacy compatibility since it's really no more/less code.

    Bottom line, you have a number of DIV for nothing whilst possibly lacking them in some needed spots, DIV doing H1 and H2's job, and possibly a IMG that has no business in the HTML. Not surprising you're having trouble with layout at that point.

    Your markup should likely read more like this:

    Code:
    <!DOCTYPE html><html><head><meta charset="utf-8">
    <meta
    	name="viewport"
    	content="width=device-width,height=device-height,initial-scale=1"
    >
    <link
    	rel="stylesheet"
    	href="screen.css"
    	media="screen,projection,tv"
    >
    <title>MB Diagnostics Centre</title>
    <link rel="stylesheet" type="text/css" href="style.css">
    </head><body>
    
    <div id="top">
    
    	<h1>MB Diagnostics Centre</h1>
    	<?php include 'navbar_inc.php'; ?>
    	
    	<div class="columnWrapper">
    	
    		<div id="content">
    			<h2>Main Content</h2>
    			<div class="inner">
    				<?php echo $maincontent; ?>
    			<!-- .inner --></div>
    		<!-- #content --></div>
    		
    		<div id="extras">
    			<h2>Page Navigation</h2>
    			<div class="inner">
    			 <?php diagStats(); ?>
    			<!-- .inner --></div>
    		<!-- #extras --></div>
    		
    	<!-- .columnWrapper --></div>
    	
    	<div class="footer">
    		<hr>
    		&copy; 2019 MB Diagnostics Services
    	<!-- #footer --></div>
    
    <!-- #top --></div>
    
    </body></html>
    The H1, H2 and HR provide navigable accessible structure and ditch a ton of "classes for nothing". You don't like how the HR looks on screen, hide it! Again, semantics before looks!

    Then pad .inner for your inner areas. To do the layout I would suggest something along the lines of:

    Code:
    /* assumes a reset is in use */
    
    #top {
    	max-width:50em;
    	margin:0 auto;
    }
    
    h1 {
    	text-indent:-999em;
    	background:url(images/header.png);
    }
    
    h1:after {
    	/* sneaky trick to maintain aspect ratio if/as image shrinks */
    	content:"";
    	display:block;
    	width:100%;
    	height:0;
    	padding-bottom:22.75%; /* 182/800ths */
    }
    
    .columnWrapper {
    	overflow:hidden;
    	padding-left:17.5em; /* width of sidebar + any desired padding */
    }
    
    #content {
    	float:right;
    	width:100%;
    }
    
    #extras {
    	float:right;
    	width:16em;
    	margin-left:-17.5em;
    }
    Again, all in EM instead of PX so you aren't telling users with accessibility needs to sod off.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  3. #3
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    6
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Thank you very much for that very informative and great advice/help! i'll certainly be researching and learning from that!

    Just in case you thought that the first screenshot was the only part of the site, i only cropped it to show you what i meant, this is the whole site(by the way, this is my first ever properly(least by looks) designed site

    -untitled-jpg

  4. #4
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    6
    Thanks
    0
    Thanked 0 Times in 0 Posts
    If my font size was 12pt, would I need a 66em width to stay the same width as I have currently? I’m at 800pxs and I like that size as all my images are sized at that as well

  5. #5
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,329
    Thanks
    4
    Thanked 479 Times in 467 Posts
    Ok, with the full image and what you're saying, you've got some incorrect preconcieved notions when it comes to building a page. Likely you've come across a mix of outdated information and just plain bad advice.

    1) Pt is 1/72th of an inch, a PRINT measurement that has no business being used on a website. It has no fixed relationship to PX nor does it scale properly in all browsers. The measurement to use is EM which starts out based on the user/browser default size (which could be ANYTHING) and is then multiplicative of whatever the parent element is set to.

    2) mixing PT with PX is bound to be broken since there is no fixed relationship betwixt the two.

    3) Fixed width layouts are trash. Not all screen sizes are the same size, some are smaller, some are larger, and you need to design in a manner that works for everyone, not just the perfect mix of screen size and pixels per inch you happen to be using.

    4) Most of what you're using images for isn't stuff web developers of any competence use images for. There's a reason Photoshop is NOT a design tool no matter how many artists under the DELUSION that they are designers try to tell you otherwise.

    In only see one thing I would have in that layout as an actual image file -- the yellow part of that logo with the text inside it. NOT the text next to it. NOT the box around it. NOT the inward slanted section below it. NOT any of those borders. NOT any of those shadows or gradients. NONE of that anytime over the past decade requires images, and most of it using images for is an epic /FAIL/ at web development for some two decades.

    But yes, there are jokers out there who will make up lame excuses about how "we don't have to worry about users of different font sizes anymore" or "that's not our audience" and all sorts of other malarkey that just tricks beginners into making the same mistakes that were made twenty years ago.

    In that way it's a bit like the measles or polio... We know how to stop it, how to avoid it, but some people insist it's harmless and then sucker others into the same delusion.

    Of course I can tell you're being taken advantage of by lies and scams just from one simple thing in your screencap -- that little green icon that says "Dw"... Dreamweaver, the only thing you can learn from it is how NOT to build websites. EVERYTHING it does "For you" it does wrong, everything it tries to teach is wrong, and whilst it's theoretically possible using JUST the code editor part of it to make a decent website, I've never actually seen it done.

    You really should do yourself a favor, kick that bloated overpriced pile of scam bait to the curb, and go get a simple flat text editor like Flo's Notepad 2 (what I use), Atom, Sublime, Visual Studio Code, EditPlus, Notepad++... there are dozens if not hundreds of them, they're free, and it means you won't track any of Adobe's manure across your website's carpets.

    I just tossed together a quick example of how I'd approach what you have so far, again using only the one image.

    https://cutcodedown.com/for_others/mike199028/

    I've had something come across my desk I need to deal with first, but when I'm done with that -- or tomorrow morning -- I'll try to put together one of my infamous "line by line" breakdowns of the how/what/why of the code so you can learn from it.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  6. #6
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    6
    Thanks
    0
    Thanked 0 Times in 0 Posts
    WOW I’ve got to hand it to you that looks AMAZING! I’d really be interested in learning how that would be done. So you’re saying simplicity is the key? No need to over complicate things?

  7. #7
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    6
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Sorry, can’t find the edit post button but I’d like to learn how to make sites that are ‘all/most device friendly’

  8. #8
    New to the CF scene
    Join Date
    Feb 2019
    Posts
    6
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi, have you had time to do the line by line break down?

  9. #9
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,329
    Thanks
    4
    Thanked 479 Times in 467 Posts
    Sorry for the delay, got distracted and lost track of this one... and sorry if I'm a bit saltier than usual today. Just found out I might have to be flown down to Maryland for an operation. (from New Hampshire -- long complicated messy story!)

    Quote Originally Posted by mike199028 View Post
    So you’re saying simplicity is the key? No need to over complicate things?
    Well, the CSS can get a bit complex, but overall the key is to let CSS do the heavy lifting and to use HTML properly.

    There's this term -- "Semantic markup" -- which is a sick euphemism for just that, using HTML properly. We use the term so as to not come right out and say "you're doing it all wrong" offending the mouth breathing halfwits still vomiting up HTML 3.2 and calling themselves "modern", or the nubes who get suckered by all the web-rot decade plus out of date tutorials filled with lies and bad advice. See the sleazy scam artist dirtbags at W3Schools and their train wreck laundry lists of how NOT to build websites.

    The core of semantic markup plays to HTML's original purpose: Accessibility. HTML's entire job is to say what things ARE or WOULD BE in a professionally written document, and !!!NOT!!! what you want it to look like. All but three of the tags that go inside BODY have a grammatical/structural meaning separate from their default appearance. The three tags without full meanings. are <A>nchor, <DIV>, and <SPAN>, and exist to say "this might recieve style or have a behavior" WITHOUT saying exactly what that style is.

    To that end your classes and ID's should also try to say what things are or what they would be in professional writing, and !!!NOT!!! what it looks like. This is why classes like "w3-red", "text-center", "box-shadow", or "col-4-s" are mentally enfeebled BS promoted by people unqualified to write a single blasted line of HTML or CSS. See EVERY crippled dumbass ignorant "front end framework" -- bootcrap, w3.css, etc, etc -- for such stunning examples of developer incompetence and ignorance.

    This means an H1 is (unless you use HTML 5's pointless SECTION tag) is THE headING (singular) under which everything on every page of the site is a subsection. Hence the site title is usually the best candidate for this. It means a H2 or HR (horizontal rule) indicates the start of a major subsection of the current page. (hence SECTION being a pointless redundancy!) with the first H2 or HR indicating the start of the main content. (Hence HTML 5's MAIN being a pointless redundancy). An H3 is the start of a subsection of the H2 preceding it. H4 is the start of a subsection of the H3 preceding it. Care to guess what H5 and H6 mean? HR means a change in topic/section where heading text is unwanted or unwarranted. This creates your "logical document structure" which non-visual UA's and other means of conveying the page can leverage. THEY DO NOT MEAN fonts in different weights and sizes or "draw a line across the screen", that is JUST their default appearance. Anyone telling you they exist to control appearance or "Just for SEO" are flapping their arse-cheeks in the wind.
    |
    This is why skipping over heading depths going "down" (like putting an H4 after a H1) or pairing headings for title + tagline is incompetent ignorant trash.

    Warning, I tend to overuse the words "incompetent" and "ignorant". One is a insult, the other is not. Ignorant just means people don't know; In THEORY we can fix ignorant.

    P is for grammatical paragraphs, not "oh this is some text", or "this single image is by itself" and it sure as shine-ola doesn't mean "I want a double break after it.". UL/OL are for short bullet point lists or sets of selections/choices. That's bullet point as in the grammatical sense and not "Hurr durrz its be haz teh dots befur 'em" and it certainly doesn't mean giant sections with headings.

    So keeping all that in mind, let's break down the HTML first. I'm uploading a .txt just in case one is a bit gun-shy of view-source.

    https://cutcodedown.com/for_others/m...plate.html.txt

    On the first line I condense the modern HTML 5 doctype through to the character encoding meta to a single line. This is not to try and save any bytes (as I think whitespace stripping for byte saving on markup is a waste of time) but instead is a reminder that these tags MUST appear in this order, so don't go pasting or inserting any code before or in-between them. The character set META in particular since if it gets pushed down past the first 1k of code or ends up after a CDATA bearing element (like keywords/description META or the TITLE tag) the browser will have to restart from the beginning of the page when it hits that META to make sure it understood all the text correctly.

    Hence a very important little good practice to get into? META FIRST. charset META first of all.

    I likewise if you check further down the document condense the close of HEAD and opening of BODY, and the close of BODY and HTML to single lines. You'll see it all the time where someone either accidentally or out of ignorance will paste code between those tags which is invalid. Having a gentle reminger "don't do that" can make a big difference.

    Next is the viewport META. This tag exists to tell small screen devices that we know what we're doing, so do not try and override our style with their own sizes and scaling, or to lie to us about how big the screen is. Some devices (HDX/Retina displays, tablets) will still lie to us, but do so in a less destructive manner than smaller and older phones. Some people say you can skip the height setting here, my android tablet and older phone beg to disagree.

    The stylesheet LINK we no longer have to say type="text/css" on, as HTML 5 dropped that when rel="stylesheet" and no browser ever actually paid attention to it anyways. Likewise if you have scripting you no longer need to say type="text/javascript" on your SCRIPT tags. (and you certainly don't need to say LANGUAGE="") If you see those attributes in someone's markup, it's either old code or someone hasn't updated their skill set in a while.

    The MEDIA attribute on the stylesheet LINK is important to say what the style is actually for. Otherwise you're sending your screen media style to print, aural/speech, tty, and who knows what else. The HTML 5 validator will complain about the use of "projection" and "tv", to blazes with that noise. There are still enough devices in circulation (nintendo browsers, kiosks, MSN TV) that will try to muck with our style if we don't include these, so I ignore that warning. Honestly, the 'valid' media targets should be none of the HTML specifications business! Let's just say I don't entirely agree with everything they've done in 5.

    TITLE, /HEAD, and BODY are nothing to write home about, but on TITLE try to keep it formatted as "Page Title - Site Title". The purpose of the title tag is to be shown in the window frame, tab box, taskbar, and as the text of any backlinks to the page such as on your SERP listing. (Search Engine Results Page). As such try to keep it useful and try not to let some alleged "SEO Expert" dupe you into keyword stuffing it for no good reason. As Matt Cutts told us over a decade ago, "write for the user not the search engine."

    DIV#top -- our outermost wrapper. It's easier to just have a wrapper to set the max-width on so that the contents just auto-constrain to that one container. That way we're not wasting time trying to declare perfect widths on every blasted thing. I call it #top so that if we want to add a "back to top" link in the footer later on, we can just do <a href="#top"> and be done with it. What it is, the top of the page.

    H1 -- Our main heading. The site title. TEXT. The images used are presentation not content, so they belong in the stylesheet and not the HTML.

    DIV#h1After -- says what it is, "something" after the H1, without saying what. This is a styling hook that does not alter the meaning of any of the content, and will be used to make the diagonally offset box that gives the H1 the 3d-looking effect.

    DIV#outer -- another wrapper for presentation, without saying what that presentation is. It's just an outer wrapper around the menu, content, extras, and footer.

    UL#mainMenu -- the menu. UL/LI since a menu is a short list of selections, Anchors for the behavior, and one class "current" to mark the current page. Some people use a class "active" to indicate the current page, I consider that just begging to screw up since :active is a CSS state. TRY not to name things the exact same things as CSS pseudo-classes!

    DIV#columnWrapper -- wraps around things that MIGHT be columns, without saying how many columns. This lets us if desired use floats or other techniques without having to resort to the outmoded "clearing DIV" nonsense or slopping a class like "clearfix" all over the place.

    DIV#content -- the main content. I put this first because from a logical document structure and accessibility standpoint you want the content FIRST for people not looking at it on screens!

    DIV.subsection -- these appear multiple times. Technically as you only had two boxes this [i]could[/b] be "DIV for nothing", but since you likely would have multiple subsection boxes these hooks allow for that styling to be more easily re-used. "subsection" is again saying what it is, NOT what we want them to look like. This is one of the few places the "semantic" SECTION tag might have made sense, but it applies meaning before we have meaning so I just use DIV. Really the new "structural" tags in HTML 5 are little more than pointless code bloat.

    The H2 inside them of course mark them as the grammatical / structural start of the content.

    DIV#extras -- Just extra page stuff like your secondary "navigation" or whatever else is going into the sidebar. I do not say "left" or "right" on content/extras since that's saying what they look like. It's just "extra" stuff after the content.

    If building three column layouts I'll often have DIV.firstSection and DIV.secondSection inside #div, so that the inner DIV behave as the second and third columns, but I can kill that column behavior when the screen narrows and make them one tall column as #extras, then when narrower again put them below the content side-by-side, then even narrower make the whole layout one column. The true power of media queries!

    DIV#pageNavigation.subsection DL -- I used a definition list for the semantics of the values and descriptions. This is slightly abusive of the tag's meaning -- terms and definitions -- but an accepted practice. Depending on what else is done this MAY qualify as tabular data, in which case TABLE would be the correct tag.

    Oh, and notice my closing comments. When you have DIV it's easy to lose track of which one you're closing, so adding a comment to say what's being closed just makes life easier. Even though your indentation habits should keep this clear as well! I don't say "end" because hurr-durrz, that's what the / in /DIV means. I put the comment before the closure because if a comment ends up between two sibling elements it can in older versions of IE and like every other blasted version of Firefox introduce rendering errors or stuff you have to 'hack around'. With the comment before the closing tag it can never be between sibling-level elements dodging that headache altogether whilst still giving us clear code. I also use period and # to indicate what exactly is being closed (class or ID).

    If nothing else with longer content-filled pages it saves you some scrolling up and down.

    #footer -- we start with a HR to say this is NOT part of the H2 "something else" before it. That's what HR does. We don't like the appearance on screen of that, hide the HR. The text inside it is NOT a grammatical paragraph, barely qualifies as a sentence fragment. As such I just leave the text 'hanging' without it's own block-level tag.

    Close it out and there's the markup. Gimme time for lunch and I'll belt out a CSS breakdown which is where things get more complex.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com

  10. #10
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Location
    Keene, NH
    Posts
    3,329
    Thanks
    4
    Thanked 479 Times in 467 Posts
    Ok, on to the CSS. Follow along with the bouncing ball at:

    https://cutcodedown.com/for_others/m...028/screen.css

    Every one of my stylesheet starts out with a "reset". Resets exist because the HTML specification does not actually even say how any of the tags should be rendered for screen. That was never its job and it's mostly the luck that IE and Netscape were based on MOSAIC that we even have close to a common starting base when using CSS. Unfortunately some values -- margins, padding, and borders -- were not consistent as M$ and Netscape got into the little pissing contest known as the "browser wars" so we have to fix those elements that disagree.

    I also set the line-height as it doesn't inherit properly and I prefer slightly taller than the default as it aids legibility.

    There are smaller resets, like the so called universal "* { margin:0; padding:0; border:0; }" but that can wreak havoc with the size of form elements between IE and FF. There are larger resets like Eric Meyer's "Reset Reloaded" but that fat bloated pig wastes a slew of code changing values that are NOT inconsistent cross-browser to the point it borders on being a framework unto itself. Massive resets are what gives them a bad name and is why even though it's harder and more bug prone, many developers who try them end up disenchanted with the entire concept.

    I find the truth to be more in the middle. At a quarter k it's not so big as to cause bandwidth issues or make things harder, whilst fixing all the problems that can otherwise arise.

    After the reset I hide all HR since those are for semantics and non-screen navigation/structure. We will be conveying it's meaning via other means.

    The -text-size-adjusts inside the media query, well the comment there says what it's for. Telling first and second gen handhelds that don't know what a viewport META is to not play stupid games with the font-size or scaling.

    From here out I'll go by selector. I always start with the desktop layout first. A LOT of people will say "mobile first", I consider that foolhardy at best, ignorant at worst. Mobile / small screen devices we care about can be targeted/modified by media queries. What we can't customize with media queries is legacy desktops... so why would you start with what can be customizes instead of what CAN'T?!? Doesn't make a lick of sense!

    html, body -- I set this to 100% height to fix how the body background will incorrectly "shrink" if the window is taller than the content. It also means IF we want to implement a 100% min-height layout later the hooks are already in place to allow it.

    body, button, input, select, table, textarea -- sets the font-family we want over most of the document AND by setting the font-size and line-height we fix how by default the table and form elements do not inherit their font-size from BODY. Using the condensed "FONT" property just saves us a few bytes at the same time.

    I declare my font-sizes in EM and will use EM across the entire page so that users with non-standard font-size preferences will have the entire page scale to what THEY like. That way large-font users (like myself) aren't sent diving for the zoom. This is called "elastic layout" and alongside "fluid" (min/max dynamic width) and "responsive" are major checkboxes for accessibility. 90%+ of the time you see a measurement in PX other than a small border, shadow, etc, it's being done wrong.

    body -- pad the sides to make sure that when the window is narrower we can still see the background when there's the screen space to do so. Then a background colour for older browsers that don't know linear-gradient, then the gradient itself. The "fixed" and "background-size" fix bugs in Safari and Chrome where the linear gradient will repeat no matter what else you set if the content is taller than the window.

    #top -- the overflow:hidden makes sure any 'floats' are contained inside it. I generally do this as a safety precaution just in case a content float is improperly handled elsewhere in the future. The max-width means the page will grow to that width and no wider, but will also shrink down to fit smaller displays. 90% of the grunt-work of a 'responsive' / mobile friendly design can be handled right there by simply not even thinking in fixed widths and letting the width and 'flow' do their job! Then the auto-margin centers it.

    h1 -- pad all around, bump the text size, center everything... the border gives that outer black area at 1/3rd the font-size (0.33em), whilst I use an inset box-shadow to draw that faint tan line. No images needed.

    h1:before -- this is called "generated content" which lets us inject extra elements (or even text) into an existing element. In this case we're adding an empty (content:"") element that's inline-block for the image. I declare the image size in EM so that it scales to the user's font preference. To that end I created a much, MUCH larger version of the image:

    https://cutcodedown.com/for_others/m...ges/h1Logo.png

    That the browser can then scale down. This means "retina / HDX" display users (who usually get pages zoomed in 2x) get a high res image without any extra work needed. Thankfully modern browser image scaling is top notch often leveraging the anisotropic filtering capabilities of video cards, and when it comes to older browsers (IE8/earlier) if they can still see it, who gives a flying purple fish?

    In production I would consider trying to make that image a SVG or a crisper .png than the one I made there.

    Bottom line, that generated content creates the image, it being inline-block and vertical-align:middle makes it behave as if it were a giant character next to the existing H1 text.

    .h1After Normally I'd try to use generated content for this, but with the border on the H1 it gets a bit fragile and tricky, so I created a HTML element to hook. This creates that black trapezoid beneath the H1 using a cool trick. Borders of multiple colours have diagonal intersections, so by makign the top border tall and black, and all the other borders invisible we can make a trapezoid of a solid colour. Set the height of the empty DIV itself to zero and Bob's your uncle, it's ready to go.

    consider this example:

    <div class="trap"></div>

    Code:
    .trap {
    	height:1em;
    	width:10em;
    	border:3em solid;
    	border-color:red green blue orange;
    }
    See how the top red area is a trapezoid. If we set the height to zero and the green/blue/orange area to transparent, we are left with just the top trapezoid. Same method can be used to make triangles since if the height was zero the green/orange areas would be triangles. IF the width was 0 the red/blue would be triangles. VERY powerful trick that often means one less image file.

    .outer -- I added position:relative just in case you get fancy in the future with the H1. Should you have positioned content in the H1 it could depth-sort over .outer, the relative prevents this. This is important as the box-shadow that's declared we want to blur over the black trapezoid. I set each side manually using overlapping shadows for better definition and so that the top one (-0.25em)

    If you're unfamiliar with box-shadow, you can declare multiple shadows per element comma delimited, with the first parameter being X offset, second being Y offset, the third being blur. If the fourth parameter is a measurement of distance it will be a "Grow" that expands it in all directions as a solid color before the blur is applied (I rarely use that), and the last parameter is always the color to apply. If you use a brighter color than the background, you get a glow instead of a shadow.

    text-shadow is similar in function, but does not accept the "grow" value.

    We use border-radius to round the corners, I gave it a slightly darker background for better defintion of the .subsection boxes, and of course we margin it in on the sides for the same width as the bottom of the trapezoid. The bottom margin makes sure that some of the BODY background will appear down below.

    #mainMenu -- turn off bullets, center the text, background colour for old browsers, gradient for the modern background. Easy peasy lemon squeezy.

    #mainMenu li -- makes them all show on one line. Inline-block could cause problems in legacy IE and trying to style LI on menus can be a headache, so I prefer to only set the LI as inline and style Anchors or SPAN inside the LI instead when it's a single-row menu.

    #mainMenu li:after -- another generated content, this time plugging in a vertical break character as the divider. The left/right padding is unevent as the spaces between LI end up on the right side and are roughly 3/10ths of a EM in width for arail. You may have to adjust this if you choose another font-family. There are ways to avoid this and make it consistent, but they tend to be code-heavy and not worth the effort when you can just tweak the padding smaller on the right.

    #mainMenu li:last-child:after -- naturally we don't want the padding or vertical break on the last LI, so just hide that one.

    Combined, proper block-level semantics for accessibility in the markup, but we still get our dividers on the screen version.

    #mainMenu a -- inline-block so we can set top/bottom padding on it. (the default of inline top/bottom padding is ignored!). Color them, and I applied some black text-shadow to improve the legibility. I also set up a color transition for the hover state.

    #mainMenu a:active,
    #mainMenu a:focus,
    #mainMenu a:hover,
    #mainMenu .current a
    -- the hover/navigation and .current appearance. Brighter, with a slight glow. :hover is obivously the mouse-over state, but navigation isn't always done with a mouse. :focus is for keyboard navigation, and whilst technically :active represents that it's the most recently clicked on Anchor, some older browsers incorrectly use :active instead of :focus. Good rule of thumb? Just set all three psuedoclasses of :active, :focus, and :hover when designing hover states.

    .columnWrapper -- overflow:hidden to wrap floats, pad the content in. The massive right padding sets up for whats called "negative margin" columns.

    there are MANY ways to make columns now, but not all of them can do a "content first" approach or do so easily. Floats remain a tried and true method that's rock solid reliable -- whereas doing this with flex-box would/could be a confusing mess, and CSS grids whilst insanely powerful whilst simultaneously easy to use, doesn't exist in older browsers. For your purposes, I would say stick to the proven techniques.

    So, that giant left side padding? The #extra's column is actually going to sit over that.

    #content -- floated right it's set to take up the full available width, leaving zero space free for anything to float next to it. 0 pixels free for something to fit. REMEMBER THAT.

    #extras -- position:relative let's us tweak it's positioning with "left'. We float it right and set the elastic width of 16em, so with the 18em padding on .columnWrapper we have an extra 1em of space around it. Then we set a negative margin equal to it's width.

    Negative margins are... funky. They tell the browser to treat the element as smaller than it is drawn. It will still be drawn the same size, but in "Flow" -- how other elements react to it -- it will be treated as smaller. Making the left negative margin equal to the width makes it zero width "in flow".

    ... and since it has no width in flow, it can now fit next to #content! Boom, columns.

    Finally we slide it left:-1em more with relative positioning so that our padding all-around is even. Don't know if anyone has explained relative positioning to you yet, but when you left/right/top/bottom an element with relative positioning every other element on the page treats it like it's in the original location, you're only moving where it's drawn.

    Positioning, flow, and margins could take up three chapters of a book to fully explain properly.

    .subsection -- each section has the same background, border, margin, and padding. I pad the bottom but not the top, so that margin/padding on the child elements can handle the other sides. This avoids a issue called "margin-collapse" that could rear its ugly head if we tried to use margin on all sides of the children, or dealing with padding on the parent causing width issues. MORE importantly it lets us have the H2 stretch edge to edge.

    .subsection h2 -- drop the size to 1em, pad it, bold, colour, nothing too fancy.

    .subsection p, .subsection dl -- top and side padding as per the bottom of the container already being padded. If you add UL or other tags that need similar spaceing you'll want to add them here.

    #pageNavigation dt -- floating the terms puts them on the same line as their defintions, and padding to space them apart.

    #footer -- pad it all around, center it, DONE.

    ... and that is the entire desktop layout up and working. To make it small screen / mobile friendly MOST of the work is already done thanks to the elastic semi-fluid design. That max-width letting the page shrink just means when it gets too small we strip off the columns to make it one, and adjust any other elements like the H1.

    To determine the media query triggers I just narrow the window until it breaks, figure out how many EM that is (for normal settings take the pixel width and divide by 16. On the machine I'm on right now it's divide by 20), add 5% to it as wiggle room. Then I make the changes to make the page useful and lather-rinse-repeat until I'm down to 12em, which at normal 16px font-sizes is the smallest device you really have to worry about.

    In this case it only needed one query for 48em. If the screen is wider than 48em everything inside this media query is ignored.

    First we null the padding on body and kill the gradient. We want as much screen space available as we can so ditch the pretty gradient, and setting the background solid uses less memory -- important on handhelds.

    The h1 has its padding shrunk, then we hide both the image (which got too tiny and doesn't fit small screen nicely) and the trapezoid. Basically stripping off excess presentation to put the focus on what's really important -- THE CONTENT!

    With .outer we likewise strip off the border, rounding, and shadows. ColumnWrapper has its padding greatly reduced, whist we strip the floats, left positioning, width, margins, and other values off both #content and #extras removing even more style that we have neither the room nor the time for on mobile.

    ... and that's it. Elastic Semi-Fluid Responsive layout.

    Read through all that, any questions fire away.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture
    http://www.cutcodedown.com


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •