This is my first post here so I hope this is the right place. I am trying to teach myself how to build responsive websites and am just in the learning stages of trying to figure out Zurb's Foundation 6. Anyway, I have put together a simple web page, but I have a couple of questions I cannot find answers for. I am hoping the experts here can help me out. I am trying to figure all of this out and I think I do best with the trial and error method of learning. Question 1: How can I move the sidebar further to the right? Question 2: How can I add space just before where it reads "More Videos" towards the bottom of the page? My test page is at test.allvixen.com/p2.html And my code is: <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Bound Gangbangers</title> <link rel="stylehseet" href="http://test.allvixen.com/css/foundation.css"> <link rel="stylesheet" href="http://test.allvixen.com/css/normalize.css"> <link rel="stylesheet" href="http://test.allvixen.com/css/foundation.min.css"> <link rel="stylesheet" href="http://test.allvixen.com/css/app.css"> <!--[if IE]> <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script> <![endif]--> <meta content="width=device-width" name="viewport"> </head> <body> <header id="site-header"> <a href="http://test.allvixen.com/"> <img src="http://test.allvixen.com/images/header.jpg"></a> </header> <div class="wrapper"> <div class="large-8 columns"> <a href="http://promo.boundgangbangs.com/g/allvixen:revshare-bgbanger/16832/m/0/h/w"> <video id="bound_gangbang_video_1" class="video-js vjs-default-skin" controls preload="none" width="100%" poster="http://test.allvixen.com/images/1.jpg" data-setup='{"example_option":true}'> <source src="http://test.allvixen.com/video/test1.mpg" type='video/mp4' /></a> <p>This is just some sample text for whatever purpose. This is just some sample text for whatever purpose. This is just some sample text for whatever purpose. This is just some sample text for whatever purpose. This is just some sample text for whatever purpose. This is just some sample text for whatever purpose. This is just some sample text for whatever purpose. This is just some sample text for whatever purpose.</p> </div> <div id="sidebar"> <div class="large-3 columns" style="background-color: pink"> <center> <p class="text2">SIDE BAR</p> <a href=""> <img style="margin-bottom: 5em" src="http://test.allvixen.com/images/2.jpg" alt="join now" /></a> <br /> <a href=""> <img src="http://test.allvixen.com/images/2.jpg" alt="join now"/></a> </center> </div> </div> </div> <div class="large-12 columns"> <div class="text3">Other Videos You May Enjoy</div> <div class="large-3 medium-6 columns" style="padding: 1%"> <a href="" rel="nofollow"> <img src="http://test.allvixen.com/images/3.jpg" alt="" /></a> <p>Just some pure simple text describing what the video is all about</p> </div> <div class="large-3 medium-6 columns" style="padding: 1%"> <a href="" rel="nofollow"> <img src="http://test.allvixen.com/images/3.jpg" alt="" /></a> <p>Just some pure simple text describing what the video is all about</p> </div> <div class="large-3 medium-6 columns" style="padding: 1%"> <a href="" rel="nofollow"> <img src="http://test.allvixen.com/images/3.jpg" alt="" /></a> <p>Just some pure simple text describing what the video is all about</p> </div> <div class="large-3 medium-6 columns" style="padding: 1%"> <a href="" rel="nofollow"> <img src="http://test.allvixen.com/images/3.jpg" alt="" /></a> <p>Just some pure simple text describing what the video is all about</p> </div> <div class="large-3 medium-6 columns" style="padding: 1%"> <a href="" rel="nofollow"> <img src="http://test.allvixen.com/images/3.jpg" alt="" /></a> <p>Just some pure simple text describing what the video is all about</p> </div> <div class="large-3 medium-6 columns" style="padding: 1%"> <a href="" rel="nofollow"> <img src="http://test.allvixen.com/images/3.jpg" alt="" /></a> <p>Just some pure simple text describing what the video is all about</p> </div> <div class="large-3 medium-6 columns" style="padding: 1%"> <a href="" rel="nofollow"> <img src="http://test.allvixen.com/images/3.jpg" alt="" /></a> <p>Just some pure simple text describing what the video is all about</p> </div> <div class="large-3 medium-6 columns" style="padding: 1%"> <a href="" rel="nofollow"> <img src="http://test.allvixen.com/images/3.jpg" alt="" /></a> <p>Just some pure simple text describing what the video is all about</p> </div> </div> </div> </body> </html> Code (markup):
Like most framework BS, welcome to what happens when you want to change things. You lack the knowledge of the underlying CSS to make the changes yourself. Do yourself a HUGE favor and kick that steaming pile of halfwit nonsense with it's PRESENTATONAL use of classes to the curb, and just write flat HTML+CSS so you have ACTUAL control and can use a fraction the code. MORE SO that you can get all the extra crap out of the markup (like those style attributes) and actually leverage semantic markup -- like those obvious headings that should be H2 that you have in P. Hence why you've got probably around 33% more HTML than you should have for something relatively simple. Forget the frameworks, and learn to use HTML and CSS without that bloated rubbish. The ONLY thing you can learn from frameworks -- like bootcrap, like foundation, like YUI -- is how NOT to build a website. Hence why you have three stylesheets doing the job of one, improper use or outright lack of proper media targets,
Laugh is since you're green, I stopped prematurely and just hit post. That was the watered down incomplete version. IF I have time later (no promises) I may do a quick rewrite from scratch to show you what I consider the "proper" approach. I do these from time to time.
I would appreciate that. While I am a noob I do have a little working knowledge of html and css - probably just enough to get me into heaps of trouble. You should also know that I am not looking for the "easy" way to build website. I am looking for a method that my tired old brain can figure out and makes sense. Maybe I should start looking to how to build using flat html and css. Thanks again for your input.
Yeah, I gotta agree with @deathshadow here - that layout is quite simple to make with at least no more than half the HTML, and the CSS for it shouldn't be more than a few lines, really. Using the Foundation-crap is basically just asking for trouble - and there is really absolutely no need for it for such a simple site. Depending on what you want to support, if you go with CSS 3 solutions, you can utilize some modern display-techniques as well, like display: flex; - but that won't work in anything older than IE 10(?) (I'm a little bit unsure when IE started supporting flex - it might not have been until 11). If you don't care about older browsers, that isn't really a problem, though.
Ok, since I'm bedridden (again), sitting here with insomnia (again) that has my non-24 all screwed up (again)... I started in on a rewrite for you. For now I've not styled it, so the final markup may change, but I've usually got a pretty good idea of what's needed these days. I'll pretty much be using the methodology I outline here -- that article is meant for advanced programmers, but it should outline the somewhat... different approach I advocate. http://www.cutcodedown.com/article/progressive_enhancement Whenever I do a layout, the first thing I do is as "what is my content" -- I arrange that content as if HTML doesn't even exist, then apply my semantic markup to it. Since you already had the content in a fairly logical order (good job on that BTW, means you've got the instincts for this!) it was just a matter of stripping OUT the markup, then adding back in the tags to semantically say what things ARE. That's what HTML is for really, saying what things ARE. This includes your classes and ID's as the appearance in one condition may not be the appearance for ALL media conditions or targets. That's why <link> has a media attribute and why we now have media queries -- and why MOST of your "responsive frameworks" are utter and complete rubbish as they use classes PRECISELY to say what things will look like... I mean, there's some leeway like saying "widthWrapper" or "heightWrapper" on a DIV as that's what it does, but that's not saying WHAT style is being applied. Because this is the semantic markup stage, tags that are "semantically neutral" -- aka they apply no meaning to their content -- are not applied at this point. Pretty much that means no DIV or SPAN. If we use numbered headings and horizontal rules PROPERLY, that also means we don't need any of the new HTML 5 structural tags as they are redundant. That means no NAV, SECTION, HEADER, FOOTER, ARTICLE, or ASIDE. NOT that ANYONE uses ASIDE for what it means, and instead uses it for sidebars. Herpaderp. Seriously, did nobody else take Theatre Arts in high school? Bueller? I do this initial markup without the header or footer stuff so I can focus on JUST the semantic body content. I choose ALL the tags based on what they mean, and NOT their default appearance. That ends up being something like this: http://www.cutcodedown.com/for_others/vanceVP/semantic.markup.txt Most every document's first content element should be a H1, as that means (using the 4 Strict style logical document structure mindset) the heading that EVERYTHING on EVERY page on the site is a subsection of. You know how in a newspaper or book the title of said document is at the top of every page or fold-pair? Sure, the PRESENTATION might be different on the front page or cover, but that's STILL the H1 regardless of how it's shown. In this case, your different presentation may be an image -- there are techniques for using images whilst retaining proper semantic text, and a good rule of thumb? If an image is presentational (like a logo, which usually represents the company or site name) it does NOT belong in a <img> tag. H2 then mean the start of subsections of the H1, H3 mean the start of subsections of the H2 before it, and so forth. This is why skipping heading numbers is gibberish, choosing numbered headings based on what the look like is equally nonsensical. Equally important is the horizontal rule, which means a change in topic or section where heading text is unwanted or unwarranted. It does NOT mean "draw a line across the screen" as there are many different ways a horizontal rule can be portrayed in text... sometimes it's three asterisks spaced apart and centered, other times it's a line, sometimes it's a single tilde on a line by itself, sometimes it's a page-break. The MEANING of WHY we do that is what the tag exists for. That's why I put a heading in for the video, to say what it is. This marks the start of a new subsection. I put some comments in on advice of stuff to be added later too. The paragraph remains a paragraph as, well, it's a bunch of sentences, that's a grammatical paragraph. The advertisements heading is also, well... a heading, so it gets a numbered heading. IT's NOT a subsection of the video so it too is a H2. You can see again I do this with the "other videos" section. They are all siblings to each-other, the most important one being first. Of course with numbered headings indicating the start of subsections, UA's can (and are supposed) to let you navigate between them (only classic Opera ever did this properly) -- performing much the same job as "skip to" links people hide or HTML 5's <nav> tag that not one blasted legitimate user-agent (browser) has done a blasted thing with. Technically <nav> is supposed to mean "you can skip this section to get to the content" on things like screen readers (software that reads the screen to you)... but that's really the first H2 or HR's job to say "hey, the real content starts here!" Your "other videos" seems to be a list of videos, we have tags for lists... and since it doesn't seem numerically ordered, a unordered list fits the bill. I put the text inside the anchors as it will make a bigger "target" for people to click on or hover over, improving navigation. I did NOT make them paragraphs as LI already implies bullet point text. A good rule of thumb is that if your text is 'hefty' enough to warrant paragraph tags or worse, numbered headings, it's no longer a bullet point list and as such does not belong in UL or OL. In this case, seems perfect. Finally at the bottom I added a horizontal rule to say "this text is NOT part of the subsection before it" -- in this case "Other Videos You May Enjoy", so we can have a brief footer blurb. You lacked that in your design, and I figured I'd toss that in to polish it up a bit more. Ok, gimme a few minutes and I'll write the version that adds the DIV and SPAN for use as presentational hooks, and put a proper HTML document around it.
Alright, I guessed somewhat and this may change when I write the CSS, but for now you can view the document without style here: http://www.cutcodedown.com/for_others/vanceVP/noCSS.html It's important to have some idea what your site will do without CSS -- people on screen readers, braille readers, puffers (devices that tap or blow air on your arm in morse), search engines, and a whole host of other possible user agents (devices used to let users access pages, a browser is always a UA but a UA isn't always a browser) THIS IS WHAT THEY GET. REGARDLESS of what you declare in your CSS. You can see it makes sense and is usable, even if it's not pretty. That's the point -- it "gracefully degrades" to still be useful even without all the bells and whistles. The other point being that if you have multiple pages that use this same style, having all that style external to the markup means you can cache and even pre-cache it site-wide speeding up loads of subsequent subpages. This is why you should NOT EVER use the <style> tag (no matter how many mouth-breathers claim otherwise) and avoid using the style="" attribute unless that is conveying meaning... style conveying meaning is pretty damned rare; tag clouds, progress bars/charts, and... uhm, yeah. Those. So, follow along with the .txt version here: http://www.cutcodedown.com/for_others/vanceVP/template.html.txt I put the doctype, html open, head open, and charset meta all on one line as a reminder that NOTHING should ever go between those, and that the charset encoding should be declared AS SOON AS POSSIBLE just in case the HTTP header is missing. It's a gentle reminder that these go in this order and only whtiespace has ANY business between them. I do the same with </head><body> and </body></html>. ANYTHING you can do to remind yourself not to do something bad (like paste stuff in the wrong spot between things)? DO IT! It's often shocking how often people will just paste things in the wrong spots between those elements. Whenever any line of attributes would get really long, I like to put each attribute indented on their own line. This drives the minification nutjobs nutters, as "aaah, whitespace!!!" but it makes the code clearer and easier to maintain. Besides, 99% of the time how I write pages is smaller without minifying than they have with! The viewport meta is there to tell small screen devices that we know what the hell we are doing on font-sizes and resolution checks. Most people only declare the width and initial-scale, but I've found that some android devices when in landscape will report height as width, so you need that too. There are other values people will put in there, but universally those screw up the user's ability to zoom, a giant middle-finger to anyone who, well... needs to zoom. The CSS link nowadays no longer needs a "type" attribute on it if the REL is a known type with a default value, like a stylesheet defaults to text/css. I always try to name my stylesheets the same as the primary media target they are for, in this case screen devices. It's generally sloppy/bad practice to omit the media attribute, or to use "all" as the value. Your screen layout very rarely makes the least bit of sense in print, aural, or any other possible target. I include projection and TV despite HTML 5 validation bitching about them being deprecated, as there are STILL plenty of devices like kiosks and Nintendo consoles that will either override our style with their own or flat out ignore it if we fail to include those. IMHO the targets for the media attribute have zero damned business in the markup specification! The title tag it's often best to do "page title - site title" as your format. Remember title exists to be the link text on a serp, the title in the window or tab, etc, etc... It's not a place to blindly stuff a useless paragraph when most things will just cut it off. The current page is the important bit of info, so in this case that would be the title of the video being displayed. In our H1 I added a empty span as a "image sandbag" which we'll use a technique called 'Gilder-levin" to place the image over our text hiding it. This way people with images blocked will get the text, search engines will get the text, people on non-visual UA's will get the text, and when the display is too small for our logo image? WE CAN SHOW THE TEXT!!! Or swap for a image more friendly to the smaller size if desired... Cool idea, huh? I added a .heightWrapper div so that we can have a coloured background different from the header and footer which I'm going to leave transparent. This way if the content is shorter than the display, the main colour doesn't run after the footer. We could do a min-height layout where the footer stays at the bottom if the page is too short, but that's a headache and a half to implement. Sometimes you're just better off saying "close enough" since given your content, the "need' for that behavior seems unlikely anyways. #contentWrapper and #content is the "double wrapped" method for making a fluid (aka variable width) column next to one (or more) fixed or elastic column, where the latter one is second in the code -- while at the same time being able to put columns in any order we like, and to strip the columns off completely if so desired. This is a fairly standard -- if not older -- layout practice, but unlike newer techniques like flex it's rock solid reliable -- even all the way back to IE 5.2 Mac. (NOT that we really should be giving a *** about anything prior to IE8, or even IE9 since you're using <video>) #extras is just my name for the secondary column wrapper. I do NOT call EITHER of them columns as they may not always be shown AS columns. That would be presentational, and as such does not belong in the markup. It is NOT an aside, as the advertisements are NOT directly related to the content preceding them or part of same. That's what aside means grammatically, and semantic markup is supposed to be about grammatical meaning and professional writing norms, NOT layout and presentation! Hence why 99%+ of the people using ASIDE are using it wrong, and/or there's no reason for that tag to even exist!... bottom line, ASIDE is as mindlessly stupid and presentational as the CENTER tag, which like FONT has no business on any website written after 1997. I put an extra DIV.adverts in there as a hook to style the anchors and images on the assumption you may have other subsections in the sidebar at a later point. If all you plan on having there is the adverts, you could likely remove that DIV and use #extras as the hook. #otherVideos is likewise a hook so I can target the h2, ul, li, a, and img tags inside it without slapping classes on all of them. It will also be handy for applying things like margins and padding. Close out #othervideos, close out .heightWrapper, and we have #footer. Give it a DIV since the HR is already saying it's unrelated content at the end. Again, why <footer> is pointless as well. Of course another advantage of avoiding all the pointless redundant HTML 5 tags, we don't need to worry about IE8/earlier having no clue what they mean. One thing you might notices is my commenting style. DIV tend to be remarkably vague, and I like to know WHICH div I'm closing. I don't have opening comments because I use meaningful names... <!-- start Other Videos --> <div id="otherVideos"> Code (markup): Would be herpaderp re-re idiotic... really? A div with the ID "othervideos" is the start of our other videos? Whoddathunkit?!? But on the close, it's damned helpful... but I don't say "end" -- why not? Because that's what </div> means... I put the closing comment BEFORE the closure itself because there's a bug in some builds of FF (I swear it comes back every other update) and older versions of IE where a comment between sibling-level tags that get formatting like float, margin, position:relative, etc, etc, can end up with all sorts of rendering issues like the content flat out disappearing, being drawn twice on the screen, etc, etc... people use all sorts of crazy hacks to avoid this problem, when all you have to do is make sure your comments are not between elements. If it's before the closure, it can NEVER be between sibling level tags. Just a good practice to get into alongside strict formatting habits to keep it as clean and legible as possible. That part can seem like a bit of extra work but it really pays off in the long haul. Ok, I'll get to styling this. The markup MAY change while I write the CSS, but I've got the experience at this point to be fairly confident I got it 99% correct.
Sorry for the delay but had to take a break from explaining it. Takes longer to write the explanation than it does to write the code itself. You can view the completed version here: http://www.cutcodedown.com/for_others/vanceVP/template.html There were no major changes to the markup... In practice with real content you may end up fiddling with DIV, SPAN, ID's and classes as you style. Remember only to add them when needed and once you've expended what you can do with the existing semantic tags. I also redid the images early on to better match real world content. Since most modern video is 16:9 I made the poster and the thumbnails that aspect in usable sizes, and made the advert placeholders the proper 300x250. (you had like 298x247 or something) Oh, and with all my examples (going back nearly a decade) the directory is unlocked for easy access to the gooey bits and pieces. http://www.cutcodedown.com/for_others/vanceVP/ Feel free to have a look around if you like. Oh, forgot to mention I upped the "other videos" count to twelve for a reason; 2*2*3... means in 2, 3, 4 and 6 column layouts, we get an even amount. Only 5 per row is the odd man out, leaving two hanging. Centering everything makes it pretty even when that happens, without resorting to image resizing -- we'll get to the "why" of that shortly. In any case, follow along with the CSS here: http://www.cutcodedown.com/for_others/vanceVP/screen.css I start all my stylesheets with a "reset". Resets exist because it's really NONE of HTML's business to say the default appearance of tags. Been that way since HTML was invented as that wasn't the point. The point was to say what things were and to let the user-agent best determine how to convey that meaning. We got away from that with HTML 3.2 and the proprietary crap from the browser wars (much of which wormed it's way into HTML 4 Transitional and 5, but is nowhere to be found in 4 Strict)... Unfortunately when there's no rules for what should be applied, everyone did it differently. Then CSS came along and those differences -- particularly on margins and paddings -- started biting us in the backside. A reset simply says to the handful of elements that need it to have zero margin and zero padding, so we can apply them when and where we want without having to remember all the special cases. There are smaller resets like the so called "universal reset" of: * { margin:0; padding:0; } Code (markup): But that can make some elements like input, select, and textarea hard to deal with across different browsers. It's cute for quick testing, but can bite you in the backside on deployment. There are larger resets, like Eric Meyer's "Reset Reloaded" -- but that's so fat and heavy it gives resets a bad name. It doesn't just reset, it goes off on a styling spree to the point it might as well be a framework. Such resets are why many developers flat out reject the idea of even using a reset -- even if it means their layouts end up broken in certain browsers. The one I use (developed by Dan Schulz, a friend who passed away a few years ago) is the perfect middle-ground. At a quarter K, NOBODY is going to bitch about the filesize. After the reset, there are a few more standard things I do. HR -- I hide all HR as while they have a semantic meaning, their default appearance of a line across the screen doesn't always fit our layout concepts. Again semantic markup is about more than layout, and if you don't like the default appearance, CHANGE IT. -text-resize -- the -webkit and -ms versions are for older smallscreen devices running iOS or Windows Mobile that don't obey the viewport meta. I put this in a small pixel metric media query as there are no devices wider than that which need said override, and sending that to desktop Safari breaks the ability to zoom. (REALLY stupid since it doesn't break Safari on iOS? Apple can be so herpaderp it's like they TRY to make it harder than need be.) media (-webkit-min-device-pixel-ratio:2) and (min-width:1600px), (min-resolution:172dpi) and (min-width:1600px) -- newer Android HDX devices fail to lie to us about their resolution, making our viewport meta behavior unwarranted. Apple's Retina displays lie to us no matter what, but for other high dpi small size devices like the new Kindle Fire HDX, we have to force the issue doubling our font size page-wide on any fonts based on the default. ... and now a word about font sizes. Whenever possible, fonts should be declared in either % or EM. Likewise layout widths should be declared in EM. This is because not all systems start out with the same font size. While 16px is the most common default, my workstation and media center are set to 24px, I've seen TV's set as high as 32px, and both my laptops are set to 20px. The browser can pick up on this and scale the text automatically without the user having to dive for the zoom. This is why the WCAG (Web content accessibility guidelines) says to use EM, so... well, use 'em! To that end, widths and paddings when possible should also be in EM as should most media queries, so that the layout itself adjusts to this auto-zoom. As a rule of thumb, most of the time people declare a font size in pixels, they're flipping the bird at accessibility. Same for declaring widths in pixels -- but like any good rule, there are exceptions! There are two good ones on this page, and they involve the images. We'll get to that shortly, for now... body -- I set a min-width so that older browsers that can't re-arrange the layout with media queries won't go so narrow as to break things. I then like to set the font size, face, and line-height that will be for the majority of the content on the page. Again this is done in percent or EM (I use percent on font-size out of habit and higher non-floating point granularity). I like taller than the norm line-heights as it aids in legibility. The background and foreground colours also get set -- in this case for the h1 and footer as mentioned before so that should you have content shorter than the display, that color will stretch at the bottom. .heightWrapper -- goes around our content, gets the darker background colour. h1 -- I set a side padding to match the body padding we'll use below in EM. I set the font size explicity 1) so we know that 1EM is still 1EM without resorting to REM (which aren't ready for primetime browser-support-wise), and so that certain builds of gecko based browsers dont' magically up and decide to use the value declared on the anchor instead. h1 a -- Detroit avenue! Wait, no... relative positioned so anything we absolute position inside it (like that span) bases it's coordinates on the corners of this anchor. display:block so we can set vertical padding on this... Know how I was saying there are exceptions to "don't use pixels"? Well here's one. Underneath a image replacement. Images (particularly background images) are best used without being resized... this is more true if you're going to make an image larger than it is smaller, but on the whole it's best to leave it alone. By using PX here we can be sure that font scaling (the reason to use EM) won't make the text pop out from under the image we'll be applying with the span. Block extends to full width so we don't need to play with that, but the padding+line-height creates the 144px I made the image height. Finally we just colour it and turn off underscores to try and look somewhat like the logo. h1 span -- this is our "gilder levin image replacement". We just absolute position the image over the text as a background to this element. I adjusted the size to best fit the idea of turning it off when the screen is too narrow. This is something that REALLY should be customized for every site or layout and really can't be accurately predicted until you really have an idea what the logo is. Image replacements also set limits on what you can and cannot do for logo design -- like alpha transparency is typically (but not always) right out. h2 for consistency we nab all our headings at once. 1.33em * 150% font-size == 2 body EM aka 2 REM, so that's a 2em gap at the normal font size below them. That's something a lot of people have trouble keeping track of, is that EM's are multiplicative. You increase the font size, you increased the size of ALL EM inside that element. That's why the feeble minded are jonesing for REM (EM relative to browser default) to be a reality, while those of us with enough brain cells left to rub together aren't frightened by a little math. I'm not Thomas Dolby, science doesn't blind me. #contentWrapper -- here's where our layout magic begins. By setting it to float:left at 100% width, we leave 0 pixels of width free for a float to fit next to this. Sounds strange, but remember that as we'll get to why that's important shortly. #content the padding top and right are the 2em gap I chose for "all around the layout". I put no gap on the right as we'll use padding on #extras to create that gap. If you had coloured columns or a divider, you'd want that gap on both sides. As I typically pad the bottom of all content elements like lists and paragraphs by 1EM, I only put 1EM of padding on the bottom to equal that same 2EM around the edges total. I find this easier than trying to play with "margin collapse". The massive right margin pushes the content over leaving a "gap" that our #extras is going to sit atop. #extras -- and here's that magic. I float it left, and set a 22em width, then pad it 2 at the top, 2 on the sides, and 1 at the bottom (again since the content itself gets 1)... this comes to a total of 26em width since padding is added to width declarations. (in any modern browser with a doctype... only reason to worry about that not being true would be if you need IE 5 support). Negative margins do something really funky to elements. They reduce how big other elements behave around them, effectively changing their size in "page flow" without changing how big they render. It's still drawn that full 26em, but the layout engine will treat it as being 0 width! Now that it's 0 width, it magically fits next to #contentWrapper! Pops right up into place in every browser that's ever supported CSS. Boom, there's our two columns. We fake a empty spot for it, that trick it into place. IT's a trick, but a old, reliable, and faithful one. It also means we can turn all that stuff off when we want to remove the columns. video -- I scaled the video up and gave it 1EM of bottom margin. I'd use padding to avoid collapse, but that's really a non-issue in this layout and padding a video behaves... wonky. Video is one of the few elements that is generally acceptable to let size upwards, and in this case I have it set to "expand to fill". That 16:9 poster forces the aspect ratio to something sound too, looking really good on every 16:9 or narrower aspect display. (not that great at 256:135, but that's the point at which a max-width may be in order!) p -- I set a max width as long lines of text can be hard to follow. I also use margin to center it (just looked better to me), and as mentioned before pad the bottom by 1EM. When the containing column/section is smaller than 52 body EM, the paragraphs will center and not expand wider than that. When less space than that is available, the paragrapsh will shrink to fit. Accessibility 101 if you're making a layout you want to allow to expand things like videos to screen width. .adverts -- center alignment for consistency should you add text, or for if we switch to inline behavior in our media queries. .adverts img -- for our desktop layout though, make them block and use margin to center and space them. More predictable behavior. #otherVideos -- clear to make sure we're past our floats, top and bottom padding, I use margin on the sides so the border does NOT stretch to the corners, it just looked better with a divider there to me. Now, rather than play with trying to scale the thumbnails up or play fancy layout tricks, I just made these all inline-flow so they'll auto-wrap without making them "grow" past their default size (which usually would look like arse with real content)... as I mentioned before image scaling sucks, particularly at making things bigger -- which is why this layout will only scale them smaller, and only do so when we're down to the screen being smaller than a thumbnail. #otherVideos ul -- turn off bullets, align center, pad the bottom. #otherVideos li -- I set these to inline since legacy IE can't do inline-block (aka accepting height or top/bottom padding) on block-level elements, and inline-block on LI can introduce some really wierd-ass behavior in IE8. Good rule of thumb, if you can avoid styling an LI, avoid styling it. I set vertical-align to top both here and in the anchors inside them so that if the text is different heights, the images in each row will align with each-other. #otherVideos a -- ANOTHER case of using a pixel width, in this case so that our thumbs aren't trying to scale upwards unneccesarily. I still pad them in EM though, and as mentioned these are inline-block so that they can actually accept top and bottom padding (something display:inline can't do in spec compliant browsers). I round the corners and set up some transitions here so that... #otherVideos a:active, #otherVideos a:focus, #otherVideos a:hover -- we can have a pretty hover and/or keyboard navigation state. :focus is supposed to be for when you keyboard navigate to an anchor, but some older browsers mistakingly use :active instead (which is only supposed to trigger when you click on said anchor). Usually if you're going to make a hover state on a anchor, input, select, or textarea, you should be declaring all three of these, typically to the same value... at least if you care about more than people who only navigate websites with mice. #otherVideos img -- display:block to force them to their own line (so no extra BR in the markup), auto side margins to center it, bottom margin to push the text away from it, and max-width so if the parent container is too small it will force it to shrink. #footer -- padding, center alignment, yawn. ... and that's how I'd build the desktop layout. I always build my legacy browser desktop layout first as it's what we cannot target with media queries. A LOT of "experts" will tell you to go with a mobile first approach, and I consider that broken and shortsighted. "mobile" and other small screen devices CAN be targeted with media queries, so why would you start with what you CAN target as the default... and how would you override that mobile default to even make a proper desktop layout?!? Doesn't make any sense, hence my legacy desktop first approach. You can see rather than play games trying to make it all perfect width filling, I just let things wrap automatically fitting as many as fit and centering it... there's some extra gaps at the side? OH WELL. JUST as useful to the user and it looks FINE. ... and with real content it would probably look better thanks to not trying to scale images up in size! That just leaves making it responsive for modern small screen/mobile. media (max-width:50em) -- one thing to remember is that media query EM's is browser default, not what we declare on HTML or BODY. (and there's SUPPOSED to be no parent element to target there). Basically in a media query, EM is REM. (sucks). Since I use a 85% font-size on body, 50em "global" is the same as 58.82 body EM... slightly more than the min-width of our layout, but takes into account a bit of extra "wiggle room". So what do we do when we get this narrow? Well, first off we want to say 'yes layout, you can go smaller" so we drop the min-width on body to the smallest any handheld we care about supporting is likely to have. (there are older 128 wide web capable devices, but they won't know media queries or <video>, or even flash, so **** 'em.) The dynamically sized video gets a bit tiny with the ads next to it, so let's remove that columnar behavior, and instead display the ads side-by-side below the content section. We just pull the floats, set the widths to auto, pull out any offending margins and even out the padding. I also narrow the side padding down really small so that we use as much of the dwindling screen width as possible for content. Once that's done we just need to tweak the bottom padding on our h2 to match, adjust advertisements appearance a bit... I added a top border to it to mimic the look of the one from "otherVideos". Making the advert images inline-block puts them neatly side-by-side (you could tweak the padding if you wanted to space them apart), with a 49% max-width forcing them to stay side by side when there's not enough room for them. This WILL scale them down, but screw it, they're ads. Finally #otherVideos gets it's padding and margins tweaked to better use the available space as well. In that one query, we've made the content handle most any screen width we throw at it, leaving just two little niggles to fix. media (max-width:660px) -- another exception, and it's for that logo image. Down this narrow the image won't fit on the screen, and scaling it down would probably look like ass. You could use this point to simply replace it with a smaller image, or the route I usually take which is to just strip the logo off completely and use the plaintext. To that end I change the text alignment to center, tweak the padding, switch to a EM font size since we no longer have the image involved, and kill off the span. I also at this point tweak the adverts to be one over the other as they would start to scale smaller than I'd really ever deploy on a site. (so much for "oh well") media (max-width:340px) -- at this small a size the wrapping and padding for the othervideos anchors starts to fall apart, so I just switch them to auto width and centered. The biggest change is using box-sizing to force the padding inside the width instead of outside it. padding-box is pretty new, and you can't really rely on it if you are supporting older browsers -- but since we're inside a media query we KNOW CSS3 is present and as such box-sizing will work. ... and that's a fully responsive, dynamic, elastic, fluid layout. The only possible change I might make conceptually would be to add a max-width to certain areas like the columns and other videos areas, so REALLY big displays (2560px or wider) -- particularly those at really high aspect ratios -- don't have layout issues. I'm away from my workstation right now so I can't test that, but it's something to consider. Now, I know all this is a LOT to take in, but take your time, go through it, compare my descriptions to the code side-by-side (aren't multiple windows great?) and when you have questions, fire away. Really, CSS layout is a swan dive into the deep end of the pool... taking it responsive? That's a HALO drop into the Mariana Trench. There's a lot to learn if you want to do it right, and sadly most hand-holding tools only make it worse as they prevent you from learning how to survive such a feat. I like it though, because you write some code, alt-tab F5, and see the changes, everything you do feels like a genuine accomplishment, no matter how simple. Hence two articles I'm working on for my site; "HTML is easy, Stop making it hard" and "CSS: The Hard Stuff, take it slow and make it easy!". No promises to anyone on when those'll be finished though. I'm on like draft #9 on each. Well, that and my top secret "Project Simple" is consuming most of my time.
Deathshadow, you weren't kidding about alot . . . were you? I spent much of yesterday reading your reply. Some of it made sense to me right off the bat. Some of it I had to read 2 -3 times before it made sense, but regardless, there is a ton of information that I need to digest. I have no idea how to express my appreciation for the time and effort that went into your reply. I have been on several forums looking for information and advice and most will give you a quick answer - if you're lucky - but I cannot remember the last time I saw someone take the time to give such in-depth information as you have provided me. You can count on the fact that I will be going over your information again and again. I appreciate the fact that you will be available when I have additional questions. As I get further into this I can assure you I will have more questions. I just hope that I don't wear out my welcome. Again, thank you so very, very much for the time and effort you expended in your putting your reply together and I hope to learn as much as I can from you. Your effort is greatly appreciated. Regards . . .
Deathshadow . . . I hope you are prepared for the open door invite you extended to ask questions because I got a bunch of them. BTW . . . I tried to send you a pm a couple of days ago. Don't know if you saw/got it . . . just FYI. Anyway, I am in the process of trying to redo a second website to make it responsive following your guidelines and I am having a couple of problems that I just cannot figure out. First off, the site I am redoing is at http://amazingbarbeque.com/ and the first problem I am having is making the header image responsive. You can see how I am doing with re-coding at http://amazingbarbeque.com/index2.html . If you look at the re-coded site vs the original code, you will also see that my images are out of whack. I have read some of your other posts here and on your website and you mention optimized images. Where can I go to learn about this so that everything works within a responsive site the way it is suppose to? This brings me to the second thing that I just cannot figure out. Keep in mind that I am old and things just don't sink in as fast as they use too. As you can see from the original site, I think I would like to have the responsive re-coded to reflect the content and sidebar being around 1020px wide and centered, but the header being full width is okay. I have tried changing around the code you provided (thank you so very much again), and I just cannot figure out how to get it to work. I have read your posts above again and again and unless I am missing something I am still in the dark. And my final question for now revolves around being able to use php include statements with html5 and css3. In the sidebar of this site is a place for "Popular Articles" and for "How To Articles". I intent to keep adding articles to both and originally am using a php include so that all I have to do is add new pages to the a single file instead of having to change each and every page. Is it possible to do this and keep it responsive? I have searched google and everything I have read says it can be done, but when I try it, it don't work. Do you have any suggestions? I would also appreciate it if you could take a look at my code and see if I am making any progress with learning this stuff. And finally, is there someplace you would suggest as a source for me to re-learn to build responsive sites the right way? Many thanks and awaiting your reply . . .
For what it's worth, I think I pretty much figured things out so disregard my previous posts. I got the site working the way I wanted it to. Don't know if its the right way, but it works.
The header is difficult to read and it's not clickable, please check contrasts according to WCAG. These two links may help you: http://cutcodedown.com/article/whats_wrong_with_HTML_5 https://www.nngroup.com/articles/guidelines-for-visualizing-links/
Apart from that, you might also wanna set a minimum size on the header, because as it is now, it gets very small very quickly. Doesn't have to be a bad thing, by all means, but on small phone screens, it might not be very readable at all.
Popsicle & Puntocom81: thanks for the input, but I am not sure that we are all looking at the same page/site. Are ya'll looking at amazingbarbeque.com? I am having a hard time understanding the header being difficult to read and resizing of the header. I have checked the index page of the site on Samsung S6 and it looks fine - to me. Below is a screen shot from my phone. Am I missing something here? I have now made the header clickable and I am going to play around with the header image to see if I can figure out how to get it to resize it depending on the device it is being viewed. I have added some shadowing to the <h1> header title to make it a little easier to read (I hope). Now all I got to figure/find out is whether or not php include statements so that when I want to add a new article or something to the menu I only have to do it once for the php include instead of having to do it to each and every page. So . . . I hope that we are looking at the same page/site and are seeing the same thing, cause like I said, on my devices things look fine to me. If not, I would appreciate it if ya'll would let me know. Many thanks . . .
First off, sorry for the delay in responding, doctors appointments and memorial day weekend got in the way. Your latest incarnation of that site the background is WAY too bright to be using white text on, and yet too dark for black either. It's a poor choice in terms of exposure/brightness. The markup has some pretty big issues -- like no doctype, h1+h2 doing h1+small's job (You're NOT starting a new subsection, so H2 is COMPLETELY inappropriate no matter how many mouth-breathers you'll see doing that -- yes, I'm including the dipshits at WhatWG in that with their idiotic HGROUP tag). You're using the style attribute which really has no business pissing on the markup, all your H3 should be H2, you have the POINTLESS nav and section tags, are abusing ASIDE for something it doesn't mean (since your sidebar is NOT a literary aside or related to the main column content), you are wasting time on absolute URI's for no good reason, your links in the sidebar are neither clearly marked nor spaced to say that it's all not one run-on sentence link, etc, etc... Remember: H1 is the heading that EVERYTHING on the SITE is a subsection of, that's why your title AND tagline belong inside it. (and why <header> is utterly pointless). H2 indicate the start of a subsection of the H1, not "I want text of a certain size" just as H3 indicate the start of a subsection of the H2. Likewise HR means a change in section/topic where heading text is unwanted/unwarranted, such sections possibly including footers -- hence why <section> and <footer> are utterly pointless crap too. THEN there's <aside>, which if you use for the meaning "this stuff is off to one side" you have just reverted to making markup as utterly nonsensical and presentational as using the deprecated <center> tag!!! As such using it for a sidebar is nonsensical gibberish unless it's something like addendum or related content to the main column; aka a literary aside. Remember you should be choosing all tags other than DIV and SPAN for their meaning in a grammatical or professional writing sense, and NOT for what you want things to look like. As such a Deadpool or Ferris Beuller style fourth-wall break is an "Aside"... Macbeth uses asides; a sidebar is NOT an aside -- hell it might not even BE a sidebar on all your layouts! You'll see similar flubs from people in relation to <b> and <i>, where they use them to say "I want this to be bold or italic" instead of "this would be bold or italic in a professionally written document" -- or worse the people who magically turn "STRONG and EM should be used when their meaning is more accurate" into "never use <b> and <i>" -- which is NOT what the specification even comes CLOSE to saying. EM means the text is emphasized, STRONG means the text is receiving MORE emphasis, CITE means your're citing a source (it just so happens the DEFAULT appearance is italic)... <b> means text that would be bold in a professionally written document that is NOT getting emphasis, like a entity name in a legal document, whilst <i> means text that would be italic in a professionally written document, such as a book, paper, or document title that you are NOT quoting or using as a citation. For example: "I read <i>At the mountains of madness</i> last night after getting home from my job at <b>Plimoth Plantation</b>... <em>I'm a huge H.P Lovecraft fan.</em> You don't like Lovecraft? In the words of <cite title="coffee, beer and the pope">Dennis Leary</cite> <q><strong>dubayu dubayu dubayu dot blowme dot com!!!</strong></q>" MEANING, none of that -- not even the <b> and <i> tags actually have or even should be shown in bold or italic, they should be shown to whatever the design and capabilities of the device the page is being transmitted to the user with... and that distinction goes all the way back to the intent and purpose of HTML from the day Tim Berners-Lee created it! In that same way, <small> means de-emphasis, such as in a tagline -- text that WOULD be smaller for grammatical or structural reasons in a professionally written document; your'e not actually saying it's being displayed smaller in your layout. That's the philosophical distinction and intent that is utterly lost on a great many people writing HTML -- and it is a pretty big mental hurdle to jump. Colour contrasts for images is often hard to work with, you have to figure in the largest areas of colours closest to your text -- in your case the steak itself is WAY too bright for the subtext at DESKTOP resolutions. That said I see you discovered the appropriate approach to fixing your logo area, put the text in the markup and just use the image as a background behind real text. You could enhance that further with box-shadow to closer reflect your original design, and that text-shadow COULD improve legibility over the image if you layer it more. Most people don't realize this, but you can put more than one text-shadow or box-shadow on things... text-shadow: -2px 0 4px #F40, 2px 0 4px #F40, 0 -2px 4px #F40, 0 2px 4px #F40, 0 0 8px #F40; Code (markup): for example would mimic the reddish-orange you had in your original picture. (I pulled a full rip before your latest update)... the black edged smaller text would be something like: text-shadow: -2px 0 3px #000, 2px 0 3px #000, 0 -2px 4px #000, 0 2px 4px #000, 0 0 5px #000; Code (markup): While that would help, I'd be using a much darker image if I wanted white text.... sadly I really don't think that image is conducive to light or dark text. Text over images is ALWAYS a gamble, and one that takes a good deal of experience to go "no, we can't use that" or "this is just right". Another flub is this: <link rel="stylesheet" type="text/css" href="reset.css"> <link rel="stylesheet" type="text/css" href="style.css"> <link rel="stylesheet" media="screen,projection,tv"> Code (markup): Multiple stylesheets for nothing, garbage oversized reset, and the media attribute goes on EVERY link -- not on a link all by itself that doesn't even link to anything! Also as of HTML 5, you don't need to say text/css on LINK that are rel="stylesheet" -- its' now assumed. IF multiple stylesheets were in fact warranted, that should be: <link rel="stylesheet" href="reset.css" media="screen,projection,tv"> <link rel="stylesheet" href="style.css" media="screen,projection,tv"> Code (markup): NOT that I'd have two stylesheets just to keep the reset separate as why have an extra handshake for nothing, AND I probably wouldn't be using a pointlessly uselessly vague filename like "style.css" since of course it's style, it's a freaking stylesheet!!! "screen.css" is more useful since it tells you what that stylesheet is for... just as a "print.css" or any other primary media target as the filename would. Hence why on 99.99% of my sites, the ONLY stylesheet links you'll find are: <link rel="stylesheet" href="screen.css" media="screen,projection,tv"> <link rel="stylesheet" href="print.css" media="print"> Code (markup): ... and that's assuming I take the time to make the site print friendly, which I may or may not do depending on the site in question. You also have a pretty useless TITLE tag... simply too big and filled with stuff that there's not enough room to show on most UA's... while search engines will cut off at a whopping 72 characters, most tabs/window titles/taskbars you're lucky if it has a third that, so <title> should JUST be the site name/title without the extra crap. If you're going to have extra crap, it should be the sub-page name followed by a hyphen BEFORE the site title, so that the result is actually useful in tabbed interfaces. Just don't show that on the homepage, that should be self explanatory. for example: Homepage: <title>AmazingBarbeque</title> About Page: <title>About Us - AmazingBarbeque</title> Recipes Page: <title>Recipes - AmazingBarbeque</title> That's what it's FOR. You want to further describe the page, that's <meta name="description">'s job... said description should AVOID repeating the title text since that's duplicate content and a flag for the site to possibly be penalized for SEO abuse. Hence why your homepage description meta I'd have read something like this: <meta name="description" content="Information about Great backyard barbecue, grilling, outdoor cooking, techniques. We have reviews of grills, smokers, and thermometers, as well as recipes for baby back ribs, spareribs, pulled pork, beef brisket, hamburgers, and other popular BBQ foods."> Code (markup): A Natural language description of the page. You don't need to repeat the title inside it! In fact, AVOID DOING SO!!! You do your job right with TITLE and the description META, your SERP listing will end up looking something like this: AmazingBarbeque Information about Great backyard barbecue, grilling, outdoor cooking, techniques. We have reviews of grills, smokers, and thermometers, as well as recipes for baby back ribs, spareribs, pulled pork, beef brisket, hamburgers, and other popular BBQ foods. That's what those tags are FOR! Likewise, I'd get a keywords meta on that. Remember that it's called keyWORDS. Not keyphrases, not keysentences, but keyWORDS!!! Seven or eight single words or proper names that exist between <body> and </body> as text that you want a SLIGHT upranking on. TRY to keep it under 128 characters, most people who know what they are talking about suggest 96 characters or less... so something like: <meta name="keywords" content="barbeque,grill,smoker,thermometer,brisket,pulled,pork,beef"> Code (markup): Also you're using pixel media queries when to be frank, you REALLY shouldn't. If you're designing with EM or % fonts like a good little doobie, your media queries should be in EM so that your breakpoints adjust to the font size. AGAIN, remember that 1EM does NOT always equal 16px... the user is free to change that from their OS or even the browser directly so they don't have to dive for the zoom. Oh, and clearfix? REALLY? Stop learning from people who haven't extracted their craniums from 1990's rectum. Like that dipshit Eric Meyer and his fat bloated oversized idiotic "reset"... I wish there were less Eric Meyer wieners, that is what I'd really like to see; 'cause if there were less Eric Meyer wieners, developers would stop aggravating me! Seriously, has he ever done anything that DIDN'T piss all over the web? I swear between him and the Kevin Yank-holes... --------------------------------------- I was actually working on a rewrite of what you had when I got waylaid, lemme upload that now.... As always I start with semantics: http://www.cutcodedown.com/for_others/vanceVP/bbq/template.semantic.txt No classes, no ID's, and none of the HTML 5-tard bullshit redundancies (article, nav, section, footer, aside). Once I have that, I put the normal header for a modern 5 document on it and add DIV and SPAN (the semantically neutral tags, they don't change the meaning of what they wrap or imply any meaning of their own -- that's WHY we use them) as part of building the layout(s). The H1 is the heading that everything on every page is a subsection of, the H2 indicate the start of major subsections, I went with H3 as they're all part of that article -- I rewrote the H2 to better reflect the home page's meaning (your copy could use some punching up BTW)... I suspect a lot of the content flubs comes from your taking some BAD SEO advice. Some of the alleged SEO experts have it in their heads to "repeat the same thing over and over" when that's not only crappy writing, it's actually likely to get you slapped down by search for abuse! Basically search engines are on to that "trick", have been for years! I also put the text from that amazon link into there as actual text instead of as part of the image... meant splitting the images but the smaller overall sizes more than makes up for the overhead of an extra "handshake" to the server, particularly given the already low file count. Which is why (based on your original) I'd end up with something more like this: http://www.cutcodedown.com/for_others/vanceVP/bbq/template.html If you take a peek at the source -- here's a .txt for people too lazy to hit "view source" http://www.cutcodedown.com/for_others/vanceVP/bbq/template.html.txt You'll see it's pretty much what I've said here and in my "progressive enhancement" article. Double wrapper for the column as it's easier to manipulate and avoids that stupid broken "percentage width" column crap. (I prefer an EM width on my sidebars so they're elastic and do NOT resize with the layout, leaving as much free as possible for the content column!) I chose a much darker image for the background behind the h1 text, and went ahead and loaded up on the text-shadow to improve the legibility. While I went with a pretty big image (2000 x 256) so that legacy browsers will work in MOST cases , I use background-size on modern browsers to be sure of this. I use "plate" classes for the implication that they are plate images, with "leading" and "trailing" prefixes to IMPLY that they may go to one side or the other, WITHOUT coming right out and saying it. This is important since we DON'T want to align them when the screen is too small -- hence why you have ZERO business on a modern layout using the style="" attribute unless that style is conveying meaning -- a VERY rare occurrence not oft found outside of tag clouds or charts. So, go ahead and give that a once-twice-thrice-over, digest it, and see if you can tell the differences. As to your PHP question, you're not doing a single thing that stops you from using PHP includes. When doing so on simple static sites I often like to make it so that EVERYTHING from the "template" that's common to all pages is in two simple function -- template_header and template_footer so they can be included from one simple common.template.php file in a /template subdirectory. This lets me keep all "layout" images in /template/images and the css in /template so that they are separate from my content images in /images. Basically: / -- root contains all user callable .php files, and any configuration data. /images -- content images /downloads -- files people can DL directly. /template -- various xxx.template.php files filled with template functions (so if called directly they return NOTHING), the various .css files, etc. /template/images -- images such as backgrounds that are specific to the template and are not content. Your h1 background for example. One of the reasons I do this is so that all directory links point downwards, this means I don't need to dick around with absolute URI's (aka including the http or domain name part) or worse, the ../ asshattery. USED to be back in the '80's anyone working in software was taught that up-tree linking (../) was a BAD thing that should never be done. For some reason that disappeared in the late 1990's and is virtually unheard or today, despite it REPEATEDLY opening up holes and biting developers in the ass. If you need to say something like: <li><a href="http://amazingbarbeque.com/index.php/">Home</a></li> Code (markup): On a file being served from http://amazingbarbeque.com, well, then there's something DISASTROUSLY wrong with your page as that's a pointless waste of bandwidth. Another thing I would suggest when doing a simple static site pasted together with php includes is to use variables to pass to things like the HTML header values that would be different across pages -- such as the page title prefix for the <title> tag, the description and keywords meta, the current page to match for highlighting the current item on the menu, and so forth. Tomorrow morning if I have the time (or if insomnia sets in, possibly sooner) i'll make up an example of that in action as well. It'll basically be a dumbed down version of how I build pretty much all my sites -- just without the mod_rewrite friendly URI's or database activity. I'll make source copies for easy web viewing of that and a .rar of the completed version too for simplicity sake.
Alright, I wrote up a quick dumbed down version of how I would break up the PHP -- it's also providing the start of what could become a more complex CMS and is fairly close to how my own sites work -- though again, I removed a lot of extra stuff so we can go "baby steps" here. NORMALLY I say "if you have more than one <?php per file you're doing something wrong", but in this case for each of the user callable pages I made an exception to keep it simple for you. Every good rule MUST be allowed exceptions. I'm going to assume at least a passing familiarity with PHP on your part -- if any part of this is hard to follow, please ask. All the files are here, I made .source copies of the .php so folks can view them online. http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/ There's a .rar of everything here: http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/bbq.rar Let's see... how to explain this. I guess the first place to start would be the config.php which contains all the default values common to all pages. Follow along with the source here: http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/config.source In a production CMS most of these would be: 1) loaded from the database not a static file 2) likely hidden behind a getter/setter so code elevations can't change them. But since this is a simple static system the odds of anything jacking this is nil, so it's fine to use globals for now... This file will automatically be included when you load the template, that way at the start of your user callable files (like index.php, about.php, etc) you only need to include template/common.template.php at the very start. LANG and CHARSET get plugged in automatically to all the places they are needed, this includes not only the markup, but also a http header() in the template. $pageTitle - the title put before the site title if non-false. By default we just want the site title for the home page. Change this value on your subpages if desired. $siteTitle -- always shown in the <title> tag. $namedMeta -- an array where the key is the meta name, and the value is the content. The only default named meta we have so far for all pages is of course the viewport meta. $complexMeta -- an array of arrays where each sub-array the key is the attribute and the value is, well, the value. The comment tries to explain this further. $styles -- our stylesheets to be plugged into link tags. Your individual pages can add more stylesheets to this if/as needed. The array key is the name of the file, which will be plugged in as "template/key.css" while the value is the media target. $currentPage -- the key to match in $mainMenu to say "this is the current page" so the current menu item can be highlighted via the "current" class. I sue the class "current" instead of the more common "active" because there's a pseudostate called :active, and it's REALLY easy to get .active and :active confused. class="current" is just as functional and prevents that confusion. $mainMenu -- rather than have to dig into the template just to add/remove menu items, I like to make a nice simple array. The key is the text to go inside the anchor, the value is the URI. If we run everything user-callable from the root, we don't need to waste bandwidth or time with paths or full (aka absolute) URI's. #extras -- an array of file basenames to be included inside DIV#extras from /extras/basename.extra.php -- these includes will be put inside a DIV#basename.subsection automatically. By setting up all these values, we can automate the common template for uniform markup headache-free. I also included my gzip.lib.php, source here: http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/libs/gzip.lib.source The template will also call this so that if possible, your PHP output will be automatically gzipped. It's a headache-free implementation as I hook PHP's shutdown functions so even on error, you'll still get gzipped output. MOST implementations require you to manually call this when the program exits, mine you simply include at the start of your program if needed (we'll get to that in the common.template.php shortly) and it just does all the heavy lifting for you. Just thought that might be handy. So let's talk the common.template.php -- source here: http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/template/common.template.source As mentioned, we check for if gzip compression is even possible. If you want to force it disabled you can define('CONTENT_ENCODING', false); in your user callable file BEFORE you include the template. Some larger outputs can induce more overhead than the bandwidth reduction saves, so I always include the option. For your pages, it's unlikely you'd need to do so, but better to have the option and not use it than to need it and not have it. We only include('libs/gzip.lib.php') when it's ACTUALLY needed -- not all client support it so why load code that might not even be run? I then include the config.php -- notice in all cases the paths assume we're running from root -- again root is where I put all user callable files and if someone tries to call any of these files directly they're either get no output (as it's all functions) or bomb out with a meaningless error. template_header() -- starts out by declaring access to all those values we set up in config.php. It then creates a proper content-type header(), and outputs our proper doctype, lang, and meta HTML header. I then go through and loop the various meta to output those. The formatting may look a bit odd here, but I do this so that my PHP output is properly formatted. I find it easier to debug output that's formatted than it is to format it for the PHP then have a confusing jumble client side. I really don't get how people work with it the other way around. Just as with the meta we loop any stylesheets, I then also link to the shortcut icon (if present). Oh, when it comes to a favicon, CALL it favicon.ico and use a .ico even if you also have a .png, as some browsers ignore the <link> and will just go looking for that file regardless of what the markup says. Do NOT say type="" on the favicon link as it will in fact BREAK it in many browsers, and use "shortcut icon" as the REL for the .ico version. The way I have it worded there is the most compatible across all browsers. With <title> you can see I check if $pageTitle is loose true, if so we output it followed by a hyphen, if not we output nothing. Either way $siteTitle is shown after. From there it's just the same template as our standalone, apart from using a loop to pull the menu items and check for a current page match. Once we get so far as opening up the content area, we are at the end of template_header(). This means when you call template_header() in your index.php and other such user-callable files, you can just close PHP and insert your page content. template_footer() -- this closes out #content, it's wrapper, and creates our "extras" section. It loops through $extras including the appropriate file inside a well ID'd and classed DIV, then goes ahead and closes out #extras, .main, and finally outputs our footer before finishing off the page. Have a look at each of the contents of the "extras" to see how simple those are. http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/extras/ As there's no executable code in them and you will show them on pages raw, there's no need to worry about masking their output if directly called. So... how do we actually use all this to build a page? Have a look at the example.php's source: http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/example.source We open <?php, include the common template for all pages, set up our custom values like description, keywords, pageTitle and currentPage, call template_header(), close ?>, put in our unique content for the page, open PHP and call template_footer. Boom you get this for output: http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/example.php Just as the very similar home.php: http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/home.php Has a relatively simple source: http://www.cutcodedown.com/for_others/vanceVP/bbq/managed/home.source Letting you belt out your subpages lickety-split. A more robust approach involves "friendly URI's" -- basically ones that don't use .php at the end and allow for more complex directory structures client side. The approach I use for that (I may make a demo of that later too) uses a rewrite rule in .htaccess or httpd.conf to redirect all files NOT on a whitelist to a single index.php, which then parses the requested URI and turns it into the appropriate markup... but for now this simple approach could serve anyone with a static site quite well. Hope that helps, again I know, this is a LOT to take in -- tossing you into the deep end, let's see if you can swim.
WOW again! I love your in-depth answers, Jason. Only thing is that the more I read from you the more I realize that, while I thought I had a decent handle on html and css, I don't really know squat. The older I get the slow I get so some of this is taking a while to sink in. Seems that I need to read, then play around with it, read again then play around with it before it sinks in. I am beginning to understand what you are trying to tell me about the purpose of html and the more I come to understand it, the easier it seems to be putting together a responsive website than I originally thought. And I should tell you that the only thing I know about php is how to stick the php include statement into my code. And apparently I wasn't even doing that correctly. So when you try to explain php, know that it is all Greek to me and I was lost from the very beginning. Now, in keeping with my read it once, play with it, read it again . . . I tried creating an 'about' page (/about.php) utilizing your example.php and when I try to view it, I get an error message: Parse error: syntax error, unexpected '[', expecting ')' in /web/sites/pimpdaddy/amazingbarbeque.com/libs/gzip.lib.php on line 26 I took the liberty of adding the above files for this site to my server so that I can play around with it to try to SEE how it all works as well to maybe be able to answer some of my own questions. If this is unacceptable, please let know and I will immediately remove the files. Awaiting your reply . . .
The only reason that error would occur is if you are on an outdated (and possibly insecure) version of PHP, as it's barfing on the PHP 5.4/newer array. That means none of the code I presented will work as the config.php uses those as well. Simply put, you're on PHP 5.3/older. To fix gzip.lib.php for that you'd have to change it to: if (defined('STRIP_WHITESPACE')) $contents = preg_replace( array('#<!--.*?-->#s', '#>\s+<#', '#\n\s+<#'), array('', '><', '<'), $data ); Code (markup): Several other sets of [] across the codebase (again, config.php being a likely candidate for this) will also need the [] turned into array(). <?php DEFINE('LANG', 'en'); DEFINE('CHARSET', 'utf-8'); $pageTitle = false; /* Automatically prepended to <title> if defined, with a hyphen between it and $siteTitle. I Recommened that you define this on all sub-pages but not the home page for useful <title> values in tabs/windows/SERP listings. */ $siteTitle = 'AmazingBarbeque'; // Always shown at end of <title> $namedMeta = array( 'viewport' => 'width=device-width,height=device-height,initial-scale=1' ); /* These meta use the name => content format. */ $complexMeta = array(); /* complexMeta is an array of array, where the inner array for each meta consists of attribute and value pairs. Useful for things like Opengraph which flat out ignores the rules of HTML and makes up their own BS implementations, or http-equiv values. (NOT that we really use the latter anymore, thanks HTML 5!) */ $styles = array( 'screen' => 'screen,projection,tv' ); /* default stylesheets to load on all pages. Index will be used as 'template/' . $index . '.css', the values are the media targets. EXAMPLE: 'boring' => 'print' OUTPUTS: <link rel="stylesheet" href="template/boring.css" media="print"> */ $currentPage = false; /* if this value is set to same as a main menu item's text, that menu entry will get the '.current' class added to it. */ $mainMenu = array( 'Home' => '/', 'About Us' => 'about.php', 'Reviews' => 'reviews.php', 'Recipies' => 'receipes.php', 'Fact or Fiction' => 'fact_or_fiction.php', 'Techniques' => 'techniques.php', 'Contact Us' => 'contact.php' ); /* Menu entries in order you want listed. $text => $url format. */ $extras = array( 'popularArticles', 'howToArticles', 'amazonShopLinks' ); /* Extras to be included in #extra. The value is used both as the ID for each div.subsection and to find the file as 'extras/' . $id . '.extra.php' */ Code (markup): Now, that said... I actually use the shorter version NOT because it's less typing, but as a test to see if an old outdated version of PHP is in use as a warning as to whether one's hosting inhales upon the proverbial equine of short stature or not. Really if it's throwing that error you should be either riding your hosting's ass about being on an outdated version of PHP, or get better hosting elsewhere. After all, PHP 7's been real-world deployable for six months, and PHP 5.4 is now over four years old! Hell, the latest in the 5.x branch is 5.6.21!!! Sadly a LOT of hosts simply aren't updating as the poorly written off the shelf garbage that haven't updated their code bases for good practices in nearly a decade bomb or throw endless errors in anything newer than 5.3. RATHER than using the new version to force clients to secure and optimize their codebases, they just let people sleaze along with pages slopped together any-old-way. Something that leaves me scratching my head as we've been told for nearly a decade this was coming! Laughably the most common EXCUSE you heard over that decade was "I'll deal with it when we get there" -- now that it's hear, those same fools are bitching and moaning about no longer being supported or it magically all being PHP's fault. It's like dealing with Frank Burns. (as portrayed by Robert Duvall)... Duke: "Dammit, Henry; Frank Burns is a menace! Every time a patient croaks on him he says it's "God's will" or somebody else's fault." Admittedly, the "difficulty" some people have with responsive design has much the same blame game and attitude. People -- including many "experts" who make tutorials -- have ignored the reasoning behind HTML 4 Strict, the purpose of HTML, the advantages of progressive enhancement and separation of presentation from content. They've flipped the bird at accessibility, and will outright go on the attack against all these good practices as "too limiting" or some noodle-doodle BS about it being "too hard" or "more work", then wonder why they are facing an uphill battle. Since responsive is just the natural progression from a content oriented, semantic, progressively enhanced, semi-fluid elastic layout built with versatile and easily changed layout methodology. Instead en-masse people ignored 4 Strict, started out worrying about what it looks like instead of what things ARE by dicking around with presentation before they even think about content (much less the needs of future content), continued to sleaze out the idiotic abortive rubbish that was HTML 3.2 and the proprietary crap from the interim, and slapped 4 tranny atop it. Today they just slap 5 lip-service around the same outdated outmoded methodology for zero real-world improvement; basically ignoring some 18 years of good practices. The really hard part for an old-timer like myself to grasp about it being that I fail to understand how writing two to fifty times the code is "easier" to these people. The only defense that seems to hold any water is "Wah, wah, I don't wanna learn!" -- which is why I consider a LOT of the people out there right now to have minds like a steel... sieve. That's the best kind of sieve don't you know?!? The REAL laugh being these dipshits with their jQuery, bootcrap, and 1990's style presentational use of HTML 5's pointless redundancies then get wood over things like minification in a pathetic attempt to sweep their filth-ridden code under the rug -- or rely out even dumber asshattery like LESS/SASS/SCSS to further cover up their ignorance and ineptitude. Major chubby. Language Padre, language...
Alrighty! I just checked with my host and have found out that my virtual server is running PHP 5.3.3-7+squeeze25, but is being upgraded at this time. I am assuming that this will be finished shortly so I am not going to change anything. Once that is done I want to get into playing with this to see if I am getting a handle on it. As previously stated, it appears that what I learned about html and css was all wrong. I am a firm believer in the KISS system (ya know: Keep It Simple Stupid) and from what I am learning from you fits that bill to a tee. In what I had figured out in building my simple little sites seemed that more code could fix most any problem that popped up. Sure wish I had run into you back in the beginning when I first started to learn this stuff. Now it looks like I need to go back to square one and re-learn all over again. And that's okay cause it gives me something to do during the day and hopefully helps keep my worn out brain a little more active. The next thing I am going to try is putting together a new site from scratch using your lessons to see if any of your info is sinking it. Again, I cannot thank you enough for all of your help, advice and guidance.