It was a pleasure speaking at CSSConf 2016 in Boston!
Here are some of my notes from the event –
covering everything from creativity and the Bauhaus
movement to SVG 2 internals, React styles, CSS grid layouts,
and custom properties (e.g. CSS-native variables).
I included links to slides and video whenever possible.
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.
Question the base premises
Impose artificial bounds
Repurpose existing solutions
Combine existing solutions
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.
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
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.
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?
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.
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.
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.
Lea Verou demonstrated various ways to use native CSS variables (AKACSS 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:
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:
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.
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.
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.
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.
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.
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.
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.
For many years, it has been ‘best practice’ to use relative units (especially em and rem) for sizing text. That’s great! But after playing around with my user preferences, I think we can improve on the common approaches.
It is frustrating to track down why an anchor isn’t being found. I’ve found a simple way that should work in most cases. If that doesn’t work, step through the checklist, and then dive in to get a better understanding of how Anchor Positioning works.