NOTE I now use the conventions detailed in the SUIT framework
Used to provide structural templates.
Pattern
t-template-name
| (function() { | |
| // Do not use this library. This is just a fun example to prove a | |
| // point. | |
| var Bloop = window.Bloop = {}; | |
| var mountId = 0; | |
| function newMountId() { | |
| return mountId++; | |
| } |
| module.exports = function(grunt) { | |
| grunt.initConfig({ | |
| pkg: grunt.file.readJSON('package.json'), | |
| uglify: { | |
| options: { | |
| sourceMap: true, | |
| sourceMapIncludeSources: true, | |
| sourceMapIn: 'js/app.coffee.js.map' | |
| }, |
NOTE I now use the conventions detailed in the SUIT framework
Used to provide structural templates.
Pattern
t-template-name
| // Still need to work out how to combine rules for numbers | |
| // that share a greatest common factor without the unit-builder | |
| // actually containing the fraction to which they can both be | |
| // reduced. | |
| // Calculate the greatest common factor of two integers | |
| @function gcf($a, $b) { | |
| @if $b == 0 { | |
| @return $a; | |
| } |
| /*------------------------------------*\ | |
| $NAV | |
| \*------------------------------------*/ | |
| /* | |
| TAGS: ^lists ^navigation ^text | |
| */ | |
| /* | |
| As per csswizardry.com/2011/09/the-nav-abstraction | |
| */ | |
| .nav{ |
| /* | |
| * anchor-include pattern for already-functional links that work as a client-side include | |
| * Copyright 2011, Scott Jehl, scottjehl.com | |
| * Dual licensed under the MIT | |
| * Idea from Scott Gonzalez | |
| * to use, place attributes on an already-functional anchor pointing to content | |
| * that should either replace, or insert before or after that anchor | |
| * after the page has loaded | |
| * Replace: <a href="..." data-replace="articles/latest/fragment">Latest Articles</a> | |
| * Before: <a href="..." data-before="articles/latest/fragment">Latest Articles</a> |
| from zope.schema import getFields | |
| from zope.interface import providedBy | |
| from zope.interface import implementedBy | |
| from zope.component import getUtility | |
| from zope.component import queryUtility | |
| from plone.behavior.interfaces import IBehavior | |
| from plone.behavior.interfaces import IBehaviorAssignable | |
| from plone.dexterity.interfaces import IDexterityFTI | |
| from plone.dexterity.utils import resolveDottedName |
| # The following recipe works with upstream rails proxy for custom 404s and 500s. | |
| # Errors are usually handled via rails except if proxy is really down, in which case | |
| # nginx needs a bit more configration. | |
| server { | |
| # ... | |
| location / { | |
| error_page 404 = @rails; # let rails show a page with suggestions | |
| try_files maintenance.html @rails; |
Harry,
I wanted to first thank you for creating inuitcss which I point my students to in my Object-Oriented CSS class I teach. I do have a philosophical question. From experience, I noticed that my websites have become abstraction heavy, and more often than not code was being duplicated. It is really because abstractions are owned by an object.
For example, I created a simple object called
.boxwith abstractions to change the padding. Later I created an object for alert messages, inline labels, and inputs and noticed that the sizing abstractions were the same. Since then, I moved away from creating abstractions unless they need to target a child element or are SPECIFIC to that object, and began working with atoms.So:
.box { } .box--xs { padding: 6px; }