CSS and Child-Proofing

I’ve watched my sister put out a beautiful display of perfectly non-choke-able sized toys and games for her 18-month-old child to play with. Know what the Kid does?

Goes straight for the plug socket. Figures out how to open the door to the backyard, where there is a pool. Carries her bicycle around and tries to ride the dog.

So my sister has bought those little plug covers, built a fence around the pool, and constructed a couch fort for the dog (keeping him out of view, if he chooses to be in the same room as the Kid).

What does all this have to do with CSS?

Just as there are too many possibilities to account for once the Kid’s in a room, there are too many variables to test for once a design’s on the Web. Child-proofing and writing CSS are about mitigating the worst possible outcomes.

Figure out where things will break (i.e. become unreadable or inoperable) and manage those cases. Yes, under optimal circumstances, the Kid will play with her plushy animal mix-and-match game and the design will look like Figma. But you cannot guarantee those circumstances and should not expect them.

I’ve learned to write CSS as if my niece is coming to play with it. That means exercising author control in so far as it doesn’t conflict with user control and acknowledging the browser is better positioned to calculate final values than I ever will be.

CSS works best when you anticipate the unhappy paths. Watch out for choke hazards and sharp edges and hide the dog and everything will be fine.

More resources:

• Stephanie Eckles’ Developing for Imperfect: Future Proofing CSS Styles
• Ahmad Shadeed’s Defensive CSS
• Andy Bell’s Be the browser's mentor, not its micromanager