On Tuesday, December 9th, I had the opportunity to attend CSSConf Oakland. CSSConf originally started in the US on the east coast (Amelia Island) and has since expanded to Australia (Melbourne), Europe (Berlin, Germany), and Asia (Sentosa, Singapore). This was the first conference they’ve held on the US west coast, which took place at Oakland’s eclectic venue, The New Parkway Theater. The one-day event — a part of the week of JSFest Oakland events — was filled with like-minded designers and developers who share a passion for front-end development, architecture, and product design.
The conversations I took part in with the speakers and attendees were very valuable and I took away a lot of resources to apply to my current projects. It was great talking with people who were as passionate about user-centric design, accessibility, and product design as they were about Cascading Style Sheets! ☺
I enjoyed the quality and range of the talks and topics, as well as the diversity in speakers. The fellow attendees were also very friendly and eager to learn. Seven women and five men in the industry presented CSS-related talks in a single track. Here, I’ll share my notes from the talks.
“What Makes Something Revolutionary?”
of Oddbird, SassConf, & GothamSass
Our tools transform our behavior.
Pave the cowpaths
Examples like these show that we can do this ourselves — we don’t need to wait for institutions to make things work for us. We can do this ourselves via collective participation + collective action.
We make great strides to advance and help create better technology. Where can our skills help give back to humanity?
Keep creating and innovating, and generating ideas and giving back.
“The Future of CSS”
of Google Chrome & the CSS Working Group
There are a lot of new features coming in CSS that will make our development lives easier. Here are just a few that are particularly exciting:
- image() function — souped up url()
- image-set() function — specify multiple resolutions
- cross-fade() function — smoothly fade between 2 images
- image-rendering() function — types of scaling (pixelated, crisp, etc)
- Flex box improvements and grid alignments
- Selector improvements — :nth-child indexing, :matches
- Improved color functionality — alpha(), hwb(), gray(), color()
- Additional media queries for pointer/touch, course/fine, hover, whether it allows for animation (useful for e-ink devices), luminosity, etc.
- Animation — web animation spec and motion path
- Poly-filling CSS — the real future — can make custom media queries, pseudo-classes, functions, mixins, at-rules, layout
Contact the working group with ideas & feature requests. They’re listening!
“SVG Can Do That?”
of Ladies Learning Code & HackerYou
SVG can do much more than display a vector graphic.
VREAM: “viewBox rules everything around me”
There are ~80 valid SVG elements. There is so much more you can do with SVG than just display a vector graphic. You can do:
- Editorialized text, which is responsive because the viewBox will scale automatically.
- Curved text
- Fancy fills (gradients, images, patterns)
- Image effects and masks
- Filter effects — SVG your own Instagram!
- You can mix and match these to get some really interesting results. Imagine an animated .gif masked inside editorialized text.
- Animations — you can actually animate the SVG drawing itself, and it can do fun tweens.
“What’s in a Name?”
Exploring the Origins of CSS Namespace Colors
of Code for America
Color is fascinating. There are many attributes of a color: hue, saturation, brightness, variants. These can lead to some interesting names for them.
The web is made up of colors, information, stories, people. Let’s find out the stories around our available color names. Most of us are aware of a recent name, RebeccaPurple (#663399). How did we get the other color names?
The names are not original to CSS. These web standard colors have been around since the 80's and have been used for other screen UIs as well.
There are some benefits to using namespace colors in your project. They’re guaranteed to work in all browsers, and have been time and user-tested for accessibility. Plus they have fun names!
Many of the color names came from Sinclair paint swatches. And many came from Crayola crayons.
Let’s get more colorful on the web. Of course, you always want to remember testing colors for accessibility and contrast. But we shouldn’t be afraid to use color. Don’t ask permission to use pastels.
Let’s make the web more colorful!
“Tonight, We’re Gonna Code Like It’s 1999.”
Creating Responsive Emails
Designing and developing emails are hard. Here are some tips & tricks learned along the way:
Keep email text light. Use eye-catching imagery. Have a logo on the top so it’s clear who the email is from. Make all your email communications consistent and drive brand awareness.
“An aesthetic Prince would be proud of!”
We all know that tables are terrible to use for layout and that we shouldn’t use them for that purpose. Email design says, “LOL” to that.
Make sure your links are very tappable so emails are easy to interact with on a mobile device.
You can add display: block to the outer table so it will respect your max-width, which you need so emails don’t stretch super wide and unreadable on wide browser windows. A good max-width should be around 550–600px.
You’ll have better design consistency across mail clients if you inline your CSS. There are many tools out there that make this easier.
Use comments to clearly define where tables begin and end, especially since you’ll find you’ll need to nest them.
Make sure you’re using alt attributes on your emails in case the images don’t load in. That way users know what they’re missing.
You can use @media queries to make responsive adjustments. If doing this along with inline CSS, you’ll find yourself having to use !important. Pay attention to your device pixel ratios as well.
Check your line-heights — they may cause gaps. And check for white-space in your markup. They can also cause gaps.
or “Things I Learned in CSS Through My 10 Years or So of Typing It Sometimes”
of clrs, CSS Stats, Pesticide, Fluidity, Tachyons, CSS Uncut, etc.
Adam Morse used to work with us here at Salesforce UX! It was great seeing him speak at the event!
On the web, you can change something very quickly and someone may not have noticed if there was an error. However, if you send many people a printed piece and there’s an error, you can’t really take that back.
As designers, we need to be empathetic. Everyone has a veil of ignorance.
CSS is only ~20kb!
The user is the most important part of what we’re doing. We need to remember:
- Everything should be 100% responsive.
- Everything should be readable on any device.
- Everything should be as performant as possible.
- Designing in the browser should be easy.
- Doing one thing extremely well promotes reusability.
“Better Product Design with HTML & CSS”
Design is a process.
Typically, that process looks something like:
Sketching → Wireframing → Photoshopping → Coding
Sometimes that takes a while.
We need to get from the sketch to the code much faster to greatly improve product design.
Get to code faster!
Doing this will:
- elevate the conversation through real data, real “feels”, real interaction
- promote systemic design — think about components across pages instead of pages of components
- allow you to speak the same language as the final output — work things out through coded components instead of design spec’ed pixels
Speed is a feature.
This will make you think through problems more realistically in a more real environment. This will make you a better product designer.
“Building with CSS First”
Steps to CSS Degradation:
- Determination — I’m gonna make a maintainable CSS architecture. Let’s do this!
- Development — Okay, we’re getting there, we can still do this.
- Denial — Hey, everything is fine. We’re still… pretty clean and maintainable.
- Despair — This is a disaster.
How did this happen? No tests, no conventions, no CSS Reuse.
“bootstripe” — Stripe’s CSS framework:
Convention for classes: .[namespace]-[component]-[descendant]- -[delimiter]
Example: .bs-searchbox-button- -hover
Rework, pseudo-classes + grunt-huxley, checked into GitHub, to see diffs.
“Build CSS first to think about CSS less.”
“Useful Frontend Metrics”
of CSSConf Australia & Calibre
Everyone on your team is responsible for the performance of your site or app.
Okay, you know all the rules (minify everything, async JS, use CSS animations instead of JS, base64, etc). But what next?
- Monitor your work.
- Set performance budgets.
- Don’t rely on what you know. Prove it.
“Implementing a Visual CSS Testing Framework”
We tried a lot of tools out there now, like Huxley, PhantomCSS, Ghost Story, Cactus, etc. None of these really did exactly what we wanted, and so we built our own. The process:
- Visit the page
- Screenshot the page
- Upload the screenshot
- Get a diff
- View the diffs
Avoid false positives. Try making your own! (See her slides for more in-depth steps on how she built it.)
“I have no idea what I’m doing”
of RetailMeNot & ATXSass
The tigers don’t matter.
Read: The Commandments of Work. We’ve all heard “Fake it ‘til you make it.” We should change our perception: “I’m not good at this” should become “This challenges me.”
There are three parts of the pie chart:
- tiny piece: stuff we know
- slightly larger piece: stuff we know we don’t know
- rest of the pie (huge piece): stuff we don’t know we don’t know
Levels of knowledge:
novice → advanced beginner → competent → proficient → expert
Rather than focusing on making the tiny piece of “stuff we know” larger, focus on making the huge “stuff we don’t know we don’t know” smaller.
share your doubts
celebrate your wins
We are made of the words we choose. There are no shortcuts. Be kind to yourself. Know what it means to succeed.
Inspiration exists, but it must find you working. — Picasso
Overall, the quality of the talks given were top-notch. It was interesting to see other people’s workflows and how they approach front-end architecture and process. I definitely learned a lot and I’d highly recommend attending a future CSS Conf!