As per CSSConf AU’s photo policy, I tried to be respectful and only photograph individuals who signalled by their lanyards they were okay with being photographed.

If you’re in a photo and would like it removed, please do let me know.

Barely a month after Mixin, it was time to jet off to one of the main sources of inspiration for our conference.

I arrived at the still rather-new Virgin Australia T1 terminal and checked in for my flight.

Virgin Australia Airlines
Plenty of Plane Hax... That dongle struggle is real tho

One plane-hack filled flight later, I landed in Melbourne. I departed the airport and made my way into the city to my hotel.

Somerset on Elizabeth
250 Elizabeth St, Melbourne VIC
29 Nov
Check in
2 Dec
Check out
★ ★ ★ ★

Now around 5:30pm Melbourne time, I had barely any time to settle in before the pre-conference social event in Collingwood.

I dropped my bags, picked up yet another Myki, and set off for Stomping Grounds in Collingwood, via the South Morang line.

Stomping Ground
100 Gipps St, Collingwood VIC
Beer Hall
★ ★ ★ ★ ★

There I met Patima and Mandy, two of our fellow talented Mixin conference organisers, and Mike, one of our excellent MixinConf 2016 speakers.

We met with other CSSConfAU attendees, the very talented and passionate organisers, and speakers.

Not to mention — a large number of Perth expats (Jacob, Mario, Simon to name a few, and more if I asked around I’m sure!)

It’s always nice to catch up with everyone in the industry. Sometimes being in Perth can feel a little isolated but we have such a welcoming community that whenever we return to Melbourne or Sydney and catch up with everyone, it feels a bit like seeing an extended family.

Some time much later that night, I decided I needed to get an uber home in preparation for the conference day ahead…

The next morning I set off for CSSConf. It was a brisk Melbournian morning as I headed for the North Melbourne Meat Market.

On the way I stopped in at Code Black Coffee to grab a quick filter to go.

Code Black Coffee
119 Howard St, North Melbourne VIC
★ ★ ★ ★ ★

I then headed to the Meat Market/Arts House, where many attendees were already congregating.

Before long the sign was placed outside, and we were in.

~(˘▾˘~) CSSConf Time Again! (~˘▾˘)~

After registration, I caught up with some fellow Perthians (or Perthons), some Melbournians, and some of the speakers.

After some coffee and bagels, we entered the theatre to begin the day.

Ben Scwarz and Karolina Szczur took to the stage to welcome us, set the ground rules and go over the housekeeping, before handing over to Kristina from CSSConfEU to emcee for the rest of the day, which was a nice touch.

Kristina then introduced the first speaker of the day.

Ally kicked off the day by examining how people less tech savvy experience the apps we design and develop. It’s sometimes easy to forget as developers in the first world with access to the latest phones and with high standards of network connectivity how our work fares in less ideal scenarios.

A lot of the work Ally encountered when working with people in West Africa led her to realise how different their experiences with technology were. Many had their first exposure to technology through second-hand, often knockoff phones, on networks with poor connectivity.

And while there are simple things we take forgranted — like scrolling offscreen elements into view — many less tech savvy individuals were unaware of it, simply because of lack of prior experience.

Another point Ally highlighted was the trend in flat design which eschews some visual affordance on elements. While we are still able to parse and use these interfaces, many less tech literate individuals are not as likely to realise they can interact with elements treated in this visual style.

This talk served as a great reminder about the impact of our work beyond those in our own immediate vicinity, which we can so easily think of as our only users.

As Senior Front-End Engineer at Vox Media, Ally took us through the process of making Accessibility a key part of Vox’s development process.

As designers and developers, the impact of disability is radically changed on the web because the web remove barriers to communication and interaction that exist in the physical world.

A key takeaway from Ally’s talk was that by designing with disabilities in mind, we create better products for everyone. The results may not always quantifiable, but we should remember that these decisions improve the experience for everyone, rather than considering accessibility as some sort of edge-case.

Ally stressed that for accessibility to be a key part of a team’s process, you have to make everyone care about it — not just a few people policing accessibility. In order to do so, Ally recommended keeping everyone accountable, making it part of the QA acceptance stage, and considering it as a key feature of any work.

After morning coffee, Michael was up to give a talk on AMP, a tech spec backed by Google with the goal of drastically increasing page performanace and load times on websites, because average users quickly abandon slow-loading websites.

Some of the features of AMP include async everywhere, dns preconnect for third party services, static layout engine and content prioritization.

One of the nice things about AMP is once you’ve loaded it in, you get a lot of the nice benefits without much additional effort on your part. The impact of loading an AMP page from a list of Google Search results is quite remarkable, with pages appearing to load nearly-instantaneously.

Michael was keen to stress that even if you don’t want to use AMP, their ideas and goals are a good idea and you can follow along with some of their recommendations in order to optimise the performance of your own site.

In “At Least 6 Ways To Win With CSS Modules”, Josh recounted the pain points of CSS which led to the creation of CSS Modules.

Josh noted there are some valid things that are difficult to do with CSS Modules. But then went on to show that some of the habits we’ve accumulated when naming components in CSS is largely a result of the global scope, specificity wars and inheritance, and that with CSS Modules, we can actually breath out and let some of that go.

Of the 6 ways of winning with CSS Modules, perhaps my favourite was the removal of FORC, or fear of removing CSS. When working with CSS Modules and refactoring, if one of the UI components is not imported anymore, at that point it’s disconnected and far easier to delete CSS, without worrying it will affect anything outside the intended scope.

Ultimately, Josh concluded that with any decision there is a tradeoff. “Good or better” is subjective — what’s the cost?

In Josh’s experience, CSS Modules gave important value in a number of areas. Simpler class names and writing during authoring — only concerned with stuff that makes sense in your module. During Debugging, CSS Modules offered the benefits of immutabile CSS. With CSS Modules, it’s possible to look at a class name, and know what it means, without any more context. Explicit mapping to DOM is easy to trace back to source of error. And then Refactoring is made better with the dependency tree. As soon as a module is disconnected, it can be deleted.

After lunch, Nadieh took to the stage to discuss ways to use SVG for data analysis with SVG, and some of the fancy techniques she uses to turn her ideas and sketches of data visualisation into a reality.

One of the nice things that SVG affords us is that we can get far more creative with the way we visualise data. It allows us to build data visualisations which are interactive, dynamic, and even incorporate motion for context and meaning.

There was some rather inspiring and some mind-bending data visualisation examples, and I certainly want to play around more with SVG for data visualisation after seeing her talk. I can get behind seeing more motion blur and gooey svg effects in data visualisation.

A key takeaway from Nadieh was to think beyond mere static representations of data, and find more unique and meaningful ways to express information. By doing so, you can glean new insights from the same data, and people will often be more engaged.

Data is important, and how you communicate that data is equally important.

Barak took to the stage to deliver an entertaining and insightful talk about the gulf of time between a proposed CSS spec and its proper implementation by vendors.

First, Barak took us through the 4-step process, from stylesheet with CSS object model, to the layout, paint and composition phases a browser users to render a web page.

Houdini and the CSS Parser API allows us to hook into this process to implement out own constructs, custom functions and @rules in the same way we use media queries and custom font-face declarations.

By doing so, we are extending the CSS engine itself, and Barak gave a series of examples of how we might go about this, and create our own css values and properties to, for example, generate a QR code by calling an element with a custom URL value.

Another feature mentioned was the Typed CSS Object Model. Trying to get a value out of CSS and into javascript is complicated, and involves manipulating a string to get the numeric value and convert it to a proper number. With Typed CSS OM, values have type, with more context, and less transposing of that data to use it.

Houdini and the proposed CSS Layout Spec would allow you to define your own layout engine using the Layout API.

This is very performant as it runs on a separate thread, and would allow you to define the exact way in which the layout should work — no more weird cross-browser inconsistencies (once all browsers support Houdinin and CSS Parser API).

After a quick coffee break, José took us through some advanced image optimisation techniques and avoiding some common pitfalls.

One of the commonly-used incorrect ways to hide images that José pointed out is to call display: none on content images — the browser still sees the image tag and load the resource regardless.

A key point José made was that, unlike the costs associated with some technical choices, there is no downside to optimising your images.

He then identified some key ways to properly optimise images. The Picure element and srcset is one solution, but the markup and CSS is tightly coupled and keeping markup and CSS in sync is extra effort.

Lazy loading is another good technique, but can be difficult to get right. The forthcoming Intersection Observer API can help determine when elements are on the screen and should be loaded, and we can also improve the perceived performance by displaying blurry, low-file-size placeholders, and lazily load the full sized asset.

Serena took to the stage to deliver an entertaining and thought-provoking thought experiment about what the ideal CSS language would look like for our needs today.

She then took us through, step by step, the problems we tend to have with CSS these days, and how our ideal version of CSS would handle those pain points, including the cascade and specificity wars, and selectors, and how we’d like to see how we’d like CSS to do things.

One of the key takeaways for me was how little developers may understand the cascade. We often fear it, and perhaps don’t fully understand its limitations and opportunities.

Another key takeaway for me was this tension between the very object-oriented BEM methodology with one class, while it results in a lot of repetition of declarations, and Atomic CSS, which avoids heavy CSS repetition, but begins to pollute your markup with stylistic information. Reusability or separation of concerns. Can we have both?

Serena then pointed out that mixins — popularised by precompilers like Sass and LESS — allow for us to create functions we can reuse, which become quite powerful in native CSS. This keeps separation of concerns but allows for less repetition.

Petra took to the stage to discuss the importance of building better style guides for all users.

Creating online services for governments means making all Australians your audience — everyone who can access needs to be able to use it.

When you have an audience of everyone in Australia, that makes Accessibility of utmost importance. Last year, 5,000 sessions on government websites were using the Nintendo Wii’s web browser. Chances are, if you build your website to work for the Wii, it’ll work on anything newer than that!

Petra and her team were keen to come up with an approach that allowed them to build a reusable set of components across government websites, to help reduce repetition and improve consistency across the board. This resulted in the DTO Design Guide.

Petra had some useful and wise advice for building Don’t work in a bubble — design systems take a lot of people to build. Even though her team had research, design, and development capabilities — the team couldn’t prescribe all the ways in which everyone who used their styleguide, so being open ws important, and test early, and test often.

After a couple of quick group photos, CSSConfAU was over for another year…

… Well, not quite.

The Panama Dining Room
231 Smith St, Fitzroy VIC
★ ★ ★ ★ ★

The organisers, speakers, and fellow attendees met at The Panama Dining Hall to chat over some drinks and food. A fantastic way to end the day.