14 September

On canceling my Minnesota Twins season tickets, and the nature of professional sports

I’ve had Twins season tickets since Target Field opened in 2010. Not a full-season package, mind you. I don’t see how anyone who works for a living has time for 80 baseball games a year. Or even 40. But I’m now in my 13th year of a 20-game package, and most years (minor inconveniences like pandemics aside), I’ve actually managed to make it to 16 or 17 of them.

This year I’ve had a lot going on, and have had to reschedule (ticket exchange is a nice new benefit in the past couple of years) or miss entirely over half of the games in my package. Combine that with increasing concession prices with limited options (especially for someone who doesn’t eat meat), few other season ticket holder perks I find interesting, and the perennial futility of this particular team, and each year it has been harder and harder for me to justify renewing.

Finally over the weekend, when I missed two games in three days due to more schedule conflicts — mixed with a dash of struggling to care about a team that is once again failing to live up to even modest expectations of success — I decided I was done with it, and I emailed my rep to say I want to cancel for next season.

Last night was my first game since canceling. And what a game it was! The Twins had just finished getting swept in a 4-game series by the division rival Cleveland Guardians, a series that knocked the Twins — who had dominated the division in the first half of the season — down to third place, and below .500 for the first time since April.

But they came roaring back in last night’s game against the lowly Kansas City Royals with three home runs, and by the middle of the fifth inning, the crowd was beginning to notice that Joe Ryan also had a — shhh! don’t say it out loud! — no-hitter going.

By the end of the seventh inning, he still had a no-hitter going, and the excitement in the stadium was palpable. We might be witnessing Twins history… their first no-hitter in over a decade! But Kansas City was not making it easy. Pitch after pitch after pitch was fouled off, and by the time the last out was recorded in the seventh, Ryan had already thrown 106 pitches.

Twins manager Rocco Baldelli is a serious analytics guy. The whole game is numbers to him, to the detriment of fan excitement or even a moment of unpredictability. And one of the biggest numbers is that magic “100” pitch count. Once your starter hits 100 pitches, he’s done, no matter what. So I knew there was no way he was going to let Ryan come back out in the eighth, no matter how much of a case he might be pleading in the dugout.

So it was… Jovani Moran kept the no-hitter going through the eighth, but with one out in the ninth, he walked two batters, then gave up a double. The no-hitter was gone, as was the shutout. In the end, the Twins won, 6 to 3, but it felt worse than a loss.

I woke up this morning still thinking about the game, and getting philosophical about it, and about my waning enthusiasm for this team I have loved (at least, in fits and starts) since I was in middle school and they won their first World Series.

What is the purpose of professional sports? They are entertainment. That is their only purpose.

Fans pay a great deal of money to be entertained, and the people who comprise the “sports industrial complex” — professional athletes, coaches, staffs, broadcasters, etc. — make their very comfortable livings from the money those fans pay.

But guys like Rocco seem to think sports exist for some other reason unto themselves. That they matter in some way apart from the fans.

They do not.

If you are not making the game entertaining for the fans, you are failing at your job. And if you allow the game to be entertaining for the first 7/9, and then make a decision that ruins the remaining 2/9, you’re still failing… even if you win.

But here’s the thing: even if sports did exist for a reason unto themselves, Rocco’s approach is not going to lead to success. A conservative, risk-averse, analytics-obsessed approach can only take you so far. Baseball needs an element of risk, of surprise. Bold, unexpected, sometimes irrational decisions are what make a good team great, or at least make an average team fun to watch.

The best the Twins will ever be with Rocco’s approach is “good.” Yes they touched greatness in 2019, with their first 100+ win season since 1965, and setting an MLB record for team home runs in a season, but something strange was going on in the entire MLB that season with juiced balls or something. Then, of course, that team that was so dominant in the regular season still instantly fell apart in the postseason, because that’s what the Twins do. And that’s never going to show up in your analytics.

Making Bootstrap work with the WordPress Block Editor

tl;dr: You need to load Bootstrap’s CSS in the 'wp_enqueue_scripts' hook with a priority lower than 10.

Where do I begin with this one? First, some foundational details: I’m old school. I’ve been a professional web developer/designer since 1996. I’ve embraced new technologies as they come along, but I tend to bristle at things that are either a) not an open standard or b) need to be compiled.

I refused to use Flash. In the end I was proved right, as open web technologies supplanted it. Flash is dead, and the open web is not. I still refuse to use CSS preprocessors for a similar reason. They’re a non-standard workaround to limitations in the current standard. They fragment the landscape instead of pushing the standard forward. And as CSS variables have gained wide browser support, preprocessors are beginning to look as pointless as Flash.

Now the thing I hate is npm — or any similar tech that requires me to run shell scripts and compile anything. I’ve long since embraced server-side scripting, using open source libraries like jQuery, and even using a pre-built CMS (or CMS-ish system) like WordPress. (Yes, for many years I rolled my own CMSes.) The bottom line for me is, if it’s code I can download simply and treat as a “black box,” fine. But if it’s something I need to get my hands dirty in, I shouldn’t need anything to work with it but a text editor.

All of that to say, I am having a bit of a time with where things are going these days with Gutenberg, a.k.a. the WordPress Block Editor. And I haven’t exactly been quiet about it here.

This week I needed to extend the Block Editor by creating a carousel/slideshow block. Yep, I’ve rolled my own with these for many years as well, but this time around I decided I wanted to work with something pre-built, so I settled on the one in Bootstrap. I don’t really need all of Bootstrap (although I suspect over time I will need more of it), but customizing it requires using npm, so I decided to go ahead and include the entire pre-compiled package in my theme.

That’s when the problems began.

Oh, the carousel works great! But I spent a bunch of time yesterday trying to figure out why the custom background color and fonts defined in my theme.json file were being ignored… especially since they’re right there in the inline CSS inside the <head> of every page.

Don’t even get me started on inline CSS, or the way so many people in the industry seem to worship PageSpeed Insights. Once again we’re skating to where the puck is, instead of where it’s going, and to stretch the analogy to the limit, we’re melting all of the ice in front of it too. This is not the way to move web development forward intelligently.

Ah-hem.

Eventually I worked out what’s happening. WordPress, historically, was designed to allow you to define dependencies, so you could load CSS and JavaScript in a logical manner. Gutenberg/Block Editor throws all of this out the window with this inline CSS. Certain “critical” inline CSS for the Block Editor gets loaded immediately regardless of the dependencies you put into wp_enqueue_style(). The result being, styles defined (indirectly, in a way more convoluted way than vanilla CSS) in my theme.json file were appearing before the Bootstrap CSS file was loaded. And since I’m using the compiled Bootstrap instead of a custom npm build, there’s a bunch of “general” CSS it’s throwing in, including color and font definitions on the <body> tag that override Gutenberg’s earlier inline CSS.

Fortunately, someone else had the same problem and figured out a solution. But since, in 2022, spammers overrun any forum thread that’s left open too long, the thread was already locked and I couldn’t express my appreciation to the poster who shared it. So I’m writing this blog post instead.

The trick is to load any third-party CSS that you might need to override using a separate function called on the 'wp_enqueue_scripts' hook, with a low priority number (less than 10, since that’s the magic default).

Here’s a generalized version of the code I’m using:

function my_enqueue_scripts_early() {

    $ver = '1.0.0'; // Your theme version; could also be a class property, constant, global variable, etc.

    wp_enqueue_style('bootstrap-style', get_theme_file_uri('vendors/bootstrap/bootstrap.min.css'), array(), $ver);
    wp_enqueue_script('bootstrap', get_theme_file_uri('vendors/bootstrap/bootstrap.bundle.min.js'), array('jquery'), $ver);

}
add_action('wp_enqueue_scripts', 'my_enqueue_scripts_early', 8);

Responsive Web Design: On embracing the web’s uncertainty principle

What do Werner Heisenberg and Ethan Marcotte have in common? First and foremost is probably that I have just mentioned them in the same sentence. Second, whereas Heisenberg’s uncertainty principle paved the way for quantum physics (which revealed that matter and energy can exist as both a particle and a wave), Ethan Marcotte’s Responsive Web Design promises to usher in a new era where we discover that desktop and mobile websites, too, can be one and the same.

My analogy may be stretching thin, but the point remains that we are entering a new phase in web design. We can no longer assume websites are being viewed on a desktop computer screen of certain minimum dimensions. We also can no longer justify building and maintaining two (or more) discrete sites, shunting mobile users off to a scaled-back, limited experience while allowing desktop users access to the full version. And all of this means that we must consider the dynamic (and, in fact, increasingly so) nature of the web as a medium from the earliest steps in the design process.

Many examples of Responsive Web Design are beginning to crop up (including this site), but the best high-profile example so far is a site Marcotte himself consulted on: the new BostonGlobe.com. I’m hopeful that soon this design approach will become the norm for most websites.

But the challenges facing those of us who are ready to embrace Responsive Web Design are many. Getting a handle on the use of CSS3 media queries is the first and probably easiest of these, if you’re comfortable with code. Most of the leading innovators in web design have long worked directly in code — and knowing and working directly with HTML5 and CSS3 is pretty much a requirement for effective use of the Responsive Web Design approach.

But I would guess that the majority of web design going on today is still being done the “old fashioned” way. A graphic designer, usually with experience primarily in print, puts together a layout in one of Adobe’s creaky monolithic Creative Suite applications (Photoshop, Illustrator, InDesign), then (if we’re lucky) hands off that design file to a developer to build out as HTML. If the developer is with it, they will follow best practices and web standards, building out semantic HTML document structures with design properties defined in CSS. (No tables, please.)

There are many potential points of failure in this arrangement, because a design in an Adobe application bears little resemblance “under the hood” to an HTML/CSS layout in a web browser. It’s not just that the canvas you’re painting on is different, although there’s that. It’s that they’re not even both canvases. No matter how much Adobe tries to ease the transition for print designers, any process that forces you to start by specifying page dimensions just isn’t going to translate effectively to the nebulous, dynamic format of a website.

“Design in the browser” is the new mantra. And again, that’s great if the person designing knows how to do that. But many designers don’t, and it’s not necessarily fair to expect them to. The entire process needs to change. Developers and designers need to work together more collaboratively, and earlier on in the project. For years I’ve been promoting the importance of designers understanding HTML/CSS and the capabilities (and limitations) of web browsers, even if they don’t necessarily write the code themselves. It’s not just about knowing what certain browsers can or can’t do (like the fact that Internet Explorer didn’t support layered backgrounds until version 9). It’s about knowing all of the things browsers can do that can’t possibly be replicated or even represented in a static design built in an Adobe CS app.

There are so many aspects of this that have always been important (how best to slice up a design; what’s background/foreground; what should be images and what shouldn’t; when to use JPEG vs. PNG; optimal page widths; where the “fold” is and whether or not it exists even as a concept; the fluid nature of vertical elements; how users interact with elements and how the page gives feedback using JavaScript and/or CSS; etc.), but now on top of all of these concerns we have the additional complexity — and opportunity — of working with different classes of devices with radically different screen sizes, capabilities, and interaction methods.

Again, “design in the browser” is the ideal. But until we get there, it’s essential that graphic designers who aspire to work with the web take the time to really understand the medium: how it works, how varied it can be, how quickly it changes. Then, even if the designs are, for now, still delivered in an Adobe format, their structure and content will at least be better informed by the practical realities of the form they will finally take in a web browser.

So, as a designer, what’s the best way to get informed? Working with a developer who understands and is enthusiastic about Responsive Web Design is a great option (hint, hint), but at the very least I recommend reading Ethan Marcotte’s book. In fact, the entire A Book Apart series is essential reading for anyone who wants to build forward-looking websites. The future is coming. We may not know what it will look like yet, but it’s a safe bet that tools and techniques that were already antiquated a decade ago are not the way to get there.

I don’t want to end on a down note, so I’ll pose this final challenge to inspire and motivate any designers who might be reading this. Despite the potentially intimidating appearance of code, web standards are first and foremost about simplicity. The dynamic duo of HTML5 and CSS3 are a world apart from the hairy mess of table layouts and <font> tags that dominated the early web. Watching a design take shape directly in the web browser can even be fun! And with the powerful interactive capabilities of JavaScript tools like jQuery, and the typographic world that has been opened up recently with font embedding services like Typekit and Google Web Fonts, there’s never been a better time to be a web designer. The more you know about what goes into realizing your designs in a web browser, the better you will be at your job and the more opportunities you will have.

Federer earns his reputation

I enjoy watching tennis, but for some reason, other than Wimbledon, it’s usually not “on my radar” and I just end up missing it. That’s a shame, because it keeps me from witnessing moments like this.

Roger Federer has a growing reputation as one of the best — if not the best — players in the history of the game. It’s hard to argue against that assessment when you see this video.

Also, I felt I had to post this because although she might deny it, I think SLP has a serious crush on RF.