Tags: ties

48

sparkline

Relative Requirements – CSS Wizardry

I really like this exercise by Harry. I’ve done similar kinds of grading using dot-voting in the past. It feels like an early step to establishing design principles: “this over that.”

By deciding what we value up-front, we have an agreement that we can look back on in order to help us settle these conflicts and get us back on track again.

Relative Requirements remove the personal aspect of these disagreements and instead focuses on more objective agreements that we made as a team.

CSS: Current, Soon, Someday (Web Directions Code 2017) // Speaker Deck

Oh, how I wish I could’ve been at Web Directions Code in Melbourne to see this amazing presentation by Charlotte. I can’t quite get over how many amazing knowledge bombs she managed to drop in just 20 minutes!

0825 — ericportis.com

Well, well, well …following on from my post about container queries, it turns out that Eric has also been thinking about wrangling custom properties. He’s even written some code.

Using CSS variables correctly - Mike Riethmuller

Mike examines the real power of CSS custom properties compared to Sass variables—they can change at runtime.

I’m convinced that in almost all cases, responsive design logic should now be contained in variables. There is a strong argument too, that when changing any value, whether in a media query or an element scope, it belongs in a variable. If it changes, it is by definition a variable and this logic should be separated from design.

Learn CSS Grid - A Guide to Learning CSS Grid | Jonathan Suh

A quick visual guide to CSS Grid properties and values.

Organize your CSS properties however you dang like – Michael.blog

Neither matters all that much and you can use every method on the same project without the universe imploding.

Some interesting approaches in the comments too.

The invisible parts of CSS · MadebyMike

This is a really clear explanation of how CSS works.

Designing Systems, Part 3: Components and Composition / Paul Robert Lloyd

Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.

If you missed the other parts of this series, they are:

  1. Theory, Practice, and the Unfortunate In-between,
  2. Layers of Longevity, and
  3. Components and Composition

Designing Systems: Theory, Practice, and the Unfortunate In-between / Paul Robert Lloyd

Paul is turning his excellent talk on design systems into a three part series. Here’s part one, looking at urban planning from Brasília to London.

CSS Reference - A free visual guide to the most popular CSS properties.

A whole lotta CSS properties and values gathered together in one place. The one-page view is a bit overwhelming, but search and collections can get you to the right bit lickety-split.

Pragmatic, Practical, and Progressive Theming with Custom Properties by Harry Roberts

Harry demonstrates a really good use for CSS custom properties—allowing users to theme an interface.

AMP Design Principles

These design principles are meant to guide the ongoing design and development of AMP. They should help us make internally consistent decisions.

I’ve added these to my collection of design principles.

City Objects

A catalogue of objects and observations from cities around the world.

Progressive Enhancement—Ain’t Nobody Got Time for that | GlückPress

Two sides of a debate on progressive enhancement…

Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:

If your content website breaks down from JavaScript issue — it is broken.

Joe Hoyle disagrees:

Unlike Rarst, I don’t value progressive enhancement very highly and don’t agree it’s a fundamental principle of the web that should be universally employed. Quite frankly, I don’t care about not supporting JavaScript, and neither does virtually anyone else. It’s not that it doesn’t have any value, or utility - but in a world where we don’t have unlimited resources and time, one has to prioritise what we’ll support and not support.

Caspar acknowledges this:

I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).

But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:

Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.

See also: Mike Little’s thoughts on progressive enhancement and accessibility.

Cameron’s World

A wonderful collection of treasures excavated from GeoCities. Explore, enjoy, and remember what a crime it is that Yahoo wiped out so much creativity and expression.

Access Optional - TimKadlec.com

It will come as no surprise that I agree with every single word that Tim has written here.

Ignite Bristol 07 - Dan Williams - Walt Disney World - YouTube

I’m at Disney World for a special edition of An Event Apart, so this lightning talk from Dan Williams seems appropriate to revisit.

Incomplete List of Mistakes in the Design of CSS [CSS Working Group Wiki]

I think I concur with this list. Although I guess it’s worth remembering that, given the size of the CSS spec, this isn’t an overly-long list.

It’s interesting that quite a few of them are about how things are named. It’s almost as if that’s one of the, say, two hardest things in computer science.

Edible Geography

I’m not sure how I managed to miss this site up until now, but it’s right up my alley: equal parts urban planning, ethnography, and food science.

Paris Review – “One Murder Is Statistically Utterly Unimportant”: A Conversation with Warren Ellis, Molly Crabapple

Molly Crabapple interviews Warren Ellis. Fun and interesting …much like Molly Crabapple and Warren Ellis.