While this is a very interesting idea, I don't know how practical it would be… The first step would be using consistent markup for things like tabs, carousels, etc. But previous initiatives like jQuery UI's themes never really took off for some reason.
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.
That's a great idea. Use bootstrap as a starting point and go from there. You already have a community forming around bootstrap that you could leverage.
thanks sacha, good point about practicality. i know it ain't going to be easy and if it's just me that contributing, i think it still great. but atleast we can get something like this going, think it'll be great for developers all around.
There's something I'm often wondering why it doesn't exist: A standard, community-based document specifying a protocol for commons html/css constructs. For instance, specifically saying what is a header, what's the best html structure for it and a couple css examples.
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.
Well, HTML5 is fixing this problem by making new elements. So instead of arbitrary CSS classes, there is a standard element, such as <article> or <header>.
I think you could probably improve the usefulness and ease of use (and therefore success) of this project with a little extra leg work.
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.
thank you, this is really the type of thing i wanted to hear, as i really want to support manifest files but afraid that devs, mainly the front-end devs, would be hesitant to dealing with manifest files. so my best guess is, to make it optional, but if found, it'll get indexed by the database.
I really like this idea, and it's one I wish I had time to work on myself. I think there's a real need for something like this.
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).
You would need a consistent html structure for common components. Twitter bootstrap is not the only one of it's type also, check out zurb's foundation [0].
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.
You should know that Norton warns me of an attempted attack every time I load your page. It claims the "HTTP MS IE VML Fill Method BO" (http://www.symantec.com/business/security_response/attacksig...) attack was attempted from hosted.by.qudranet.com (This host has no DNS record as far as I can tell).
I have to admit this post was a bit pre-mature as there is nothing set up to support this yet. I just wanted to collect some feedback around this idea to hear what others think. I will have a follow-on post once I have something in action so follow me @jaequery if you want to keep tabs on the project.
[+] [-] sgdesign|14 years ago|reply
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.
[+] [-] AtTheLast|14 years ago|reply
[+] [-] jaequery|14 years ago|reply
[+] [-] phzbOx|14 years ago|reply
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.
[+] [-] Raphael|14 years ago|reply
[+] [-] giberson|14 years ago|reply
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.
[+] [-] jaequery|14 years ago|reply
[+] [-] audionerd|14 years ago|reply
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".
[+] [-] jaequery|14 years ago|reply
[+] [-] lukeholder|14 years ago|reply
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/
[+] [-] xnxn|14 years ago|reply
Alternatively, a snippet of HTML could be supplied along with every CSS component.
[+] [-] jaequery|14 years ago|reply
[+] [-] zwass|14 years ago|reply
[+] [-] jaequery|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] BillSaysThis|14 years ago|reply
[+] [-] jaequery|14 years ago|reply
[+] [-] kodablah|14 years ago|reply
[+] [-] miles_matthias|14 years ago|reply
[+] [-] jaequery|14 years ago|reply