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 wheneverpossible.
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 lovelypeople.
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 availableonline.
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 thevideos.
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 inmind.
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 aswell.
Question the basepremises
Impose artificial bounds
Repurpose existing solutions
Combine existing solutions
Use open source code (this seems like an extension of 3 and4)
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 beautifulsamples.
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 acrossdemographics.
I didn’t take thorough notes on his overview of PhantomJS, but there
were a few philisophical points that stoodout:
Test everything
Make sure everyone on the team can write tests for the code theywrite
Take the time, on occasion, to review and clean up your tests –
otherwise you will run into bloat and compile-timeissues
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 nativeAPIs.
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 awebsite.
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.
Idon’t.
From the JSX perspective, CSS has several majorproblems:
It was designed for documents, notapps
The cascade was intended to merge author & user styles, a feature
that is rarely used (I’m not sure about thatclaim)
The global name space leads to regular class-nameconflicts
The React approach:
No static HTML, all DOM nodes are generated withJS
Build components out of othercomponents
Single-class selectors only (e.g. BEM) for unambiguous
name-spacing ofclasses
Class-names referenced only once in JS, private to the component,
and functionally equivalent to inlinestyles
Of course, this causes some new issues that have to be solved by the JSprocessor:
Adding new custom attributes to the syntax for handlingpseudo-elements
Performance issues (addressed by “injecting”styles)
Server rendering is difficult, maybe Webpack can provide asolution?
Jen Kramer provided an overview of past and present CSS layout
techniques, and an introduction to the new CSS Grid feature (still
only available behindflags).
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 UIcomponents.
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 seconddimension.
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 bothdimensions.
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 inproduction.
Will Boyd provided guidelines for creating smooth animations in CSS.
To avoid jank, you have to keep all animations and transitions at60fps.
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 ourefforts.
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-acceleratedanimations).
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
soon.
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 onperformance.
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 otherproperties.
Keith J. Grant argued for using a combination of em and rem
values, instead of px, for sizing on theweb.
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 relativeunits.
Since em units are relative to inherited font size, they pose a
particular confusion – two em values in the same block can render to
differentsizes:
/* 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.
Keithrecommends:
Always use rem for font-size
Use px for border-width, since you often want thinlines
Use em for everythingelse
Line heights remainunitless
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 anothercomponent.
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 thatmore.
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 theirown.
Lea Verou demonstrated various ways to use native CSS variables (AKACSS Custom Properties) – already available in all modern browsers aside
fromIE/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 loveit.
She covered a lot of material, but here are a few things that stood out
tome:
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 customproperty:
.this{--color: blue;color:var(--color);}
You can use an @supports block to add custom properties to your site
as progressiveenhancements:
By default, custom properties are inherited. You can turn off
inheritance for a property, by resetting its value to initial in a
universalselector:
*{--property: initial;}
A few use-cases tonote:
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 inCSS
Change a --gutter variable at different viewport sizes, instead of
re-defining your gutter propertiesdirectly
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 atonce:
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 anumber
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 areneeded.
Variable definitions (--my-color) won’t animate, but you can
animate properties (background: var(--my-color)) that call the
variable, and achieve the sameoutcome.
There’s so much more! I highly recommend watching thevideo.
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 inhere!
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 fordisplay.
I showed a wide range of uses for the underused Sass “map” data type –
from simple site theme configurations, to data storage, and complex
functionalprogramming.
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 tostart.
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”) inCSS.
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 anyway.
Alisha Ramos closed out the conference with a rousing talk about
diversity (and privilege!) in tech. A fewtake-aways:
It’s important to be aware of the privileges that got you where youare.
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 takesyou.
Culture-fit can be problematic when it refers to “drinking buddies”
instead of sharedvalues.
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) tovolunteer.
Learn how to leverage Web Platform Tests to ensure your polyfills are implementing upcoming browser features correctly, including how to generate a comprehensive report of failing/passing tests on each change.
OddBird sponsored Python Web Conference 2023 and sent me to attend. In this article I showcase my favorite talks and activities from this excellent online event, including a list of useful resources for web application security, introductions to new PaaS providers, and a comparison of the most popular Python web frameworks.