Bitcss - a centralized CSS repository powered by github

Maybe a simpler approach would be building a library of Twitter Bootstrap themes, since Bootstrap is already used across a lot of sites, covers most UI elements, and their markup is pretty standard.

Some might think it's stupid or impossible, but I don't think so. How many simple header/2 columns/footer websites are they? Why are they all differently constructed.. Some uses #contents, others #main-container, others #wrapper, others #wrap, etc etc.

With a great specification for common patterns, it would be possible to document a HTML document by saying, for instance, this page respect the design #18. By that, you could clearly see the doc and it'd show a clear header/3 columns/footer page with all ids and classes used.

It'd make it easier for designers to submit design for project (Think Zen Css for instance). A css could be shared with different websites that use the same 'patterns'.

Think a little bit like the Gammas pattern; some love them, some have them, but we can't deny their usefulness when communicating or documenting a page. For instance, it's way easier to say: I've used the visitor and composite pattern for this tree of blabla rather than describing all the inner details. (Please, don't reply how Gamma patterns are in fact anti-patterns or lack of features of the language, I'm just stating that as example as what I mean by protocol, interface or pattern.)

Finally, it would just plainly make html, css (and maybe even Javascript) code less randomly hacked and easier to maintain. It'll be even easier for beginners to get started. (Take the html code of the pattern #18 and choose a css file from the list associated to the #18) - Dang, a righly constructed 3 columns html page, compliant which work out of the box.

First, add an additional requirement to contributing--require each sub folder to the project contain a manifest (json format) that describes some key information about the contribution: [{ author: 'giberson', name: 'pixel button', descripton: 'classic pixel outlined button', template: pbutton.html, stylesheet: 'pbutton.css', type: 'layout|widget', version: 1 }]

Second, actually build a site similar in functionality to Google's font site, the content generated by parsing the main trunk contribution folders. (see http://www.google.com/webfonts)

This way users can browse the contributed content with inline examples.

You can also provide the user with a "quick use" button that produces the stylesheet href link, and the html code to insert into their page to use the style.

Notes on the manifest entries:

The main object of the manifest is an array, allowing for multiple components to be housed in a single contribution folder.

"template" is the html markup to be styled via css.

"stylesheet" is the stylesheet to be included by the page.

"type" is either layout or widget to represent if the styling/template are meant to replace your html or be inserted into it. Which will help the directory site determine best method to display preview, via an inline div or a popup div or some other creative mechanism.

"version" represents the manifest version, it allows you to upgrade the site and filter out contributions that have been updated with new required/optional manifest field properties or formats to work with new site features.

I've come to the conclusion that a project like this would only be successful if contributors are expected to document WHY the code used is written as it is.

Without documentation (an example UI style guide, like the homepage of Twitter Bootstrap) it's difficult to see both the big picture and the purpose of the small details.

Twitter Bootstrap had a great home page right from the start – it served as documentation for the project, as well as a marketing demo influencing you to try it.

So imagine if the contributors to your repo were simply asked to follow a few guidelines, documenting their contributions (say, providing example HTML and using KSS to markup their CSS).

https://github.com/kneath/kss

http://www.alistapart.com/articles/writingainterfacestylegui... http://www.engineyard.com/blog/2011/front-end-maintainabilit...

Maybe ask them to follow a few of the "Object Oriented CSS" principles, so that it's easier to mix and match parts from different folders:

https://github.com/stubbornella/oocss/wiki

Principles of separating the "structure" from the skin"; and separating "container" from "content".

I would be more interested in a webservice to serve up common UI elements including html and css. I propose this would be based off something like backbone views, and Handlebars templates.

[0] http://foundation.zurb.com/