1. Reset your CSS.

   Why?: Unfortunately, the base CSS rules in browsers are not consistent so they need to be reset if you want your site to look how its supposed to look with as few surprises as possible. This is a step in that direction.

   A good CSS reset: http://meyerweb.com/eric/tools/css/reset/

   Or if you’re using HTML5: http://html5reset.org/

2. Minify your CSS and JavaScript.

   Why?: Always store your CSS and JavaScript in files and be sure to minify it. Minifying your JavaScript removes comments or whitespace from your stylesheets and scripts speeding up your load time. This also reduces the chance of your page getting hacked.

   Tools for this: http://minifyjavascript.com, http://minifycss.com.

3. Always use CSS sprites instead of JavaScript for image replacement.

   Why?: Images slow down page loads more than anything so using as few images as possible
   makes things faster. Using sprites (a composite image of the hover and non-hover states stacked
   vertically or horizontally), for rollovers significantly cuts down on the number of images the
   page has to load.

   Tools for this: http://csssprites.com/

   This will keep you from having to reload your page.

4. Ensure legibility for screen readers.

   Why?: Some users will only be able to access your website using screen readers, so you must ensure
   content appears in a logical order.

   Here is good resource for this: http://csszengarden.com

5. Let Google host JS libraries for you.

   Why?: Speeds up your site because you save your users from downloading these libraries.

   Google hosts a number of popular JavaScript libraries including jQuery, Dojo, MooTools and Prototype.
   A full list can be found here: http://code.google.com/apis/libraries/

   Example:

   <script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.7.0/jquery.min.js" ></script>

6. Load JavaScripts at the bottom of page.

   Why?: The browser loads the head before the body. So if your JavaScript is in the head your user sees white while the page loads. If you put your JavaScript at the bottom, your content will load first.

   Of course, there are exceptions to this rule, such as when you really need a JavaScript to run before the body of the page is loaded. In most circumstances, you’ll be able to get away with loading them at the bottom of the page.

7. Use multiple stylesheets

   Why?: Separation of concerns. If another developer assumes your project, he won’t want to kill you.

   I usually use one for resets, one for elements and utility classes, one for page layout, at least one for the content, one for forms, one for mobile, one for print and at least one for IE.

More to come…

• It divides the code by its functionality (aka “the separation of concerns”). This provides a guideline for where developers should include their logic which is useful when working with a team of developers. The model (in some cases the DAO) communicates with the database, the view focuses on presentation, and the controller on logic. It’s straight-forward.
• It saves the developer time, by not having to reinvent the wheel and write code that provides the base functionality for the application like a bootstrapper, a dependency injection container, a base DAO (database access object), a base model, controller, view and so forth.
• Most frameworks have API’s that provide shortcut methods and sometimes common objects that can reduce the volume of code considerably. This is especially useful for websites which have a list of common components (i.e. forms, authentication, web services, clean urls, ajax requests, email tokens, captcha, security hashes, feed aggregation, shopping carts, etc., etc., etc.) that are cumbersome to program again and again. Even if you re-use your code as boilerplate, oftentimes clients request you customize it and this is where the libraries come in handy.

Now, I must say that if you’re a developing something simple like a website with a blog (like this one) you may want a content management system. In most cases, web application development is beyond the scope of a CMS. There are usually a multitude of frameworks for every programming language with a reasonable following. In my opinion, frameworks can divided into those that include an ORM (object relational mapper) and those that don’t.

Many web developers sing the praises of ORM frameworks, such as Django, Ruby On Rails, CakePHP and Symfony because of the added speed and efficiency it gives them. This is good if you’re a freelance web developer trying to create a small-scale specialized web application in as little time as possible. However, this doesn’t make or break the framework. With ORM’s there is an inherent lack of scalability and in many cases, it is not desireable to have your database schema follow your object model completely.

ORM’s can also make code refactoring a pain because the schema is created as you create your code, so any code changes after you have initially run the ORM, result in an extra step that can become tedious. Migrating your database with an ORM can also be a pain, especially if your switching database systems (i.e. from MySQL to Postgres).

Rather than evaluating what frameworks are superior to others I will highlight each of their strengths. As you’ll notice most of these are PHP or Python frameworks because these are the ones I know the best:

Zend – Extremely thorough library of fully scalable, object-oriented components. If you don’t want to use the MVC framework, you can simply use the components independently. Support for a multitude of database systems. Supports integration with Doctrine ORM. Best suited for professional and enterprise-level projects written in PHP.

CodeIgniter – Similar to Zend, but lighter weight, so sites run faster. It has simpler API that caters to less experienced programmers. Excellent and easy to read documentation. Supports MySQL and Postgres database systems. Best suited for PHP freelancers.

Ruby On Rails – This innovative framework is perhaps the number one reason to learn Ruby. Includes an optional and flexible ORM and an all-encompassing API, partly because it’s the only major Ruby web development option. Ships with a JavaScript library, originally Prototype, now jQuery. Best suited to Ruby web shops and freelancers.

CakePHP – Ruby On Rails with PHP. Often considered the fastest PHP framework, development-wise, due to its code automation feature. Library of object-oriented components MIT licensing so you can do whatever you want with it. Best suited to PHP web shops that take on small-scale web app projects.

Django – Features a built-in admin section, a plugin system for components which already very thorough, and an ORM meaning its built for speed rather than customization. Remarkably simple and extensible templating language that allows for the ability to create custom tags. Best suited for Python web shops and those looking integrate with Google App-Engine.

TurboGears – Self-described “megaframework”. Built on top of other popular Python projects including CherryPy, Pylons and SQLAlchemy, an extremely flexible ORM. Ships with tools for AJAX integration. Best suited to complex, enterprise-level Python applications.

I learned object-oriented using Java which is a great language. It’s easy to learn, has garbage collection, a simple interpreter, has clean, consistent dot syntax and intuitively-named native functions. In addition, there’s loads of support for it. You don’t have to look far if you don’t understand something. I don’t like about it is that it’s purely object-oriented. I cannot write a script with Java (unless I’m using Groovy of course, which for all intensive purposes is considered a different language) and that is a bit of a downer. Everything must be done using objects and that’s great if you developing professional software but not so if I just want to write a little game for my son. I also don’t like the old school clunky array syntax. Really, you must use Vectors with Java and you’ll need the Iterator() object to loop through it, because there is no foreach loop.

I work with PHP and JavaScript everyday and so I should talk about them second. PHP is great language. Its easy to learn, most of its native library is crammed full of C functions so if you already know C you’ll feel right at home. Alternately, if you’re intent on learning C, PHP could serve as a good place to start. Its syntax is similar to Perl and C (almost as if it were a cross between those two languages). At first, I didn’t like the ‘$’ marking for variables, but I’d have to say it has grown on me. After all, its very easy to tell what’s a variable! Unfortunately, the downside is that the code is ugly as sin. Nested function can lead to long lines of code that can be hard to read. There are plenty of frameworks to choose from and believe me you’ll want one unless you want to be up all night coding. Zend is my choice but I’ll leave that for another article.

JavaScript is the other web language I work with and it sucks. Well, that’s a bit harsh. Most of the bare-bones language sucks which is surprising since it borrows so heavily from two good languages: Java and C. There are parts of JavaScript which are very good. But most of it stinks and here’s why: you need far too many lines of code to write simple things that websites need. The DOM tree can be quite tedious to navigate through and to top that off, there’s Internet Destroyer and all of its re-interpretations. Thankfully, to make this language more manageable, there are plenty of JavaScript libraries; jQuery, Ext, Prototype, Dojo and Mootools are some of the best in my opinion.

Python is my leisure language of choice for the desktop and it ain’t bad for the web either. Django and TurboGears are both solid frameworks that make developing a website a breeze and a blast. Mind you, website deployment is usually a bitch given the lack of hosting support. I like almost everything about Python: the syntax, the function library, the interpreter, the philosophy of the language: “there is one obvious way to do it”. The one thing I don’t like, and I’ll admit that its kind of nit-picky, is its lack of traditional operands. I’m so used to using &&, ++ and such that I can’t get into AND, OR or +1. Other than that, Python makes programming a pleasure and an ease and it supports classes, of course.

C and C++, while not as modern and streamlined as Python, deserve their props. There is a learning curve, but there is tremendous power with mastering them. C/C++ served as a blueprint for almost all programming languages after it. I’m in the midst of learning C and later C++ and while its a little more difficult than the other programming languages, the rewards justify it.

1. It uses an out-of-date box model where borders and padding are added to the width.
2. It can’t absolutely position elements correctly.
3. It can’t relatively position elements correctly.
4. Pseudo-classes only work on anchor elements. Nothing else.
5. Floated <div&rt; elements will inexplicably double their margins if they are not displayed as inline elements.
6. It doesn’t clear floats properly.
7. It doesn’t understand what overflow:hidden means
8. It doesn’t know what min and max height and width mean. Instead, it uses hasLayout.
9. It automatically expands containers based on content overflow (called “float drops”).
10. In a complete reversal of logic, it will truncate content too long for its container.
11. There’s no PNG support.
12. Flickering background images.

There are other bugs as well. I just figured I would list the most glaring and significant ones.

As of this writing, the market share for IE6 is 4.5%. About half of these are Chinese. Unfortunately, China is still an authoritarian country and users may have no choice in the matter (all the more reason Microsoft should drop support). My educated speculation is that the rest of IE6 fit into two categories:

• People who are on public computers at work or in a library (though these numbers are in decline).
• South Koreans
• Old people.

My solution to deal with the IE6 problem is simple: require IE6 users to upgrade before they enter your site. You can do this with a simple jQuery script like so:


if($.browser.msie && $.browser.version.substr(0,1) < 7){
location.href="http://www.mozilla.com/en-US/firefox/";
}


Obviously, you don't have to redirect them to Mozilla. This is simply an example. You can redirect them anywhere you like. The best option would be to redirect them to a page with links to Firefox, Chrome, Safari, Opera and IE9 download pages and have them decide for themselves. Include a message like, "Sorry, but this site's content doesn't support browsers released over 10 years ago.". Feel free to soften the blow if you'd like but, doesn't that seem reasonable?

Arguments against this method:

1. Why do you have such a problem supporting IE6?! It seems lazy to me.
2. Shouldn't a site support anyone who visits it?
3. You're sacrificing page visits.

To which I have the following rebuttal:

1. It's time-consuming to support out-of-date browsers. When you develop a website, time is money.
2. In a perfect world. Most sites no longer support Mosaic, Netscape Navigator or OmniWeb. Perhaps there's someone out there who uses these but they don't support Cascading Stylesheets so they don't support half of the websites on the web. This is why developers must pay attention to how their site looks in a screen reader. Google and YouTube no longer fully support IE<7.
3. The third argument assumes that after people upgrade they won't return to your website. I also stress that IE6 has only 4.5% of the market share, and of those 4.5%, half of them live in China and 40% live in South Korea. Unless, you plan on getting a lot of Chinese or South Korean visitors to your site. I wouldn't worry about it.

The goal of this approach is to get people/companies to upgrade so the web can move forward and everyone else's UX can improve. If your client absolutely insists on supporting IE6 after hearing all these arguments, there are certain steps that I will cover in order to improve the IE6 discrepencies but I will cover those in a later article.

]]> http://benvalentine.info/web-standards/what-is-to-be-done-about-ie6/feed 0 http://benvalentine.info/web-development/page-layout-the-header http://benvalentine.info/web-development/page-layout-the-header#comments Wed, 16 Mar 2011 22:10:13 +0000 admin http://benvalentine.info/?p=84 Read more »]]> With a company blog layout, I’ve found that the header normally contains the following sections:
1. The logo or nameplate and site title.
2. A skip-to nav that can only be seen by screen readers.
3. Utility, “tools” or “highlight” navigation where important pages that aren’t part of the main nav structure can be highlighted.
4. Searchbar.

The logo or nameplate and the site title should appear together in a single semantic section called “branding”. The site title should be wrapped in <h1> because in semantic context it is the most important headline on the page and link to the homepage.


<section id="branding">
<h1><a href="index.html"><span>My Site Title</span></a></h1>
</section&rt;


By wrapping <span&rt; tags around the Site Title, we can ensure that it can only be seen by screen readers in our CSS:


#branding a span{
visibility: hidden;
}


If your site has a tagline you can add it within the “branding” section. I usually use a <p&rt; tag with a “tagline” id.

Moving on, we’ll add our “skip-to-nav” next.


<hr class="visuallyhidden" />
<nav id="skip-to-nav">
<ul>
<li><a title="Skip to Navigation" href="#">Skip to Navigation</a></li>
<li><a title="Skip to Content" href="#content">Skip to Content</a></li>
<li><a title="Skip to Footer" href="#document-footer">Skip to Footer</a></li>
</ul>
<nav>


One thing to notice is how we add the <hr&rt; tag with the class “visuallyhidden”. This is a class that we’ll add to the stylesheet so we can hide any element from normal browsers but not from screen readers. The <hr&rt; serves to divide up the branding section from the “skip-to-nav” for screen readers. The next piece is the searchbar:


<div id="envelope">
<section id="search" class="search-box">
<form id="search-submit" method="post">
<fieldset>
<label for="search">Search:</label>
<input class="search" name="search" type="search" value="Search" /> <input class="submit" name="submit" type="submit" value="Submit" />
</fieldset>
</form>
</section>
<header id="document-header" role="banner">


Retarded browsers such as IE6, that won’t go away, don’t recognize input[type="search"] etc., so we have to code around them assigning them the classes “.search” and “.submit” which is annoying, but I digress. We’ll put the searchbar outside the header for now so that it appears at the top of the page for screen readers and then we can absolutely position it wherever we want for everybody else. The fieldset will provide its own box around the searchbox so we need not add another <hr&rt; tag. The final piece to add is our “toolbar” navigation:


<div id="envelope">
<section id="search" class="search-box"><form id="search-submit" method="post">
<fieldset><label for="search">Search:</label>
<input name="search" type="text" value="Search" /> <input class="submit" name="submit" type="submit" value="Submit" /></fieldset>
</form>
</section>
<!--end #search -->
<section id="logo">
<h1><a href="index.html"><span>Company Name</span></a></h1>
</section>
<!--end #logo -->
<hr class="visuallyhidden" />
<nav id="skip-to-nav">
<ul>
<li><a title="Skip to Navigation" href="#">Skip to Navigation</a></li>
<li><a title="Skip to Content" href="#content">Skip to Content</a></li>
<li><a title="Skip to Footer" href="#document-footer">Skip to Footer</a></li>
</ul>
</nav>
<!--end #skip-to -->
<hr class="visuallyhidden" />
<nav id="tools">
<ul>
<li><a class="current" title="Home">Home</a></li>
<li><a title="Tools Link 1" href="#">Tools Link 1</a></li>
<li><a title="Tools Link 2" href="#">Tools Link 2</a></li>
</ul>
</nav>
<!--end #tools -->
<hr class="visuallyhidden" />
</header>
<!--end #document-header -->


I prefer to specifically list them as Tools Link 1, Tools Link 2, etc. so I can tell which link part of which menu when I’m styling. On to the content area.

]]> http://benvalentine.info/web-development/page-layout-the-header/feed 0 http://benvalentine.info/world-wide-web/yahoo-losing-its-relevance http://benvalentine.info/world-wide-web/yahoo-losing-its-relevance#comments Tue, 22 Dec 2009 23:16:43 +0000 admin http://benvalentine.info/blog/?p=56 Read more »]]> I have a hunch that it may be a couple of years before Yahoo! will be going the way AOL, MSN and the countless search engines and web portals before it. Recently Facebook eclipsed Yahoo! in terms of worldwide traffic according to Alexa, a significant loss in the past 10 months. Of course, number 3 worldwide isn’t a bad place to be and neither is 41st, the spot AOL currently occupies.  However, the bar is extremely high for search engines and web portals. They are the set pieces of the World Wide Web. According to CNN, Yahoo! has seen its market share decrease 1.4 points in the last 6 months and in my own humble opinion this trend will continue until Yahoo! radically reinvents themselves.
]]> http://benvalentine.info/world-wide-web/yahoo-losing-its-relevance/feed 0 http://benvalentine.info/web-development/javascript-vs-flash-for-animations http://benvalentine.info/web-development/javascript-vs-flash-for-animations#comments Wed, 25 Nov 2009 17:37:37 +0000 admin http://localhost:8888/benvalentine/blog/?p=3 Read more »]]> It used to be that if you wanted to have a dynamic webpage, one that really snapped, wowing and impressing users with its fluid, movie-like animation, the choice was clear: Flash. However, if users don’t have the plugin installed for whatever reason, they get an annoying prompt to navigate away from the page, install the latest version of Shockwave, restart their browser and navigate back to the page. If you have Flash on your homepage, this will drive your visitors crazy and they won’t want to see the rest of your site.

A few years back, in 2005, the Prototype framework emerged, followed by the extensions, Script.aculo.us and jQuery. These libraries created an easy, cross-browser compatible way to include animations on the bare web page without the possible obstruction of Flash. With the vast array of effects at his or her disposal, a good JavaScript programmer can create a Flash-like page without all the fuss.

At this point, in the web’s evolution, I’d recommend creating basic web animations with JavaScript rather than Flash. Don’t get me wrong, Flash is still a great format for movies and other presentations, but for web page animations, I gotta go with a good JavaScript library like jQuery.

]]> http://benvalentine.info/web-development/javascript-vs-flash-for-animations/feed 0 http://benvalentine.info/web-development/html-5 http://benvalentine.info/web-development/html-5#comments Tue, 03 Nov 2009 21:09:36 +0000 admin http://localhost:8888/benvalentine/blog/?p=33 Read more »]]> Everyone has different opinions on the best way to markup HTML pages, from element positioning to what naming conventions to use and there are certainly best practices to consider as well.  If you’re like myself and write markup for a lot of websites, you don’t have time to re-invent the wheel every time, you’re going to want to create a website template. Perhaps more than one. I have a separate template for Drupal because it likes to force its own naming conventions on you but, I’ll address this in another post.

The first thing you’ll want to do is look at the similarities between the websites you have done markup for already. Also, notice that each site will need the following layout demands:

• A landing (or welcome) layout: index.html
• A layout representing a sub-level page or single post: page.html
• A layout where multiple post decks are displayed : archive.html
• A layout representing media display such as a photo or video gallery: media.html
• A page for 404 errors: 404.html
• A page for the sitemap: sitemap.html

It may look like a lot of work to write markup for all those pages but, keep in mind, the index page usually the only page with a significant difference in layout. Most of my index pages resemble this structure:


<div id="envelope">
<header id="document-header" role="banner">
</header>
<nav id="primary-navigation" role="navigation">
<ul>
</ul>
</nav>
<section id="content">
<section id="intro" role="main">
</section>
<section id="feature-deck">
</section>
</section>

<footer id="document-footer">
</footer>
<section id="hero">
</section>
</div>


index.html

In the index.html example, you’ll notice that I put the hero section below the footer. For those of you unfamiliar with the term the “hero” it refers to the main artwork or photo on the index page that is intended to grab the readers attention. The hero appears below the footer in the markup so that we may preserve the same structure of the page for people accessing the site with screen readers, in case the hero contains a jQuery carousel, a tabbed panel or a flash movie. Per the CSS Zen Garden approach, I use absolute positioning to put the hero in the correct space. The other sections should be self-explanatory. “Intro” contains an introduction to the site’s content and “feature-deck” will contain a list of recent posts or tweets. The “feature-deck” could be considered an &lt;aside&rt;, but I think that you’re better off making that decision on a site-by-site basis.

All other pages will share this structure:


<div id="envelope">
<header id="document-header" role="banner">
</header>
<nav id="primary-navigation" role="navigation">
<ul>
</ul>
</nav>
<section id="content">
<aside id="sidebar">
</aside>
<section id="posting-area" role="main">
</section>
</section>
<footer id="document-footer">
</footer>
</div>


page.html

I’ve named the major sections with semantic web-friendly conventions. You’ll also notice I use dashes instead of underscores or camelCasing. Reason being, external sources recognize dashed ids as seperate words enhancing its semantic meaning. For instance “posting-area” is interpreted as “posting area” (two English words) while “postingArea” is interpreted as “postingarea” (meaningless).

Obviously, we haven’t covered some of the nested elements and structures just created the basic skeletons for our two most important layouts. I’ll cover those region-by-region in later posts.

]]> http://benvalentine.info/web-development/html-5/feed 0 http://benvalentine.info/web-development/recommended-applications-for-mac-web-developers http://benvalentine.info/web-development/recommended-applications-for-mac-web-developers#comments Mon, 02 Nov 2009 16:26:30 +0000 admin http://localhost:8888/benvalentine/blog/?p=5 Read more »]]> Okay, so if you’re going to be a web developer, for starters, you’ll need a solid HTML Text Editor. I recommend three options:

1. BBEdit: The best I’ve used for basic (X)HTML/CSS is BBEdit. And from a functionality standpoint you can’t go wrong. It’s $125 a pop (if you can afford that) but it is the best. Take a pass on the freeware version, BBEdit Lite. There’s far more functionality in other text editors such as…

2. Text Wrangler: From a freeware standpoint you can’t get much better than Text Wrangler also published by Bare Bones. The only downside is its only available for Intel Macs and not the Power Macs…

3. Text Mate: The third option here is available for Power Macs. Text Mate costs 2/5’s as much as BBEdit and its better at coding your back-end languages such as PHP, RoR, Perl, Python, VB, etc. Plus there are 30+ bundles perfect for cutting corners.

Next you’ll need design tools. I recommend the Adobe Suite (its pretty much a no brainer) Illustrator & Photoshop. Here is an area where you don’t want to skimp, but if you absolutely must, get Gimp (a rhyme was not originally intended in that sentence). Gimp and Inkscape (vector graphics app) are available at Open Source Mac.

Third you’ll need a good browser to debug your (X)HTML, CSS, and JavaScript in. I highly recommend Firefox. At addons.firefox.org, you can add Web Developer and Firebug (these two addons will save you a ridiculous amount of time).

When you finally finish your site and wish to upload you’ll need a good ftp client. This will save you a lot of time especially when compared to binary uploads at Network Solutions or GoDaddy and dealing with their harum-scarum interfaces. I recommend Transmit because its a good app and because its logo is a dump-truck and you can dump stuff on it and ship it through the series of tubes . Again, if you don’t want to shell out the $$ because you spent your whole fortune on the Adobe software, FireFTP is a suitable alternative.

Now you’ll need to solve the IE problem. Microsoft does not make Explorer for Mac anymore, which is both good and bad. Good because let’s face it, IE stinks, and the fewer people who use it, the better; bad because now we have to design web pages for a browser that we don’t have access to (not to mention, all the annoying little quirks). So how do you preview your site in IE. Three options: 1. Aside from shelling out for BootCamp or Fusion, at Mike’s Massive Mess you can download ie4osX with Darwine for Intel macs. If you don’t have an Intel mac things get a bit more difficult. You can either try downloading Q at opensourcemac.org or use the IE Net Renderer. This is an awesome site because you can render your pages in multiple versions of IE.

Well that’s all for now. Anyone that can add to my list is welcome to post..

]]> http://benvalentine.info/web-development/recommended-applications-for-mac-web-developers/feed 0 http://benvalentine.info/web-development/embedding-a-blog-into-a-pre-existing-site http://benvalentine.info/web-development/embedding-a-blog-into-a-pre-existing-site#comments Fri, 18 Sep 2009 19:23:09 +0000 admin http://localhost:8888/benvalentine/blog/?p=8 Read more »]]> In this entry, I’ll demonstrate some useful tips on how to embed a blog into pre-existing website. Before, we begin I’ll assume two things: that you know at least a little bit of PHP and that have already installed WordPress in your website.

The first you’ll want to do is choose one of the themes that WordPress comes packaged with. There are two, Classic and Default (or Kubrick). I usually choose Classic because it makes things a lot simpler and also for the sake of this tutorial, quicker. Once you have chosen the theme you want to use, copy it and rename it something like “sitetheme”. This is an optional step, however, it will save you some aggravation if you decide to change layouts in the future. Open “style.css” and change the theme name to : “sitetheme” on the first line. You may want to change a few other details as well. Login to the admin panel and select “sitetheme” as your theme (in the panel under Appearance > Themes) and your ready to begin.

What I usually do first is open “header.php” at the top of the page I create a constant called ‘BASE_HREF’ that contains a link pointing back to the main site. If you are working on a local machine before you move to the server, you may want to include some flow control. For instance:

$server = $_SERVER['SERVER_NAME'];
$base = (strstr($server, "localhost")) ? "http://localhost:8888/mysite/" : "http://mysite.com/";
define("BASE_HREF", $base);

Next thing you’ll wanna do is create a base tag. The base tag should be placed in the header and is going to make sure that your menu links point back to the pages on your website. Our constant variable, “BASE_HREF” makes it easy for us:

<base href="<?php BASE_HREF; ?>">

Now onto styling. What I usually do is create a new file called blog.php in the css file in my main website and another file called blog.css. I copy all the styles from style.css and paste them into blog.css, making sure to leave the commented text at the top. Then in “blog.php”, I’ll require all the stylesheets that I need to make the blog layout work.

<?php
header("Content-type: text/css; charset: UTF-8");
require_once('layout.css');
require_once('typography.css');
require_once('nav.css');
require_once('blog.css');
?>

If we go back to “header.php”, we can create an absolute link to the stylesheet with our constant, it will link to our site layout plus add the styles from the ‘classic template’. But, if you view the blog, things will probably still look pretty cockeyed. Reason being, we haven’t changed the HTML yet. Copy the HTML below the body tag from your site’s “header.php” file and paste it into the template’s “header.php”. Do the same with the footer.:

It will probably take some tweaking in ‘blog.css’ to get eveything to line up properly. But there’s a simple way to do this. I start by commenting out the entire file, so you can see what everything looks like without the theme’s stylesheet added in. Then gradually start commenting things in as you tweak the design.

Hope this was a helpful tutorial and saved you a bit of time in the long run!

]]> http://benvalentine.info/web-development/embedding-a-blog-into-a-pre-existing-site/feed 0