Hard to read one-liners

All surgical staples got removed from my knee today, so that's a win. You could say I got rid of some optional closing tags. So, sitting with my leg up again, time for a knee-jerk reaction on Vasilis' comment the other day, your source looks nice (except for the style block, with the hard to read one-liners.

This is interesting in multiple ways, because somehow, as a community, we agreed that this looks nice:

<input type="text" name="foo" id="whatever" class="something" autofocus placeholder="Hold it">

Something, with some properties and some values.

But this is a hard to read one-liner:

input { box-sizing: border-box; max-inline-size: 100%; border-radius: 1.23em; font: inherit; }

Something, with some properties and some values.

As if CSS has some unwritten rule about how it should be written. Many people would say this looks nicer:

input {
	box-sizing: border-box;
	max-inline-size: 100%;
	border-radius: 1.23em;
	font: inherit;
}

Something, with some properties and values, separated on each line.

Applying that logic to HTML, would those people also say this looks nicer?

<input
	type="text"
	name="foo"
	id="whatever"
	class="something"
	autofocus
	placeholder="Hold it"
>

Something, with some properties and values, separated on each line.

Let me try to change your mind on CSS one-liners. Or, a bit more realistic, show what's on my mind about this. After writing CSS for about 25 years, and trying out various, uh, styles: In 90% of all cases, I think, the complexity isn't in the properties and values, but in the selectors. And in the scope, and in figuring out how you've structured and ordered your selectors. Or how the person before you tried to do that. I'm trying to optimize for that part, when writing plain CSS (which is always, on my own projects). Also, when coding, screens are typically landscape oriented. One-liners make sure I'm using more of my available pixels.

I know, with version control, and teams, and same-line commits, you'll have conflicts with one-liners. But I'm not in a team today. And I'm not using version control for my own projects anyway. (In teams, I'll adapt to whatever is used, and I'll try to blend in. For a while.)

At FDND we're doing a mix of this, since we do want to make our students nice team players. But we also want to nudge them into not writing too many selectors, by nesting their media queries. Since CSS nesting will be Baseline Widely available in two months, we think that's smart to start using at school. And most will eventually use tools like Sass, which transpiles this anyway. Or never write CSS again and cry about React and Tailwind complexity all day. But I digress.

Oh, right, media queries. I haven't added those to this site yet, but now I'm thinking about it, I want to try out this style:

body { max-inline-size: 40em; margin-inline: auto; padding-inline: 1em; font-family: sans-serif; line-height: 1.6;
	@media (min-width: 30em) { display: grid; grid-template-column: 1fr 1fr; }
	@media (min-width: 50em) { grid-template-columns: 1fr 2fr auto; }
	@media (prefers-reduced-motion: no-preference) { transition: .2s ease-out; }
	@container style(--theme: whatever) { --do-something: different; }
}

As in: put the selector and the media queries as close to each other as possible. That's where the complexity is in responsive design. Not in the finicky details and syntax within.

Comments

Okay, I understand that you have a reason for it, and it even kinda makes sense, in a nice contrarian kind of way. Ignoring conventions is a healthy thing. And happy to see that the reason is not performance, hahaha.
Recently I gave some students the advice to write multiline HTML when elements have many attributes. It makes it easier to see what’s going on.

I didn’t give the advice to you, I gave it to my students. If you know HTML like you do, multiline probably doesn’t make it easier. But if you just start learning HTML, and you have no idea of all the possible attributes, that’s a different case.

Add a comment