Let's serve everyone good-looking content

in thoughts

In Benjamin’s poll, the second most voted reason to avoid Grid Layout was supporting Internet Explorer users. I think it all depends on how we want to support users. Of any browser. Warning: opinions ahead.

What lack of Grid Layout means

Let’s look at what a browser that does not support Grid Layout actually means.

What it is not

To be very clear, let’s all agree this is not the case:

That would be bad. Luckily, it is not that bad. CSS comes with a cascade, which includes the mechanism that the values of style rules are always set to something. Rules have a default value, which is usually what browsers will apply for you. It can be overridden by a website’s stylesheet, which in turn can also be overridden by user stylesheets. Because of the design of CSS, properties always compute to some value.

What it is

When turning an element on the page into a grid, we apply display: grid to it. At that point, it becomes a grid container and we can apply grid properties to it (and its children). If we set display: grid in an unsupported browser, the element will simply not become a grid container, and it will not get any of the grid properties you set applied. The display property will be whatever it was, usually inline or block, different elements have different defaults.

A little sideline: per spec, if you use floats (or clear), they will be ignored on children of grid containers. This is great for fallbacks.

Without Grid Layout, you still get your content, typography, imagery, colours, shadows, all of that. It will likely be displayed in a linear fashion, so it will be more or less like most mobile views. That is a perfectly ok starting point and it is good-looking content that we can serve to everyone.

Serving users good-looking content

I think our goal, rather than supporting specific browsers or specific CSS properties, should always be this: to serve users good-looking content and usable interfaces that are on-brand. I think good-looking and usable do not depend on how griddy your layout is. On-brand might, though. Some brand design guidelines come with specific grids that content needs to be layed out in. But aren’t we already used to stretching such guidelines, building responsive interfaces that work across viewports? Shouldn’t we let go, because we cannot control a user’s browser?

If for some small proportion of our users, we let go of the specific grid we created with grid layout, that will not hurt them. Likely not without any fallback, but definitely not with a simple fallback based on floats, inline-block or maybe flex and/or feature queries. But keep it simple. As Jeremy Keith wrote:

You could jump through hoops to try to get your grid layout working in IE11, […] but at that point, the amount of effort you’re putting in negates the time-saving benefits of using CSS grid in the first place.

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere. We already do this across devices of different sizes. For responsive design, we’ve already accepted this inevitability. This whole thing is a communication issue, more than a technical issue.

Save costs and sanity

If we succeed in the communication part, we can spend less time on fallbacks, now and in the future (I’m not saying no time, we want good-looking content). An example: that mixin we created to automatically fallback grid to flex to inline-block might look like a great piece of engineering now, it may later become a piece of hard to comprehend code. Solving the communication issue instead of the technical one, will save time in initial development costs and help prevent technical debt.

Comments & mentions (19)

HJ Chen replied: "Solving the communication issue instead of the technical one, will save time in initial development costs and help prevent technical debt."
Large Heydon Collider replied: Been meaning to mention this, but your site appears to have no max-width, hence very long measure and no margins?
HJ Chen likes this
Nathan de Vries likes this
Ahmad likes this
Anselm Hannemann likes this
Jeremy Keith replied:

A terrific piece by Hidde, about CSS grid, but also about a much bigger question:

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

If users don’t mind, that leaves us with team members, bosses and clients. In my ideal world we should convince each other, and with that I mean visual designers, product owners, brand people, developers, that it is ok for our lay-out not to look the same everywhere. Because serving good-looking content everywhere is more important than same grids everywhere.

Adactio Links replied: Let’s serve everyone good-looking content hiddedevries.nl/en/blog/2018-0…
@baldur@toot.cafe replied: “Let’s serve everyone good-looking content” hiddedevries.nl/en/blog/2018-0…
Grrr Tech replied: Loving the message of @hdv in this article on Grid Layout: it touches on why it should be ok for layouts not to look the same *everywhere*.

hiddedevries.nl/en/blog/2018-0…
Grrr Tech replied: Loving the message of @hdv in this article on Grid Layout: it touches on why it should be ok for layouts not to look the same *everywhere*.

hiddedevries.nl/en/blog/2018-0…
Front-End Front replied: Let’s serve everyone good-looking content hiddedevries.nl/en/blog/2018-0…
Claudio Semeraro replied: "I don’t think we owe it to any users to make it all exactly the same. [...] users don't mind."
Let's serve everyone good-looking content - hiddedevries.nl/en/blog/2018-0…
ShitMarcusSays replied: #RT @marcusklaas: @hdv een klasse functies waar je een hoop mee kan berekenen dat in normale SQL extreem moeizaam of traag is
ShitMarcusSays replied: #RT @marcusklaas: @hdv wat ik bijvoorbeeld vaak wil is: geef me binnen elke groep de rij waarvoor een waarde maximaal is. zonder window functions is dat bijna niet te doen
CSS {IRL} replied: This: hiddedevries.nl/en/blog/2018-0…
Unknown replied:

Hidde de Vries posted some excellent thoughts on not bothering with complex CSS fallbacks for older browsers (in this case when using CSS grid):

I don’t think we owe it to any users to make it all exactly the same. Therefore we can get away with keeping fallbacks very simple. My hypothesis: users don’t mind, they’ve come for the content.

Granted, what we mean by “content” is vague. A blog post is different from a list of trainers, which may require a more complex layout than a single column. But what always strikes me about these types of posts (which have been written for years) is that they don’t take the obvious next step and recommend ditching complex layouts altogether.

If users don’t care about a complex layout then why should the people making web pages? Why do we bother creating griddy layouts at all when it means more work and more code?

(Actually, a few designers have argued just this.)

Hidde acknowledges the main reason for implementing grids is to keep on-brand: Some brand design guidelines come with specific grids that content needs to be layed [sic] out in. In other words, it’s not users who demand grids, but marketing departments.

But that’s not a good reason, and something designers should resist. You could argue for making things look fancy for their own sake by referring to the world of advertising. Companies still pay for display adverts and TV spots because they communicate something about the the “brand” beyond its content and price. They don’t want to look cheap, and nor does your website:

… an ad can emit a powerful signal about a brand, regardless of information content. Online ads are cheap and easy to make, but the problem is, they look it.

But this is by the by. Even if we accept the Don Draper logic, a simple layout doesn’t have to look cheap. If your user is happier with plainer then that’s a good business reason for keeping it simple. Online, the interface is the brand, and your testing and feedback should dictate the layout you implement.


Note: That’s not a reason to discard CSS grid

Frontend Daily replied: Let's Serve Everyone Good-Looking Content: hiddedevries.nl/en/blog/2018-0… (Whether or not their browser supports the latest layout model or not.)
Hidde de Vries replied:

The year is about to end, so it is time for another year in review post! I love reading what others write about their years, hopefully mine is interesting to some people.

Like last year, I’ve divided stuff into highlights and things I learned. To be clear, that doesn’t mean I had a year consisting of 100% highlights and learnings, there is also stuff that went wrong, wasn’t amazing or was personal, I just think they’re for elsewhere (in person over drinks).

Highlights

Projects

In 2018, I spent most of my time in Mozilla’s Open Innovation team, working specifically on the IAM project. For those unfamiliar with it, IAM is short for identity and access management, it is about how people proof who they are and get access to stuff with as little friction as possible. It’s been super exciting to build most of the front-end for a project codenamed “DinoPark”.

In the last quarter, I’ve also spent a day a week working at the City of The Hague, specifically helping with improving accessibility and profesionalising front-end development of their digital services. It’s been great to see improvements shipped both in the application’s code as well as the content management system product.

Other short engagements included:

  • teaming up with Jeroen and Peter, I helped NOS, the Dutch broadcaster, with an accessibility audit, user tests with visually impaired users and an in-house presentation on technical accessibility
  • I ran a one day workshop on accessibility guidelines at Zilveren Kruis
  • with Peter, I worked on JavaScript to power a chat-like interface for the Dutch government

Volunteering

I did not do a lot of volunteering this year, but I did translate the Inclusive Design Principles into Dutch and worked on improving MDN documentation on accessibility.

Conferences and events

This year, I attended these events:

I spoke multiple times, too:

I did my CSS Layout workshop three more times (for Fronteers and at Front-end United) and ran a new accessible components workshop (for Frozen Rockets).

Organisers, thanks so much for having me. The first time conference speaking was stressful, time-consuming and very scary, but also satisfying. I got great feedback, both praise and things I can improve on (thanks, you know who you are).

I’d love to speak more in 2019, please do get in touch if you want to have me present at your event or give a workshop.

Writing

I published 26 posts on this blog, not including this one. Like I said in last year’s review: I very much recommend writing, it can be helpful in many ways. It is also great to be able to do this on a domain you own, on pages you designed. If anyone needs mentoring around this, get in touch, I would love to help!

Some of the most read posts:

Reading

It felt a bit weird to have the Goodreads app keep me in check reading-wise, but it did the job. I managed to read more than the goal I set. Some that readers of this blog might find interesting:

Book covers of brotopia, klont, common sense and killing commendatore
  • Brotopia, about the ‘bros’ that founded some of the biggest Sillicon Valley corporations and the culture they created. I must admit some doubts towards the word ‘bro’ , but wow, the book taught me a lot about how I don’t want to be and where I don’t want to work.
  • Klont – if you read Dutch, get it! This novel brilliantly captures the phenomenon ‘datafication’ and how it endangers some of the basic concepts of free societies, as well as, unrelated, the phenomenon of ‘experts’ traveling the world to give talks
  • Common sense, the Turing test and the quest for real AI – sometimes fairly technical and academic, but I loved the hype-free thinking about artifical intelligence and what to expect from it
  • Killing Commendatore – if you’re into Murakami or want to start reading his work, this is great. It is a lot of pages, in two parts, but worthwile. I read the Dutch translation, it is available in many other languages, too.

For all the ‘big data’ and AI expertise that Amazon, which owns Goodreads, has, the app is still very bad at recommending new books. For me, it doesn’t go beyond what the most generic airport bookshops stock. The real human beings I have befriended there brought much more reading inspiration.

Things I learned

Some random things I learned:

  • I finally got my hands dirty in declarative client-side component frameworks. My framework of choice was Vue.JS. I learned concepts like routers, props down / events up, reactivity and lifecycle hooks, enjoyed working in this paradigm, but even within that, I mostly wrote just JavaScript, good markup and sensible CSS. I have a blog post upcoming on this.
  • I learned in multiple projects this year how hard it can be to explain the concept of focus. It exists as a thing in the browser (the document.activeElement), but also as a thing in people’s thinking, not necessarily the same way. And then I’m not even talking about indicating focus yet. In my talk in Groningen I spent a number of slides trying to get it crystal clear. I like Laura Carvajals “You wouldn’t steal their cursor” and tried a streetlights metaphor (they are not pretty, but if they’re not there, you can’t see where you’re going at night)
  • I worked with WCAG 2.1 in real projects (testing for the newly added success criteria and talking about them in slides)
  • I added CSPs to some sites (see also How I learned to stop worrying and love CSPs)
  • I did more background reading to better understand the world we’re developing front-ends for (super meta), inspired by various colleagues, conference speakers and friends

What I want to get better at next year:

  • writing and presenting
  • I want to try and build something with Rust
  • get more people excited about having a personal website with a blog

With that, I wish all readers a fantastic 2019! If anyone has written year in review posts, I’d love to hear about them in the comments/webmentions, and read what you have done.

Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.