This is the kind of thing that I find maddening about Gutenberg

First off, if you are the regular reader of this blog, you are painfully aware of how much I am waffling on rejecting or embracing Gutenberg (a.k.a. the WordPress Block Editor). There are things I genuinely do like about it, but I also have some fundamental disagreements with its approach (like the facts that it writes inline CSS directly into post content, or that its templates don’t support PHP code).

And then there are the weird little quirks that just make using it much more difficult than it needs to be. In general I have learned that this comes down to the incredible finickiness of JSON. Fine. But the fact that one character out of place in the theme.json file can break everything seems a bit ridiculous… or at least, a big step backwards for usability.

Fix your syntax. Sure. I wish JSON allowed trailing commas the way PHP — and even JavaScript! — does, but I can grok the fact that it doesn’t and learn to adapt. What I have a bit more trouble with is the problem that struck yesterday, only because it was so hard to pin down.

I’m working on a new, small block theme as a one-off for a unique project — a website that will feed menu board monitors in a pizza place. Seems like a perfect opportunity to practice and experiment a bit with what Gutenberg can do. (And, after over a decade of trying to find the “right” way to give restaurant staff a reliable but still easy-to-manage web interface for updating menu information, I actually think Gutenberg’s Block Patterns might be the optimal solution.)

So here’s the maddening thing. I was setting up my theme.json file like a good Block Theme developer, defining all of my colors, typography, etc. And then I started loading in some test content. All looked fine on the back end, in the Block Editor itself. But none of the styles were getting applied on the front end!

I googled the problem, of course, and found a WordPress forum thread about this very issue.

Huh. Sure enough, what’s described in the thread was exactly what was happening in my case. I had this line in my code (font names changed to protect the innocent):

"fontFamily": "'Helvetica Neue', 'Comic Sans', 'sans-serif",

Do you see the problem there? (No, it’s not the trailing comma… that actually belongs, in context.) It’s the stray apostrophe before sans-serif. Removing that fixed the problem.

Now, if this were just in straight CSS, I would have seen the problem immediately, because the syntax highlighting in BBEdit would’ve gone all wonky. But since this was inside a text string in JSON, it looked just fine, and I didn’t notice the apostrophe was there.

I get that the parser that converts the contents of theme.json into CSS would get thrown off by this. Honestly, I’m surprised it didn’t cause the whole page to bork with a PHP fatal error… I’m pretty sure earlier versions did throw a fatal error if there was any problem parsing the theme.json file. So this is… an improvement?

I also get that the generated CSS output would not work properly. What I don’t get is that it all looked correct in the Block Editor. Why was the Block Editor on the admin side able to “fix” this issue, but on the front end it didn’t? It doesn’t make sense!

Anyway, trying to unravel that mystery wasted about an hour late yesterday afternoon, when I was finally starting to get productive after having a near existential crisis over Gutenberg for most of the week.

These are hard times to be a WordPress developer. No, strike that. These are hard times to be a generalist web developer who happened to make the fateful decision 8 years ago to go all-in on WordPress.

How to listen to “classical” music, a 20-second guide

When I was in college, I went to NCUR (’94, I believe) presenting a paper I wrote for music history on Baroque performance practices on modern recordings, using Handel’s Water Music as an example, and specifically comparing an $18 CD by an ensemble that specialized in Baroque music with a $5 budget CD by an anonymous orchestra.

Today I went looking for Debussy (not Baroque, that’s not the point) in Apple Music, and… ugh. Not saying you should judge a book — or a recording — by its cover. But when that’s all you have to go by, it can still be fairly effective. There is so much anonymous garbage on the streaming music services now. (Granted, Spotify is orders of magnitude worse in this regard than Apple, but both are plagued by it.) I feel like I need to write an updated version of that paper for 2022.

Hint: Don’t waste your time listening to an album with a generic landscape cover and a title like “The Most Famous Classical Music” or “The Best Classical Music.”

Although I was hoping to hear something new today, I ended up settling for the same album I have owned on CD for ~25 years. This one is excellent.

My hot take on 303 Creative v. Elenis

This morning I’ve been preoccupied with 303 Creative v. Elenis, a case presently being heard by the Supreme Court. I have a lot of complicated thoughts on this case. Too many to sit comfortably with long enough to craft a well-structured blog post about, when I have actual work I need to be doing.

But since this case has potential implications for my “actual work,” it matters. I’ve been exploring the idea with some friends on Facebook, so for now I am going to just encapsulate my thoughts with a few lightly-edited excerpts of what I posted there.

First off, let me be clear that I’m on the opposite end of the political spectrum from Lorie Smith, the plaintiff in this case. But we do similar work, and I absolutely feel that as a freelance consultant, I should have a right to choose which projects I take on. I would have no problem building a website that was pro-same-sex-marriage. But I would absolutely choose not to work on a website that was anti-same-sex-marriage.

In broader terms, I would eagerly accept work that fights discrimination, while I would actively refuse to accept a project that promotes discrimination. But it’s impossible to just invert my political beliefs and say that’s where Ms. Smith stands. Because the work itself isn’t for or against discrimination. It’s the refusal to do the work that constitutes the discrimination. Still, should she be legally compelled to do work she personally disagrees with?

That case with the bakery a few years ago always made me feel uncomfortable, even though ultimately I sided with the gay couple who wanted the cake. I think I’ve hit on the key point: there is a significant difference between selling an off-the-shelf product in a public space, vs. accepting a job to produce new custom work to client specifications, or to do future work-for-hire off-site.

In baking there’s a “gray area” in work-for-hire, unlike web design, and it comes back to the generic sheet cake example. (The baker was willing to produce a generic cake for the couple.) There’s no equivalent to a “generic sheet cake” in web design, other than a service like Squarespace. I don’t think a service provider (e.g. Squarespace) that commodifies a website as a prebuilt, “off-the-shelf” product should be allowed to discriminate in who uses its service, as long as their activities are legal. That’s radically different from compelling a “creative” to produce new, custom work promoting ideas they don’t agree with.

But ultimately this whole case just reeks of ulterior motive by the political right wing. Any reasonable person in my position, when asked to take on a project they disagree with (or just don’t care to do, or are too booked up to take on) should just offer to refer the potential client to someone else and leave it at that. This lawsuit is not about individual freedom of speech… it’s a salvo in a culture war. I suspect it could even play a role in future cases concerning content moderation on social media sites.

Happy holidays from Room 34!

I was stuck inside the house today, so I decided to do this… a few years back I arranged Vince Guaraldi’s “Linus and Lucy” (from A Charlie Brown Christmas, the best Christmas album of all time) for my band, 32nd Street Jazz. I decided to tweak that arrangement just a bit, muster my best effort at brush technique on the drums, and see if I could pull it off. I did!

Don’t use JPEG for logos, example #24,315

A client just sent me a logo to add to their website. I let out a little whimper when I looked at the file and noticed that, as is so often the case when someone sends me a logo, it’s a JPEG.

Don’t use JPEG for logos!

Without naming names (or, hopefully, showing enough of the logo to give away the identity), here’s a close-up detail of the actual JPEG I was sent, which does a really good job of illustrating the issues. I zoomed way in on the file in Affinity Photo (my preferred alternative to the 800-pound gorilla of design software), and captured a screenshot which I am sharing here as a PNG — the correct format for logos, because it doesn’t introduce these “compression artifacts“:

Just in case the problems are not readily apparent to your eye, here’s a version where I’ve cranked up the contrast to accentuate the inconsistency of the colors in the image:

And for comparison, here’s what the same level of detail would look like if the image were delivered in PNG format instead of JPEG:

Of course, these days we can do even better than PNG. If a logo is a vector-based design (which it really should be), we can use SVG to get a perfectly sharp rendering of the logo at any size. Here’s what that would look like, zoomed in the same amount:

To be clear: the logo is not for my client’s organization itself. If that were the case I would have pushed back. It’s the logo of a partner organization that was provided to my client to add to the site, so there’s probably little that could be done. (OK, that’s not true; I could — and did — do what I often do in this situation. I went out and found a PNG version of the logo myself.)