CSS in PHP include header and footer not working

@kirstenMay 28.2014

Hi I can’t get my php include/header & footer to recognize my css.

My header.php and css are in the same file so I don’t believe it is a directory issue.

I have tried to make a base to link to the root but that didn’t work.

My website is kirsteneaton.com/myWebsite/currentProjects.php

I have tried everything I know to get this to work for 2 days.

Thank you.

to post a comment

CSS

28 Comments(s) _↴

@BapuaseMay 28.2014 — #The gurus will soon attend to you

@deathshadowMay 28.2014 — #Link 404 -- did you take it down because you got it sorted?

Really, it's unlikely it belongs in your footer, since the STYLE and LINK tags are only valid in <HEAD></HEAD>

really though, without seeing the PHP that generates your markup, it's unlikely we can help you.

@kirstenauthorMay 28.2014 — #Link 404 -- did you take it down because you got it sorted?

Really, it's unlikely it belongs in your footer, since the STYLE and LINK tags are only valid in <HEAD></HEAD>

really though, without seeing the PHP that generates your markup, it's unlikely we can help you.[/QUOTE]

Thank you for your reply. No, it was never up. Were you able to view it privately. I'm sorry for not including my php...

<?php include 'header.php'; ?>

<!DOCTYPE html>

<html>

<title>Current Projects with PHP, SEO, JQuery</title>

<body>

<div>

<div class="content">

<div id="box">

<h4>Making a Blog in PHP</h4>

<p>Client based database</p>

<p>Building Website using SEO</p>

</div>

</div>

</body>

</html>

<?php include 'footer.php'; ?>

@kirstenauthorMay 29.2014 — #Oh no I didn't give you the proper file name.

http://kirsteneaton.com/myWebsite/php/currentProjects.php

And I have a header.php and a footer.php

@deathshadowMay 29.2014 — #Well, I should probably read you the riot act on the halfwit garbage known as bootstrap, the HTML 5 trash, stupid bandwidth wasting "modernizr" script, gibberish use of numbered headings, incomplete form, lack of media targets on your script LINK...

But setting all that /fail/ at building a website before you even have content aside...

http://kirsteneaton.com/myWebsite/php/bootstrap/css/bootstrap.min.css

404, file not found

http://kirsteneaton.com/myWebsite/php/includes/css/bootstrap-glyphicons.css

404, file not found

The files don't exist. Did you mean to do:

http://kirsteneaton.com/myWebsite/bootstrap/css/bootstrap.min.css

http://kirsteneaton.com/myWebsite/includes/css/bootstrap-glyphicons.css

Remember, the relative path of an include be it JS or CSS is to the location of the PHP file, so this:

<link href="bootstrap/css/bootstrap.min.css" rel="stylesheet">

run from this:

http://kirsteneaton.com/myWebsite/php/currentProjects.php

results in this:

http://kirsteneaton.com/myWebsite/php/bootstrap/css/bootstrap.min.css

Not this:

http://kirsteneaton.com/myWebsite/bootstrap/css/bootstrap.min.css

Since it's not in the root, you'll need to uptree link if you don't want to re-adjust your directory structure.

&lt;link
 rel="stylesheet"
 type="text/css"
 href="../bootstrap/css/bootstrap.min.css"
 media="screen, projection, tv"
 /&gt;

[i]I added in all the stuff you are missing on those incomplete LINK[/i]

Though honestly, I advise against that -- it seems more like your directory structure is flawed since up-tree linking (../) is just sloppy coding and poor planning. I'd move any files users can call directly into the 'root' of the site's location, so that all LINK and SCRIPT tags point down-tree instead.

Now, that said, your includes also appear to be busted since you've got more than one doctype, head and body... and really you might want to learn a bit more about how to write HTML before you start playing with PHP as to be brutally frank, your markup is bloated gibberish nonsense -- though that's typical of what happens the moment you drag bootcrap and HTML 5-tardery all over a website's carpets.

@kirstenauthorMay 29.2014 — #Yeah, I'm new, I suck, I get it. Ugh....where do I start? To be a little defensive I created the header.php and footer.php after my header and footer.html didn't work. I thought bootstrap would be easy now I'm left with this mess. I'll be back after I try to make some of the changes you suggested and let you know. I promise I am not a bad person.

@kirstenauthorMay 29.2014 — #Ok, I see what you are saying. I am going to change my directory. No I did not know that it has to be http://kirsteneaton.com/myWebsite/php/bootstrap/css/bootstrap.min.css. Did I tell you thank you for beating me up and helping me? Thank you, but I am sure we aren't finished here.

@jedaisoulMay 29.2014 — #I strongly recommend using PHP include files, but only AFTER you have learned to write good HTML and CSS. They give a much better structure and maintainability, particularly for larger sites.

@kirstenauthorMay 31.2014 — #Hi. Ok, so I canned the whole bootstrap mess and i wrote my website by hand taking in all of you suggestitions for meta tags and SEO purposes, thanks!

I changed my file directory to put the css, header and footer all in the php file with the my php pages. I still can't access the css when i pull up my php pages.

kirsteneaton.com/website my code is:

<?phpinclude('php/header.php')?>

i left a copy of 1.css in the website file for now.

What am i still doing wrong?

@deathshadowMay 31.2014 — #Did you figure it out, because it's loading CSS here.

that said you are missing a few parameters on your LINK... You have:

<link href="1.css" rel="stylesheet">

... and that's only part of the story. You might be having trouble from omitting the TYPE attribute... to say that it's text/css

... and since that's a screen layout you should also have a MEDIA attribute saying what media target that is for -- being a screen layout that's typically "screen, projection, tv"

&lt;link
 type="text/css"
 rel="stylesheet"
 href="screen.css"
 media="screen,projection,tv"
 /&gt;

It's also nice to name your stylesheet what they are for -- print, screen, handheld, aural... etc.

Other than that you seem to be working OK, unless you're using some old browser that can't do flex-box -- like IE 9/earlier.

Though combining like values in the CSS might help things, as would a reset since there's extra padding in IE and 'real' Opera around things. Semantic/logical heading orders might be in order too... but that's unrelated to your CSS not loading.

Is that still a problem? If so, what browser and what OS? did you accidentally disable CSS somehow (like with the web developer toolbar extension?)

@deathshadowMay 31.2014 — #Oh, and on this:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

Those last two values REALLY shouldn't be declared, they break the ability to zoom in desktop Safari and [b]ALL[/b] mobile devices. Maximum-scale and user-scalable should REALLY be avoided as they make mobile harder to use, not easier. For SOME reason some 'experts' out there are claiming this does something useful (they aren't clear what), but given that it screws up one of the most important tools for mobile accessibility -- zooming in -- I can't imagine it to be worth that penalty.

<meta name="viewport" content="width=device-width; height=device-height; initial-scale=1.0" />

Would probably be better for you. I'd also suggest:

@media (max-width:600px) {
 * {
 -webkit-text-size-adjust:none;
 -moz-text-size-adjust:none;
 -ms-text-size-adjust:none;
 }
 }

Which would probably fix whatever those extra viewport meta values have, without screwing up desktop browsers. The media query is there because tablets don't need those settings usually, and sending the webkit one to desktop safari -- again -- breaks the ability to zoom... the laugh being it does NOT impact Safari on mobile's zooming, making it one of the real "what the devil were they thinking" of these new values.

@deathshadowMay 31.2014 — #Oh, and you might want to validate your markup -- you've got an unclosed DIV, a second href with no values on your anchor, it's actually a little surprising the layout works with those issues; but HTML is very forgiving -- sometimes I think too forgiving as it makes it WAY harder than need be to notice mistakes.

Often makes me wonder if the XML guys have it right -- when there's an error just "stop dead" right where the error is instead of plowing on blindly hoping things work; it would make finding errors simpler, and motivate people to actually fix errors instead of shrugging and going "eh, close enough".

Current SGML style behavior sure as shine-ola doesn't seem to make things easier on people just starting out.

@kirstenauthorMay 31.2014 — #Ok, let me catch up and make all of these changes.

But first let me get something straightened out. Should my files be:

header and footer html or .php?

should my css file be inside of my php file?

Thank you so much, so much for your help.

@kirstenauthorMay 31.2014 — #ok. I am ready to go. Fixed my div, fixed my <links> changed the name of my css. My file structure is:

screen.css

header.html footer.html and a

php file with all of my pages.

if you go to kirsteneaton.com and then click on references my references.php is displayed with out the css. (my same ole problem)

my code is:

<?php include('header.html')?>

I am clueless.

You know if we got married I could make you dinner and you could teach me coding? How about it?

So what's my problem with this css? You said before that all php point upwards that i would need to put my css in the root?

@kirstenauthorMay 31.2014 — #oh.. and I was unable to find the href with no value. And...thanks for hating bootstrap and wordpress, it sparked me to with this all on my own with out the over load of these two programs.

@jedaisoulMay 31.2014 — #
Ok, let me catch up and make all of these changes.

Should my files be: header and footer html or .php?
[/QUOTE]
Makes no difference.

should my css file be inside of my php file?

[/QUOTE]
Technically, no. There are good reasons for using separate .css file(s). On the other hand, it SHOULD work, so long as it is included correctly. I.e. Php include files are included at the point where the "include" instruction is in the .php file. So something like:

PHP file:

<i>
 </i>&lt;html&gt;
 &lt;head&gt;
 &lt;?php include 'header.inc'; ?&gt;
 &lt;/head&gt;
 &lt;body&gt;
 
 &lt;!-- html goes here --&gt;
 
 &lt;/body&gt;
 &lt;/html&gt;

INC file:

<i>
 </i>&lt;!-- the include file --&gt;
 &lt;title&gt;my web site&lt;/title&gt;
 &lt;style&gt;
 
 &lt;!-- CSS goes here --&gt;
 
 &lt;/style&gt;
 &lt;!-- end include file --&gt;

Produces:

<i>
 </i>&lt;html&gt;
 &lt;head&gt;
 &lt;!-- the include file --&gt;
 &lt;title&gt;my web site&lt;/title&gt;
 &lt;style&gt;
 
 &lt;!-- CSS goes here --&gt;
 
 &lt;/style&gt;
 &lt;!-- end include file --&gt;
 &lt;/head&gt;
 &lt;body&gt;
 
 &lt;!-- html goes here --&gt;
 
 &lt;/body&gt;
 &lt;/html&gt;

See how the text inside the include file is substituted for the "include" instruction? So the CSS is included between the <head> </head> tags and has <style> </style> tags, and will work. But position the "include" instruction elsewhere (e.g. between the <body> </body> tags, or before the <head> tag) won't work.

@kirstenauthorMay 31.2014 — #I'm sorry, I do not understand this:<html>

<head>

<?php include 'header.inc'; ?>

</head>

<body>



</body>

Why would I start this as <html> when the html is included in the includes file?

@kirstenauthorMay 31.2014 — #If you look at my header file you will see that the css is linked in.

@kirstenauthorMay 31.2014 — #OMG I think I got it but now my body html is not showing up.<?php /* My References page */

include('../header.html');

include('../images/kirstenEaton (2).png')

?>

<!DOCTYPE html>

<html>

<head>

<title>My References</title>

</head>

<body>

<h3>My References</h3>

<p>John Mierzwa Deep Dive Coders</p>

</body>
  </html>

<?php

include('../footer.html');

?>

@jedaisoulMay 31.2014 — #I suspect that you are confusing CSS link files with PHP include files. They work very differently:

CSS link files:

- Contain only CSS instructions.

- Must be called "name.css", e.g. "screen.css".

- Can be linked to HTML and/or PHP files.

- Must not contain <style> </style> tags ('cos they are HTML not CSS instructions).

- Work in browsers as well as on web sites (i.e. do not need a host).

- Must be linked between the <head> </head> tags with the syntax:

<link rel="stylesheet" href="name.css" type="text/css">

PHP include files:

- Contain any valid HTML, CSS and/or PHP instructions.

- Can be called anything, e.g. "name.inc".

- By default can only be linked to PHP files (depending on server configuration).

- Only work on a web server (or a local host).

- Are included in the PHP file where their content is intended to go, using the syntax:

<?php include 'name.inc'; ?>

You should use CSS link files to link the CSS instructions rather than PHP include files.

@jedaisoulMay 31.2014 — #Press <ctrl> U to view the source code of the references page. You will see that there is a spurious:

<i>
 </i>&lt;!DOCTYPE html&gt;
 &lt;html&gt;
 &lt;head&gt;
 
 
 <i>    </i>        &lt;title&gt;My References&lt;/title&gt;
 <i>    </i>    &lt;/head&gt;
 
 <i>    </i>&lt;body&gt;

inserted BEFORE the original doctype instruction.

@jedaisoulMay 31.2014 — #Basically, you should NOT put any instructions BEFORE the doctype declaration, and it would be better to avoid putting <head> </head> <body> </body> codes in include files until you have a better understanding of how PHP include files work.

Until then, use include files only to contain common code that is otherwise duplicated in every web page, like nav bars, headers and footers. Note: by "headers" I mean visible headings on the web ages, not the <head> </head> area of the HTML code. You will probably get on better if you are less ambitious at the start:

1. Write your web pages and get them working WITHOUT PHP include files.

2. Save a copy of the working site (in case you mess up).

3. Then identify a block of duplicated code, and put it in an ".inc" file.

E.g. "name.inc".

4. Substitute the instruction <?php include 'name.inc' ?> for the code it contains in just one page of the web site.

5. When you have got that working, do the same in the other pages.

6. When you have got that working, identify any other blocks of duplicated code, and repeat steps 3. to 5. above (using different names for each include file).

@deathshadowJun 01.2014 — #It's loading a screen.css here, the one that's in the same directory as it... which doesn't look very good. Are you trying to have it use the screen.css that's in the root instead?

Basically is this what you meant to use:

http://kirsteneaton.com/php/screen.css

Or this?

http://kirsteneaton.com/screen.css

If the former, it's working just fine from here. If the latter, you'll need to ../ again... or put your .php file in the root and stop making a subdirectory for it.

Once again though you have multiple doctypes meaning you are pasting separate HTML files together instead of PARTS of a HTML file.

As to the file extension, if you are using include then name it PHP. Really though when it's include it doesn't matter, but I'd make it .php so you can run PHP inside it, that way you could use things like functions so you can make ALL your pages use the same header and footer code while passing the unique values like page title and key/desc meta.

I tell you what; I do this every now and then -- I'll do a rewrite example of your page using "poor man's CMS" style includes (what you are trying to do here it seems) so you can learn from the markup and PHP -- and I'll write up full line-by-line section-by-section breakdowns of the PHP, HTML and CSS for you to learn from.

@deathshadowJun 01.2014 — #Alright, I have a live copy of my rewrite of your main page here:

http://www.cutcodedown.com/for_others/kirsten/site1_live/

... and the references page here:

http://www.cutcodedown.com/for_others/kirsten/site1_live/references.php

The main directory:

http://www.cutcodedown.com/for_others/kirsten

Contains a .rar of the entire "poor man's" setup and a variety of useful files. The site1_phps directory:

http://www.cutcodedown.com/for_others/kirsten/site1_phps

Contains viewable PHP source files so we can refer to the code online easily.

I will now attempt to break this down to explain the process it was built with, and how it all works. I'll likely be teaching you some HTML stuff you probably never heard of, particularly if you took classes on the subject since most "educators" when it comes to web technologies do NOT know enough to be opening their traps on the subject.

[b]--- Directory Structure ---[/b]

Before we start diving into code, I want to go over the directory structure used by this example. Planning where things will be BEFORE you even THINK about writing a line of code is a really good practice I cannot recommend highly enough. In this case it's gutted down from my normal system, which works as follows.

[b]/[/b]

-- root, contains all user-callable .php or .html files.

[b]/images[/b]

-- contains content images, aka images that are not part of the template

[b]/template[/b]

-- contains the various .template.php bits and pieces, like the header, footer, etc, as well as the .css file for that template.

[b]/template/images[/b]

-- because images called by the CSS are part of the skin, and are called in relation to the CSS file's location, keeping them separate makes file management easier and makes any future reskin of the site simple too.

Really keeping all user callable files in the root makes directory management really, REALLY simple, as everything can be linked downtree.

From the PHP include of the 'common' template elements:

include('template/common.template.php');

To the content images:

<img src="images/test.jpg" alt="test image" />

To the CSS:

<link type="text/css" rel="stylesheet" src="template/screen.css" media="screen, projection, tv" />

To the images included from the CSS

background:url(images/h1Logo.png)

[i]That last one resolving to /template/images/h1Logo.png[/i]

This way you don't have to up-tree with ../ and everything is well organized and easy to get to.

The distinction between a content image (one that belongs in the markup) and a presentational image (one that goes in the CSS) is a very important one to establish early on. Your logo for example is a presentational affectation of text - like most logos -- which means it has NO business in the markup in a IMG tag. We'll get more into that once we get to markup and CSS.

[b]--- Logical Document Structure ---[/b]

When building a site it helps to have a gameplan that works to how HTML and CSS are supposed to work, and the rules of how they are SUPPOSED to be used. Sadly, most people working on sites don't take the time to do this, and rarely if ever learn the actual rules of using HTML. You can see this when people omit fieldsets and labels from forms, when they don't use numbered headings properly (which you weren't), or when you see nonsense like <td class="heading"> or <td rowspan="4"><b>My Table</b></td>.

I'm going to outline my process -- you can take it or leave it, but it helps to at least have one.

The first thing I do when working on a new site, is take my content, or a reasonable facsimile of future content, and just write it flat in a text editor in an order that would make sense as if HTML didn't even exist. This is the lowest common denominator you can start with.

I included what I did for this rewrite here:

http://www.cutcodedown.com/for_others/kirsten/indexContent.txt

Things simply in the order of importance or use. I use a few special characters to say 'this will be a heading' or 'this links to or is a image of this'... with three hyphens to clearly divide 'sections' of the page.

I then take that simple outline and mark it up semantically, which you can see here:

http://www.cutcodedown.com/for_others/kirsten/indexSemantic.txt

The first thing you'll notice there is I start with an H1... so lets talk headings. You were using numbered headings in a willy-nilly nonsensical manner; mind you, that willy-nilly nonsensical manner is used by a LOT of developers who passed it on to others out of their own ignorance... You learned from a bad source.

First up, if you were choosing the headings based on their default text size, you were choosing the wrong tags for the wrong reasons -- tags should be chosen for what they MEAN, [b]NOT[/b] what they look like.

The reason heading tags have numbers stems from professional writing of documents like research papers, science papers and reports. (what Tim Berners Lee actually created HTML to do). In professional writing differerent level headings indicate the start of subsections of the page -- lower order (higher numbered in HTML) headings indicating the start of a subsection of the higher order (lower numbered in HTML) heading preceeding it.

Because of that, used properly you should have one and ONLY one H1. [i](HTML 5 changes this slightly, we'll cover that bit of idiocy in a moment)[/i] -- as a H1 is the heading under which EVERY subsection of the page is... well, a subsection. This is why a H1 for the main article is often gibberish -- while the site title (or logo) is often the best candidate for it.

Think of a newspaper -- is the headline the top-most heading in terms of structural importance? [i](as opposed to important importance -- there is a difference)[/i] Of course not. Structurally the main giant headline is NOT the heading for every other article on the front page. The name of the paper is the H1, as evidenced by it being at the top of every sub-page, even if it is shown smaller on those sub-pages. All the articles are H2 as they are siblings to each-other, even if the first one is shown in bigger text. You would hope that "Man mugged and left for dead near downtown diner" and "K-6 gets new school building" are not subsections of "[b]MAYOR CAUGHT TAKING MILLION DOLLAR BRIBE[/b]" [i]If they were, that would be one screwed up town.[/i] - they are all H2 regardless of their appearance.

Likewise, H2 means subsections of the h1... H3 mean subsections of the H2, and so forth down to H6... If you don't have H4 or H5, you have no business using a H6 on a page. If you don't have a h1, you have no business using a H2. HR also has a semantic meaning -- a change in topic/section when a heading is unwanted/unwarranted.

Think of it like a 'tree' -- headings should 'fan out' in a logical structural order. This can help with search, AND in certain user-agents (browsers) can also help with navigating the page when the user isn't on a mouse or touch interface. You can actually see this tree if you have the [url=https://addons.mozilla.org/en-US/firefox/addon/web-developer/]web developer toolbar installed in Firefox.[/url] -- just go into information -> document structure and it will yell at you about missing headings and broken structure!

That's why numbered headings exist, and why if you're not doing that you are using them wrong.

Now that said, the steaming pile known as HTML 5 [i](can you tell I'm a fan?)[/i] destroys this usefulness as every time you open a "SECTION" you revert to a new H1, resulting in a gibberish multiple H1 on a page. ? Think about it though -- semantically if numbered headings and horizontal rules divide the page into sections, why do we need a SECTION tag? If heading navigation lets you skip from the h1 to the first H2 (which should be your main content) why do we need a NAV tag? If the last heading, set of headings, or everything after the last HR on the page are the start of the footer, why do we need a FOOTER tag? They are ALL just pointless redundant code bloat put together by a group (the WHATWG) that never grasped how to use HTML properly in the first place!

Which is just part of why I do NOT advocate the use of HTML 5, and prefer a RECOMMENDATION doctype like HTML 4.01 STRICT or XHTML 1.0 STRICT. Well, and I remember what happened the last time people started deploying websites using draft specifications; two years later it was called "Quirks" and we pay for it to this day.

So as you can see, I just have the semantic markup, with an ID or two on elements that we may want to target. H1 as the structural root, ul#mainMenu for the menu, H2/img/P/a.more for the three 'panel' areas, H2+P and H2+UL for the footer subsections. ALL those subsections get H2 [b]because they are NOT subsections of each-other.[/b]

The next step in this is 'rounding out' the markup with the rest of what a page should have, and providing hooks for the application of appearance. I ALWAYS write a static version of the very first page on a site first, so I can cut it up into the pieces needed by the PHP or skinning system of whatever it is going into. It is just easier at this point to design a flat page and split it up, than it is to try and design with the PHP in the way.

The final markup for the page being this:

http://www.cutcodedown.com/for_others/kirsten/indexSource.txt

Alright, coming close to the 10k post limit, so I'll continue this in the next post.

... to be continued.

@deathshadowJun 01.2014 — #... continued

You'll notice the final source uses XHTML 1.0 STRICT. I like XHTML 1.0 for it's more consistent structural rules -- I like STRICT because it means code elements that have no business on any website written after 1997 like TARGET, ALIGN, BORDER, BGCOLOR, CENTER, FONT -- wil throw an error in validation.

EVEN IF I was forced to use the halfwit garbage known as HTML 5 for the one or two useful things like MANIFEST and SANDBOX, or that are shoved down our throats thanks to the freetards Apple zealots like the pointlessly redundant AUDIO and VIDEO, I'd design in XHTML 1.0 STRICT, ignore the validation errors for those elements/attributes, then swap to the HTML 5 doctype right before deployment... something that a LOT of developers who have given up on fighting HTML 5 now advocate. [i]Like Don Quixote, I'm still tilting at that particular windmill.[/i]

Another thing you'll probably see is I'm a nut when it comes to using tab and enter -- they are your friend and it's much clearer whats going on if you don't stuff everything onto one long incomprehensible line. This is REALLY true of attributes on really long tags like HTML, META and LINK. For the most part there's nothing too fancy going on, but let's hit a couple of things before moving on to BODY.

--- META ---

[b]Content-type[/b] -- handy in local testing so the browser knows what you are working with when there is no content-type headers being served; you never know if headers are going to be sent or sent properly, so despite what the HTML 5 nutters say, keep this one around.

[b]Content-Language[/b] -- always good to state it, even with lang and xml:lang on HTML.

[b]viewport[/b] -- the 'fix' to tell mobile devices we actually know what we are doing. You now need to say height as well as width since some versions of Android now seem to report the height as width when in portrait mode.

[b]keywords[/b] -- a LOT of people say the keywords meta is ignored, even some folks at Google; guess what? They're full of it. It's ignored IF YOU USE IT WRONG!

It is called keyWORDS -- not keysentences, not keyphrases, key[b]WORDS[/b]! [b]Seven or eight[/b] single words, proper names or compound terms [b]that exist inside BODY as CDATA[/b] you want a slight ranking boost on, preferably totalling less than 96 characters. Do NOT word-jumble evey possible combination as that does absolutely nothing, and NEVER DID -- no matter how many examples you'll find online doing exactly that.

For example, this is bloated gibberish likely to be ignored:

content="babysitting in new hampshire, new hampshire babysitting, new hampshire child care, child care and babysitting, daycare, daycare in new hampshire"+

New Hampshire is a proper name, child care is a compound term, so this on the other hand:

content="new hampshire, babysitting, daycare, child care"

Would most likely still work -- assuming ALL of those terms exist inside BODY as content text. It's ignored if you don't use it right -- who'd have thought?!?

[b]description[/b] -- a natural language paragraph you want shown below your TITLE on the SERP. That's ALL it's for. It is NOT a place to stuff with keywords (though if they happen naturally then fine) -- it is where you describe what the current page IS.

When it comes to METADATA, those are really the only ones that you should have before you add things like tracking scripts or advertising. Most of the rest of the META people put on their sites aren't actually used by anything.

[b]--- LINK ---[/b]

[b]stylesheet[/b] -- You'll notice I have a TYPE on that so, well... it knows what type of stylesheet is in use. In STRICT that's NOT an optional value. Likewise I am targeting with the MEDIA attribute "screen, projection, tv" -- as projection is what kiosks use operating fullscreen, and there are still a number of folks out there using things like MSN web TV boxes. (scary as that is). If you omit the MEDIA attribute your CSS will be sent to all -- and that might not make the least bit of sense for print, handheld, aural, braille...

Ok, on to

[b]--- BODY ---[/b]

First notice I put <html><head>, </head><body> and </body></html> on the same line together. Some people assume I do this to save two bytes -- no so. This is a reminder that nothign should EVER go between those elements. WAY too many times I've seen people paste stuff between them, and putting them on the same line reduces the odds of somebody screwing things up that way.

I added span inside the anchor so that first when images are off, the text is shown instead -- this is called 'image replacement' and we'll get more into detail on that in the CSS. The inner span will be our image replacement, the outer one is to apply color styling near identical to your image so that it still kinda looks the same should images be disabled/blocked.

A [b]lot[/b] of users are starting to block images and scripting to save bandwidth on metered connections (like our friends in Canada and Australia), and increase performance on mobile [i](since images chew a lot of RAM and mobile... doesn't have a lot of RAM)[/i]. Your page should be ready to adjust to that, and doing it this way gives us a H1 for structure, actual text for screen readers, and graceful degradation images off. Serious win/win.

Because of the nature of the styling we end up with several DIV -- DIV and SPAN are 'semantically neutral containers' -- they do not impart ANY semantic meaning to the structure or the tags and data inside them. They exist to be hooks for presentation, without saying WHAT that presentation [b]is[/b]. I try to use the same philosophy on my ID's and classes, though sometimes (like with the widthwrapper) you end up just not being able to come up with a better name for it.

[b]div#content[/b] and [b]div.widthwrapper[/b] would be around all content on all pages, the former for float wrapping and background effects if desired, the latter to apply a 'max-width' so long lines of text don't become painful to read.

[b]div.panels[/b] is specific to the home page, and is there to wrap the three panels so we can hook them by that class.

Which is why you'll notice a distinct lack of classes (other than .more) inside each of the panel DIV. Since we don't have DIV inside the DIV and all three would get the same CSS, none of them need classes or ID's. The only reason I have a.more in there is on the odd chance you might want an anchor inside your H2 or P, or around the IMG.

When it comes time to close my DIV you'll notice I have comments to say what is being closed. I do this because </div> is a bit vague, particularly if you're a good ways down the page. I don't say "end" because that's wastefully stupid, what else would </div> mean?!?

You'll often see comments like:



<div id="content">

</div>



Really? Opening a DIV called #content is the start of the content?!? Who'd have thunk it? That's just stupid.... likewise </div> is the end, we don't need to say end...

Now, you'll notice I put the comment BEFORE the closing tag. In certain versions of IE and FF if you have comments between floats, inline-blocks, or a number of other types of positioned elements you can trip rendering bugs. YES, I said COMMENTS can trip rendering bugs! Sounds really stupid doesn't it? Well, I did say Internet Explorer didn't I? When the errors occur, the content of the second sibling element can just up and disappear, while the content of the first element can often be drawn a second time in a random location. They are called the "disappearing content" and "double render" bugs respectively... but, it only occurs when commments are BETWEEN elements... solution? If you put the comment BEFORE you close the tag, it's not between elements is it?

Also, you'll notice I say  or , just as in CSS so I know if it's a class or ID being closed.

It's just a good habit for code clarity.

in [b]#footer[/b] we just have a bunch of DIV that I DID end up wanting to target, so they all get ID saying what each of them ARE. This is where things like bootcrap can fall falt on their face with their needlessly vague presentational classes.

Now, even with all of that, the larger XHTML 1.0 header, the closing comments, tripple wrapping of DIV at the content area -- it's still three quarters the size of your original... another reason using semantic markup and logical structure can really rock!

Alright, gimme a few and I'll break down the CSS, then I'll go through and document the PHP.

... to be continued.

@deathshadowJun 01.2014 — #... continued

Alright, on to the CSS:

http://www.cutcodedown.com/for_others/kirsten/site1_phps/template/screen.css

The top section is stuff common to all pages. The second half is page specific. I put everything for one media target (like screen) into a single "monolithic" file as properly written websites shouldn't need enough CSS for the extra size to have an impact. Sure, the halfwits vomiting up 200k of CSS might thing monolithic is bad, but when there is no real excuse for the stylesheet of an entire forum or CMS to break 48k, it's really stupid to break it into separate files which results in extra handshakes, especially when it means you can pre-cache on first load the appearance of sub-pages the user might visit. Maybe a half second more load time on first visit to have sub-pages load and render almost instantly? Not a hard choice.

I always start out with a reset -- The simple fact is across browsers elements do NOT start out with the same padding or margin behavior, and it's a pain in the ass to have to set padding and margins on EVERY element as you use them.

There are smaller resets, like the so called "universal reset" of:

* { margin:0; padding:0; }

But that can cause problems with form elements as FF and IE both apply their own 'extra' padding you have no control over, and stripping the padding off INPUT, SELECT and TEXTAREA can cause those elements to be wildly different sizes across the four (well, now three) major browser engines.

There are also larger resets, like Eric Meyer's "Reset Reloaded" -- problem with that is it does MORE than just reset, and is very close to becoming a framework. It's big, it's fat, and most of what it does has nothing to do with being a reset. Resets like that one are what gives them a bad name.

The one I use is a nice safe middle ground. It targets what is needed, comes in at under a quarter-k, and has never failed me.

The comment on the HR says it all -- HR in my markup are for semantic structure, not drawing lines on the screen. Usually as I use other elements to make the 'sections' clear on the page, I hide my HR by default.

[b]@media (max-width:600px) { *[/b] - The first media query is to address a text sizing issue in lower resolution mobile devices. It's in a media query as sending this value to desktop Safari will prevent being able to zoom in that browser -- a laugh since iOS Safari has no such issues making that... well... just really stupid on Apple's part.

[b]body[/b] - Font, color, background... nothign too fancy. I set the background color to the footer's blue so that when the page is shorter than the screen the footer color continues. The other alternative would be a min-height layout, but given how well a flex inside a flex works (which is to say not at all) and that we really shouldn't fix the height of such a simple footer, I wouldn't consider that a viable choice.

[b]h1[/b] - padding and background color. Gecko based browsers (firefox, iceweasel) have this goof assed bug where if you declare PX inside an element as font size, the PARENT inherits it -- which is COMPLETELY the wrong behavior and probaly one of the dumbest things a browser can do... so we need to explicity set 100% font-size so our 1em padding is actually system 1em and not the 28px of the anchor inside it.

[b]h1 a[/b] -- Now, I'm well known for ranting and raving about using PX on font sizes, but in this case because we are behind a fixed size image we really don't have a choice. If we left it elastic, the text under our image replacement would peek out. The position:relative is so we can absolute position the span inside it. The zoom trips a IE condition called "haslayout" so our absolute positioning isn't screwed up in IE7/earlier. I added letter spacing and used "trebuchet ms" so it at least comes close to looking like your image on windows.

You'll notice I explicity set text-decoration:none -- I advise against setting that globally since removing it from flow content is poor accessibility.

Also you might notice I always use the 'condensed' font property of

font:weight style size/line-height family;

This is because if you change the font size EXPLICITLY REDECLARE YOUR LINE-HEIGHT. Line-height does NOT inherit reliably when you change the size, which can lead to broken layouts, particularly if designing elastic with dynamic fonts. There is a [b]LIE[/b] being circulated on some forums that omitting a metric (px, em, whatever) will make a value that does inherit properly... aka:

line-height:1.5;

But as the word "lie" would imply, that's 100% ignorant fiction; the laugh being no matter how many live examples of it not working you show the advocates of that technique, they more vehemently they claim it works. Then they wonder why I call them a string of expletives that would make truckers tell me "watch your mouth, there are mechanics in here."

[b]h1 a span[/b] -- different color to match the image for our images off appearance.

[b]h1 a span span[/b] -- the inner span is sized to our logo image and absolute positioned over the text. This requires an opaque image, and as such I remastered the logo into a palettized png.

http://www.cutcodedown.com/for_others/kirsten/site1_phps/template/images/h1Logo.png

Losing the transparency and dropping it to 6 bit / 64 color reduced it to a mere 1.4k in size. /WIN/ compared to the 12k or so of the original.

[b]#mainMenu[/b] -- turn off bullets, set the alignment, pad the top and bottom, color and border. Nothing fancy.

[b]#mainMenu li[/b] -- I set these to display:inline as LI can cause real headache rendering bugs in IE8, the worst of which being the staircase bug. Setting that means we can't set heights or top/bottom padding, but we can use padding to space the anchors apart.

[b]#mainMenu a[/b] -- these get set to inline-block so we can set top/bottom padding on them. I also set them to nowrap for mobile. The uneven top/bottom padding accounts for oddball alignments of the vertical position of fonts and to compensate for a slight optical illusion the color choices are creating. I also set up some nice transitions for our hover states as well as rounding off the corners. The box shadows being the same color as #mainMenu's background are invisible until we hover.

[b]#mainMenu a:[i]psuedostates[/i][/b] -- the hover state is just background-color change and text-shadow. This gives it that really cool glow effect for a minimum of effort. You'll notice I use :active, :focus AND :hover. :focus is for keyboard navigation in modern browsers, legacy IE will incorrectly use :active (meaning it's been clicked on) for keyboard nav, and of course :hover is for mouse users. It's a good idea to state all three the same in most cases... [i](at least until you start using CSS3's [b]WONDERFUL HEAVEN SENT[/b] :target attribute)[/i]

[b]#content[/b] -- full width, the white background of the content area, and I gave it a inset box-shadow to slightly darken the corners for another bit of attractiveness.

[b].widthWrapper[/b] -- I made this container semi-fluid (min/max-width) and elastic (values in EM) so long lines aren't painful, and pre media-query browsers don't try to go narrower than the content is designed for. The 100% width also trips haslayout, to TRY and fix some positioning bugs in IE.

[b]#content h2[/b] -- size and padding -- yawn.

[b]#content p[/b] -- padding, yawn -- but on both of these, notice I use padding not margin. I try to use padding instead of margin whereever possible so I don't have to keep track of margin-collapse headaches.

[b]#footer[/b] -- overflow to wrap floats, set the text color, border... again, yawn.

[b]#footerCopyright,

#footerFollow,

#footerNav[/b]-- align their text center, float them right. Floating these three shrinks them to their smallest size, so that nice heading and paragraph on the right can use as much of the remaining space as possible. Ends up looking really nice.

[b]#footerCopyright[/b] -- I add some extra right padding to address a browser flaw common after a flex container, where the floats in the next element lose half an em on the right. No clue WHY it happens, but it does. I also align it right, so it counterparts #footerAbout's left alignment nicely.

[b]#footerAbout[/b] -- overflow:hidden can have a number of strange effects, in this case I'm leveraging that it prevents the text inside this container from dropping UNDER the three stacked floats.

[b]#footer h2[/b] - padding, fonts, yawn

[b]#footer p[/b] -- Zzzzzzzzzzz.....

[b]#footer ul[/b] -- kill bullets, pad it...

[b]#footer li[/b] -- a little extra space between them.

[b]#footer a[/b] -- more attractive (and legible) color, and a fade transition for:

[b]#footer a:[i]pseudostates[/i][/b] -- color for the hover states.

Alright, getting close to the post limit again, so once again I'll continue on the next post with media queries and page specific CSS.

... to be continued.

@deathshadowJun 01.2014 — #... continued

My responsive process is a bit different -- I like to start out designing for middle-resolution desktop FIRST, becuase the most likely browsers to not have media query support are NOT mobile, it's IE8 and earlier! That's the most common lowest common denominator, so that's my starting point. As such my media queries strip off columns and work towards mobile, or if need be towards larger screen sizes -- basically if you start in the middle, you have less distance to travel each direction!

[b]@media (max-width:56em)[/b] --he first media query just strips off the min-width for media query browsers and shrinks the menu padding... Notice that I declare my breakpoints in EM so that it's based on the user's default font size, NOT pixels -- since pixels could result in a broken layout on large font/120dpi or other systems NOT using the 16px = 1em default. [i]LIKE MINE![/b]

[b]@media (max-width:46em)[/b] -- I test by shrinking the page until it breaks, then figure out how many EM that is to reflow whatever broke. In this case it's just the footer. Easiest fix is to turn that four columns into three, and put the wide text below it. That's just changing the floats, setting 33% width, some alignment, and breaking the copyright area's h2 into two lines with that little span I tossed in there. Clearing floats on #footerAbout makes sure it doesn't ride up accidentally.

[b]@media (max-width:38em)[/b] -- again the footer is the only thing in the main template that needs more tweaking at small sizes. At this point it's just too narrow for attractive columns, so we strip the floats and sizes, resulting in no columns. I also added a border between the elements.

--- and that's the template CSS, onto the page specific stuff

[b].panels[/b] - overflow:hidden fixes a oddball firefox bug with flex where the footer rides up over the flex container for no fathomable reason at certain sizes. I kept the flex-box model you were using (for the most part) but a word of warning, it barely works in IE10 and not at all in IE9/earlier. If you care about legacy IE this type of layout used to be "not viable for web deployment" in concept. Honestly, the page is still usable in IE9/earlier, it's just ugly... You could probably live with it as-is. If I really cared about it this would be one of the few scenario's I'd load a second stylesheet behind a IE conditional comment to make these all just 33% width floats... that or maybe a media selector hack, though for targeting IE9/earlier wholesale that could get ugly. I pad the right side so the flex boxes can margin just one direction -- this makes having the same space between the child DIV a lot easier as we then don't have margin stacking in the way.

[b].panels>div[/b] -- this lets us target those child DIV without wasting classes on 'nothing'. They get the flex model, overflow:hidden to wrap floats and crop the drop-shadow on the nested H2, margin with the right side left as zero... alignment, border radius and drop-shadow shouldn't be unfamiliar given what you had... BUT

There's that bottom padding. I used a 'trick' to make the '.more' buttons line up. First I padded the bottom of all the DIV a sufficient amount to place those buttons -- we'll explain why when we get to a.more

[b]#content .panels h2[/b] -- we have to say #content on these to resolve a specificity issue since the 'generic' #content h2 for normal pages sets some values we want to change. Doing this beats the tar out of using !important. Padding, margin, size, border, shadow -- nothing fancy.

[b]#content .panels h2 small[/b] -- after some playing with it I found the de-emphasized subtext (what small means semantically) just looked nicer on it's own line. The vertical-align:middle fixes a odd chrome rendering bug where the small line appears too close or even overlaps the text above it on zoom.

[b].panels img[/b] -- setting it to display:block and using margin to center it removes a LOT of the headaches leaving it inline can cause, such as inconsistent behavior after a margin and extra padding at the bottom that's not the same across browsers.

I set a max-width so that they do NOT resize larger automatically, since that generally looks like a blurry mess, but they will shrink as needed.

[b]#content .panels p[/b] -- as with H2 we have to say #content to get around the specificity of the generic version (as used on the references page). Other than that, we're not doing anything too wild with these.

[b].panels .more[/b] -- here's that magic I mentioned earlier. I absolute position the .more buttons over that bottom padding, using the left:50% margin-left: negative half the fixed width trick to center them across the display. I use uneven top/bottom padding to actually center the text top to bottom due to oddities in alignments of fonts that way. The rest of it is just style and color.

I changed them to blue for two reasons -- first, for consistency with the rest of the design, second that blue creates less luminance making the white text legible, something that light yellow/orange you were using didn't provide. If you were to use that yellow/orange you'd have to switch to a dark text if you want things actually legible -- and in testing I thought that looked horrible. (probably why you were using white even if you couldn't read it).

[b].panels .more:[i]psuedostates[/i][/b] -- simple color and background change, but that nice transition on the non-pseudo makes it a smooth and pretty change. Blessed be - CSS3.

Then the media queries specific to pages with .panels on them.

[b]@media (max-width:56em)[/b]

Setting .panels to display:block removes the flex-box model, making the DIV be displayed one over the other. Removing the block from the SMALL text reduces the title to a single line, then floating the image rides the paragraph up next to it making better use of the available screen space at smaller display sizes. Likewise a negative bottom margin rides the bottom padding up into the image, so we can move the a.more over to the right side where it looks nicer in this version of the layout.

[b]@media (max-width:38em)[/b]

This narrow we are better off pulling the floated image and making them centered again as they were on the large screen layout, likewise moving .more back to it's original position as well.

... and that's the CSS. Ok, in our next episode I'll dig into explaining the PHP version of this, starting with the common.template.php -- might be a bit, I need to have some lunch first.

... to be continued.

@deathshadowJun 01.2014 — #... continued.

In our common.template.php -- read along with the .phps here:

http://www.cutcodedown.com/for_others/kirsten/site1_phps/template/common.template.phps

The first thing I have in there looks pretty complex -- it is. It's a simple hook I provide to automatically add gzip compression to the page. Normally php output isn't gzipped, and manually setting up to support it is tricky; that one simple snippet of the first 20 lines of code handles it for you by starting buffering if the browser supports it, and using a shutdown function to compress it and send it properly. Don't worry about that part, it does the work for you.

Inside this .php I put both the header and the footer as functions. This makes it easy to pass values to the header like a unique page title, keywords and description. Similar values could be passed to the footer if desired in a later version.

[b]function template_header[/b] -- this function takes three OPTIONAL parameters, if you exclude them when you call the function they will be treated as false.

I use echo to output the markup. You could close PHP and re-open it again all over the place, but to me that just always feels like ugly code bloat -- probably because it's NOT how real programming languages (C, Pascal, Modula) handle output. I echo using single quoutes, which as a rule of thumb means we can use double quotes normally and only have to "escape" single quotes -- which usually won't exist in a theme anyways.

we take from our original testing source the first part right up until our variable based META. I use an IF statement to test if $keywords is set, and if it is we echo it out as the content of META[keywords], then do the same thing for $description and META[description].

then output the CSS link, and then use an if statement on $pageTitle. If it's set, we output $pageTitle - SiteName, if it's not set, we just have Sitename -- which in this case is "Kirsten Eaton Website". Having a unique title for every page is good usability, Google also suggests it to aid with search; using a hyphen between the page and site names works great.

From there we just echo out the rest of the markup right up until where we'd have the page-unique content... and that's where the template_header ends. Again, you'll see I put a closing commment in so I know what's being closed.

[b]function template_footer[/b] -- this one doesn't get any parameters for now -- it just outputs the rest of the template after where the page unique content would go as per our original template.

... and that's all that's there. Now, how do we use it? Well, lets use the smaller "references" page as an example. If we look at it's code:

We open PHP, include template/common.template.php, and call the header function passing it a unique title for the current page, keywords we want to use (those should be changed to reflect your final page content), and a short paragraph describing the page (you'll want to write one of those)

After we close PHP your page unique content can be plugged in. In this case a simple DIV#references with a h2 and a couple paragraphs.

After your content, we just open up PHP again, call template_footer, close PHP and we're done.

If you take a look a the source for the index.php

http://www.cutcodedown.com/for_others/kirsten/site1_phps/index.phps

You'll see it works exactly the same way, the only real difference is my passing FALSE to $pageTitle so that just the sitename is shown on the homepage.

Pretty slick, pretty simple, and pretty powerful.

... and that's the most basic of what used to be called a "Poor Man's CMS" in action. [i]Oddly, it was commonplace to call it that a decade ago, seems like I'm the only one still using the term now?[/i]

I know all this is a LOT to take in. Take your time, go over it, and if you have any questions, I'll be here.

Also in #CSS _↴

Applying a style border to ONE side of a cell CSS div and span instead of table W3C CSS Validator Service

Success!

Help @kirsten spread the word by sharing this article on Twitter...

Tweet This

CSS in PHP include header and footer not working

28 Comments(s) _↴

Also in #CSS _↴

Success!

Social

Version

CSS in PHP include header and footer not working

28 Comments(s) ↴

Also in #CSS ↴

Success!

The web is an endless sea of information. Don't miss the boat... Subscribe!

Social

Version

28 Comments(s) _↴

Also in #CSS _↴