10 July

Some problems just never go away… especially where CSS3 multi-columns are concerned

Note: This post has been updated.

I don’t use CSS3 multi-columns (based around the column-count and column-gap properties) very much, mainly because a) I don’t need columns in my layouts very often and b) usually when I do need columns, this method is inadequately flexible for what I’m trying to accomplish.

Today I have a good use case though. A simple (but long) list of links, that I want to display as 3 columns on wide screens, 2 columns on tablets and a single column on phones. Great, except when I got it working, I found that — in Chrome only, which is a bit odd — the top of the first column is higher than the rest. It looks fine in Safari and Firefox.

I googled, as always, for a solution, and found several suggestions that seemed like they should work, and people claimed they did work, but for me, they didn’t. Then I found this comment on a post on the topic, and decided to try the column-break-inside property, which is something I normally only use in print CSS.

It still didn’t work. But then, vendor prefix to the rescue! I needed the -webkit prefix, and it worked. This needs to be applied to the elements inside your column container, not the container itself. Here’s my full CSS block:

.columns {
  -moz-column-count: 3;
  -webkit-column-count: 3;
  column-count: 3;
  -moz-column-gap: 3em;
  -webkit-column-gap: 3em;
  column-gap: 3em;
}

/* Fix for unbalanced top alignment in Chrome */
.columns > * {
  -webkit-column-break-inside: avoid;
  column-break-inside: avoid;
}

You’ll also want to repeat the .columns section (or its equivalent for your class/element names) in your media queries, changing column-count appropriately where you want to collapse down to fewer columns.

Since other solutions worked for other people, I’m guessing my solution might not work for everyone either. But I hope it helps someone… maybe you!

Update (6/28/2017)

This problem really does never go away. And I’ve just run into a situation where the above fix doesn’t work. This is only affecting Safari — I think Chrome has actually fixed the bug. But some trial and error led to this new solution that fixes the problem in Safari as well.

/* New fix for Safari */
.columns > * {
  display: inline-block;
  width: 100%;
}

I’m still not totally sure why display: inline-block; is the magic bullet for column alignment issues, but it works. Adding width: 100%; is what keeps these inline blocks from actually appearing on the same line, if they’re short enough. (Also note that I removed the column-break-inside stuff… don’t seem to need it with this change.)

Update (6/12/2020)

Wow… it really never goes away, does it?

Now I’ve found that if I am applying my .columns class to a <ul> tag, its <li> tags lose their bullets, because they apparently need to have display: list-item (or have it implied). When did display: list-item get added to the CSS spec anyway? I’d swear it didn’t even exist when I was first working on this issue, but I’m an old fart now and time has lost all meaning.

Anyway… I did manage to figure out a workaround to this. So add the following after the update above (which you’ll still keep):

/* New fix for Safari */
.columns > li {
  display: list-item;
  margin: 0 !important; /* Maybe you won’t need !important */
  padding-bottom: 0.5em; /* Add some padding to make up for any margin you’re losing above */
}

From the Stupid PHP Tricks files: rounding numbers and creeping inaccuracy

This morning as I walked to the studio I was doing what geeks do best: pondering a slightly esoteric mathematical quandary.

Glass Half Full by S_novaIngraining the American spirit of optimism at a young age, and under dubious circumstances, our schools always taught rounding numbers in a peculiar way. You always round your decimal values to the nearest integer. That part makes sense. But what if the decimal is .5 — exactly half? In my education, at least until late in high school (or was it college?), we were always taught to round up! The glass is half full. Optimism.

Eventually — far later than it should have been, I think — the concept was introduced that always rounding .5 up is not really that accurate, statistically speaking. It might be nice in the case of a single number to be an optimist and think a solid half is good as a whole, but in aggregate this thinking introduces a problem.

If you have a whole lot of numbers, and you’re always rounding your halves up, eventually your totals are going to be grossly inaccurate.

Of course, the same would happen if you were ever the pessimist and always rounded down.

The solution, I later learned, was to round halves up or down, depending upon the integer value that precedes them. Which way you go doesn’t really matter, as long as you’re consistent, but as it happens, I learned it as such: if the integer is odd, round up; if it is even, round down.

In my work, I write a lot of PHP code. Most of it is of the extremely practical variety; I’m building websites for clients, after all. But every once in a while I like to indulge my coding abilities in a bit of frivolous experimentation, and so today I produced a little PHP script that generates 10,000 random numbers between 1 and 100, with one decimal place, and then it shows the actual sum and average of those numbers, along with what you get as the sum and average if you go through all 10,000 numbers and round them to whole integers by the various methods described above. Try it for yourself!

Any time the rounded average is different from the “precise” (and I use that term somewhat loosely) average, it is displayed in red. Interestingly, and not at all surprisingly, when you always round halves in one direction or the other, at least one of those directions will (almost) always yield an incorrect average. Yet if you use the “even or odd” methods, both of those methods will almost always yield a correct average.

It’s all about the aggregate.

Questlove tries to salvage something of musical value from a (the) Philip Michael Thomas album

I just started following Questlove (drummer of The Roots) on Twitter less than an hour ago, and it’s already paid off with this little gem, which I believe is how he’s spending his summer vacation (i.e. week off from Late Night with Jimmy Fallon). Nice. It’s cool to see him in action at home (a.k.a. the studio).

Since the video is so tantalizingly incomplete, he has also shared the finished product.

Mellotronic, Mk. II: Jazz Odyssey

My loyal reader(s) may recall that back in May I posted a couple of new music tracks I was working on. One of them was a little too… meh… so I probably won’t be doing anything more with it, but I was really pleased with the early results of my work on a track I was tentatively calling “Mellotronic.”

Last night I put some more work into the track and I think it’s nearly complete. I just want to tweak some of the Mellotron parts a bit, and I am also thinking of re-recording the synth solo near the end. (It’s just a little too modulation and pitch bend heavy for the style of the track.)

I currently have 4 tracks I’ve been playing around with since the RPM Challenge that are complete or nearly complete, and they’re all drenched in Mellotron. (OK, I don’t own an actual Mellotron, but I do own the next best thing.) As a result, I am planning to go with Mellotronic as the name of a 4-song EP that I hope to release before the end of July.

This, of course, is the title track, which I am now calling “Mellotronic, Mk. II: Jazz Odyssey.” I hope the reference is obvious. Please enjoy this early rough mix of the nearly-finalized arrangement.

[audio:http://blog.room34.com/wp-content/uploads/underdog/mellotronic05.mp3]

Pay attention to the sustained note at the end. That’s one of the classic traits of the Mellotron, faithfully reproduced by the M-Tron virtual instrument: Mellotron tapes were 8 seconds long, so if you held a note for longer than that, it would stop. But some of the notes are not quite the full length, and since they’re actual recordings of real people playing the real instruments, sometimes they falter a bit. So I held the final chords on the flute and violin settings until they stopped. I’ve noticed in the past that the flute recordings seem a lot more… let’s say “variable”… than some of the other instruments, and that observation certainly bears out here!