A One Web Boilerplate for all your Responsive Web needs. Powered by Apache SSI, SMACSS, Sass and RequireJS. Also includes Ant build script with several useful tools, as well as an SSI-based fork of adactio's Pattern-Primer (https://github.com/akikoo/Pattern-Primer).
The One Web Front-end Boilerplate is a modular framework for building responsive websites with Apache Server Side Includes (http://httpd.apache.org/docs/2.2/howto/ssi.html), SMACSS (Scalable and Modular Architecture for CSS, http://smacss.com/), Sass preprocessor (http://sass-lang.com/), and RequireJS (http://requirejs.org/).
Demo: Optimized Styleguide Page: http://akikoo.github.com/one-web-boilerplate/publish/html-compressed/pages/styleguide/index.html.
This boilerplate draws code from many other projects, combining various solutions into a custom, modular, and responsive front-end build framework. It's packed with goodies, building on many of the industry best practices found in the resources listed under Credits. The project also includes Ant build script that runs code quality tools against JavaScript and CSS files, minifying and concatenating them at the end of the process.
The One Web Boilerplate works well for me which is why I'm publishing it here for you to use and improve. It basically extends popular boilerplates, including 320 and Up (https://github.com/malarkey/320andup/), HTML5 Boilerplate (http://html5boilerplate.com/), Mobile Boilerplate (http://html5boilerplate.com/mobile/), ZURB Foundation (http://foundation.zurb.com/), Twitter Bootstrap (http://twitter.github.com/bootstrap/), and many others, with Server Side Includes. The framework can easily be plugged into Continuous Integration solutions, such as Jenkins: http://jenkins-ci.org.
This framework doesn't include any grid. You decide how you build your site. However, if you need a grid, have a look at the Fluid Grid that supports both Sass (SCSS) and LESS CSS: http://akikoo.github.com/Fluid-Grid/. Sass/Compass is used by default, both in One Web Boilerplate and the Fluid Grid.
/build contains Ant build script and all the tools you need to make your frontend build. Common build properties are defined in /build/config/project.properties. There's also a folder called masterpage, which is used as a blueprint for creating new pages.
/webroot contains two subdirectories: /assets and /html.
/webroot/assets contains all the Sass and LESS files, stylesheets, JavaScript files and theme images.
/webroot/html contains all the HTML files, generated by Apache Server Side Includes. HTML properties are defined in /webroot/config.shtml.
Dev files are in /webroot/assets and /webroot/html. Optimised files are in /build/publish/assets and /build/publish/html.
Whether you're on Windows or Mac, you'll need the Java Development Kit (JDK) (at least version 1.4). You can download it here: http://www.oracle.com/technetwork/java/javase/downloads/index.html. If you're not sure which version of the JDK you have, run the command java -version in the terminal.
Download Apache Ant here (on Mac OSX it's usually already installed): http://ant.apache.org/bindownload.cgi. On Windows, it's probably best to extract the contents of the zip to C:\ant.
See this article for how to finish the installation on your platform: http://net.tutsplus.com/tutorials/other/automate-your-projects-with-apache-ant/ (see section Windows- and Mac-Specific Install Bits.)
To permit SSI on your server, see this article: http://httpd.apache.org/docs/2.2/howto/ssi.html
On OS X, you'll already have Ruby installed. On Windows, see http://rubyinstaller.org/downloads/. For installing Sass, see http://sass-lang.com/tutorial.html. For installing Compass, see http://compass-style.org/install/. You should use it, it's awesome.
All the other tools needed in the local build are in the tools folder.
After Apache Ant, SSI, Ruby, Sass and Compass setup, you need to do two more things to configure the build:
If you get the "java.lang.OutOfMemoryError: PermGen space" error during the build on OS X (I did), try running this in your terminal: export ANT_OPTS=-XX:MaxPermSize=256m
You should now be up and running with both the environment and the local build.
A CSS preprocessor, either Sass (http://sass-lang.com/), default option with Compass (http://compass-style.org/), or LESS (http://lesscss.org/) is used to compile the stylesheets. If you don't want to use a preprocessor, you can of course work with the CSS files directly. By default, it's assumed that you compile Sass or LESS files on your local machine, and let the build process do the CSSLint check on your generated CSS files. (There are tasks for Sass and LESS processing in /build/build.xml, namely <css.compile.sass /> and <css.compile.less /> macrodef calls, but they are commented out.) To compile CSS files on your local machine, type one of the following commands in the terminal (replace the '{pathtoworkingcopy}' with your local path):
a) using Sass: sass --watch /{pathtoworkingcopy}/webroot/assets/scss:/{pathtoworkingcopy}/webroot/assets/css
b) using Compass with Sass: compass watch /{pathtoworkingcopy}/webroot/assets
For more info, see Sass and Compass documentation.
Media Queries are based on 16px default font size and defined in ems. The framework is designed to be modular so you should split the rules into logical modules, and place the styles in /webroot/assets/scss/components/modules. For more info on how to categorize your CSS, see SMACSS: http://smacss.com/.
JavaScript should not be relied on for layout. That's why I've adopted a bulletproof solution from Nicholas Zakas and Tantek Çelik: http://www.nczonline.net/blog/2011/03/22/using-html5-semantic-elements-today/ and http://tantek.com/presentations/2010/11/html5-now/.
Don't use IDs in CSS selectors. Use classes, or ARIA landmark roles instead (referenced with CSS attribute selectors). See also http://oli.jp/2011/ids/.
Scalable and Modular Architecture for CSS (SMACSS, http://smacss.com/) is used by default. main.scss and main-ie.scss are the main stylesheets that @import all the common styles. Note that styles are @import-ed only for development. For production, the build script inlines and minifies styles in the same order that you @import-ed them. Nice, eh? But keep in mind that you have to @import the core styles (see above) before anything else.
Remember that if you work with Sass, you should only do changes in /webroot/assets/scss/ directory, as the files in /webroot/assets/css/ will obviously be the generated ones, rewritten on each save.
New stylesheets you create should be placed in /webroot/assets/scss/components/modules. Remember to add @import rules for any new styles. After the base styles, the order in which the module stylesheets are included should't matter (you write your styles carefully, right?) The idea is that module styles inherit only from base rules, not from other modules.
config.rb file in /assets is used for passing compile options to Compass. By default you don't need to touch that file. If you want to edit it, see Compass documentation.
This assumes you've set up the build, as explained in Build configuration.
Congratulations! You now have a brand new /build/publish directory that has the following four directories:
You can now deploy the site using your favourite Continuous Integration server. It could be Jenkins (http://jenkins-ci.org) or Bamboo (http://www.atlassian.com/software/bamboo/). You decide.
Please note that the earlier version of this framework that uses the Yahoo YUI compressor is tagged here: https://github.com/akikoo/one-web-boilerplate/tags. Nowadays I prefer this framework to use RequireJS with an optimizer that manages dependencies in a much easier way.
Another note: I prefer Sass preprocessor nowadays because it's more powerful (especially with Compass) and because it's actively maintained and developed. This means that I'm not anymore actively maintaining the LESS files in this framework. Just wanted to let you know. However do let me know if you have any LESS issues so I can try to fix them (I'd be more up for it if I knew someone out there was still using LESS with this framework...).
One more thing: you should obviously exclude /build/publish directory from version control because that directory is cleaned up and recreated on each build. No need to track changes to that.
Thanks and good luck!
There's no mobile, everything's mobile.