Add Date Greater Than validation to jQuery.Validate

This method adds date or number greater than validation to jQuery.Validation plugin.
From: http://stackoverflow.com/questions/833997/end-date-greater-than-start-date-jquery-validation
 
jQuery.validator.addMethod("greaterThan", function (value, element, params) {
 
            if (!/Invalid|NaN/.test(new Date(value))) {
                return new Date(value) > new Date($(params).val());
            }
            return isNaN(value) && isNaN($(params).val()) || (parseFloat(value) > parseFloat($(params).val()));
        }, 'Must be greater than {0}.');

My Best Practices for Writing web Applications

A few people have asked me what patterns do I use when developing web applications so I figured I would take a few minutes to write them down. Please note that these are the practices I have found work great for me. Warning: one size does not fit all

First let me say that I’m a pragmatist at heart, and I write software for a living, so I must find a balance between perfection, maintainability, and profitability.

I’m sure there are other people out there that have created their own development style that works very well for them, for me however, after using most of the shiny three letter patterns, I have found that these principles give me the best of both worlds, RAD development and a Maintainable application. And best of all they help me enjoy my job.

1. Hand Crafted Model

I use POCO objects as my model. These objects are hand crafted by me instead of being generated by a tool, and they are the foundation of my app.

2. No ORM

I do not use an ORM, but rather I use my own tool BigfootSQL. It gives me the best of worlds, complete control over my SQL while at the same time saving me from all the grunt work of object Hydration and query execution. I have been developing software for a while, and have fallen victim to the Microsoft fascination with changing data access technologies with almost every release. My strategy is to try to stay as close to SQL as possible while minimizing the manual work, BigfootSQL does this for me.

3. Operation based validation

I validate at the point of the operation execution, rather than performing model based validation. When validation must be shared across operations then a validation helper is employed in order to share this logic. Models rarely if ever are validated in a vacuum, validation changes depending on the type of operation being performed and depending on more than a single model object. Operation validation on the other hand, validates at the operation end, it simply looks at what the action itself is, and validates the action. This way you can effectively and simply validate against multiple types of operations against your object model while keeping your validation and business rules simple. It also keeps you from writing validation code that you won’t use. To achieve this, I use a modified version of TNValidate. TNValidate is an open source fluid interface style validation framework that makes validating my objects extremely simple. I’ve repackaged my modified version of TNValidate into BigfootSQL. I also use a set of Post helper methods that help me retrieve the values from a post while providing simple type validation and required validation. You can find my PostHelper class in my open source project BigfootMVC, this is an ongoing compilation of helper methods I use for MVC style development. I use these helpers when developing for classic ASP.NET, ASP.NET MVC, and DotNetNuke module applications.

4. Highly specific and smart ViewModel

For every view, I create a ViewModel whose job it is to handle all data requirements and operations for the view. These VMs are smart and self aware, they have static factory methods for creating themselves, and also handle all view operations which get executed by the Controller. They talk to the Repository to get data and execute operations against the Database. They help me keep my controllers thin by delegating a lot of the operations responsibility closer to where the action is.

5. No IoC container

It is ok to take a dependency on your own code. Most of of the time we find ourselves using IoC simply for the reason of making our code testable. Instead of adding complexity to the code to make it testable, I use a smart mocking framework that allows me to effectively mock any kind of dependency without having to use the IoC pattern, I use JustMock by Telerik. This allows me to write my applications in a much simpler way while still keeping them completely testable. I know this is a religious topic for a lot of people, however in my experience, after using several IoC containers, you are simply adding undue complexity to 90% of your apps. I do acknowledge there is a 10% that need it, all I’m saying is, use it where required, be a craftsman, use the right tool for the right job.

6. Highly Helped Views

I have developed a set of Html helpers that allow me to perform most view operations, including complex ajax operations, in a very simple way. They help me be extremely productive while creating highly responsive web interfaces. As a developer of some experience with web development, highly responsive (ajax) web interfaces and productivity do not always go hand in hand. I set out to develop a rich set of helpers that allow me to perform the 80% case scenarios with one line or less of strongly typed code. I open sourced all of these helpers under my ongoing BigfootMVC project.

7. Take a dependency on JavaScript

For web applications, I take a dependency on JavaScript. This allows me to deal with older less capable browsers much more efficiently. While not all sites can do this, most applications are safe to take a dependency on JavaScript. I also use a strong master page that helps me deal with the browser differences. I use jQuery, Selectivizr, and a few other tricks to make working with IE6 and other non CSS3 HTML5 browsers much easier and less painful.

8. Strong CSS reset with a rich set of helper classes

I have published the CSS framework that I use, BigfootCSS, it is a compilation of best practices I have found around the web published by really smart people like Eric Meyer, Paul Irish, and a few others. I have also loaded it with a lot of helper classes that I use over and over again in more utilitarian application interfaces. For me it provides a good middle ground between inline styles and 100% custom CSS. I reserve the use of custom CSS classes in my design for what is truly custom, and use helper classes for the common operations.

 

Summary

If I had to sum up my strategy in one word – or one acronym rather – I would say “KISS”. Above all keep it simple, that is the secret to productivity and maintainability.

So that’s it really, a few simple no non-sense principles that make my life easier when it comes to developing web applications.

Hope this helps!

Mitch

How to load jQuery from within your DotNetNuke module safely

If you are writing a module for DotNetNuke that depends on jQuery, you must find a reliable way to make sure jQuery is loaded. Furthermore, you must make sure the right version of jQuery is loaded and must also ensure the rest of the DNN installation is not affected. Here is how you can do that.

Goals:

1. Detect whether jQuery is installed

2. Determine whether the right version of jQuery is installed. I will use 1.4.2 as my base.

3. Make sure to not cause conflict with other libraries that might be using the $ variable

 

Code:

<script type=”text/javascript”>

    // Check whether jquery 1.4.2 or greater is loaded
    var loadJQuery = (typeof (jQuery) == 'undefined' || 
                jQuery().jquery < "1.4.2");

    // Add a marker to invoke no conflict when the $ 
    //    is mapped to a library other than jQuery
    var callNoConflict = (typeof ($) != 'undefined' 
                && typeof (jQuery) == 'undefined')

    if (loadJQuery) {

        var filename= ‘your path to the jquery file’;
        var fileref=document.createElement('script');
        fileref.setAttribute("type","text/javascript");
        fileref.setAttribute("src", filename);
        document.getElementsByTagName("head")[0].appendChild(fileref);

    }

    if (callNoConflict) {
        jQuery(function(){
            jQuery.noConflict();
        });
    }

</script>

 

Will Strohl has put together a great article on the best practices for using jQuery within DNN

How to change the way jQuery.validate handles error messages

I use the jQuery.validate plugin to handle most of my html form validation. This is by far the most widely used jQuery plugin for form validation. To reinforce the importance and quality of this plugin a bit more, Microsoft recently announced that they were dropping their own validation implementation in favor of jQuery.Validate for ASP.NET MVC 3. This plug-in is really outstanding, but best of all it is incredibly simple to customize.

Right, so the the topic of this post. Whenever an element being validated by jQuery.Validate in your page is found to be invalid, jQuery.validate  – referred to as “VAL” from now on – adds a label element next to it showing the error message for the particular validation being performed. This is fine for most situations, however sometimes you need to handle scenarios where the default placement of the error message is not quite right. The creators of VAL anticipated this and provided several built-in ways to customize this behavior with just a little bit of effort. These are the three scenarios I find myself using most often:

Scenario 1: I want to show all my error messages inside a single error container as a UL element

                   $("#addEventForm").validate({
                            errorContainer: "#errorContainer",
                            errorLabelContainer: "#errorContainer",
                            errorElement: "li”

                     })

errorContainer : is a space separated list of element ids that will be shown when the form is invalid and hidden when the form is valid.

errorLabelContainer : this is the id (or any jquery selector string) of the element that will contain the error labels generated for each invalid field

errorElement : by default the error element generated by VAL is a label control. If your container is a UL then you can set this variable to “li” in order to generate LI elements instead of label elements.

 

Scenario 2: I want to show the error control before the field it is validating rather than after it (which is the default location)

 

                    $("#addEventForm").validate({
                            errorPlacement: function (error, element) {
                                error.insertBefore(element);   
                             }          
                        })

errorPlacement: is the function that is called by VAL to inject the error element into the DOM. By overriding this function we are able to place it anywhere we want. Both the error and element parameters passed into the function are jQuery objects. Sky is the limit as to what you can do here.

 

Scenario 3: I have a form with two input fields, first name and last name. They are located next to each other, and they are both required. When either one of these fields is empty I want to show the error label generated by VAL inside a div element named “nameError” which is placed bellow the two input controls.

To do this we are going to use the same trick as in scenario 2 except that we are going to inspect the name of the invalid element being passed into the errorPlacement function and do a custom injection of the error message for just the first and last name. For all other errors we do the default, which is append the error label next to the invalid input control.

                    ("#addEventForm").validate({
                            errorPlacement: function (error, element) {
                                     if (element.attr(“name”) == “fname” || element.attr(“name”) == “lname”)
                                            $(“#nameError”).append(error);
                                     else
                                             error.insertAfter(element);
                             }          
                        })

 

That’s it!

Enjoy!

HtmlDirect: A DotNetNuke module that outputs the content of an html file to the page

A few weeks back I blogged about wanting to create a module that would simply output the contents of an html file. After watching Will Morgenweck video on how to create a simple one page module in DotNetNuke 5.5 – an awesome feature by the way – I had the idea to do the same thing for the HtmlDirect module. It should be a simple enough module, and it can be done in a single page. So here we go:

This is the workflow I want to use when editing this static html content to be included in my portal:

1. Open my favorite html editor

2. Create a new html file and write some cool / mean / clean html code

3. Reference some special css and js files if I want to

4. Upload it to my site

5. Add the html direct module, point it to the file and that’s it.

Editing is now simply opening the html file, editing it and republishing it. Rinse and repeat

 

Overview:

1. Create a new module through the DNN interface

2. Edit the View.ascx file that gets created automatically, to render the file named in the module settings

3. Create an editor to edit the fileName module setting. This must be done in the same page. So I’ll show it when the module is editable, and hide it when it is not.

 

Here is a video that shows the process, and you can download the source packaged module bellow.

DNNRecording

 

Code:

   1: <%@ Control Language="C#" Inherits="DotNetNuke.Entities.Modules.PortalModuleBase" %>

   2: <%@ Import Namespace="System.IO" %>

   3: <%@ Import Namespace="DotNetNuke.Entities.Modules" %>

   4:  

   5: <script runat="server">

   6:     

   7:     protected void Page_Load(object sender, EventArgs e)

   8:     {

   9:         // Render the file

  10:         RenderFile((string)Settings["fileName"]);

  11:         

  12:         // Show the editor

  13:         if (IsEditable && !IsPostBack)

  14:         {

  15:             fileNameDiv.Visible = true;

  16:             fileName.Text = (string)Settings["fileName"];

  17:         }

  18:     }

  19:  

  20:     // Render the html file

  21:     private void RenderFile(string renderFileName)

  22:     {

  23:         try 

  24:         {

  25:             if (!string.IsNullOrEmpty(renderFileName))

  26:             {

  27:                 // Strip off the initial slash if any

  28:                 if (renderFileName.StartsWith("/") || renderFileName.StartsWith("\\")) 

  29:                     renderFileName = renderFileName.Substring(1);

  30:                 

  31:                 // convert into a physical path

  32:                 renderFileName = "~/portals/" + PortalId + "/" + renderFileName;

  33:                 

  34:                 // render the text of the file

  35:                 fileContent.Text = File.OpenText(Server.MapPath(renderFileName)).ReadToEnd();

  36:             }

  37:         }

  38:         catch (Exception ex)

  39:         {

  40:             fileContent.Text = (IsEditable) ? ex.ToString() : "Error displaying module content. Unable to find file!";

  41:         }

  42:     }

  43:  

  44:  

  45:     // This changes the rendered file to a new file and saves in the module settings

  46:     private void SaveFileNameButton_Click(object sender, EventArgs e)

  47:     {

  48:         ModuleController objModules = new ModuleController();

  49:         objModules.UpdateTabModuleSetting(TabModuleId, "fileName", fileName.Text);

  50:         RenderFile(fileName.Text);

  51:     }

  52:     

  53: </script>

  54:  

  55:  

  56: <%--Edit the file name--%>

  57: <div runat="server" id="fileNameDiv" visible="false">

  58:     File Name <br /> 

  59:     (i.e. HomePageFiles/Content.htm where "HomePageFiles" is a folder at the root of the portal): <br />

  60:     <asp:TextBox runat="server" ID="fileName" width="100%"></asp:TextBox> <br />

  61:     <asp:Button runat="server" ID="saveFileNameButton" Text="Save File" OnClick="SaveFileNameButton_Click" /> <br />

  62:     <br /><br /> 

  63: </div>

  64:  

  65:  

  66: <%--Placeholder for the html content--%>

  67: <asp:Literal runat="server" ID="fileContent"></asp:Literal>

  68:  

  69:  

 

You can download the packaged module here

http://cdn.mitmar.com/HtmlDirect_01.00.00_Install.zip

DotNetNuke *must* hit reset on Design

Let me start by saying that I love DotNetNuke! I believe it to be the most powerful CMS in the market from both a 3rd party support perspective as well as from a developer perspective. I am however dumbfounded by the atrocious design decisions made on the main DNN site. I’m not a designer, I’m a developer, however even to me, a non-designer, it is absolutely obvious that DNN Corp must hit reset on their site’s design.

Rather than just complaining about it, I figured I would do a bit of constructive criticism. We are going to look at the blog post page. I got there by clicking a link on Twitter by Joe Brinkman. My main objective is to read the blog post and move on.

DNN_BlogPage

Use Case: Read the blog post

  1. First I’m overwhelmed by everything going on in the page. The actual content of the blog post – higlighted in green – is deemphasized to the point that I have to hunt for it. Let’s not forget that the post is the reason I’m here, it is the main point of the page.
  2. One third of the page fold is taken up by irrelevant data to the use case. The header menu must be deemphasized. It should not take 1/3rd of the page fold.
  3. The left pane content should be completely removed. I came to the page to read the blog post, I don’t need to search for it, or care about the blog roll, this would be great for the landing page of the blogs section but not here. This page should be all about reading the post content.
  4. Yes, I know it is a blog post that’s why I’m here is there a particular reason why "DNN Blog" must me more prominent than the actual blog post title?
  5. The actual post content font, again the main point of the page, is small and does not have enough line height to make it easy to read.

Result: Joe’s *great* post has been relegated to the last position of visual importance in the page.

Here are a few sites that get it right:

In everyone of these instances the most important emphasis in the design is given to the content, as it should be, everything else is noise. Notice how they all have other things going on in the page, but nothing takes precedence over the post content.

The chrome is not as important as the content!

 

wordpress

snappages

37signals

rubyonrails

Sitefinity

twitter

umbraco

BigfootCSS, my CSS bag of tricks

BigfootCSS_Logo_whitebg

BigfootCSS is a 22k uncompressed / 6k compressed CSS stylesheet that can be used to aid you in the styling of your web pages. It is a collection of real world CSS classes, box model fixes, generic classes for various common styles, standard Ad sizes, and a solid browser reset based on Eric Meyer’s CSS reset. It can be applied to the whole page, or it can simply be applied to a particular element within the page and its children. This latter option is very useful for CMS module development as it makes it easy to style just your module without being affected by or affecting the host page.

If you have written a module that sits inside of DotNetNuke, WordPress, Jumla, etc. you know what I mean. You can’t control the skin in which your module runs, but you have to provide a reasonable amount of protection to ensure the proper layout of your module. You must also be a good citizen of the ecosystem and not allow your styles to bleed into the rest of the skin. BigfootCSS solves this problem very easily by only targeting elements with a certain id.

Why?

 

Over the years I have used a number of CSS frameworks. In them I found a lot of good techniques, and others… well not so great. So I started creating my own CSS bag of tricks, I’m not sure I would call it a framework, but rather a collection of real world CSS classes, hacks, and fixes. Most of the tools in this toolbox come from everything I’ve liked about the other frameworks I’ve used, most of the credit goes the guys that have figure out the different hacks to fix the IE box model, to create a proper reset, etc. I’ve lovingly named this compilation of ideas bigfootCSS.

Context in which I use bigfootCSS:

 

1. I’m a developer creating business apps, not just websites. A lot of the utility classes found in the framework – for lack of a better word – are meant to aid in the utilitarian way in which business applications are styled.

2. I dislike inline styles, but do not mind a composition of classes to achieve a certain result. This is a good middle ground between a completely custom rule for the element and inline styles.

3. I reserve the creation of custom styles for the elements that truly are unique in your project. For example I don’t like to reinvent the wheel when doing grid layouts. I have a solid grid system that is tested across browsers.

4. I’ve said this before, but it bears repeating I’m a developer, not a designer.  This is a framework that has worked for me in my projects. It is not 100% perfect or bug free. For the 10% outlier, I simply write custom CSS to cover these use cases.

What’s in it?

 

A browser reset

I believe Eric Meyer’s is the best and longest standing browser reset out there. For you who are not familiar with browser resets, the short of it is, that every browser before they apply your styles, the browser’s default stylesheet gets applied, and it creates the base set of styles for the the page. Trouble is, every browser has a slightly different base style, which makes your design vary from browser to browser based on the inherited base style. To counter this, you can create a reset if you will, which neutralizes all default browser styling and creates a baseline which is the same across all your browsers.

Baseline

Once you have run a browser reset, you have created a consistent baseline accross all browsers by removing all (almost) styles, but now you don’t have any defaults. The baseline serves the purpose of creating a default look for the common elements like heading tags, paragraphs, etc.

Fix for IE box model. The clearfix hack

The clearfix hack is used in order to clear floated elements. While this should be a straightforward procedure, IE makes it very challenging, as is with most other issues in IE, it implements the html spec slightly different from other browsers. The included clearfix hack, fixes all these inconsistencies and renders correctly across IE5.5+ as well as Firefox, Chrome, Safari, Opera. See this article for a clear description of the problem and it’s solutions.

The short of it is, if you have this markup, if you are floating elements inside a container, all you have to do is apply the clearfix class to the parent container and all floated children will behave correctly. for example:

   1: <div class="clearfix">

   2:     <div class="fl">fl = Float left</div>

   3:     <div class="fr">fr = Float right</div>

   4: </div>

 

Type

As part of the baseline, it creates a base type setting which is as follows:

   1: {

   2:     font-family:Segoe UI,Arial,Verdana,Helvetica,sans-serif;

   3:     font-size: 12px;

   4:     text-align:left;

   5: }

This works well in most browsers, and while I understand the shortcomings of pixel based font sizes, it just works, like I’ve said before for the cases where this does not fit, then use a custom classes, or change the default.

There is also standard sizes represented by classes. Theses classes correctly fix the problem of being overridden by element direct styling typical in a, input, td, select, and textarea tags. When you assign one of these classes to any element, it insures that it takes precedence.

s = small (13px)

xs = extra small (10px)

xxs = extra extra small (9px)

m = medium (16px)

l = large (19px)

xl =extra large (24px)

xxl = extra extra large (32px)

Floats

To float elements left or right simply apply these classes to the element. Remember to wrap them with a container that has the clearfix class applied as in the example above.

fl = float left

fr = float right

Widths, Heights, Padding and Margins

I know that some of you will balk at the idea of classes with preset sizes, but before you decide to start hurling stones, remember what I said before, every class that is there, is there because I use it often and find it to simplify and speed up my development. Like I’ve said this is a good middle ground before custom css rules for everything, and inline styles (which are evil).

w{number} = Sets the width of the element to the {number} of pixels specified. for example w25, sets the width of the element to 25px.  Numbers from 1-10 are in 1 pixel increments, 10-200 are in 5 pixel increments and 200-600 are in 25 pixel increments and 600-980 are in 10 pixel increments. With the exception of the standard ad sizes as found here

wp{number} = Sets the width of the element in percentages of it’s parent’s size. 1-10 and 95-100 are in 1% increments, the reset are in 5% point increments.

h{number} = Sets the height of the element in pixels. Numbers from 1-31 are in 1 pixel increments, from 30-250 are in 5 pixel increments, 250-600 are in 10 pixel increments

m{number} = Sets the margin for an element to the specified number. Numbers from 1-10 are in 1 pixel increments, 10-50 are in 5 pixel increments.

mt{number} , mr{number}, mb{number}, ml{number} = Sets the margin-[top, right, bottom, left] correspondingly. Numbers from 1-10 are in 1 pixel increments, 10-50 are in 5 pixel increments.

p{number} = Sets the padding for an element to the specified number. Numbers from 1-10 are in 1 pixel increments, 10-50 are in 5 pixel increments.

pt{number} , pr{number}, pb{number}, pl{number} = Sets the padding-[top, right, bottom, left] correspondingly. Numbers from 1-10 are in 1 pixel increments, 10-50 are in 5 pixel increments.

Colors and Backgrounds

These are particularly useful in application development, as you often want to change the color or background to a preset set of colors, but it is not imperative that you be extremely precise with the color as you would with the palette of a hand crafted site. In these cases having some preset colors greatly improves the consistency and speed with which you can achieve relevance through design in your applications.

bg{color} = stands for background-color and then the color specified. colors included are: white, black, light, dark, hl (which means highlight, sets the background to a light yellow), the colors are as described by their name.

black, white, red, xdard, dark, light, xlight = Sets the color css attribute of elements (including overriding the anchor tag color if applied to an anchor) to the appropriate color.

Display and Position

 

hide = sets the display property of the element to none

block = sets the display property of the element to block

inline = sets the display property of the element to inline

inlineb = sets the display property of the element to inline-block

prel = sets the position to relative

pabs = sets the position to absolute

pfixed = sets the position to fixed

pstatic = sets the position to static

Text alignment

 

tr = text-align: right

tl = text-align: left

tc = text-align: center

tj = text-align: justify

tvt = vertical-align: top

tvc = vertical-align: middle

tvb = vertical-align: bottom

Grid

 

The grid is loosely based on the 960 fluid grid. It basically implements a 16 column grid that uses percentages. I use percentages because it is particularly useful to include in other containers that might not be necessarily the whole page. For instance you can apply the grid to just a div element within your page, and it will divide that element into 16 equal columns using percentages. Particularly useful when using the the system for styling a module.

Best to way to show it is to show you some code:

   1: <!--You apply the grid to an element by adding the g16 class to it-->

   2: <div class="g16">

   3:     <div class="gc5 firstc">

   4:         This takes 5 of the sixteen columns and marks it as the first column with the firstc class,

   5:         the firstc class kills the left gutter space for this column

   6:     </div>

   7:     <div class="gc3">

   8:         Yet another column taking another 3/16 of the space

   9:     </div>

  10:     <div class="gc8 lastc">

  11:         Another column taking the ramining 8/16 space in the grid.

  12:         lastc class marks the column as the last in the grid and kills the right gutter

  13:     </div>

  14: 

  15: 

  16:     <!-- This clears the previous columns, but you only have to

  17:          use when the next column is not a full column -->

  18:     <div class="clear"></div>

  19: 

  20:     <div class="gc16">

  21:         A full column does not have to be cleared or marked with the lastc and firstc classes

  22:     </div>

  23: 

  24: </div>

The grid is pretty simple really, just a way to evenly divide any container element into 16 equal columns.

Miscellaneous Classes

 

pointer = sets the cursor to be the pointer when the mouse is over this element

cnomal = sets the mouse cursor to the normal sate

b = set the font-weight to bold

fieldlabel = sets an element ot display lock and ad bottom padding of 3 pixels this is used on <label> elements that pertain to input controls

nowrap =adds text-whitespace: nowrap

strike = adds text-decoration: line-through

cmd = used on anchor tag to make them small red and bold as it it were a command rather than just a simple link. { font-size: 10px; font-weight:bold; color:red; }

hlist = makes an unordered list’s <ul> elements display inline and horizotally, useful when creating menu and other horizontal use of <ul>

tablemin = turns a properly formatted table (one that uses the <thead> <th> and <tbody> elements) into an instance nicely displayed one by adding formatting to it in a very simplistic style

error = When applied to an element it turns it’s color red, and sets the font and font size to display as an error. Useful in applications when you want to visibly adorn an invalid input.

What about partial page styling (CMS mode)

I also created an alternative CSS stylesheet, BigfootWeb_Module.css, which would be referenced instead of BigfootWeb.css. It contains all of the same classes and styles, except they are only applied to the element in your page named bfbox.

Also by default the browser reset is not applied unless you specifically also add the reset class to the bfbox element. That’s it, very simply really. A quick example:

   1: <div>

   2:     This some other page content, not affected by bigfootCSS.

   3:     bigfootCSS rules do not apply here.

   4: </div>

   5: 

   6: <div id="bfbox" class="reset">

   7:     All elements inside this box are now under the bigfootCSS reset, and baseline

   8:     as well as all css classes and rules would apply to all children of this element

   9: </div>

  10: 

  11: <div>

  12:     Back to the page, again not affected by bigfootCSS.

  13: </div>

 

Please not that if you don’t want the browser reset portion to apply to your bfbox container, simply don’t apply the reset class. This will allow you to inherit all the CSS rules from your skin / page while still being able to take advantage of most of the classes in the framework.

Putting it all together

You can now put these classes together to create a very fast and clean layout for your page without having to create custom CSS rules for everything.

For a more complete example please visit http://cdn.mitmar.com/bigfootcss/Main.html

Cheers!

Mitch

Follow

Get every new post delivered to your Inbox.