1. Advertising
    y u no do it?

    Advertising (learn more)

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

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

Landing page template and guide

Discussion in 'HTML & Website Design' started by Pavel Yudkevich, Aug 30, 2018.


Did you learn something new from this guide?

  1. Yes

    2 vote(s)
  2. No

    0 vote(s)
  1. #1
    Hi there web builders,

    As part of my job as an affiliate manager I decided to create a simple landing page template and a guide on how to edit it.

    I believe this landing page will help you understand the basics of the Html and the CSS required to make a responsive page that works perfectly on any device. Even though the guide covers only the Html you can reverse engineer the CSS pretty easily.

    Here is the guide publicly available on Github:

    Feel free to comment questions here and I will do my best to provide a solution :)
    *There are no affiliate links in this page.
    Last edited: Aug 30, 2018
    Pavel Yudkevich, Aug 30, 2018 IP
  2. alex paul

    alex paul Peon

    Likes Received:
    Best Answers:
    Trophy Points:
    I like this guide. Thank you for sharing.
    alex paul, Aug 30, 2018 IP
  3. deathshadow

    deathshadow Acclaimed Member

    Likes Received:
    Best Answers:
    Trophy Points:
    If you "need' to do this (dumbass wreck Paul Irish unleashed upon the web):

    <!--[if lte IE 6]><html class="preIE7 preIE8 preIE9"><![endif]-->
    <!--[if IE 7]><html class="preIE8 preIE9"><![endif]-->
    <!--[if IE 8]><html class="preIE9"><![endif]-->
    <!--[if gte IE 9]><!--><html><!--<![endif]-->
    Code (markup):
    There is something WRONG with your code.

    If you need to do this on a new website:

    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    Code (markup):
    There is something WRONG with your code.

    This meta:

     <meta name="author" content="name">
    Code (markup):
    Serves NO legitimate purpose and have NOTHING to do with SEO. Not one single UA does anything with it.

    Whilst in that part of the code you might want to add a comment to the keywords one saying it should be "seven or eight SINGLE words (or proper names) that exist between <body> and </body>. You stuff ANYTHING else in there -- despite the decades of people crapping into that field with gibberish -- and it will be ignored. It's called keyWORDS, not keyphrases, not keysentences, notkeywordjumble, but keyWORDS.

      <link rel="stylesheet" type="text/css" href="CSS/style.css">
    Code (markup):
    This is 2018, you don't have to say type="text/css" on your stylesheet link (not that it EVER actually did anything), same for type="text/JavaScript" on <script>.

    ... and where's your MEDIA TARGET? Omitting media="" is the same as media="all" -- and I'm pretty sure your screen media stylesheet is a waste of bandwidth and complete gibberish for aural, search, etc... and it's probably none-to-useful for print either.

      	<div id="container">
      		<div id="flagContainer">
      		<img id="canadaFlag" src="Image/canadaflag.png" alt="Flag of Canada">
      		<!-- Edit Your Header between the h1 labels -->
      		<h1 id="headerH1">Easy immigration to Canada!</h1>
      		<div id="pageContent">
      	<div id="paragraphContainer">
    Code (markup):
    Your indentation style doesn't make any sense, there is NO reason to be wasting a DIV around that image, though to be frank that image is presentaiton not content so it has ZERO business in your HTML.

     	<div id="paragraphContainer">
    	<!-- Edit your paragraph here! High quality contect is key for good natural 
    		SEO the more words you use will help your article to be found. -->
      <pre id="paragraphText">
    Our immigration service is one of the best in the industry helping thousands of people to immigrate to Canada every year with our advenced technologies, dedicated staff and world class experts...
    Code (markup):
    What in the blazes makes that preformatted text? It's a paragraph, is the <p>aragraph tag. Likewise other pages might have their own paragraphs so <div id="paragraphContainer" is a pretty silly name. This is made all the more confusing by the fact you aren't displaying said text as preformatted.

    <div id="offerImageContainer">
    	<img id="offerImage" src="Image/canada-passport.png">
    Code (markup):
    Another "DIV for nothing" AND a "presentational image in the markup". That's not a content image, so don't treat it as such.

    <a href="https://www.itscanadatime.com" id="button"><span>Continue</span></a>
    Code (markup):
    SPAN for nothing. Generated content would probably work better. Also it's NOT a button, we have tags for <button>'s. It's just a anchor no matter how you style it. Also not a great idea to use an ID for that. That's going to be your only element of that style on all your pages?!?

       		<div id="footer">
    		  	<img class="logo" src="Image/logo.svg" alt="ItsCanadaTime Logo">
    		  	<img class="logo" src="Image/rcic.png" alt="irccrc logo">
    		  	<img class="logo" src="Image/ssl.png" alt="ssl transaction logo">
    Code (markup):
    If all elements inside a parent container with a div or class on it are getting the same class, NONE of them need classes. I'd also start that with a HR to separate it semantically at the H2 depth. Remember, an HR means a change in topic or section where heading text is unwanted or unwarranted, and not "draw a line across the screen".

      <div id="credentials">
      <p id="copyright">Copyright ┬ęthewebsitename 2018 All Rights Reserved. </p>
    Code (markup):
    I also see no real reason for this to be a separate div from the footer, or for either paragraph to have id's on them. Also it's "copyright copyright"?!? Use the symbol OR the word, not both! I would also suggest using the named entity (&copy;) instead of the utf-8 character just in case this gets sliced up into a language that doesn't internally handle utf-8 in the template. (it's stupid but it happens).

    Your all caps text should probably be normal text inside STRONG, since you're adding "more emphasis" to that text. This way screen readers and braille readers will handle it properly. Trademark symbols and <b> around facebooks name -- indicating it is a legal entity (the grammatical reason for bold when not adding emphasis) -- wouldn't hurt either. YES, <b> is valid and has a semantic meaning. YES, <b> can be valid and make sense inside <strong>! Remember, <b>, <i>, <cite>, <em>, and <strong> all have five entirely different semantic meanings even if there are only two default appearances divvied up betwixt the lot of them!

    Put all that together and there's no real reason for the HTML of that page to be much more than:

    <!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
    	content="The best in immigration service assistance."
    <title>Canadin immigration service</title>
    <h1>Easy immigration to Canada!</h1>
    <div id="content"><div class="widthWrapper">
    	<div class="subsection">
    		<p id="whatWeDo">
    			Our immigration service is one of the best in the industry helping thousands of people to immigrate to Canada every year with our advenced technologies, dedicated staff and world class experts.
    	<!-- .subsection --></div>
    	<a href="https://www.itscanadatime.com" class="continue">Continue</a>
    	<div id="footer">
    		<img src="images/logo.svg" alt="ItsCanadaTime Logo">
    		<img src="images/rcic.png" alt="irccrc logo">
    		<img src="images/ssl.png" alt="ssl transaction logo">
    			&copy; thewebsitename 2018 All Rights Reserved.
    			<strong>This site is not in any way a part of nor is it endorsed by the <b>Facebook</b>&trade; website or <b>Facebook&trade; inc.</b></strong>
    	<!-- #footer --></div>
    <!-- .widthWrapper, #content --></div>
    Code (markup):
    Or at least that's how I'd be going about it. You aren't doing much to warrant more than that. If I have the time later today I'll try to revisit this to toss together a CSS so you can see what I mean.
    deathshadow, Aug 31, 2018 IP
  4. Pavel Yudkevich

    Pavel Yudkevich Peon

    Likes Received:
    Best Answers:
    Trophy Points:
    Thank you so much for the detailed post, I am going over it for the third time now and checking what you pointed out!
    **Updates are soon to come to GitHub**
    I would be glad if you add some CSS as you said you might, it seems you have a lot of knowledge and experience I lack :)
    Pavel Yudkevich, Sep 2, 2018 IP
  5. deathshadow

    deathshadow Acclaimed Member

    Likes Received:
    Best Answers:
    Trophy Points:
    Sorry for the delay, got waylaid over the holiday weekend. Just belted it out. I used to do these types of rewrites all the time, but I've lacked the motivation of late.

    A full rewrite is here:

    It still needs some tweaking, but should give you the general idea of where to go with it. Some of the images were remastered for file size optimization... I would suggest a smaller/simpler body background though since at a megabyte that one is "not viable for web deployment" on such a simple page. I used background-size:cover on it since if you're going to use that massive an image, might be nice to show all of it and not just a tiny slice.

    When I do these rewrites I usually accompany them with section by section breakdowns of the how/what/why of the choices I make. Gimme a while and I'll get those posted up here as well.
    deathshadow, Sep 3, 2018 IP
  6. deathshadow

    deathshadow Acclaimed Member

    Likes Received:
    Best Answers:
    Trophy Points:
    Alright, let's break down the how/what/why of the HTML. Follow along with:


    though the comments in there explain most of it, let's just review those comments.

    DOCTYPE through to charset META:
    "I suggest condensing DOCTYPE through the charset META, as well as </head><body> and </body></html> to single lines as a gentle reminder that nothing should ever be pasted in-between them and they MUST appear in that order."

    It's just a good practice to avoid screwing up.

    Viewport META:
    "The viewport meta tells mobile we know what we're doing, some android devices also need height set for landscape view."

    By default most mobile devices apply an extra 'zoom/scaling' to pages and lie about their device sizes on the assumption websites were not written for mobile. Since we ARE writing for mobile, the viewport meta tells them not to do that.

    Description META:
    natural language description of the page, typically displayed belowthe page <title> on your SERP listing

    That's the description META's purpose, it's surprising how many people seem to stuff absolute trash into it.

    Keywords META:
    "seven or eight SINGLE WORDS (or proper names) that exist between <body> and </body>. This is NOT a huffing word jumble. It's called keywords... Not keyphrases, not keysentences, but keyWORDS!!!"

    I cannot put enough emphasis on that. It's funny because even Google claims that they ignore the keywords meta when they do not -- it's just that people have so utterly absued/misused that META for so long, they've forgotten their own rejection criteria. Just a handful -- preferably eight or less -- of single words and/or proper names that exist as plaintext in your document body that you want a slight uprank on. That's it, that's all it's for. It is NOT a word jumble where you blindly stuff all the possible combinations people might type in!!!

    Stylesheet LINK:
    "This is 2018, we don't need to say type="" on stylesheet <link> anymore. NOT that said attribute EVER did ANYTHING in ANY browser. HTML 5 validation will complain about projection and TV. Ignore that warning as there are plenty of devices still in use that require those targets.

    There is rarely a good reason to omit media="" or to send media="all" since your style for specific targets (screen,print,aural) rarely makes a lick of sense for other device types!

    This is also someplace people screw up all the time. 99% of the time if you don't see a medai="" or if you see media="all", the person writing the code doens't know enough about HTML or CSS to be telling you how to build pages. The laugh being that's almost everyone dumb enough to get suckered into using frameworks like bootcrap or w3.css.

    TITLE tag:
    No comment provided, just remember the title exists to be the text in back-links to the page, as the title of a window or tab, and that's about it. It is NOT a place to blindly stuff content for black hat SEO BS. I tend to follow the pattern "[page name -] Site Title" where I omit the page name on the home page (dug). It is the most useful format for USERS. ... and at all times that should be your primary focus, write for the USER.

    "A site should only ever really need one H1 if not using HTML 5's idiotic<section> tag. As such there is no reason to put an ID on it."

    The rule of thumb is you should only have one H1 per <body> or <section> tag on a page, since an H1 is THE heading (singular) that EVERY other heading on a site indicates the start of a subsection of. When you open the (pointless) <section> tag that is treated as a new / separate document for these purposes.

    From there an H2 indicates the start of a major subsection of the page, with the first H2 indicating the start of your primary content. (making NAV and MAIN pointless redundancies which is why I suggest not wasting time on those tags!). An H3 indicates the start of a subsection of the H2 before it, an H4 indicates the start of a subsection of the H3 before it, and so-forth down to H6. (there is no such thing as H7/higher). An HR indicates a change in topic/subsection where heading text is unwanted or inappropriate. THEY DO NOT MEAN CHANGES IN FONT-SIZE/WEIGHT OR DRAWING A LINE ACROSS THE SCREEN!!!

    DIV#content, DIV.widthWrapper:
    "Outer container for hash hook by id and background, inner container to set a max-width and centering.

    DIV and SPAN are nice because they're "semantically neutral" -- this means they apply NO meaning to the document allowing you to hook for the application of style WITHOUT saying what that style IS. In general you should choose your HTML to say what things ARE or ARE FOR, and not for appearance. This is where most (if not all) HTML/CSS frameworks are ignorant halfwitted crap, as they use classes like "text-center", "box-shadow", or "w3-red"... at which point you might as well pretend CSS doesn't exist and go back to using deprecated tags like FONT, CENTER or attributes like ALIGN and BORDER with tables for layout. Doing things in that manner is the pinnacle of the WORST of late 1990's browser-war era practices.

    In this case we've got two simple hooks. I use a meaninful ID for the section so if wanted later we can hash link to it. Nice side effect of ID's is that you can url#thisSection and boom, when the page loads it will scroll to id="thisSection". Just remember Id's are unique, you can only use them ONCE on a page.

    Inside that we have:

    div.subsection -- a nice container for that content border area. Using a class allows us to re-use said style if desired later.

    p#whatWeDo -- again an ID so we can hash-link to it, and as a hook to apply that passport image from the CSS. That image really isn't content so it doesn't belong in the markup, and putting it in the stylesheet makes it easier to kill off when the screen is too small for that type of thing.

    Now notice how I close that subsection:

    <!-- .subsection --></div>
    Code (markup):
    It is handy to comment your closures so you know which DIV are being closed -- this gets more and more true the larger such blocks are. I don't say "end .subsection" since duh, </div> means "end" of a DIV. I use a period to indicate that it's a class just like you would in CSS, and I put the comment before the closure because comments between sibling-level elements that end up with "positioning" (position:relative, floats) can trigger rendering bugs in some versions of IE and FF. Putting the closing comnment before the closure means it can never be between sibling-level elements, dodging that headache. The bugs in question (double-render, disappearing content) are rare, but when they happen you'll start ripping your eyebrows out. It's often been funny -- and tragic -- in the past watching people go crazy hacking around render bugs that could have been avoided if the coder had simply removed or moved their comments.

    A.continue -- this really needs nothing fancy, no extra span or containing elements. MORE than enough hooks there for CSS to do its thing.

    DIV#footer -- another DIV to let us style the footer separately. You really only had one DIV worth of stuff for the footer. (which is why I had no idea what make you use three or four)

    DIV HR:
    "These HR are to grammatically say "these are not part of the section before them" -- semantically separating them from the paragraph above. They do NOT mean "draw a line across the screen" even if that's the default appearance!"

    Basically what I said above, we use them for GRAMMATICAL reasons, not presentational ones. It's a change in topic.

    From there are the three images, the two paragraphs, we close out #footer, we close out .widthWrapper and #content, and we're done so close out the BODY and HTML tags.

    Note the use of STRONG inside the second paragraph. STRONG means "with more emphasis" -- aka drawing the user's attention to a notice, just as EM means "with emphasis". They do not mean "this text should be bold" or "this text should be italic" -- even the B and I tags don't mean those things, they mean "would be bold or italic in a professionally written document for gramamtical reasons when not adding emphasis or <cite>ing a source."

    All five tags -- B, I, CITE, EM, and STRONG -- have five separate meanings and uses despite sharing only two default appearances. This is because whilst visual users may be able to make the distinction betwixt them, non-sighted user-agents and users need extra queue's to decipher your meaning.

    Because again, HTML is for MORE than just perfectly sighted people sitting in front of screens; done properly HTML is for EVERYBODY, the ultimate in inclusive behavior.

    ... and why CSS is separate from it with distinct media targets.

    Ok, enough about the HTML you've had days to study, lemme get to documenting the CSS.
    deathshadow, Sep 3, 2018 IP
  7. deathshadow

    deathshadow Acclaimed Member

    Likes Received:
    Best Answers:
    Trophy Points:
    Alright, on to the CSS. Follow the bouncing ball at:

    I always design using a monolithic stylesheet per media target. That means one file for screen, one file for print, etc, etc. The number of separate files used in building a page slows down the page-load thanks to what's called "handshaking".

    Have you ever noticed when uploading files via FTP how a single 1 megabyte file will upload faster than 100 separate 10k files, despite being the same total filesize? That's the handshaking overhead of requesting a file or starting a new connection to transfer a file. Keeping your total file counts under control is a 'must have' and why I'm NOT a big fan of when people use dozens of separate stylesheets or dozens of separate scripts.

    ... and really if you have enough CSS to warrant more than one file, you have too much CSS; but then I've NEVER seen a normal website that warranted the use of more than 48k of CSS (not even counting minification) and why I recoil in horror when I see all the herps and derps out there vomiting up half a megabyte or more of CSS spanning dozens of files. Epic /FAIL/ at web development.

    ... and another strike against frameworks since they often start out at twice that before you've ever even written a single line of your own style!

    Enough about that, into the actual sheet we go.

    I always start out with a 'reset' in my stylesheets. Resets exist because it was NEVER the HTML specifications job to say what things look like, so in the beginning it was entirely up to the user-agent (a browser is a UA but a UA isn't always a browser) to determine how to convey those meanings. Because of this when CSS came along there was no standardized base for things like margins, paddings, and borders so many elements didn't (and still don't) have a common starting point. This is something the CSS specification SHOULD have explicitly stated and never has...

    A reset just gives you a common baseline of zero to start from.

    There are smaller resets like the so-called 'universal' one of "* { margin:0; padding:0; border:0; }" but that can wreak havoc with styling differences of form elements in FF and IE. There are larger resets like Eric Meyer's "reset reloaded" but they tend to be such fat bloated messes wasting time setting values that don't need to be reset, they border on being frameworks unto themselves. In fact, such massive resets are what give the concept a bad name and has resulted in many developers swearing off them even if it makes ensuring compatibility more work.

    The one I use (created by Dan Schulz, RIP) is the compromise; the nice safe middle ground; the Goldilocks zone. It targets only what NEEDS to have borders, padding, and margins reset and nothing else. At a quarter of a K in size it is not large enough to be a bandwidth issue or to raise any real complaints.

    Alright, moving on.

    HR -- the comment says it all. They are there for SEMANTICS and non-visual UA's. Since this is screen media where we can convey that meaning in other ways, we can hide them.

    @media (max-width:480px) -- inside this is a text-resize-adjust for Microsoft and Apple browsers. Some older devices do not recognize the viewport META, and this is the fix for that. Unfortunately if you send the -webkit- one to some desktop copies of Safari it disables the user's ability to zoom (even though ALL Mobile Safari are uneffected... it's crApple, they're worse than M$ on stuff like this! Think of Apple's web technologies as being as shoddily slopped together as their idea of a cooling solution.).

    Thankfully all the mobile devices that "need" this fix have 480px or narrower screens, and it's unlikely many desktop safari users will set the browser window that small -- so a simple media query to say don't send this to anything 'bigger' takes care of the problem.

    From this point forward I'm makign the desktop layout with legacy support/degradation FIRST. A Lot of people say "mobile first" and that's utterly back-assward. See, we can target modern mobile with media queries, we can't target legacy desktops -- so why would you code what you CAN customize for first and then leave yourself with no mechanism for supporting anything else?!?

    html, body -- setting these to 100% height allows us to create a min-height layout. This will be handy with the "grid layout" system I'm going to put in there so the background image can be stretched to fit the page.

    body, button, input, select, table, textarea -- I like to set all my common font data up-front first. It should be noted that most elements inherit from body so just setting BODY nabs almost everything. Much like the reset though, those other tags do not inherit so I nab those here too.

    I didn't implement the hard to read webfont stuff since I'm not a fan of them on flow text. Avoid using that stuff if you care about accessibility -- reserving webfonts for decoration, icons, or extra stuff the user isn't going to sit there reading at length. I do not advise using webfonts on flow paragraphs -- ESPECIALLY the illegible (for windows users) garbage Google hosts.

    Even Google agrees with this which is why they don't even use their own webfonts on Google Search or Google Plus when it comes to CONTENT! As much as typography wankers bitch about it, it's hard to go wrong with Arial; hence why Google still uses Arial as their first-choice go-to on their "public consumption" websites!

    body -- the stuff unique to just this tag. In this case I set up the CSS "grid layout module" to create a full screen row system. under "grid-template-rows" the first value of "auto" means the element shrinks to fit the content, whilst the second element of "1fr" uses up any and all remaining screen space.

    The end result of this is that our first element inside <body> -- the H1 -- will be its normal size, but the second element -- DIV#content -- will expand to fill the screen if the content is shorter than the screen, but it will also grow when the content is too tall for the screen.

    Mind you this breaks down in IE and older browsers, OH WELL. this is fancy presentational stuff. Do NOT waste time bending over backwards for older browsers. For now the result might not be pretty, but it's USABLE. that's the line to draw on your legacy browser support efforts. It should WORK, but don't go jumping through hoops of fire for people who refuse to pull their head out of a decade ago's backside!

    h1 -- the heading gets a bottom padding to make it pretty, big text, colouration, nothing fancy... YET.

    h1:before -- this generated content creates the red bar with the canadian flag in it. It's taller than the image to give that top padding area you had, with the background placed bottom-center and sized to a fraction the page.

    I didn't do this in percent like you had as it got absurd on my 4k display. EM is a far better measurement and should be used as much as possible given that it makes things automatically scale.

    PX is inaccessible, EM means users who know / need auto-scaling don't have to dive for the zoom. The WCAG says to use EM, so use 'em!

    Again this is all presentation not content, so it really has no business in the markup. Generated content :)before, :after) can often let you do all sorts of amazing things without pissing on the HTML in the process.

    #content -- background, colour, nothing too fancy but notice the background-size:cover; That's a newer property that in this case makes the image auto-scale to fill the available space showing as much of itself as possible and only being cut-off to preserve its aspect ratio. VERY handy and powerful.

    .widthWrapper -- I set a small max-width since that seemed to be what you were doing. Under normal circumstances I would have a larger max-width, but you really didn't have enough content in the design for that. The unevent padding lets us use margin/padding on content without worry of margin-collapse. A long topic worthy of an entire article unto itself. Naturally by now I assume you know what auto-margins do.

    .subsection -- also padded, and I bumped the font-size since you seemed to have it larger. Shouldn't be anything too unfamilar there but I added more text-shadow (multiple layers of it in fact) to help try and improve the legibility. Text over imaages is always dicey and compromises legibility far, FAR too often! Likewise the inset box-shadow helps and also makes it a hair prettier.

    .subsection p -- bottom padding instead of margin to again avoid margin collapse.

    #whatWeDo -- more padding on the right so we can put that passport image in. Again scaled to EM. I remastered the image to remove the excess border and have a cleaner alpha transparency instead of the palettized version you had.

    .continue -- again just simple styling of a button. I didn't really copy the appearance 1:1 and more ballpark guessed.

    -- our hover states to darken the background and 'lower' the shadow to make it look like the button is 'depressed'. When targeting :hover (at least on button and anchor) it's a good idea to nab both :active and :focus as well. Technically :focus is for keyboard navigation and other alternative methods of getting around the page, but some older browsers incorrectly use :active (which is supposed to mean it's the last element clicked on) instead, so just grab all three!

    .continue:after -- I used generated content to add the ">>" to the page. Using width and positioning tricks I'm able to slide in without any extra markup.

    -- adjust the width and left position to show it. Easy-peasy lemon-squeezy.

    #footer -- alignment, and again some text-shadow to aid in legibility.

    #footer img -- I fixed their height in EM for scaling and allow them to auto-width to preserve their aspect ratio... then some simple padding. As they by default behave as if they were inline-block (though they aren't, they're "special") we don't even need to do anything else to them.

    #footer strong -- we use upper-case transformation instead of bold to indicate our "more emphasis".

    #footer p -- I bumped the letter spacing as it just looked nicer, and of course we pad the bottom to push things apart a bit more.

    ... and that in a nutshell is the desktop layout. To make it mobile friendly we only need one media query -- we used semi-fluid (has a max-width not fixed width) elastic (em based) layout, and there's no real columns to strip off, so this is pretty simple.

    @media (max-width:48em) -- I just shrink the H1 padding/spacing and flag size, decrease the widthWrapper padding, and kill off the passport image on #whatWeDo.

    That's all.
    deathshadow, Sep 3, 2018 IP
  8. deathshadow

    deathshadow Acclaimed Member

    Likes Received:
    Best Answers:
    Trophy Points:
    (new post as I was butting heads with the post size limit)
    Now, all of that said, one final thing to pay attention to is the directory structure I used:

    / -- http root

    /images -- CONTENT images

    /template -- stylesheet

    /template/images -- PRESENTATIONAL images

    In an ideal codebase you SHOULD be able to completely reskin a site without once touching the HTML. A really well created codebase SHOULD be flexible enough for that -- which is another reason to keep your presentational images separate from your content -- since different skins might use different presentational images, but the same CONTENT. That's why the passport, flag, and background are in /template/images whilst those company logos are in just plain /images.

    This also helps avoid any 'up-tree' linking. Remember that url() paths in your CSS file are RELATIVE to the location of that CSS file. If your presentational images were in /images instead of /template/images, you'd have to write url(../images/background.jpg) instead of url(images/background.jpg)

    ... and I was always taught (decades ago) that if you have to use "../" in your code, you did something wrong.

    Again I'd also like to suggest picking something smaller for a background image as that megabyte is nuts. I would never make a page like that use more than 128k for simple presentation that adds nothing of value to the content.

    Hope all that helps, I know it's a lot to take in, but take your time, go through what I said, and any questions fire away.
    deathshadow, Sep 3, 2018 IP