Category: Front-end Dev

Most days, I spend hours upon hours doing front-end Web development for a local company. Occasionally I’ll also pick up some freelance work as well. Regardless of the type of work I’m doing, I constantly learn new things, better ways to solve old problems, and novel ideas to implement. And I bug hunt. I don’t particularly like that bit though. Here’re stories of the above.

IE Gradient Bug with PNG-24

The Web is ever changing, and this article is relatively ancient having been published 14 years ago. It is likely out of date or even blatantly incorrect in relation to modern better practices, so proceed at your own risk.

I try to make sure to do my due diligence by checking my sites in the 3 major browsers. And usually, much to my chagrin, I also end up thoroughly testing in IE6, although I’m not willing to make them pixel perfect unless I’m being paid very well to do so. So, I was extremely surprised when I client got ahold of me about a display bug in a now live site. Ok, so you have to believe me, I really did check in IE7. On multiple computers. I don’t know why the client’s installation was special, but sometimes that’s just how things go.

The problem

Demo of problem

This isn’t the actual client site, but you get the idea.

The solid-color slightly-transparent drop-down menu backgrounds were showing up as 80% alpha gray to completely transparent gradients, thus rendering most of the navigation illegible.

Code Foundations

These were pretty run-of-the-mill drop-down menus comprising

  • semantic, nested uls, with
  • CSS-styling, including hover states (where available), topped with
  • jQuery/Superfish enhancement,

although I was trying some CSS3 with the styling.

The CSS wasn’t anything for beginners although it’s nothing crazy. To start with, my backgrounds were transparent by way of RGBa background-colors for browsers that support it. Then it downgraded to a opaque grey for older versions of modern browsers/non-IE browsers. And then, in the IE-only style-sheets I swapped in a 1×1px PNG-24 w/ alpha transparency (which was being fixed by DD_belatedPNG in IE6).

Ok, no problem so far. When I tested in IE6/7 my background image swapped itself in and repeated and everything looked fab.

Except for on the client’s computer.

The Cause

After much Googling that turned up very little, I found some promising complaints about pngs going wonky in IE if they’re stretched. Then I was super confused. You can’t stretch a background image with CSS. But to keep it simple: for some reason, the JavaScript was hijacking my background-repeat and instead was scaling (stretching) the png, under certain circumstances. And voilà! seemingly-unexplained, phantom, uncoded gradients.

The Solution

Make the PNG 2×2px or 800×1px or … well, you get the idea. IE doesn’t always play nice with 1×1px PNG files with alpha transparency. Who knows why, it just doesn’t. But it’s an easy fix. Unless you want to complain about file size. But then you better go off and make me a gorgeous background sprite so you’re not killing your visitors with a bazillion extra HTTP requests if you know what’s good for you.

Closing Arguments

In short: if the background image is getting stretched, just change from 1×1px to something larger.

Also, please don’t murder the teacher, advanced kids. I realize that my implementation also had some kinks that should be ironed out, but this post is just about those damn PNGs.

IE Bug on Enter Key Form Submission

The Web is ever changing, and this article is relatively ancient having been published 14 years ago. It is likely out of date or even blatantly incorrect in relation to modern better practices, so proceed at your own risk.

Due to a punishment handed down by the gods, I’m forced on a weekly — if not daily — basis to serve and protect the ridiculous number of Web users who haven’t escaped the dark ages. Yeah, that’s right — I have to bug hunt in IE6 — a browser with many documented bugs that is quickly approaching its eighth birthday. And sometimes those funky bugs exist even in IE7. This is one of those stories.

The Problem

One of my recent projects was setting up an extremely simple app for a local company. They gave out fliers with a URL and a short alpha-numeric key to students at local schools. The purpose was to have the students go online to the URL and enter the key to access some school-specific information.

Extremely simple and quickly completed, until I was testing and found out that IE didn’t pass along the submit input value if the user submitted the form by pressing enter. Forms 101: enter submits the form, including the submit input.

So why was IE failing remedial form submission? Why, another IE bug of course. And not a very well documented one.

View a Demonstration

When Does it Happen?

Example of problematic form

Think this is a quick, simple, easy form? Not quite …

This bug rears its ugly head under the following conditions:

  1. Your form contains one, and only one, text input. (It can still have other types)
  2. Your visitor hits enter to submit the form while not focusing on a checkbox, radio, or the submit input (in other words, most likely only if they’re focusing on that single text input or some esoteric input element).

The Solution

This issue throws us into a bit of a grey area in terms of a solution, because frankly, there’s no magic fix. But, there are a few different workarounds that you can use. There are various ways you can do it with Javascript, of course. But that means the form can’t be submitted with the bug fixed without JS enabled, thus I’m not going to explain those methods.

Probably the best solution is the one Jim Meyes posits:

The solution is to hide an additional disabled input for IE to find, using IE conditional Comments and hiding it from view with some CSS.

<!--[if IE]><input type="text" style="display: none;" disabled="disabled" »
	 size="1" /><![endif]-->

Editor’s note: Line breaks marked by ».

Why this is a good solution

This is extremely unobtrusive (and thus a quality solution) for a few reasons.

  1. Only IE will “see” the extra input, so we’re not fixing anything that’s not broken in other browsers.
  2. Because the field is disabled, the value isn’t getting passed through to the processing scripts when the form is submitted, so it’s not going to get in the way in the backend.
  3. This might be the only case in which I advocate for inline styles, but they’re solid here, because even if there is a user-specific stylesheet enabeld, it’s unlikely that a style will take precedence unless !important is employed (and IE <= 6 ignores that declaration anyhow …)

The only case I can think of where the user will notice this is when CSS is disabled (and far more unlikely: if for some reason a screen reader or such doesn’t ignore display:none;). My only suggested improvement: add a value to the field that succinctly describes why the field exists and is disabled. Thus, I would use this code:

<!--[if IE]><input type="text" style="display: none;" disabled="disabled"  »
	 size="20" value="Ignore field. IE bug fix" /><![endif]-->

Editor’s note: Line breaks marked by ».

N.B. I also bumped up the size of the field so that the visitor could see the entire value. This shouldn’t be a problem; if they’re actually seeing the field, your layout is already mangled.

Can you think of a better workaround?

Closing Arguments

Basically, if you are doing any server-side processing that relies on checking to see if the submit button was pressed, you must have multiple text fields or implement a workaround.

Best of luck in your own IE bug hunting. And please, wear bright colors and don’t shoot other hunters.

Update: I haven’t tested it personally, but I’ve received a few comments and e-mails that it also happens in IE8. So, maybe it’s not a bug, but it is an annoying decision on Microsoft’s part. This hack works, at least.