I hereby claim:
- I am charlespeters on github.
- I am charlespeters (https://keybase.io/charlespeters) on keybase.
- I have a public key whose fingerprint is D213 9CA8 A569 2673 1D78 A83C 1F8F A04D 7EFE F65D
To claim this, I am signing this object:
module.exports = function(grunt) { | |
// Project configuration. | |
grunt.initConfig({ | |
pkg: grunt.file.readJSON('package.json'), | |
uglify: { | |
build: { | |
src: ['js/lib/*.js', 'js/global.js'], | |
//input | |
dest: 'js/build/global.min.js' //output | |
} |
// app/models/post.js | |
import DS from 'ember-data'; | |
export default DS.Model.extend({ | |
title: DS.attr('string'), | |
body: DS.attr('string'), | |
slug: DS.attr('string'), | |
dateCreated: DS.attr('date'), | |
dateModified: DS.attr('date'), |
const gulp = require('gulp'); | |
const browserify = require('browserify'); | |
const babelify = require('babelify'); | |
const watchify = require('watchify'); | |
const source = require('vinyl-source-stream'); | |
const buffer = require('vinyl-buffer'); | |
const paths = require('./paths'); | |
// Transpile JavaScript through Browserify with Babel | |
const bundler = watchify(browserify(paths.js.src, watchify.args)); |
I hereby claim:
To claim this, I am signing this object:
@import 'obsidian.css/lib/settings'; | |
@import 'obsidian.css/lib/generic'; | |
@import 'obsidian.css/lib/elements'; | |
@import 'obsidian.css/lib/objects'; | |
@import 'obsidian.css/lib/components'; | |
@import 'obsidian.css/lib/utilities'; |
Writing CSS is easy. It has a really low barrier to entry with simple declarative syntax combined with its results being (for the most part), visual. Authoring CSS is simple, it doesn’t need to be compiled to be interpreted by a browser. It’s an easy target for being dismissed because of misunderstanding the properties and values have assumed meanings (like float or inline-block or positioning entirely).
Now writing good CSS is a completely different animal. While authorship is simple and we face a whole host of challenges in order to reach our users. Chief among them is maintaining a consistent visual style across components while writing performant front-end code. To make this even more difficult we can draw very few concrete conclusions about users as our landscape of even-increasing devices expands and never knowing the type of connection speed a user will have at a given time. All this leads to a high level of complexity within our projects’ front-end code.
Quite a few meth
:root { | |
--UIList-border: #CCCCCC; | |
--UIList-space: .5rem; | |
} | |
.o-UIList { | |
list-style: inside none; | |
margin: 0; | |
padding: 0; | |
} |
<div class='Flex'> | |
<div class="Flex__child bcc gray0"></div> | |
<div class="Flex__child bcc gray1"></div> | |
<div class="Flex__child bcc gray2"></div> | |
<div class="Flex__child bcc gray3"></div> | |
<div class="Flex__child bcc gray4"></div> | |
<div class="Flex__child bcc gray5"></div> | |
<div class="Flex__child bcc gray6"></div> | |
</div> | |
<div class='Flex'> |
[*] | |
indent_style = space | |
indent_size = 2 | |
end_of_line = lf | |
charset = utf-8 | |
trim_trailing_whitespace = true | |
insert_final_newline = true | |
[*.md] |