After the CSS Layer Tennis (check out the tag “cascadiacss” on codepen), the day continued with more talks. Here’s part 1 of the afternoon.
Shay Howe: CSS as a Service: Maintaining Style
Build a lot of website, and have separate code bases which is good, but replicating a lot of base styles.
Build on top of a Service-Oriented Architecture (SOA). Databases store the content, with client computers with services in between. Compile content from databases and serves it to client.
Wanted to do the same thing with design. Building a system to share common:
- CSS & SASS (variables, mixims, utilities, the works!)
- JS & CoffeeScript modules
- images
- fonts
- misc assets
Rolodex – recommend looking at it, forking it.
Wrote toolkit in parallel with project. Style guides rarely used as intended.
Took common components into toolkit, then into style guide. Page and style guide @import rolodex, Toolkit: rolodex.css.sass
Implementation
Single responsibility principle
- every class should have a single responsibility
- responsibility should be encapsulated by the class
- each module should do its own thing
Want to make sure that not dependent on HTML. Don’t override and not depending on parent. e.g. .feat-box / article .feat-box => .feat-box / .feat-box-alt
Name with Care
- name for understanding
- favor functional names
- have a pattern
Leverage Sass Maps
- dynamically generate styles
- quickly build components
- allows scaling incredibly well
Compose with Sass Mixins
- share common groups of declarations
- create variables for repeated values
- use arguments when beneficial
Measure your Improvements
- identify a baseline
- select a few KPIs (file size, number of rulesets, properties etc.)
- look into stylestats, CSSCSS, CSS Lint, WebPagetest
Don’t Over Think
- write code ou the long way, then refactor
- rename, rewrite, refactor willing
- document everything!
Start where you are, keep going, no one said it would be easy.
Enjoy your work!
Kenneth Ormandy: Efficient Web Type, c. 1556
Used to be done using punch cutter, and now changed. Still asking
How might a text be read and used more efficiently?
Even in the past, building tools to solve own problems. e.g. creating pocket-sized Bible. Needed a typeface that is legible even when printed very small.
On the web, unlikely creating own font, but importing fonts using CSS.
Adoption of performance problems because of this. 8kb avg in 2012, now 50+kb
Some recommend subsetting, but aggressive subsetting can be a problem.
Normalize-OpenType.css to normalize fonts and deal with the details e.g. small caps for all cap words.
Work is going into refining WOFF into WOFF2 using Brotli compression algorithm. 14% compression rate improvement, 60% for non-latin faces
One of the best things is the a familiar interface. No changes to syntax in CSS.
You might already be trying WOFF2 today and not even though this using font links e.g. Google Web Fonts
If self-hosting, can convert font files to WOFF2 format, but need to check license.
Browser support: Chrome 36, opera 23, firefox 39, android 37, IE in consideration
Opportunity for Designers and Developers
* no more “css-only”, might actually use JavaScript option, because can influence loading, use web font loader
* can load asynchronously: text is more important than typeset
* can set timeout (1.5 seconds)
* font stacks still matter (can map to variable in preprocessor)
Though, the issue is driving our optimizations are not
always dire, they’re perhaps more relevant than ever.
Break Time
