Last month, I was fortunate enough to receive a free diversity ticket to one of the days of #FinchConf, a front-end conference held in Edinburgh. I've chosen to attend day one, focused on Layout, Optimisation, and Organisation. Here are my notes.
Jeremy Keith (probably more famous as @adactio ) on Going Offline
The web has come a long way. Websites used to be static pages, which changed with the rise of JavaScript and then AJAX (which actually stands for Ask Jeremy About XML, true story). After we started doing stuff in JS, over time some of the things like :hover actually came down to declarative HTML/CSS languages, leaving JS for something more fun.
(And look where it led us. If twenty-aughts were all about “lets use more JS”, 2019 is more like “can we please tone it down with JS already”.)
We had a couple of paradigm shifts along the way, too. One came with jQuery, which ultimately changed the way we manipulate the DOM. The other might be coming now, with the rise of service workers.
Jeremy described service worker (SW) as a “man-in-the-middle attack on your own website”, which I think is quite brilliant. Indeed, after SW is installed on a device, it acts as an interceptor for network calls, which allows us to do all kinds of things like re-routing a request from going all the way to the server to look in cache at hand instead.
Considering we now have two possible sources - remote server and local cache, - there can be different strategies for implementing service workers:
- Cache first, which basically means “if you have a resource saved in cache, use it, and skip the network call”;
- Network first, or “try fetching the resource from server first, and if something goes wrong, get it from cache, or if you don't have it in cache, show a specifically designed offline page”.
Which one to use is up to you. Think about what content are you working with: most likely, styles can be cached, but a list of available products has to be fresh. We also don't have to decide everything for ourselves, and can offer choice to save the content for offline use to the user, as Sara Soueidan does on articles on her website.
Jeremy showed how easy it is to start using service workers. If you understand the general logic, you can implement them. There is no need for fancy frameworks or libraries, a couple of lines of JavaScript will do the trick. Throw in a manifest, which is a simple JSON file — and you have a PWA. You don't need to have a “web app” for this to work: having a website is perfectly fine.
Rachel Andrew (no, seriously, the Rachel Andrew) on CSS Layouts
If there's a motto for CSS Working Group, it's this: We can't break the web. No, really, we can't. We have to make sure every website, no matter how old, still works as expected after spec changes.
That's one of the reasons why spec writing is hard.
And yet, we still have a lot of new things in CSS, the biggest ones being, of course, flexbox and Grid.
If you think Rachel gave a once and for all answer to “should I use flex or should I use grid” question, you're wrong. Instead, she asked: “Well, does it work?”, and proceeded with an in-depth explanation of block formatting contexts (every time you set display property, you create a new block formatting context), two-value display properties (when you say display: grid, what you are really saying is display: block grid, first value for container, the second value for its children), and logical dimensions (width and height don't make much sense if document flow goes from right to left, do they?).
Rachel’s talk was packed with information. If you want to learn more about this, here are some articles by Rachel herself to dig into:
David Khourshid on Stateful Styles
@markdalgleish Designer: *presents beautiful, high-fidelity app screen mockup*
Developer: cool, this is one of... 1,208 possible states this app screen can be in... and we need an iOS and Android mockup too
Designer: I will start working on the second screen then!23:00 PM - 01 Sep 2019
36
214
Personally, I almost never get all the designs from UI department. A button or a link will most probably only have two states: regular and :hover; it's rare when :focus and :active are also provided. Every single link or button on the web have these states, and yet they are still forgotten. But your website or app can have a lot of custom states as well, eg “Fetching information from back-end” state, or “Loading” state, or “Success” state, or “Error” state.
That's a lot of states.
David talked about how using finite state machines and statecharts can make life easier for everyone involved. Business will have a clear overview of application flows, designers will know what screens are missing, developers will know what to implement.
David suggests to start development in old-fashioned way: with pencil and a piece of paper, in order to draw statechart for the app. It will define which states the app can be in, and what events can lead to transition between different states.
In code, the diagram can be represented as a simple object.
const machine = {
initial: 'idle',
states: {
idle: {
on: {
CLICK: 'loading'
}
},
loading: {
on: {
RESOLVE: 'success',
REJECT: 'error',
}
},
success: {
on: {
CLICK: 'loading'
}
},
error: {
on: {
CLICK: 'loading'
}
}
}
};
Getting the next state then is as easy as getting the value from this object:
const transition = (state, event) => {
return machine
.states[state]
.on[event]
|| state;
}
To tie JavaScript and CSS, David suggests using data-* attributes instead of classes. Not only they are designed to hold custom application data, but they are also easy to manipulate via JS and fully accessible in CSS.
If this topic if something you find interesting and want to dig deeper into, here are some links:
- David's XState library;
- Statecharts: A Visual Formalism For Complex Systems by David Harel;
- Pure UI, by Guillermo Rauch.
Chen Hui Jing on Devtools and Using Them to Understand and Learn Modern CSS
Modern CSS can be hard to bend your mind around when reading about it. We have a whole new layout system built-in now, and with it a whole bunch of new units, and the only way to really grasp it all is to play around with it - and here's where browser's devtools can help, showing the layout and the computed values for any selected element.
Hui Jing's slides for Finch are not up yet, but you can poke around their slides for ConnectFest or examples for Examining “squishiness” in Intrinsic Web Design article - and when I say “poke”, I mean “inspect different elements while resizing browser window like a hundred times to see how different values of different properties behave in different screen sizes, eg observe the difference between auto-fill and auto-fit (spoiler: the first one preserves space for empty “imaginary” columns while the second doesn't), and click on everything you haven't ever clicked on in devtools in browser of your choice”.
Harry Roberts on Those Small Properties You Can Add to Resource Links in <head> to Make Page Faster
Not much to add there. Resource hints are a simple thing to implement, and they make page faster, - use them.
Léonie Watson on Talking Technology
Screen reader users rely on machines to read out content, and the result is... boring. Yet there isn't much we can do about it, not on the web, at least - sadly, CSS Speech module has been retired due to lack of interest in implementation from browser vendors.
Shame!
We could have had amazing things, like control over voice, volume, and speaking rate, to make our websites more expressive not only visually, but also verbally.
The spec for CSS Speech is still there, so maybe one day it will be implemented. In the meanwhile, semantic HTML is free, and it makes real lives easier. Please, ditch endless <div>s and <span>s in favour of semantic elements 💛
All in all, I loved Finch. Every talk was great in its own way, and it's incredible how many famous speakers there were in one place. I overheard that it was a tough conf to organise, and there weren't many attendees - but I'm very grateful it still happened.
Happy coding, and gods bless.
Top comments (0)