CSSConf 2016 Recap

Thanks to Nicole Sullivan for founding the series, Bocoup for hosting the event, Claudina Sarahe (an OddBird alum) for her amazing emcee-ing, all the other speakers for their inspiring talks, and everyone else for attending! It was a great atmosphere, and I met all sorts of lovely people.

My talk was called Sass Map Magic – a major update to a talk I had given several years back at BlendConf (may it rest in peace). The video is available online.

I took extensive notes on day one, but lost my focus on day two, when I was part of the lineup. All the talks were great, and worth your time if you have a chance to watch the videos.

Sarah Drasner talked about programming as a creative act. There is more than one way to solve any given problem – and different solutions will come with different trade-offs. It’s worth exploring the options, while keeping in mind that code is a communication tool, and you should engineer with maintainers in mind.

In the second part of the talk, Sarah listed several tools for creative thinking. I have found all these tools particularly helpful as an artist, and it was a nice reminder that they can apply to code as well.

1. Question the base premises
2. Impose artificial bounds
3. Repurpose existing solutions
4. Combine existing solutions
5. Use open source code (this seems like an extension of 3 and 4)

Of course, this summary barely does justice to the beautiful demonstrantions Sarah included. Check out her CodePen page for a whole load of amazing and beautiful samples.

• Sarah Drasner Slides
• Sarah Drasner Video

Brian Jordan talked about automated front-end testing, with tools like PhantomJS. He works with code.org, a non-profit working to increase student access to computer science curriculum across demographics.

I didn’t take thorough notes on his overview of PhantomJS, but there were a few philisophical points that stood out:

• Test everything

• Make sure everyone on the team can write tests for the code they write

• Take the time, on occasion, to review and clean up your tests – otherwise you will run into bloat and compile-time issues

• Brian Jordan Slides

• Brian Jordan Video

Jessica Lord showed us how to use Electron to build native (Mac, Windows, Linux) desktop applications using Node, HTML, and CSS – with simplified access to native APIs.

That was pretty cool, but then she got to the point of the talk title: CSS to help “nativize” your styles, so your app feels like desktop software, and not a website.

Since Electron uses the latest Choromium rendering, you don’t have to target multiple browsers – but you do have to contend with multiple operating systems. Among other things, she advised disabling cursor: pointer and “rubber-band” scrolling.

• Jessica Lord Video

Pete Hunt gave the most controversial talk of the conference, exploring the advantages of in-line CSS generated by JavaScript, using tools like React, JSX, and JSX Style. It’s the obvious solution if you hate the cascade or think the separation-of-concerns is over-rated. I don’t.

From the JSX perspective, CSS has several major problems:

• It was designed for documents, not apps
• The cascade was intended to merge author & user styles, a feature that is rarely used (I’m not sure about that claim)
• The global name space leads to regular class-name conflicts

The React approach:

• No static HTML, all DOM nodes are generated with JS
• Build components out of other components
• Single-class selectors only (e.g. BEM) for unambiguous name-spacing of classes
• Class-names referenced only once in JS,  private to the component, and functionally equivalent to inline styles

Of course, this causes some new issues that have to be solved by the JS processor:

• Adding new custom attributes to the syntax for handling pseudo-elements

• Performance issues (addressed by “injecting” styles)

• Server rendering is difficult, maybe Webpack can provide a solution?

• Pete Hunt Video

Jen Kramer provided an overview of past and present CSS layout techniques, and an introduction to the new CSS Grid feature (still only available behind flags).

None of the existing options were designed for page layout. Tables were designed for tabular data, floats for inline content wrapped by text (like images and callouts), and flexbox for gallery-style UI components.

All of them deal with layout along a single axis of flow – what Jen referrs to as “one-dimensional” layout. To use any of them for layout, we have to include “row” markup to handle the second dimension.

CSS Grids are substantially different, providing layout options along both dimensions, and changing the way we think about flow. No row markup is required, because rows are handled directly in the CSS syntax, and elements can be rearranged (think flexbox order) along both dimensions.

The spec is mostly complete but implementations are sparse, hidden behind flags, and buggy across all browsers. Jen recommends using Chrome to explore the new possibilities – but it will be some time before we can use it in production.

• Jen Kramer Slides
• Jen Kramer Video

Will Boyd provided guidelines for creating smooth animations in CSS. To avoid jank, you have to keep all animations and transitions at 60fps.

By breaking performance down into multiple steps (loading, rendering, painting, displaying), Will was able to isolate the main causes of “jank” and show us where to focus our efforts.

Loading the DOM tree from HTML is outside the scope of CSS animations – so not a central issue for frame-rate (though unrelated background loading can slow down overall performance for non-accelerated animations).

Rendering the DOM tree into a visual layout requires matching CSS to DOM elements. The hardest part is determining geometry and position in the flow. Re-rendering also requires a re-paint, so anything that forces the document to re-calculate flow is going to cause performance issues. Avoid reflow by avoiding changes to properties like height, width, margin, padding, top, right, bottom, left, font-size, and so on.

Painting the rendered layout into individual pixel bitmaps is mostly a matter of color and style. Avoid re-paints by avoiding properties like color, background, box-shadow, etc. Re-paint rarely causes re-flow, so these properties are a smaller drain on performance.

Displaying painted pixels onto the screen is handled by the GPU, and there are several CSS properties that have been GPU-accelerated –  meaning they will never cause a re-flow or re-paint. That includes transform, most filter values (except for drop-shadow and blur), and opacity.

All of these aspects can be tracked in browser Dev Tools, and Will provided great demonstrations to show the differences in performance, and ways to use accelerated properties to achieve affects you might initially try to achieve with other properties.

• Will Boyd Video

Keith J. Grant argued for using a combination of em and rem values, instead of px, for sizing on the web.

Interesting metaphor to “kick” it off: when runners wear softer shoes, they instinctively step harder – negating any medical benefits. Keith suggests that we often do the same with relative units – trying to reverse-engineer pixel values, when we could simply trust the abstration. We all need to learn how to “step softer” with our relative units.

Since em units are relative to inherited font size, they pose a particular confusion – two em values in the same block can render to different sizes:

/* assuming a 16px default inherited font size */
.title {
  font-size: 1.2em; /* 19.2px relative to default font-size */
  padding: 1.2em; /* 23.04px relative to adjusted font-size */
}

Add in nesting, and the problem gets worse. Using rem (root-relative) units in some situations can help provide a more reliable baseline. Keith recommends:

• Always use rem for font-size
• Use px for border-width, since you often want thin lines
• Use em for everything else
• Line heights remain unitless

In order to ensure that modular components work anywhere, Keiths sets a rem font-size on the container of every component. Internal elements will be relative to that component root, even when nested inside another component.

I thought that was clever, but haven’t had a chance to play with it. We have generally reverse-engineered pixel values, and I appreciated the reminder that it’s probably not worth our effort. We’ll have to think about that more.

Keith also provides more detail on using viewport-relative vw units for your root font-size. Hint: they work great inside calc(), but provide terrible results on their own.

• Keith Grant Slides
• Keith Grant Video

Lea Verou demonstrated various ways to use native CSS variables (AKA CSS Custom Properties) – already available in all modern browsers aside from IE/Edge.

As a side note: Lea live-codes her entire talk, and it’s amazing to watch. I learned (after the fact) that she has speaker notes overlayed directly on her slides at low color contrast – invisible to the audience, because projectors can’t handle the subtlety, but clearly visible on her own screen. I love it.

She covered a lot of material, but here are a few things that stood out to me:

The first CSS variable was currentColor, added to Opera in 2009. The new CSS variables are actually more like custom properties, written with an “empty” prefix (e.g. --property) – and solve a much different issue than Sass variables by inheriting as part of the DOM. Here’s a basic example for defining and accessing a custom property:

.this {
  --color: blue;
  color: var(--color);
}

You can use an @supports block to add custom properties to your site as progressive enhancements:

@supports (--css: variables) {
  /* etc */
}

@supports not (--css: variables) {
  /* etc */
}

By default, custom properties are inherited. You can turn off inheritance for a property, by resetting its value to initial in a universal selector:

* { --property: initial; }

A few use-cases to note:

• Apply variables inline, to create variations on a global style e.g. style="--color: blue" on a button element – especially when using JS to adjust styles, so the logical definitions remain in CSS
• Change a --gutter variable at different viewport sizes, instead of re-defining your gutter properties directly
• Create property shortcuts with pre-filled default “theme” values
• Create custom long-hands for changing a single aspect of a short-hand property like box-shadow

You can also use custom properties to handle autoprefixing, or setting multiple properties at once. Setting the global value to initial ensures that nothing new is applied by default, but any new value will be applied to all the properties at once:

* {
  --clip-path: initial;
  -webkit-clip-path: var(--clip-path);
  clip-path: var(--clip-path);
}

Some custom-property gotchas:

• Properties are case-sensative
• Don’t work well inside the url() function
• Can’t have an empty value :; but they can have a single space value : ;
• Values are typed token lists, so you can’t do things like var(--size)em to add units to a number
• Adding units is simple using e.g. calc(var(--size) * 1em), but there is no good way to remove units – so it is often best to store unitless values, and only add the units when they are needed.
• Variable definitions (--my-color) won’t animate, but you can animate properties (background: var(--my-color)) that call the variable, and achieve the same outcome.

There’s so much more! I highly recommend watching the video.

• Lea Verou Slides
• Lea Verou Video

Sara Soueidan was scheduled to talk about SVG, but talked instead about hacks that she has learned to appreciate while working on the redesign of a major site. I found it hard to take good notes – but this talk is well worth the watch. So much good material in here!

Henri Helvetica talked about optimizing page and image sizes for the web. Did you know mp4 videos have better performance than gif images? Sites like Twitter convert your animated gif into mp4 format for display.

• Henri Helvetica Video

I showed a wide range of uses for the underused Sass “map” data type – from simple site theme configurations, to data storage, and complex functional programming.

• Miriam Suzanne Video

Zach Green walked us through his Webpack setup. I missed most of this, recovering from my own talk.

• Zach Green Video

Emily Hayman demonstrated the ins and outs of using flexbox to build “content-driven” layouts, instead of forcing our content into grid colums. It’s a great overview, and I particularly resonate with the “step lightly” philosophy that was repeated here. If you need a refresher on the how and why of flexbox, this is a great place to start.

• Emily Hayman Video

Justin McDowell used CSS transforms, grids, and more to bring Bauhaus-inspired art and layouts to the browser. It’s a fun and beautiful talk, that includes a demonstration of “Dolly zoom” (also known as the “vertigo effect”) in CSS.

• Justin McDowell Slides
• Justin McDowell Video

Amelia Bellamy-Royds gave us a full overview of changes in SVG2, along with a history of SVG. This talk is packed full of useful information, if you are using SVG in any way.

• Amelia Bellamy-Royds Slides
• Amelia Bellamy-Royds Video

Alisha Ramos closed out the conference with a rousing talk about diversity (and privilege!) in tech. A few take-aways:

• It’s important to be aware of the privileges that got you where you are.
• Diversity is not just a pipeline issue. Representation is worse in the workforce than it is in training programs. A pipeline is only as useful as the place it takes you.
• Culture-fit can be problematic when it refers to “drinking buddies” instead of shared values.

I would have taken better notes, but I was too busy applauding. This was a great way to end the conference. You should watch the video, and I should find my local Black Girls Code (or similar) to volunteer.

• Alisha Ramos Slides
• Alisha Ramos Video