Slides from my talk at cssconf oakland
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
1.png
10.png
11.png
12.png
13.png
14.png
15.png
16.png
17.png
18.png
19.png
2.png
20.png
21.png
22.png
23.png
24.png
25.png
26.png
27.png
28.png
29.png
3.png
30.png
31.png
32.png
33.png
35.png
36.png
37.png
38.png
39.png
4.png
40.png
41.png
42.png
43.png
5.png
6.png
7.png
8.png
9.png
README.md

README.md

Slides from my talk at CSSCONF - Oakland 2014

I recently gave a talk at CSSCONF in Oakland. Here are my slides.

For those of you who attended - or to anyone who watches the video, I'd like to clarify a few points.

At one point I kind of champion inline styles. I forgot to clarify I mean the mental model that inline styles provide. Inline styles are actually quite slow to render to the browser as each declaration has a one to one relationship with the dom. A single purpose class however i.e .bg-red { background-color: red; } has a one to many relationship with the dom and is faster for the browser to paint. I find this is the same type of encapsulation - but it's far easier to maintain.

I don't know if I somehow missed it during my talk or if slide 25 just didn't load for some reason - but I'd be remiss to not call attention to the one quote that completely changed my workflow when writing css.

In Nicole Sullivan's post 'The media object saves hundreds of lines of code' she has the following quote:

When I’m building a new object, the first thing I do is to figure out which parts are reusable components, and define what I know and do not know about them.

This is not something I had ever thought of before. When I am building components I now stop and write out notes about all the things I know and all the things I don't know. I've found that being informed on what you don't know, will help you in keeping concerns separated - and that your abstractions are on point. Bad css is full of assumptions. Understanding where you can't make assumptions can help you write code that works in more contexts.

All of CSS in one file

If you want to see my experiment with putting the entire css language into one file it's called css unabridged. I've tried to make it as verbose as possible and it is currently 20.15kb minified and gzipped.

Reading

These articles have helped change how I think about writing css, html. Some of them are not actually articles about front-end development, but still introduced concepts to me that changed how I approached authoring code for users.

This article is a little more technical - but gives some interesting insight into how chrome handles painting to the screen. GPU accelerated compositing in chrome

License

The MIT License (MIT)

Copyright (c) 2014 @mrmrs

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.