Making Inline SVG Play Nice in Legacy IE

Last week I was tearing my hair out trying to track down why the latest version of this site was rendering so badly in legacy versions of Internet Explorer.

It was particularly annoying because I’m such a strong believer in progressive enhancement. I try to build my projects with the basics first, then layer on the more sophisticated bits. That usually makes legacy browser support easier, if not trivial. The fancy stuff typically doesn’t render or get in the way, and foundation-level content still works in the accounting department’s crusty old browser of choice. But not this time.

Specifically, jQuery was going a little nuts trying to traverse the DOM in IE8 or older, returning weirdly inconsistent results. Here’s a sampling of some queries and their pass/fail results:

• $('footer[role="contentinfo"]') = failed
• $('div[role="contentinfo"]') = worked
• $('div[role="contentinfo"] nav') = failed
• $('footer') = worked

After doing a few reductions I found the issue, and it wasn’t at all what I expected: inline SVG. Specifically, there are two components of inline SVG that seem to scramble legacy IE’s brain:

1. The XML namespace attribute: Removing the xmlns attribute from svg elements (or simply setting its value to “ ”) returns sanity to the DOM. Interestingly, related attributes such as xmlns:xlink don’t have a similar negative impact. Only the default namespace attribute causes this behavior.
2. Self-closing elements inside inline SVG: The presence of self-closing child elements in inline SVG (like <circle /> or <path />) consistently triggers this issue in IE8 and lower. This one also has an easy fix. Simply change self-closing child elements in your SVG to have a separate closing tag. So instead of <circle />, use <circle></circle>.

Update: Both Fixes Work

I’ve updated this post to reflect feedback I’ve received since it was initially published. Tab Atkins responded on Twitter to point out that xml attributes should be ignored by the HTML5 parsing algorithm in modern browsers, so they can be safely removed. That means both methods are viable options for bulletproofing your inline SVG, allowing it to degrade gracefully in older versions of Internet Explorer.

State of Transition

Yesterday was my birthday, so I gave myself a little gift in the form of a redesign. Which was really just a convenient excuse to take some of the tools and methods I use every day on client projects and apply them to my own digs.

New Body, New Engine

Two big changes are working in concert on this redesign. First is the visual design, which pares the layout down even more. Navigation has been tucked away, heavy borders removed. I enjoyed the old design, but it wasn’t well-suited for presenting shorter content, links, and photos alongside longer entries. I need a space for content that’s longer than a tweet, but less than an essay; one that’s more conducive to a, “Short assignments, shitty first drafts,” philosophy. This design forces my hand less both as a writer and as a reader.

The other big change is under the hood. Whatever technology I’m using to run this site should support the goals I just outlined. The tools I’m using are going to influence the output whether I like it or not, so it better be the right influence. So for the first time since 2005, Stuntbox isn’t a WordPress joint. I’ve converted it to Jekyll.

Don’t get me wrong, WordPress is perfectly fine for lots of projects. But after years spent deep, deep in the bowels of The Loop, writing more one-off custom functions and plugins than I care to recall, I wanted something more lightweight. Something fast, flexible, and as mercifully cruft-free as possible. Jekyll wins on all three fronts. (It also helps that Jekyll went 1.0 the same day I started this redesign.)

Jekyll is the first site management tool I’ve had fun working with in years. Aided by YAML front matter and the simplicity of Liquid’s template system, it’s nearly ideal for my uses.

The key difference is that it lets me start with the absolute basics, then add in pieces as required. No ripping out chunk after chunk of template pieces you don’t need, all while crossing your fingers that you’re not cutting muscle and bone along with all the fat.

And then there’s the writing itself, done largely in Markdown. Markdown strikes a pragmatic balance between legible formatting and data portability. And apps like Editorially make it a pleasure to blog with. (Editorially in particular gets props in my book for getting on-the-fly formatting right, exporting to Markdown files with a click, and for being built by some damn fine people.)

Other Bits and Pieces

I’ve also run through a laundry list of optimizations, with a few more to come. That includes lazy-loading images and using inline SVG wherever possible to reduce HTTP requests. I’ve added custom plugins to combine and minify my JavaScript, as well as run SASS and Bourbon. I’m also using Amazon CloudFront’s super convenient origin pull option to speed up delivery of images, scripts, styles, and the like (while making sure to enable gzip for everything that’s still coming directly from my server).

And, oh yeah, GitHub all the things. Ever. Logging issues in GitHub has probably had the single biggest impact on how I manage client projects since Basecamp. But this is the first time I’ve turned it around and used it on myself for a personal project, and it’s made a huge, huge difference.

But Wait, There’s Less

With all the changes and additions, there’s one big thing I’ve taken away: comments.

I know it’s a little vogue to hate on comments right now, and I don’t necessarily agree with that stance. You can’t improve discourse by shutting it out, and it’s on me as a site operator to cultivate meaningful discussion around the content I showcase. But therein lies the rub. I don’t think the off-the-shelf solutions I could use help much in that department (and some are completely at odds with it).

So I’m shelving them while I tinker with other improvements to the site. Past comments have been safely tucked away in an archive, perhaps to be pulled out again when I’ve given this some real thought. In the meantime, if you’d like to bat around ideas, hit me up.

Go Indy

Back in October I gave a talk about digital publishing at re:build 2012 in Indianapolis. It was a great conference experience, and my hat goes off to organizers Justin and Tony for going out of their way to make the audience and us speakers feel right at home. (Snack room! Pulled pork grilled cheese sandwiches! Seriously.) There were a lot of great questions from the audience—Q&A starts around 22 minutes into the video—and plenty of good conversation after the session.

Their team recently posted the full video of my talk. I used my time on stage to provide a quick survey of the publishing landscape, dive into some nagging issues I see with print versus digital artifacts, and give a little glimpse into some paths forward for the industry. Check it out when you have a moment. If you’re interested in the topic, I’ve got a new column out today on A List Apart that covers the artifact issues from the talk a bit more.

Let Them Eat Main Elements

So it looks like we’ll be getting a main element in HTML5 after all. Good news. But Jeremy Keith poses a follow-up question I’d been wondering myself: Why can’t we use it in every section, just like header and footer, instead of only once on the body element? (Check out Jeremy’s post for the necessary technical background.)

We saw this same kind of thing during the last go-around with footer. To a lot of us markup jockeys it feels off. For us the fundamental nature of HTML5’s foundation-level markup improvements have been all about sectioning content. To have something dangled in front of us that seems so darn, well, section friendly, and then be told we can’t use it in those those places is odd. Especially when its closest siblings don’t behave the same way (those would be header and the now-revised footer).

Now me, I’m selfish. I want to see main made available for use inside elements like section and article because I want to explicitly define the core content of those elements and provide an easy hook for styling in one semantic shot. It’s a markup pattern I run into a lot. One I’d wager plenty of other folks do too.

I know there are all sorts of solid reasons the standard might not go this way, based on a pile of data about markup usage in the wild. But the potential uses that come from making main more flexible strike me as both beneficial to developers and not much of a stretch from the current proposal. It might not be a cowpath yet, but plenty of us would sure like to tread down it.

Update

It’s been pointed out to me that this incarnation of the main element was focused right from the very start on accessibility, which brings with it a very different set of concerns that override what I’ve noted above. And at the end of the day, it’s what won out. Bruce Lawson has a good write-up. After a few quick tweaks to reset stylesheets, shivs, and the like, I’ve already started using it in my projects. (Though I do still kinda-sorta wish there was a more explicit, semantic way to identify the main content of sectioned items other than just treating it as, “stuff in a section that isn’t inside a header or footer.”)

Getting Past Step One

To misappropriate a line from another form of recovery, admitting you have a problem is the first step. Mercifully, a healthy chunk of the traditional publishing industry got past that point some time ago, and has since moved onto the business of grappling with the, oh, one or two bazillion small challenges they face adapting their businesses to the realities of digital distribution. But there are still a few stragglers.

MacArthur’s latest rant on the Harper’s blog is an extreme example of the same recycled, hostile attitudes we saw in the early days of digital publishing. And insofar as it devolves into outright name-calling, it doesn’t merit much in the way of a response. What is worth noting is that if you’re in charge of transitioning a publishing operation from the old world to the new, you need to be concerned with what is happening, not what should be happening, or still worse, what you wish was happening.

For the laggards who’d rather throw temper tantrums instead of getting on with the actual business of adapting, the following needs to be said: Pausing to pitch fits is a luxury you can ill afford. You just don’t have that kind of time. The ship has sailed. The house is on fire. This is your burning hand. Pick whatever metaphor suits your tastes. Whichever it is, please ensure it reminds you that this stuff is happening right now and is absolutely, positively not going away—regardless of whether you think it’s right or wrong.

Why does this matter? If the leaders of publishing’s old guard aren’t spending what precious little time they have left working on solutions, they are actively abdicating their seat at the table, along with their power of self-determination in possible new futures. And that’d be a damn shame when so many of their organizations still have something to offer.

Addendum

Alexis Madrigal has written an appropriately mocking riposte that does a great job of highlighting the obtuseness of MacArthur’s contentions.

News Corp Shutters The Daily

Yesterday News Corp announced the shuttering of The Daily, their major iPad-only newspaper venture. For me personally, The Daily was emblematic of the soft mania I felt spread through the magazine and newspaper industries immediately following the launch of the iPad. It’s a period we’re still working our way out of, one that I’ve come to think of as the Era of Tablet Myopia—or, alternatively, the Era of the Print Artifact Tablet App and Business Model and Staffing Structure.

The fundamental contradiction at the heart of The Daily was that it was trying to be a large-scale, mass market newspaper (big staff, ambitious reach) while only pursuing one delivery channel. Even at the outset, many noted the financials simply did not (and still do not) add up to a return anywhere near the level required to support an operation of that size and nature.

All this merits a thorough postmortem, but for now I’ll just use the opportunity to flog something I and many others have been pointing out for some time: if you want to be a modern, mass market digital publication, you absolutely, positively must be multi-platform. That means the answer to, “What platform should we be on?” is, “All of the above.” Getting there is the tricky part.

On Demonstrating Progress

I’ve been devoting a good chunk of my time lately to documenting progress. Not technical documentation, but acknowledging effort and promoting it where others can see it. It’s an important piece of the everyday work puzzle, whether you’re doing client services or working in-house, but it’s often overlooked.

It’s hard to overstate the importance of keeping stakeholders in the loop via regular, concise demonstrations of progress (and yes, users are stakeholders) and reminding teams about what they’ve accomplished (insert well-deserved pats on the back here). It’s not something that happens on its own. You need to deliberately set aside time for it during your planning, and choose progress markers that are both immediately tangible and easily grokked.

For me, the ultimate example of this isn’t a tech project, it’s a landmark: Grand Central Terminal. A Beaux Arts masterpiece, it was brought back from the brink through major restoration efforts in the 1980s and 90s. The folks who worked on it were smart enough to leave behind a little reminder.

The next time you find yourself strolling through the Main Concourse, just glance up at the ceiling in the northwest corner. (Across the terminal from the Apple Store, on the side where the track entrances are). If you look closely, you’ll spot a small dark rectangle sitting smack dab in the middle of all those beautiful architectural accents. That’s a section that was left uncleaned by the restoration team, a deliberate before-and-after marker that stands in stark contrast to its restored surroundings.

And just like that, any passer-by—even those as unschooled in architecture and restoration as myself—can begin to grasp what was accomplished.

Let’s Build a Better Way

Today I’m very happy to announce that I’m joining Readability as their new product lead. I’ll be helping shape strategy and vision for the Readability platform and tools, and working with a truly awesome team.

These are gloriously fun (and occasionally frustrating) times for publishing and content. There’s much the established players have gotten wrong and so much more that we, the tech types, have yet to get right. Genuinely new thinking—the kind that actually helps great content flourish, profitably—is in order.

The future of publishing is waiting to be made. Right here, right now, in the weird, fluid space between the dissolution of old models and the unfinished formation of new, tech-driven realities. I’ve spent a lot of time untangling these knots for clients, and it’s my desire to help push the conversation and the tools as far forward as we possibly can. I’m thrilled to be joining up with the talented folks at Readability to make that happen. Now, onward!

People Are Squishy

One of the single worst lines you will ever hear in the context of a business environment is, “People are simple.”

That’s bunk. What motivates people can can be simplistic (think Maslow's Hiearchy of Needs) but from that springs a font of applied complexity. Human beings operate at different levels of self-awareness (from blithe to Buddhist master) and can hew to multiple, contradictory notions without their heads exploding.

We are not logic machines. We are organic and squishy. The outputs seldom flow directly from the inputs without modification. Correctly identifying the latter is great, but don’t think the sum of those alone will always add up to the former.

Recognizing this helps prepare you for the interpersonal adventures of the average day, and makes you more likely to stand back and give a knotty issue or unfathomable personality the time and due care they require to be successfully untangled and dealt with.

Dead Silos and the Content Archipelago Ascendant

Last week the Pew Research Center published its annual State of the News Media report for 2012. It’s a broad piece of industry self-analysis that documents trends in the field over the preceding year. Pew’s findings focus specifically on journalism, but there are lessons aplenty for publishers and content builders of all stripes. And when it comes to digital and devices, this year’s edition does not fuss about:

Nearly a quarter of U.S. adults, 23%, now get news on at least two devices—a desktop/laptop computer and smartphone, a computer and a tablet, a tablet and a smartphone, or on all three.

And those numbers are growing. They go on to summarize:

All of these findings, which hint that mobile is adding to and expanding rather than replacing news behavior, are reinforced by other data we have seen that track online behavior.”

Fancy that. Devices aren’t replacing the Web for content consumption, as some publishers have doggedly asserted, they're adding to it. The Talking Points Memo headline announcing the report got it wrong. The future of news isn’t just “in your hand”. It’s in your hand, on your desktop, and materializing in myriad flickering transports we haven’t conceived of yet. And users are learning to snatch them all up at the same time.

Despite this, the study notes, “The top priority for many magazine executives in 2011 was building a tablet app.” That’s unfortunate. Throughout the report, Pew’s data reinforces the conclusion that focusing on a single device is heading down the wrong path. Tactics like isolating tablet customers with deliberately obtuse price tiers will cost you in the long run. The Great and Terrible Problem of the Web is not going away. The ever-fracturing multiplicity of devices is not going away. Print isn’t even going away (although it will be greatly reduced). For many publishers, a course correction is in order.

So Now What?

As I’ve been keen to assert, the future of media tends towards access. The ability to meet a user wherever they are with the content they want, on terms of their choosing. Techniques like Responsive Web Design have already helped developers evolve their mindsets. Related ideas, like Adaptive Content, can help writers, editors, and general managers do likewise. Content organizations should be experimenting with and adopting these techniques now. There are smart people working on this stuff. Go see their presentations. Read what they have to say. Hire them.

These approaches aren’t just ends in themselves, they’re transformative mental training wheels, teaching organizations to think content-out rather than canvas-in. And that’s the key to not only surviving, but thriving in a world where you have no idea what the next hot channel for your content will be. A world where a publisher puts out countless permutations of their content, small islands loosely connected—a content archipelago, not a field of closed silos.