toadstool 0.0.0.1

data/Gemfile

@@ -0,0 +1,11 @@
+source 'http://rubygems.org'
+
+gem 'sinatra'
+gem 'sass'
+gem 'compass'
+gem 'sinatra-partial'
+gem 'rake'
+gem 'stipe'
+
+# Only use when in gem development
+# gem 'stipe', :path => '../stipe'

data/Rakefile

@@ -0,0 +1,4 @@
+desc "Run the development server"
+task :server do
+  exec "bundle exec ruby toadstool.rb -p 3000"
+end

data/config.rb

@@ -0,0 +1,42 @@
+# Require any additional compass plugins here.
+# require '../stipe/lib/stipe.rb' # locally as a Compass extension
+require 'stipe'
+
+# Set this to the root of your project when deployed:
+http_path = "/"
+
+#if ENV['PWD'].end_with?('sass')
+#  css_dir = "../public/stylesheets"
+#  sass_dir = "."
+#else
+#  css_dir = "public/stylesheets"
+#  sass_dir = "sass"
+#end
+
+css_dir = "public/stylesheets"
+sass_dir = "sass"
+images_dir = "images"
+javascripts_dir = "javascripts"
+
+# You can select your preferred output style here (can be overridden via the command line):
+# output_style = :expanded or :nested or :compact or :compressed
+output_style = :expanded
+
+# To enable relative paths to assets via compass helper functions. Uncomment:
+# relative_assets = true
+
+# To disable debugging comments that display the original location of your selectors. Uncomment:
+line_comments = true
+
+# http://www.mobify.com/dev/sass-sleuth-debugging-sass-in-webkit-browsers/
+# compass watch --debug-info
+
+sass_options = {
+  :debug_info => true
+}
+
+# If you prefer the indented syntax, you might want to regenerate this
+# project again passing --syntax sass, or you can uncomment this:
+# preferred_syntax = :sass
+# and then run:
+# sass-convert -R --from scss --to sass sass scss && rm -rf sass && mv scss sass

data/config.ru

@@ -0,0 +1,6 @@
+require './toadstool'
+
+## There is no need to set directories here anymore;
+## Just run the application
+
+run Sinatra::Application

data/doc-src/SASS-Guidelines.md

@@ -0,0 +1,222 @@
+# General Sass notes, advice and guidelines
+
+**Follow contributers on Twitter [@anotheruiguy](http://twitter.com/anotheruiguy) and [@ScottKellum](http://twitter.com/ScottKellum)**
+
+## Syntax and formatting
+
+Sass is written using the multi-line format very similar to CSS. While Sass is the language, SCSS is a version of the syntax. There is no right or wrong, better or worse. Some prefer the Sass syntax, I prefer to work with SCSS. For the purpose of this document I will refer Sass as the language, but code examples will be written as SCSS and file names as `.scss`.  
+
+### Sass and SCSS
+
+Sass has two equally valid syntaxes, Sass and SCSS. Some key differences to be illustrated are, Sass uses less characters and a 'double space' tab for child selector delineation, exactly like HAML. While SCSS uses a syntax that is more representational of CSS and you can use a full 'tab' for child selector delineation. See examples.
+
+**Sass**
+
+```Sass
+.your_new_class
+  margin: 0
+  padding: 0
+```
+
+**SCSS**
+
+```scss
+.your_new_class {
+	margin: 0;
+	padding: 0;
+}
+```
+
+## Comments
+
+SCSS supports both invisible and visible comments. Using `//` before any SCSS, this will place a comment in your SCSS code, but will not be output in the processed CSS. 
+
+Using the standard `/* */` CSS comments in your SCSS, when processed this will be output in your CSS.  
+
+Comments in code is awesome. Especially when working with a team. Be kind, leave instructions. 
+
+### Nesting
+
+Nesting in Sass is not like indenting in CSS. In Sass nesting has meaning. Sass uses the nested white space to declare parent child relationships. Nesting allows the developer to inherit the parent selector, but be mindful, it is easy to fall into the trap of insane selector inheritance. Rule of thumb, if you are tabbing in a third time, is this declaration really that specific to this namespace or can you abstract to be used more universally? 
+
+Just because you are using Sass doesn't mean that you should toss all CSS and OOCSS best practices out the window. 
+
+**The Good**
+
+```scss
+.your_new_class {
+	margin: 0;
+	padding: 0;
+	p {
+		color: red;
+	}
+	a {
+		color: blue;
+		text-decoration: none;
+	}
+	li {
+		float: left;
+		width: 100%;
+	}
+}
+```
+
+**The Bad**
+
+```scss
+.your_new_class {
+	margin: 0;
+	padding: 0;
+	div {
+		p {
+			color: red:
+			a {
+				color: blue
+				text-decoration: none;
+			}
+		}
+		ul {
+			li {
+				float: left;
+				width: 100%;
+				a {
+					color: blue;
+					text-decoration: none;
+				}
+			}
+		}
+	}
+}
+```
+
+### Declaration best practice
+
+It is best practice to list your parent specific declarations directly under the class selector and then list the indented child selectors to keep readability at a maximum.  
+
+Example of a parent class selector with nested selectors:
+
+```scss
+.fieldset {
+	margin-bottom: 2em;
+	p {
+		margin-bottom: 0;
+		line-height: 1.5em;		
+	}
+	legend {
+		float: left;
+		width: 100%;
+	}
+}
+```
+
+### Selector naming conventions
+
+I personally use underscore delimited lowercase selectors. Why? I can double click on a selector and get the whole thing. `.CamelCase{}`, `.hyphen-delimited{}`, or `.underscore_delimited{}`, as long as you are consistent, rock on!
+
+
+## Working with partials
+
+A partial in Sass is a document with an underscore preceding the name.  Example, `_widget.scss`. Using this convention, when processed, Sass will not output a standalone CSS file. A partial is simply a resource file that other docs can consume and use. This is essential for managing large libraries of Sass logic, element and widget styles. 
+
+I have found that the simplest way to manage your Sass files is via a core.scss file consisting of imported partials and a logical grouping of sub files. With Sass, @import works and it works really well, unlike standard CSS. It is encouraged to break your files into smaller manageable chunks of code. 
+
+If you can't decide whether to use Sass or SCSS, the good news is that you don't. Sass and SCSS files can live together in perfect harmony. So if you have a reason for using one syntax over another for specific use cases, this is acceptable. For example, some like to use SCSS for logic building and then use Sass for design building. You do not need to state either SCSS or Sass with the @import function, just the path to the partial.
+
+
+## Dynamic and reusable code
+
+Sass's greatest strength is in it's ability to create dynamic, intelligent and efficiently reusable code. 
+
+### @mixins
+
+Mixins are a great way to keep your code DRY as well as create logical chunks of code to be reused again and again. Using the `@mixin` directive you can engineer smart reusable code to be used throughout your application. It is considered best practice to only use a mixin if you are also using arguments like the following. 
+
+```scss
+@mixin the_box ($padding, $background, $border, $style, $color) {
+	padding: $padding;
+	background: $background;
+	border: $border $style $color;
+}
+```
+
+To use the mixin use the `@include` directive like so
+
+```scss
+.your_new_class {
+	@include the_box (10px, red, 1px, solid, black);
+}
+```
+
+### @extend
+
+If you are not using arguments in your mixin, you should consider using a CSS class object and apply using the `@extend` directive. Here is a best practice example for creating a stylistic class for use as an extend using a Compass mixin.
+
+```scss
+// Style class object
+.default_gray_border {
+	@include border-radius(25px);
+	border: 1px solid gray;
+}  
+
+// Semantically names class
+.promoters_box {
+	@extend .default_gray_border;
+}
+```
+
+This will produce the following best practice CSS
+
+```scss
+.default_gray_border, promoters_box {
+	-webkit-border-radius: 25px;
+	-moz-border-radius: 25px;
+	-ms-border-radius: 25px;
+	-o-border-radius: 25px;
+	border-radius: 25px;
+	border: 1px solid gray;
+}
+```
+
+### @extends gone bad
+
+@extend is an awesome tool, but used unwisely will cause real issues. Something I consider to be best practice is to NEVER USE extends inside a mixin. Depending on how the parent mixin is used in generating more CSS even with the possibility of that mixin being used to create a class that is in turn extended, this can create an amazing array of selectors in your final CSS.
+
+**The Bad**
+
+	need to engineer bad @mixin with @extend example
+	
+**The Bad CSS**
+
+	illustrate css selector blote 
+
+
+
+### @-Rules and Directives
+
+One of the advantages Sass has over other languages are control directives. This allows for the ability to programmatically generate css and values.
+
+### Functions
+
+Sass has built in functions like `percentage($value)` along with [plenty of others](http://Sass-lang.com/docs/yardoc/Sass/Script/Functions.html). However you can build your own functions to help with calculations and generating values for a verity of use cases. Below is an exponent function that can be used on any value.
+
+```scss
+@function exponent($base, $exponent) {
+  // reset value
+  $value: $base;
+  // positive intergers get multiplied
+  @if $exponent > 1 {
+    @for $i from 2 through $exponent {
+      $value: $value * $base; } }
+  // negitive intergers get divided. A number divided by itself is 1
+  @if $exponent < 1 {
+    @for $i from 0 through -$exponent {
+      $value: $value / $base; } }
+  // return the last value written
+  @return $value; 
+}
+```
+
+
+### Combining features
+
+The above tools can be combined to provide even more powerful tools for writing CSS. Loops can be placed in mixins to create grids. Mixins can be nested in mixins to cleanly write code that effects lots of areas. While you need to be careful with the CSS this generates nesting features can provide you with a lot of power when generating styles.

data/doc-src/What-Is-Toadstool.md

@@ -0,0 +1,44 @@
+#What is Toadstool?
+
+While CSS frameworks are in increasing abound, one thing that is consistently missing is a good styleguide solution. While it appears that styleguides are an interesting topic and almost everyone agrees that styleguides are the way to go, all the energy for development is going onto yet another version of a UI framework.  
+
+Toadstool aims to bring a little sanity to an insane world. Built in Sanatra, using Sass and Compass, Toadstool in it's core is a styleguide templating solution. 
+
+##Toadstool is a process
+In the countless projects I have been involved in, one constant is the lack of abstraction between the design element, HTML and CSS for the widget and the view. 
+
+Toadstool aims to give structure to the styleguide development process.
+
+##Don't go chasing waterfalls 
+In the old waterfall days, it was common to think a project's problems all the way through. Specification documents and comps that encompassed almost the entire project before line one of code was ever written was the expectation. Oh, those were the days. 
+
+For developers, It was easier for them to see the future and write patterned code, but the expense was to great. All the upfront planning was very time consuming and when developers began to layout patterns in their code based on those assumptions, changes down the road were much harder to manage. Not to mention expensive and opportunities for broken code were to high. Anyone remember writing tests in those days?
+
+In agile the idea is to not solve the problem until it is an official problem. Sure we can speculate, but the idea is to not execute until it is appropriate. So, what does that mean for designers and developers? For developers that is pretty easy to answer, don't develop that feature until it is time. But for designers, this has been a harder problem to solve. After all, the designer's role has traditionally been to be the ones who think ahead. Developers have looked to them to be ready when the time comes. 
+
+##Designers, get agile or The Failure of the Comp
+Up till now the designer's deliverable has been and in most cases continues to be the comp. While most of the development world has moved on from waterfall, I see time and time again designers holding onto the same processes. Given a project I have seen design teams go overboard in trying to solve problems that don't yet exist. This leads them down a path of no return having thought so deep into solving a problem that the attachment to a solution becomes too great. When the times comes that there needs to be adjustments to the solution to fit the changing needs of the business, 'turning the boat' comes with great costs and is usually meet with frustrations, if not full out resistance. 
+
+Getting agile fills the gap where the comp fails. All to often when composing the comp, the designer feels the need to design the whole experience of a single view. This means a lot of time in Photoshop and duplicating screens again and again just to adjust subtle nuances. This means making changes comes at to great a cost.
+
+Version control is another issue of great frustration. Many times the 'comp' from the designer will go through other experimental iterations that may accidentally get incorporated into a delivered design to a developer. This is a classic case of 'signal vs noise' issue. A developer will typically pick up on these inconsistent nuances and make the changes to the layout of the view. It is this simple issue that commonly leads to unnecessary work and frustrations. 
+
+Another common versioning issue is that there may be changes in the view that are not appropriately managed in the next series of comps that are coming down the line. In the waterfall comp design process, many of the screens are created way ahead of time and as the project progresses things change. It is typically very time consuming and expensive to go back and update all the comps with the changes that have happened in the UI since that view was designed. So again we find ourselves measuring final deliverables against an imperfect measuring stick that leads to confusion and frustration. 
+
+What if we were to bite this off into smaller chunks? What if at fist we we're to only decide things like color pallet, typography, forms and buttons? This is pretty cool and most will agree that this is a process that most designers go through. The breakdown is how to document these choices. Historically designers did this with the comp. Today I say do it with a styleguide. 
+
+##The comp is D.O.A.
+To me, the delivery of a comp is a 'dead on arrival' document. The first thing I am going to do is convert this to code and it's lifecycle will exist in code. The customers of our site will never see the comp. So why do we treat it as the defacto standard from which all our site's views will be measured?
+
+The fact of the matter is, in today's landscape of devices that are consuming content, this process is flawed in more ways one. As designers and developers we need to be living in the medium is which our product will ship. This means documenting our user's experience in a format that is abstracted from the actual product, but is representational of the environment from which the user will interact. My answer, styleguide. 
+
+##Abstraction is the key
+Since the very early days of CSS it has been prophesied that you could develop a site and redesign it with only CSS. And then there are those who would say that this is a myth, a holy grail that is impossible to achieve. I say, bollocks. 
+
+A trap that developers fall into time and time again is that they write the code to fit the UI. There is zero abstraction between content, markup and then design. It is this error in development that causes developers and designers to state that a redesign will always demand that we re-engineer the markup.
+
+While I will agree that we have not always had the tools at our ready to achieve the holy grail of goals, but that doesn't mean that we throw our hand up in the air either and surrender. We must persevere and persist. We must create the tools we are lacking. 
+
+A goal of Toadstool's styleguide is to provide a framework so that UI elements are created in an environment that is completely abstract from the actual application. As stated above, developers many times fall into trap of developing a UI element to specific to a view and customized to the content they are given. When I hear a developer say, �If you change the copy the UI will break�, that really tells me that they are doing it wrong. 
+
+Good UI developers will tell you that when they begin writing code they are looking at the structure of the UI element. From there it is a series of decisions on what markup to use that best represents the layout and the content within. Then we need to provide hooks for your CSS to apply the look and our JavaScript to apply experience. 

data/doc-src/changelog.md

@@ -0,0 +1,29 @@
+# Toadstool Changelog
+## Oct. 3 2012
+* Updated js for em view calc to round up value and show px value too.
+* Removed form select menu
+* Updating views with better solution for showing code
+
+## Oct. 30 2012
+* Added 24col grid view
+* Updated gemspec for Stipe 0.0.4.6
+
+## Sept. 6 2012
+* Added .rvmrc - I know, should have done this a long time ago.
+
+## Aug. 31 2012
+* Added support for non-core modernizr features
+** boxsizing - necessary for grid solution
+** lastchild
+
+## Aug. 30 2012
+* Moved color defaults to control under Toadstool style guide
+* Updates tempalte markup so that css is not leveraging generic tags. Corrected issues where styles were stomping on prototype views
+
+## Aug, 13 2012
+* Updates required to meet specification of 0.0.2.8 Stipe gem update
+
+## Aug 9, 2012
+* Updated `public/javascripts/application.js` with support for creating hex values on the fly in the browser for the colors view
+* Updated navigation, consolidated abstract and semantic colors view (still need to complete semantic swatches)
+* BUG: Colors in the view are being pulled from Stipe, not the Toadstool styleguide.   

data/doc-src/config.md

@@ -0,0 +1,18 @@
+#Toadstool config
+
+Please read the following information as how to use Toadstool's configurations
+
+## CSS Reset
+Toadstool is designed to support any CSS rest you prefer. Resets installed are Toadstool reset, HTML5 reset, Eric Meyer's reset and Nicolas Gallagher's Normalize. And of course, Compass' reset is supported as well. 
+
+All resets are written in Sass and configuration is as simple as uncommenting the preferred reset in the ``config_files/_reset.scss`` directory. In any of the reset files, any hardcoded pixel values are being converted to ems and all hex colors have of course been replaced with Toadstool's variables. Activation of any reset will inherit color values as dictated by the ``_config.scss`` file. 
+
+###Toadstool reset
+Toadstool's reset is a slight modification on the HTML5 reset. All of the font styling features of this reset have been moved to the ``_text.scss`` file.
+
+###HTML5 reset and Normalize
+To the same effect that all styling in Toadstool's reset have been moved to more appropriate locations in the framework, same has been done with the installation of HTML5 reset and Normalize. 
+
+###'My Reset'
+You have your own preferences for reset, that's cool. In the ``sass`` directory there is a placeholder ``_myreset.scss`` that is all yours to use. Simply uncomment the import listing in ``config_files/_reset.scss`` and profit.
+

data/doc-src/mit_license.md

@@ -0,0 +1,7 @@
+Copyright (c) 2012 Dale Sande and Jed Foster
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/doc-src/mixin_directory.md

@@ -0,0 +1,17 @@
+#Toadstool's mixins directory
+
+Toadstool is a Styleguide UI Framework designed to give you all the power and flexibility of more traditional CSS frameworks without all the crufty CSS that bloats your stylesheets. But how do we do this? The secret is Sass. Or should I say a combination of Sass and the Compass library. Toadstool is a collection of fabricated mixins that are designed to solve common problems. 
+
+##Toadstool mixins
+###@include main_content
+Designed to be used for the large main content area of a site. Typically a section block set to a specified width that is centered in the view.
+**Supported arguments** ``$main_col_count, $main_grid_align: center, $main_grid_uom: em`` If needed
+**Example use case**
+``
+	.main_content {
+		@include main_content(6);
+	}
+``
+
+
+### Work in progress ... don't mind the mess.

data/doc-src/sass.md

@@ -0,0 +1,4 @@
+#File and folder structure
+
+### To Do
+Write up how to use the file and folder structure at this level

data/lib/RackServer.rb

@@ -0,0 +1,93 @@
+require 'rack'
+require 'fileutils'
+require 'optparse'
+
+class RackServer < ::Rack::Server
+  class Options
+    def parse!(args)
+      args, options = args.dup, {}
+
+      opt_parser = OptionParser.new do |opts|
+        opts.banner = "Usage: rails server [mongrel, thin, etc] [options]"
+        opts.on("-p", "--port=port", Integer,
+                "Runs Rails on the specified port.", "Default: 3000") { |v| options[:Port] = v }
+        opts.on("-b", "--binding=ip", String,
+                "Binds Rails to the specified ip.", "Default: 0.0.0.0") { |v| options[:Host] = v }
+        opts.on("-c", "--config=file", String,
+                "Use custom rackup configuration file") { |v| options[:config] = v }
+        opts.on("-d", "--daemon", "Make server run as a Daemon.") { options[:daemonize] = true }
+        opts.on("-u", "--debugger", "Enable the debugger") { options[:debugger] = true }
+        opts.on("-e", "--environment=name", String,
+                "Specifies the environment to run this server under (test/development/production).",
+                "Default: development") { |v| options[:environment] = v }
+        opts.on("-P","--pid=pid",String,
+                "Specifies the PID file.",
+                "Default: tmp/pids/server.pid") { |v| options[:pid] = v }
+
+        opts.separator ""
+
+        opts.on("-h", "--help", "Show this help message.") { puts opts; exit }
+      end
+
+      opt_parser.parse! args
+
+      options[:server] = args.shift
+      options
+    end
+  end
+
+  def initialize(*)
+    super
+    set_environment
+  end
+
+  def app
+    @app ||= super.respond_to?(:to_app) ? super.to_app : super
+  end
+
+  def opt_parser
+    Options.new
+  end
+
+  def set_environment
+    ENV["RAILS_ENV"] ||= options[:environment]
+  end
+
+  def start
+    url = "#{options[:SSLEnable] ? 'https' : 'http'}://#{options[:Host]}:#{options[:Port]}"
+    puts "=> Call with -d to detach" unless options[:daemonize]
+    trap(:INT) { exit }
+    puts "=> Ctrl-C to shutdown server" unless options[:daemonize]
+
+    #Create required tmp directories if not found
+    %w(cache pids).each do |dir_to_make|
+      FileUtils.mkdir_p(File.join(Dir.pwd, 'tmp', dir_to_make))
+    end
+# puts wrapped_app
+    unless options[:daemonize]
+      wrapped_app # touch the app so the logger is set up
+    end
+
+    super
+  ensure
+    # The '-h' option calls exit before @options is set.
+    # If we call 'options' with it unset, we get double help banners.
+    puts 'Exiting' unless @options && options[:daemonize]
+  end
+
+  def log_path
+    "log/#{options[:environment]}.log"
+  end
+
+  def default_options
+    super.merge({
+      Port:         3000,
+      DoNotReverseLookup:  true,
+      environment:  (ENV['RAILS_ENV'] || "development").dup,
+      daemonize:    false,
+      debugger:     false,
+      pid:          File.expand_path("tmp/pids/server.pid"),
+      config:       File.expand_path("config.ru")
+    })
+  end
+end