John Ternus is the CEO of Apple, and Lake Ontario is still Lake Ontario

I present two screenshots I just took a few minutes ago, on September 1, 2026.

The first image is from Apple’s website. As of today, John Ternus is the new CEO of Apple, taking over from Tim Cook, who led the company since Steve Jobs’ death in 2011.

The second, of course, is from the Apple Maps app, correctly identifying the… uh… least great of the Great Lakes by the name it has had since long before either Canada or the United States existed as countries: Lake Ontario.

Now, of course, if you were to look at that same lake today on Google Maps, it would be incorrectly labeled as “Lake America” because… well, you know why.

I’ve been a map geek since I was a kid. Since before I had ever heard the name of the guy who decided Lake Ontario needed to be renamed. If you had told me that someday “She Makes Henry Eat Onions” would need to be changed to “She Makes Henry Eat Apples,” I’d have said “That’s about as likely as my very educated mother serving us something other than nine pizzas.” Well, times change. Still, the bar for renaming an international body of water should be even higher than the one for demoting a planet. (There are good reasons for renaming things, but a temper tantrum isn’t one of them.)

The timing of the decree that this change should occur was telling, because a similar decree was issued last year, and Apple fell in line almost as quickly as Google did. But not this time. What’s different?

This time, it was just days before Apple’s change of the guard. And just like how you “can’t” appoint a new Supreme Court justice in an election year (except when you can), I guess you can’t rename a Great Lake right before a new CEO takes over.

Where am I going with all of this?

For the past year and a half, let’s just say, Apple has handled certain situations in certain ways. And now they seem to be handling them differently. John Ternus is not Tim Cook. And John Ternus’s Apple is not Tim Cook’s Apple.

This seems like a rather absurd detail to dwell on, but I don’t think it’s an accident or a coincidence. Watch this space. (“This space” being Apple Maps.) Whether or not that lake gets renamed there will tell you a lot, I think, about how John Ternus thinks.


Postscript: I don’t really believe in synchronicity (nor do I believe my devices are surveilling me 24/7). But I also don’t think about planetary mnemonics, like… ever. The last time any phrase starting with “my very educated mother” crossed my mind was probably the same day I learned the term “dwarf planet.”

And yet, here’s something funny that just happened. I referenced that mnemonic in this blog post, and then, less than an hour later, as I have been working my way through the New York Times Connections archive, I happened to play the puzzle from April 23. I immediately spotted the most unlikely grouping of words.


Update, a few hours later: Oh well.

Screenshot

Gravity Forms: the selector you need to override default CSS variable values

I’m a big Gravity Forms fan. It’s the WordPress form plugin I recommend to all my clients.

Recent versions use a new theming engine for styles, with a default theme called Orbital. I do like the fact that it offers a lot of style customizations in the Block Editor. The only problem is, you can’t save your own default preferences for these settings. You can copy your styles from one block and paste them onto another, but that’s a pretty weak substitute for just setting your defaults that you want all of your forms to use automatically.

The Gravity Forms documentation doesn’t really acknowledge this seemingly obvious need. But I did manage to find a thread in their support forums that gets right at it. There are just two problems: a) the given answer is not quite right, and b) the forums automatically lock threads after 24 hours.

As far as that second issue goes, I kind of get it; I know how much forums can be magnets for spammers. But it seems easy enough for a paid plugin to restrict forum posting access to paying customers, which should pretty much eliminate that issue.

Of course, the only reason I even cared about that is that I have a correction to address the first problem, but I can’t post it as a reply on the thread, because of the second. So I’m posting it here instead.

The problem with the answer in the forum is that it assumes the CSS code is in the body tag, but it’s not. So, here I present, the correct (well, a correct) selector for applying your own overrides to the CSS variables in the Orbital theme:

html:has(#gravity_forms_theme_framework-css)
.gform-theme--framework.gform-theme--orbital


(That’s supposed to have a space in it, not a line break, but it’s too long to fit on one line in my current site theme, and a line break is fine in CSS code formatting anyway.)

The change I made was to replace body with html at the beginning of the selector.

I’ve confirmed this works, with my main goal of overriding the default blue “accent” color with one of the colors from my client’s customized Astra theme, like this:

html:has(#gravity_forms_theme_framework-css)
.gform-theme--framework.gform-theme--orbital {
	--gf-color-primary: var(--ast-global-color-2);
}


I don’t consider this a complete answer though, because a) it doesn’t change the accent color in the Block Editor sidebar, and b) that technically doesn’t matter, because when you use this CSS, the accent color in the sidebar gets ignored anyway.

Still, the goal here is mainly to impose my consistent theme style on the forms, so I’m not so concerned with the user being unable to customize the appearance. In fact, I don’t want them to be able to customize the appearance.

Ultimately, there are two features I want Gravity Forms to add, so I’ll shout them into the void here and try to will them into existence.

First, I’d like a global configuration page for the parameters of the Orbital theme, and/or for all of the default CSS variables.

Second, I’d like the ability to turn off the style tools in the Block Editor.

Come on Apple, give me more control over the stupid crap I don’t want in your interfaces

I can sometimes get hung up on small, seemingly trivial details of things. A perfect example of that is the absolutely stupid “bounce” animation on Liquid Glass on/off toggles in the “26” OSes.

I have been wanting a tidy way to get rid of that annoying nonsense from the moment I first saw it. It’s one of many things about Liquid Glass that annoyed me enough that, as soon as the “27” OS betas were available, I immediately installed them on all of my devices — my Mac, my iPad, and my iPhone. Even though betas can be unstable. I’d rather have instability than the hideous mess that macOS 26, in particular, has been for the past several months.

So anyway, I’m not entirely sure if the “Reduce Motion” option had this particular effect in 26, but in 27, one of the (many) things it changes in the interface is that it removes the bounce. Yes!

I don’t really like some of the other motion reductions, especially the transitions between apps and the home screen in iOS, but I’ll live with it.

Unfortunately, and honestly quite surprisingly, I discovered that one of the things it reduces is animation in web pages. Including animated effects I might be working on within websites I’m building for clients. While in the Block Editor on a site I’m currently building, I noticed the following alert:

So, in other words, the only way I can get my Mac to not have that dumb bounce effect on OS interface toggles is to turn off my ability to see animated effects I’m creating in websites I’m building.

This is a very small problem in the grand scheme of everything in the world going completely off the rails. And yet, it’s a part of it.


I also don’t like the fact that Pages and Numbers have AI auto-suggested filenames when saving new documents. Just stop.

I nearly fell for a phishing scam. They’re getting more sophisticated (or I’m getting less)

A couple of days ago, I received an email from a client whose site I’ve been managing for over a decade, but who doesn’t have much reason to contact me on a regular basis, because, not to brag, but generally when I build something, it just works.

The subject line was BID PROPOSAL (in all caps), so my immediate thought was, ah crap, they’re planning to redo their website and they’re not just automatically giving the project to me. Bummer. But at least they still want to consider me.

Here’s the message:

I should have immediately suspected the curious phrasing of “Kindly review” but I was too concerned about the nature of the message to focus on that detail. In retrospect, I also should have been suspicious that the “To” field was addressed to herself and I was listed in the “Bcc” field but, then again… if you’re blasting this out to a bunch of different people, that would be the easiest way to do it.

Of course, if that was the case, the “inform me if any modifications are required” bit wouldn’t make any sense. Never mind any of that though, this was late in the afternoon and I was sitting on a beach reading this, so I wasn’t exactly giving it my full level of concentration.

I opened the PDF and was confused, because it looked like a special invitation to some kind of private event. I became convinced that the client meant to send this to someone else who has my same first name — that happens to me a lot. So, not yet thinking anything was untoward (which, again, I probably should have already), I replied:

Very quickly she replied:

OK, so, at this point, I was finally starting to get suspicious, but mostly I was just so confused by it all that I wasn’t thinking clearly. “Thank you for reaching out!” certainly seemed odd.

Anyway, I took another look at the PDF, was still confused by the vague wording of it and the fact that it didn’t come right out and say what I would be submitting a proposal for, but since this isn’t a client I want to lose, I ignored the nagging feeling that something wasn’t right.

There was a link in the PDF to access the full details, so I clicked it. (Again, it’s all so obviously “off” in hindsight, but in the moment I kind of just went with it.)

The link initially went to a Cloudflare CAPTCHA page, which wasn’t entirely surprising, and I was mainly thinking, wow, they are really being excessively cautious with this whole thing.

And then it happened. The moment that shook me out of my beach vibes stupor. It took me to the Google account login screen. Or, at least, a page that fully appeared to be the official Google account login screen. Hence that bit in the last email about having to “authenticate using your email address.”

Uh yeah… no way. Sorry phishing scammers. I may be getting old and clueless, but I’m not that old and clueless. I immediately closed the window, deleted my cookies, cleared my cache, and even restarted my computer for good measure.

Then I checked the raw source of the original email, and it did appear to originate from this client’s legit email account, so it was obvious at that point that she must have gotten hacked. Instead of replying any further to the email chain, I sent an email to her boss, saying I had just gotten a really suspicious email from her and asking if she had been hacked.

The next day he replied, confirming that was the case.

Now, of course, I suppose it’s possible that I got infected with a virus by even opening that PDF, but… I doubt it. These scams are all about social engineering. Why bother writing a virus when you can just convince someone to hand you their Google login credentials?

Stupid CSS Selector Tricks

I’m impressed with the logical capabilities of modern CSS, even if it does result in mind-bending selectors like this:

li:not(:has(> a:hover))

I just wrote that bit of CSS to resolve an issue I have with dropdown menus on a site I’m working on.

The top-level nav items need to have a dark blue background and white text when you’re hovering directly over the link itself. They also have an accessibility toggle caret next to (but not inside) the link.

When you’re hovering over the accessibility toggle, or the submenu — i.e. anywhere within the li that isn’t the a directly inside it — then the top-level item needs to have a light blue background with dark blue text.

The problem I had was, the caret was staying white when I hovered over any part of the li.

This CSS selector is perfect for styling the li under all conditions except when the user is hovering over the direct descendant a tag. If you’re hovering somewhere within the li itself, i.e. the caret, or anywhere at all inside the nested ul for the submenu (even on a link within that submenu), then the above condition applies.

Now that I think about it though, this selector is not quite accessible enough. It really should be this:

li:not(:has(> a:is(:focus, :hover)))

😵‍💫

Don’t even get me started on :is vs. :where.