Sometimes the hardest part about a project is sitting down to organize your environment before you begin. Sure, you probably have several, maybe hundreds, of pieces of functional code stashed in your git repo or squirreled away in different folders on your hard drive, but starting a brand new project? Ugh! Enter the project sandbox.

Why a Project Sandbox?

Project sandboxes are templates designed for easy duplication that allow you to quickly create an ideal project environment. Pre-configured folder structures and file names optimized to your liking make launching a new project as easy as duplicating a template and making a tweak to the new project’s server config file.

Similar to regular sandboxes – also known as development servers – project sandboxes isolate projects to a well-defined structure, preventing code pollution. The key difference is Sandboxes are usually designed for developing within an existing code base protected by a code repository. Project sandboxes, however, exist only to help start new and potentially disposable development in a reliable way.

Naming schemes

Regarding naming schemes: the word of the day is CONSISTENCY. Name your project sandbox files anything you like and commit to your scheme. When you find a better naming method (and you will), retrofit your project sandbox right away – don’t put it off! Using consistent file names will build strong mental associations that help you decide where to put certain code.

My project sandbox files:

• main.js
• main.css
• index.html

Some file stubs (files that exist without any content) I like keeping handy to handle RWD needs, or to load AMD formatted scripts, respectively:

• responsive.css
• requireLoader.js

Being Flexible

Flexibility in terms of a project sandbox means keeping a variety of battle tested and carefully vetted resources at your finger tips, not all of which you may need for every project. Some resources should be configured to load by default, while others (like frameworks) are kept out of the loading stack.

Some of my core resources:

General Tools

• Modernizr (good for detecting CSS3 / HTML5 compatibility in older browsers, affords better Progressive Enhancement – load by default)
• HTML5 Boilerplate: Homepage (designed for easy tweaking – load by default)
• HTML5 Boilerplate: github
• Bootstrap (load by default)

Asynchronous Resource Loaders

• RequireJS
• yepnopejs (bundled with Modernizr)

JS MVC Frameworks

• AngularJS
• Backbone
• Ember.js

JS Libraries

• Underscore.js
• jQuery (keep a couple of versions handy – load one by default)
• Zepto.js (lighter weight than jQuery, better for mobile devices)
• [Your Favorite jQuery Plug-ins Here]

CDN vs Locally Stored Resources

Should you use a CDN or keep your toolkit stored locally? I prefer using local files. Staying local removes a layer of potential complexity (not relying on a file that probably stays the same), improves performance, and keeps resource files readily available for dissection. That said, CDNs are extremely valuable in many other situations.

However, using local resources means you must manually keep your project sandbox current. Get into the habit of watching for updates, reading release notes, and making informed decisions about updating your resources. Broken and dull tools are even worse than no tool at all!

Folder Organization

Folder organization depends largely on your web server and middle tier language of choice. Discussing the best ways to organize folders for different servers and languages could be a cool topic for another day.

Since I use Node.js my project sandbox folder structure is pretty simple, as demonstrated below.

• WEBROOT
  • TEMPLATE (this is your Project Sandbox – copy and paste at will!)
    • startServer.js (the Project Sandbox config file)
    • PUBLIC
      • index.html
      • JS
        • main.js
        • requireLoader.js
      • CSS
        • main.css
        • responsive.css
      • FONTS
      • IMG
  • RESOURCES (libraries, frameworks, often used assets – only one copy necessary)
    • JS
      • LIBRARIES
        • jQuery (development and minified versions)
        • JQUERY PLUG-INS
          • [your favorite plug-ins here]
        • Zepto.js
        • Underscore.js
      • LOADERS
        • RequireJS
        • Modernizr (includes yepnope.js)
      • FRAMEWORKS
        • AngularJS
        • Backbone
        • Ember.js
    • CSS
      • FRAMEWORKS
        • Bootstrap
    • FONTS
      • [non-web fonts used often go here]
    • IMG
      • [logos, backgrounds, etc – include only if used frequently]

Of course, this is only a start! Your project sandbox can be tailored in any way you see fit and will change over time. The important lessons are: make one, keep it consistent, keep it current.

Good luck, and please comment with any suggestions. And as always, thank you for reading!

The conventional approach to detecting screen resolution with JavaScript using RWD requires you to duplicate break points within your actual code and consequently having to maintain them in two different places. Very annoying. Using a flag embedded in each of your CSS break points is a much simpler approach because they can be programmatically accessed. Multiple flag techniques exist, but in this blog post I will discuss my personal favorite, the pseudo-element flag, invented in 2012 by Jeremy Keith and the readers of his blog adactio.

Pseudo-elements?

Pseudo-elements exist in an odd realm. Technically they are not part of the DOM, so they cannot be accessed via traditional selectors nor participate in regular DOM flow. Pseudo-elements, and their cousins, pseudo-classes, are CSS constructions that afford some interesting presentation options. We have all used pseudo-classes before, such as :hover, :focus, and :first-child. Pseudo-elements are used in a very similar way, but not quite as often.

The relationship between real elements and their pseudo-element counterparts:

Element and Pseudo-element relationship

Image Source: Nicolas Gallagher, blog entry Multiple Backgrounds and Borders with CSS 2.1 (original image revised by me to remove some copy not topical to this blog entry, and to trim it down to size).

In fact, pseudo-elements are not new – CSS1 introduced :first-line and :first-letter. CSS2 saw the arrival of :before and :after, and CSS3 has introduced the newest member of the team, ::selection. As a quick side note, CSS3 spec suggests we use double colons (::) when using pseudo-elements, to differentiate them from pseudo-classes, which use the single colon (:). However backward compatibility within browsers ensures the single colon works for both cases, and from a practical standpoint it’s probably best to still use the single colon for now.

The :before and :after pseudo-elements, having been around for many years, are in fact backward compatible all the way to IE8 (not that modern Android or iPhone users care – but it’s still good to know). The caveat however is that the HTML5 document type declaration must be used, or IE8 will poop the bed and forget everything it learned.

Building the Pseudo-Element Flag

While other techniques probably exist, the way I implement pseudo-element flags is to differentiate one at each break point. Therefore, the values contained within each set of CSS rules for each independent flag remain constant. For this reason I like to attach the flag to a relatively safe, static element, the body itself.

body:after{ }

As CSS constructs pseudo-elements enjoy CSS rules not available to conventional DOM objects. One in particular is in fact the secret in our secret sauce:

body:after{
content:"mobile";
}

To ensure the content is not actually displayed we’ll add the final piece:

body:after{
content:"mobile";
display:none;
}

Accessing the Pseudo-Element via JS

Okay so, if a pseudo-element is not part of the actual DOM, how can we access it – or more to the point, the CSS rules defined for it? The answer:

window.getComputedStyle()

This sweet method returns the CSS styles applied to an element and the corresponding pseudo-elements, after the browser has finished applying them. Nifty right?

function whatIsMySize() { return window.getComputedStyle(document.body,':after').getPropertyValue('content'); }

Now you have access to the value of the content property of your pseudo-element. Nice!

Last note: Firefox (maybe others, I haven’t tested them all) will return an extra set of quotes if your content value was a string. So, in the example above, Firefox would return:

""mobile""

Thus for conditionals I like to use:

var checkMySize = whatIsMySize();
if ( checkMySize.indexOf("mobile") != -1 ) { // off to the races }

Thanks for reading!