[Robin]: Earlier this month Max Böck wrote about what he calls “the CSS Mindset” and it caught my eye this week because I think it details something that I’ve struggled to describe for a while. In that post, Max describes why it’s hard to write CSS and how it requires us all to look at web development in a very specific way:
Now, you probably need a mindset for coding in general, but the declarative nature of CSS makes it particularly difficult to grasp, especially if you think about it in terms of a “traditional” programming language.
Other programming languages often work in controlled environments, like servers. They expect certain conditions to be true at all times, and can therefore be understood as concrete instructions as to how a program should execute.
CSS on the other hand works in a place that can never be fully controlled, so it has to be flexible by default. It’s less about “programming the appearance” and more about translating a design into a set of rules that communicate the intent behind it. Leave enough room, and the browser will do the heavy lifting for you.
I agree with a lot of the points that Max makes in this post but I also feel like CSS is different to programming languages because it’s closer to a spoken language than it is to mathematics. So for example, on one end of the spectrum, mathematics is logical and empirical. On the other, language is adaptive and illogical:
And yet CSS sits in between these two – yes, it is coding and there are programmatic elements to writing it – but! – because we’re taking visuals and turning them into code the syntax for doing so is more like language in some ways:
So I would argue that “the CSS mindset”, if there is one, is where you have to work to keep this balance between the two. You have to be rigorous and detailed, but you also have to make visual design possible, and that will always require a little wackiness.
Anyway, this is why the handoff process between design and front-end is so fraught I reckon, because you have to push a design halfway towards the programming side of things. And Max has a few thoughts about that:
The number one mistake made by designers and developers alike is assuming that things will always look like they do in the static mockup. I can assure you, they will not.
And I completely agree on this front as whenever I work with designers I try to ensure that they actively check how things work in the browser; font rendering, icons, and spacing are good examples and all these things tend to take on different properties as soon as you move them out of a design tool and into the browser. Sometimes the effect is quite shocking.
This week I’ve also been thinking a lot about this stuff whilst checking out Andy Bell and Heydon Pickering’s new project this week: Every Layout. It’s a website that dives deep into exploring layouts with nothing more than CSS and goes about explaining what’s the best way to create some modern patterns that we’re all familiar with.
Andy and Heydon even give names to these layouts which I find pretty useful, too:
I’m uncertain if the names for these patterns will stick but I think it’s a really good start to describing layouts in a more responsive and expansive way, too.
? From the Blog
Beau Jackson takes a look at how to draw realistic clouds with SVG and CSS. There’s a few interesting tips and tricks in here, as well as some performance issues that I didn’t know about – take the box-shadow CSS property for instance. I didn’t know that on low-end devices this can have pretty big implications on scrolling performance.
This is the end result that Beau creates and it’s pretty gorgeous, huh?
Adam Giese teaches us all how to sort data with JavaScript’s native .sort method and he runs through all the edge cases that we might bump into along the way. Random sorts! Reversing sorts! Comparing strings and values! There’s so much that you can do with this method that it’s most certainly worth while to take a look at this one.
Chris made a quick note about CSS Grid, content order, and accessibility which I found pretty dang interesting. He quotes Rachel Andrew in his post where she writes:
I have long been concerned about the potential accessibility problems that grid layout could cause. These essentially centre around the concept of disconnecting the source from the visual display. […] If you mess around with the order – be that with flexbox flex-direction: row-reverse, or grid-auto-flow: dense, or by positioning items with grid layout – you risk making a very odd and disconnected experience.
So an example of this might be when you want to use CSS Grid or flex to change the order of elements on smaller devices. Maybe you want the navigation of a carousel to be moved to the very bottom of the screen for instance. Anyway, the issue is that we could cause a pretty weird experience for screen readers in the process.
What’s the answer to this? Rachel argues that:
…we sorely need to address at a CSS level. We need to provide a way to allow the tab and reading order to follow the visual order. Source order is a good default, if you are taking advantage of normal flow, a lot of the time following the source is exactly what you want. However not always, not at every breakpoint.
I wonder what folks will come up with to solve these problems – as although CSS Grid is this incredibly empowering suite of tools for us web developers it could cause a lot of issues for users of our websites. And we should never really trade developer ease of use for the user experience of our customers and readers.
SPONSOR
Hey, if you can build a site on WordPress.com, then you should build a site on WordPress.com. WordPress powers 31% of the internet and there’s a reason for that: it’s scales well for anyone, whether that’s a personal blog or a e-commerce site.
Use WordPress.com to start, update, and view your site seamlessly from any device. There is a generous free plan, but with any of three affordable paid plans you get a custom domain name and access to advanced design tools.
Some great referential JavaScript posts to round out the week!
