Tedium - Weird HTML Hacks 🕸️

Today in Tedium: As an experienced survivor of the email wars, I have seen many things over years that logically should not work, but ultimately pull off unexpected and weird tricks. Some of these are absolutely necessary because of code failures created by larger entities who failed to properly implement proper HTML code, or more egregiously, forced users to create code that was the opposite of elegant, just to get a reasonably desirable result. But some of these hacks were actually kind of brilliant and worth remembering for their sheer inventiveness. After all, we weren’t going to let Internet Explorer get in the way of a good design, right? Today’s Tedium talks about HTML hacks—whether structural or technical—that carried us through at a time when there were no guarantees that our webpages were going to work. We’re listing them out. Here’s ten. — Ernie @ Tedium

This book was a key element of convincing a generation of Web developers that they didn’t have to wait for CSS.

2. Using HTML tables for layout

So if we step back and talk about the web browser, Here was this amazing technology and people wanted to do more with it than what was technically allowed on the tin.

One of those people was David Siegel, and he came to the Web as a traditional designer. Designers have a tendency to break convention, and Siegel effectively took something that was built to hold data in a semantic format, the HTML table, and … decided to use it to build layouts.

Yes, yes, everyone did it (and in the email world, everyone still does), but it is the definition of a hack—and Seigel was one of the first to find it.

In his book Creating Killer Web Sites, he explained how he decided to flout convention, which presumed that HTML’s visual appearance would be determined by the browser owner, to build better looking websites:

I threw my HTML book in the trash and started from scratch. I figured out a bunch of tricks to get around structural markup and make pages the way %anted them to look. I began using images to lay out pages in two dimensions, rather than one. When tables became available, I poured columns of test in them. I reduced the colors and made the file sizes small and—guess what? - people came! The numbers actually broke my access counter.

As Jay Hoffman of The History of The Web explains, this was perceived as a huge no-no, because HTML and XML purists felt that design and code structure should not mix. (It also busted accessibility, a realistic concern that took years to repair.) But the idea of a portal that could be visually shaped by the developer was clearly valuable, and it’s probably up there with responsive design in terms of homegrown ideas that reshaped the internet forever.

For irony’s sake, here’s a PNG of a non-transparent Internet Explorer logo, on a background associated with transparency.

4. Using AlphaImageLoader to make PNGs transparent

We take it for granted today, but there was a time when the most popular web browser in the world did not correctly support PNG files, one of the most popular file formats on the internet.

Despite IE having support for PNGs since version 4, it did not properly render PNGs in many cases, and was often quite broken, with the most egregious problem being the lack of transparency support in Internet Explorer 5 and 6.

As blogger Jeff Starr of Perishable Press writes, the use of Microsoft’s proprietary AlphaImageLoader filter, a technique Microsoft invented that no other browser-maker used—a common theme for Microsoft. As Starr wrote:

Fortunately, there are plenty of hacks and workarounds designed to “fix” IE’s PNG image-display problem. Unfortunately, every currently available solution requires the use of Microsoft’s proprietary AlphaImageLoader transparency filter.

As he shows in his example of the filter, it was possible to completely get around Microsoft’s poor support using this method:

.png {
    cursor: pointer;
    no-background: none;
    /* filter applies only to IE5+/Win */
    filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(enabled='true', sizingMethod='fixed', src='http://domain.tld/path/image.png');
}
.png[class] {
    /* [class] applies to non-IE browsers */
    no-background: url(http://domain.tld/path/image.png) no-repeat;
}
* html .png a {
    /* make links clickable in IE */
    position: relative;
    z-index: 999;
}

Small feature gaps like these really slowed down developers, who had to account for these hacks during the late 2000s and early 2010s.

(Brett Jordan/Unsplash)

6. Scalable Inman Flash Replacement (sIFR)

The concept of web-safe fonts, as we’ve written about in the past in Tedium, were the direct result of a failure on the part of Internet Explorer to properly allow different types of fonts. (In fact, the company created an initiative, Core Fonts for the Web, which essentially discouraged people from painting outside the lines, then let the initiative die out.)

But paint outside the lines was something that people did, and often. And one of the ways that people did that were with font-replacement techniques that made it possible to

Enter Shaun Inman, who came up with the idea to replace fonts with small Adobe Flash files, built on demand, that replicated the fonts you actually wanted to use on your website. He had the spark, but it was Mike Davidson, a current executive at Microsoft, who made it sing. Davidson—who has spent time at companies like Twitter, NBC News, and Disney (where he famously helped make ESPN an early web design powerhouse)—made it possible with sIFR for the fonts to essentially scale as necessary, making the tool useful to lots of web designers for a time. (Later developers, like the programmer Mark Wubben, improved it even further.)

At the time he released sIFR in 2004, Davidson pointed out that what he had built was essentially a solution to a problem that standards bodies have done little about—the need to allow fonts not owned by the end user to display in fancy formats:

With this newfound ability to display true versions of typefaces in web browsers, you’d think typography on the web would be exploding. Well it’s not. Why? Because no one has solved the second problem yet: how to deliver custom typefaces to people who don’t have them installed.

This obviously was a way station to a real solution, and one that did not last in large part because Flash did not make the leap to mobile. It took another half a decade for a real solution to the font problem to show itself.

You got chocolate in my nightmares!

8. Google Chrome Frame

In many ways, this is more a competition hack than an HTML hack, but it’s an endlessly clever solution to a real problem that: Some people, especially in offices with tough IT departments, wanted to use more modern browsers, but these companies were reliant on technologies built around IE6 that did not work with any other browser. It could have prevented Chrome’s success, so they solved the problem by creating a browser plugin that literally replaced your IE6 renderer with a modern Chrome one.

As Google explained about the plugin in a 2014 blog post:

But in 2009, many people were using browsers that lagged behind the leading edge. In order to reach the broadest base of users, developers often had to either build multiple versions of their applications or not use the new capabilities at all. We created Chrome Frame—a secure plug-in that brings a modern engine to old versions of Internet Explorer—to allow developers to bring better experiences to more users, even those who were unable to move to a more capable browser.

There were competitive reasons to do this besides increasing Chrome’s uptake. Google was working on tools like Google Wave and YouTube that required HTML5 features, and having to support IE6 was holding them back.

Ultimately, the browser-in-a-browser trick worked extremely well, as Chrome became utterly dominant in the five years that the plugin was on the market.

Secretly the most important digital article of all time. (via Web Design Museum)

10. Responsive design

In many ways, responsive design is a hack that ended up getting a corner office in the realm of HTML.

To understand how responsive design is so important to the way web design works, it’s important to understand that there was a major debate happening in web design throughout the 2000s. Essentially, everyone wanted to have a good way to design webpages with three columns that went all the way to the bottom. This was a layout that worked well using traditional HTML tables, but wasn’t technically semantic and did not work using CSS.

A number of solutions emerged during this period, many faking it with fake columns enforced by a background image. Eventually, the interest in responsive design turned into grid-based layout, something that CSS came to support.

The point that held this up was browser support, particularly on the Internet Explorer front, but eventually as smartphones became popular, the “Holy Grail layout,” as it was long called, no longer made sense. People suddenly had to invest lots of money in mobile websites that they did not have to previously.

But then Ethan Marcotte, a web developer and writer for A List Apart, came along and pointed web designers towards a new holy grail—the use of media queries to reposition websites to match the format. This looked like magic when it first came out, in part because it used web technologies that were being ignored by most web developers, particularly media queries.

It was a hack just like HTML tables were, but unlike HTML tables, it actually worked within the parameters of what the HTML standards folks wanted. It ultimately changed web design forever—for the better.