Today in Tedium: As an experienced survivor of the email wars, I have seen many things over the years that 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 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
If you find weird or unusual topics like this super-fascinating, the best way to tell us is to give us a nod on Ko-Fi. It helps ensure that we can keep this machine moving, support outside writers, and bring on the tools to support our writing. (Also it’s heartening when someone chips in.)
We accept advertising, too! Check out this page to learn more.
Remember when our browsers defaulted to gray backgrounds? That was weird, right?
1. The Netscape Navigator 4.0 @import hack
Perhaps the first true HTML hack as we know them today, this is perhaps its purest form. Such hacks are generally used to block off code that, based on valid HTML or CSS standards, should work, but because of implementation gaps on the browser end, allow the layout to be prevented from working correctly.
As the CSS Cookbook notes, this hack effectively works by loading two HTML files, one of which will not work in Netscape:
<link rel=“stylesheet” type=“text/css” media=“all” title=“Basic CSS” href=“/basic.css” />
<style type=“text/css” media=“all”>
@import “/css/advanced.css”;
</style>
What’s interesting about this is the reason it doesn’t work. As the book explains, Netscape fought hard for a competing standard, JSSS, to defeat CSS, but the World Wide Web Consortium went another direction, leading to a heavily rushed CSS implementation in Netscape 4, which came out in the summer of 1997. That meant it worked terribly, especially compared to later browsers, and that meant as CSS grew more mature, Netscape 4 became dead weight.
(One fun side effect: If you disable JavaScript in the browser, it also disables CSS—something that is not true of most web browsers.)
This book convinced 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, it’s worth remembering how disruptive it was. 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 tend to break convention, and Siegel effectively took a semantic-data tool, 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 I wanted 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.
A modern display of CSS, which didn’t have to rely on such terrible hacks. Side note: Could you imagine being so desperate to get your website working that you just put random characters in the editor to see what happens? (Ferenc Almasi/Unsplash)
3. Putting an underscore in front of a CSS style
It sounds silly, but this was an important feature for developers during the Internet Explorer era. The reason for this is that IE often did things counter to every other web browser. A famous example of this is the box model. While the W3C intended for the width of a box to exclude the border and padding, Internet Explorer did not account for paddings and borders, leading to significant differences between browsers.
At the time IE6 first came out, Microsoft dominated the browser market, so it wasn’t an immediate problem. As the browser got older, however, it necessitated numerous weird hacks, of which the underscore hack was one. The tag invalidated the CSS, but it only hit IE6, so it was effective if you were only targeting that browser.
.class {
width: 300px;
_width: 320px;
padding: 10px;
}
IE allowed for lots of other weird hacks, too. For example, the !important tag could be morphed to only work in IE7 and below if you put another exclamation point at the end of the word.
There was no reason it should have worked, but hacky HTML features like these were often necessary because Internet Explorer was so explicitly dominant.
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;
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 */
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.
Outlook 2003, one of the primary tools that relies on conditional comments. Fun fact: Outlook 2003 actually renders HTML better than most recent versions of Outlook. Who knew?
5. Conditional Comments
At some point, Internet Explorer required web developers to use so many hacks to properly code websites that Microsoft needed to intervene. And they did—with a feature that itself was a hack.
That intervention came via conditional comments. This tactic essentially reinvented HTML comments, which naturally weren’t designed to execute code, into something far more load-bearing. They broke commenting to fix broken HTML. Here’s an example:
<!--[(if expression) (IE version)]>
<p>Can’t believe you still use Internet Explorer!</p>
<![endif]-->
First introduced with Internet Explorer 5 and still required for more ambitious email designs in the Windows version of Microsoft Outlook, the technique became increasingly popular as web designers attempted to develop pages for newer browsers, while maintaining compatibility with older versions of IE.
Jens Oliver Meiert, a web-standards advocate, argued against conditional comments—and, surprisingly, in favor of more esoteric hacks. In a 2007 post, he wrote:
No matter how you use CC, it will be necessary to adjust the HTML of each and every document or template once you focus on other Internet Explorer versions. This happens even if you’re the most visionary master of web development and there’s otherwise no need to update the structure of your documents. Remember that you strive for consistent separation of structure and formatting.
Essentially, Microsoft had to introduce an HTML hack to allow older HTML hacks to continue to be useful as the company slowly evolved its web browser.
Conditional comments were removed after IE9, but a JavaScript feature, called conditional compilation, could be used instead.
6. Scalable Inman Flash Replacement (sIFR)
The concept of web-safe fonts, as we’ve previously written, can also be blamed on Microsoft. 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 that led to a series of hacks, called font-replacement techniques, that offered more typography options. At first, this took the form of images, but that wasn’t enough, and that wasn’t accessible enough. Soon, they needed to pull out the big guns.
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.
7. The preheader text hack
These days, HTML emails carry IE’s hacky-code torch—and over time, they’ve put their own wrinkles on the process. Example: The preheader, the short snippet of text exposed by email clients that effectively works as the subhed or deck to the email.
If you don’t work in email marketing, you probably don’t realize how important this tag actually is, and also that it can be somewhat inelegant for the email client to, say, pull up an HTML tag.
Enter the preheader text hack. This thing is designed to do one thing: Add some extra space between your intended preheader, usually the first text in the email, and any unrelated content. How does it work? Essentially, you put a bunch of HTML character codes between the message and the next text passage.
It’s taken many forms over the years, but here’s the version that the email firm Litmus recommends:
<div style=“display: none; max-height: 0px; overflow: hidden;“>
Insert hidden preheader text here.
</div>
<!-- Insert ͏‌ hack after hidden preview text -->
<div style=“display: none; max-height: 0px; overflow: hidden;“>
͏ ‌   ­ ͏ ‌   ­ ͏ ‌   ­ ͏ ‌   ­ ͏ ‌   ­ ͏ ‌   ­ ͏ ‌   ­ ͏ ‌   ­
</div>
Anything to get you to read our next email.
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 emerged in the business world: 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 for Chrome Frame to exist beyond 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.
9. The Webkit-only selector hack
When Apple’s Safari web browser was first released, it was a breath of fresh air for web developers. Built on a ground-up engine rooted in the open-source community, it had stronger support for HTML and CSS standards than many other browsers of its kind upon its initial release. (Anyone who loves rounded corners in CSS should know Safari had them first.)
It still does—and for people who code emails, it is beautiful in most cases because Apple Mail, which uses WebKit, generally just works.
But as time has gone on, it’s gained some problems. One of the biggest: Apple’s Safari release schedule is generally built around Apple’s Mac and iOS release schedules, meaning it lags behind the rest of the industry. Additionally, developers have accused Apple of ignoring bugs or holding back features that undermine its competitive position.
As a Reddit user wrote a couple of years ago in a viral thread: “Oh my god. Even when they implement an API, it’s riddled with bugs they never fix. Or they do it fine, then break it later.”
So when users have to write some Safari specific CSS code to work around Apple, they do this:
@supports (-webkit-appearance:none) {}
It should be noted that this works in early versions of Chrome, which started on Webkit.
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 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.
Numerous 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 obscure, little-known web technologies, 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.
It’s fascinating to me that the intentions of HTML and how it actually works ended up differing so dramatically.
In many ways, to hear HTML tables maverick David Siegel explain it, the standards bodies wanted HTML to work like RSS—where design had no bearing on the final product, where the user ultimately was the driver. Other protocols created around the same time as HTML, like Gopher, worked like this.
But that philosophy clearly lost, in large part because of two things: First, it deeply underestimated how creative the internet’s users were, and second, it was a complete nonstarter for the commercial internet, which (for understandable reasons) leans heavily on visual language.
For decades, design nerds and user interface pros tried to put their imprint on the internet, despite all the weird code that required. It’s impressive that they actually pulled it off, given all that.
Today, I was trying to do something with some code I was working on—to put a transparent gradient over a block of text to make it fade out. This is trivial in standard HTML and CSS, but I was working in email. I tried seemingly a dozen things, but eventually I found my solution—a random HTML table glitch, highlighted by a StackOverflow commenter way back in 2009, that should not work, but somehow does.
“I know, I deserve a downvote for this,” the guy wrote. I disagree.
--
Find this one an interesting read? Share it with a pal! And back at it again in a couple of days!
