Shorts

Sounds like somebody needs an introduction to the ridiculously talented illustrator, Phoebe Wahl.

So, Cloudinary can do the exact opposite of what Jeremy wants:

BRB putting in a feature request for blurring everything but faces.

This morning, Jeremy Keith blogged about container queries. He provides much to chew on, but right now I just want to tackle this paragraph, because it seemed as good of an excuse as any to push an experiment out the door:

Custom properties feel like they could be wrangled to help with the container query problem. While it’s easy to think of custom properties as being like Sass variables, they’re much more powerful than that—the fact they can be a real-time bridge between JavaScript and CSS makes them scriptable. Alas, custom properties can’t be used in media queries but maybe some clever person can figure out a way to get the effect of container queries without a query-like syntax.

I’d been thinking along the same lines; here’s my best shot at a custom-properties-based interface for container/element queries: presto-points.

I’ve got draft post about this experiment titled Two Good Ideas and a Bad Idea About Container Queries. Spoiler alert, the bad idea is the custom properties interface. The syntax hits a nice little 80/20 point, as far as what I think most people want to do right now, and might provide a not-terrible stopgap while we wait for something better. But it isn’t a sufficiently flexible foundation for the future. For that, I think, we really do want a true query-like syntax.

More later and hopefully soon.

Re: Jonathan Snook’s Container Grids

First of all, huh! I guess Grid tracks do act sorta like pseudo contain: size layout style; (but not paint) elements.

You’d probably have to outlaw min-content and max-content grid track sizes, when using grid/container queries. minmax() too? Sometimes? That’d be a big loss.

What are the pros of tying container queries to a layout system that contains by default, rather than allowing arbitrary opt-in containment? I can think of a few:

• People are already using Grid but nobody is using contain, yet.
• Simpler for implementors. Far fewer edge cases.
• Simpler for authors? You don’t have to think about where or when to sprinkle magic contain dust – this just becomes another cool feature of Grid.

Cons:

• Less flexible, of course. You can only use Container/Element Queries when you’re also using Grid.
• One of the primary use cases for Element/Container Queries is modular drop-anywhere “widgets”. Jonathan’s proposed syntax requires me to put some of the information about a widget’s styles (namely, its breakpoints) on its Grid container. So, while we’ve moved our breakpoints much closer to the content – from breakpoints-on-the-viewport to breakpoints-on-the-grid-track – we’re still designing from the layout in, rather than from modular, independent bits of content, out. Boo.

Lastly, a criticism of the syntax:

I’m imagining a syntax similar to responsive images that allows you to specify the minimum width for which the grid would apply.

.grid {
	display: grid;
	grid-template-columns: 
	200px 300px 600w, 
	200px 200px 1fr 900w;
}

w descriptors in srcset describe the intrinsic width of the external image resource, but do not instruct the browser to do anything. The ones above are lil’ media queries – micro-if/then statements about exactly what to do under what circumstances. This proposal would be better if it just used media-query-like syntax (that queries the grid container, not the whole viewport):

.grid {
	display: grid;
	grid-template-columns: 
		(min-width: 600px) 200px 300px, 
		(min-width: 900px) 200px 200px 1fr;
}

Fiddling with this.