this document css styles

typography non-grid headers


Chapter heading

Block heading

Paragraph with hyperlink


[[ content-width ]]
[[ content-width ]]



flexbox 2009 cheatsheet

container children links

Parent properties

horizontal | vertical | block-axis | inline-axis | inherit

A box may lay out its children either horizontally or vertically.

normal | reverse | inherit

Children within a horizontally oriented box are, by default, displayed from left to right in the same order as they appear in the source document. Children within a vertically oriented box are displayed top to bottom in the same order. The box-direction and box-ordinal-group properties may be used to change this ordering.

start | end | center | justify

Used to dictate how any additional space along the box-axis should be distributed between elements. The box-pack property does not affect the position of elements in the opposite direction. That is, box-pack affects only the horizontal position in horizontally oriented boxes and only the vertical position in vertically oriented boxes.

single | multiple

By default a horizontal box will lay out its children in a single row, and a vertical box will lay out its children in a single column. This behavior can be changed using the box-lines property. The default value is single, which means that all elements will be placed in a single row or column, and any elements that don't fit will simply be considered overflow.

If a value of multiple is specified, however, then the box is allowed to expand to multiple lines (that is, multiple rows or columns) in order to accommodate all of its children. The box must attempt to fit its children on as few lines as possible by shrinking all elements down to their minimum widths or heights if necessary.

start | end | center | baseline | stretch

Specifies how a box's children are placed and aligned along the direction perpendicular to the box orientation, and where the extra space, if any, is positioned. For horizontal orientation, it specifies how the children are positioned vertically. For vertical orientation, it specifies how the children are positioned horizontally.

Child properties


Each element directly within a box may be made either flexible and inflexible. Flexible elements may grow when the containing box has extra space available after the size of all of its children have been computed, and shrink if the size would cause the containing box to overflow, yet the preferred width of the flexible element is larger than its minimum width. Inflexible elements do not change in size, even when there is extra space left over in the box.





Full code

function brightFuture(){ this.resolved = false; this.result = null; this.cb = null; this.resolve = function(result){ this.resolved = true; this.result = result; if(this.cb != null){ this.cb(result); } }; this.then = function(Callback){ /* wrapping callback into future */ var ChainedFuture = new brightFuture(); if(this.resolved){ /* we have result so triggering resolution */ var response = Callback(this.result); if(response instanceof brightFuture){ return response; } else { ChainedFuture.resolve(response); } } else { /* we dont have result so just settin callback as passed function wrapped with future */ this.cb = function(UpFuture, UpCallback, self){ return function(x){ var response = UpCallback(x); if(response instanceof brightFuture){ response.then(function(UpUpFuture){ return function(resp){ UpUpFuture.resolve(resp); return true; }}(UpFuture)); } else { UpFuture.resolve(response); } } }(ChainedFuture, Callback, this) } return ChainedFuture; }; }

Sample section

Heading 3

Thumbs should be generated as needed by your current site layout and without modifing the original image. If the layout changes there won't be the need to upload every image again, which is very conveniently.

Where should I place those thumbs? Well, a thumb should be localizable by two ways: it's origin and it's applied manipulation (resize, crop, border-radius, polaroid-effect, etc)

By it's origin, becouse if the original image gets removed, it's thumbs should be removed as well. By it's applied manipulation, becouse, as different types of thumbs may exist for the same image, if design changes and older thumbs ain't needed anymore they are all easyly removable.

A hierarchical folder organization is cheap, fast and for your thumbs should be enough, no need for an extra database table

But I need feature X implemented Great! Instead forcing this helper to fit in every possibly use case, I tried to make it easyly extensible/adaptable for your custom needs. Take this as a boilerplate codebase and please share your adaptation so is useful for everybody :)