Webmonkey stopped producing new content in the early 2000s and was sold by Wired to Lycos, I think, but much of the old content remained, such as the special characters reference, which I consult occasionally. Now the site has been re-purchased by Wired, which has decided to re-publish the tutorials on a wiki. That’s probably the best approach if you can’t spare the staff to manage the old content, but the historian in me is bothered that Thau’s JavaScript tutorial is gone, replaced by something generic. Why couldn’t Webmonkey have kept the old articles intact, perhaps with a notice suggesting that a piece might be outdated and a link to the new wiki? That’s sort of what PPK does at Quirksmode; he separates articles into “active” and “archived.” I’m sure we can live without knowing how to code for Netscape Navigator 4, but it’s good to remember where we’ve come from, to remember how and why things have changed since then.

However, Webmonkey promises to start creating new content relevant to today’s web, and that will be good news for those starting into web development.

PPK’s contest itself ended up falling flat, as even the winner, John Resig (who later created the jQuery library), later repudiated it himself. That’s probably because PPK’s contest requirements were like asking for all three of good, fast, and cheap.

So seven years later, there’s no widely-adopted replacement to the original addEvent that:

1. Is short
2. Maintains the this scope in IE
3. Has a corresponding removeEvent

The various libraries do a good job of 2 and 3, but not 1, and since I often find myself needing 1 and 2 but not 3, I came up with my own good-enough version of addEvent:

It’s short, which is just what I need when I’m trying to keep the JavaScript size low. (Whenever size isn’t so much of an issue, such as on the administrative side of a website, I’m more likely to use a library which will have a much more robust way of assigning events to objects.) And my addEvent also makes this refer to object in question, even for IE.

The idea is to emphasize that styling on the web–particularly, that done with CSS, or “cascading style sheets”–should be separate from the structure, or markup. In part, one should separate style from content because a number of people and services read your site without styling: people who have disabilities, search engine spiders, etc. It’s also much easier to change styling if it’s not mixed up with the structure of the content.

The first image shows a screenshot of the problem: the title of the post is drooping into the post. Usually when you see something like this, it means that the containing element has not been cleared. There are a number of ways to clear an element: a popular fix these days uses a pseudo class; the classic approach has been to put a cleared element within the same element as the floating element, but after it. Neither fix works for this bug.

Thankfully, I found a demonstration of a similar problem with IE 7. Apparently if the element containing the floating element has a set height or a maximum height, it confuses IE 7. According to the standard, a browser should obey the CSS height of the element (and IE 7 does—good job!—unlike IE 6). But every cleared element after the floater should be pushed down, not overlapped, by the floater.

The solution is to remove the height assignment from the container element, if you can. In my case, for another part of the site experiencing the same problem, I needed the element to have enough height to show a background image. The solution was to use the min-height property, which doesn’t trigger the bug.

The final image shows what it should look like, as rendered by Firefox.

That’s what I saw when I went to pay my bill at Comcast.com, something I’ve done several times before. I do have Flash—it just happens to be Flash 7, the highest version Adobe has yet released for Linux.

The problem with making your website depend on proprietary technology, such as a particular version of Flash, is that you exclude all those who don’t have access to that proprietary technology. Because Flash is a closed-source Adobe technology, we have to rely on Adobe to let us view it. In contrast, most of the web uses open communication protocols. If you don’t like your web browser, you’re free to design your own or use one of a number of open-source browsers.

Obviously some sites like YouTube need to require Flash or another proprietary technology. However, none of the reasons a typical customer would access Comcast.com requires Flash: reading news, finding customer support information, paying bills, etc., can all be done using HTML. So why does a major company, which is in the Internet-providing business, have a needlessly exclusive website?

I view it as a personal failure that Flash collected the bronze medal for annoyance. It’s been three years since I launched a major effort to remedy Flash problems and published the guidelines for using Flash appropriately. When I spoke at the main Flash developer conference, almost everybody agreed that past excesses should be abandoned and that Flash’s future was in providing useful user interfaces.

Despite such good intentions, most of the Flash that Web users encounter each day is bad Flash with no purpose beyond annoying people. The one bright point is that splash screens and Flash intros are almost extinct. They are so bad that even the most clueless Web designers won’t recommend them, even though a few (even more clueless) clients continue to request them.

Flash is a programming environment and should be used to offer users additional power and features that are unavailable from a static page. Flash should not be used to jazz up a page. If your content is boring, rewrite text to make it more compelling and hire a professional photographer to shoot better photos. Don’t make your pages move. It doesn’t increase users’ attention, it drives them away; most people equate animated content with useless content.

Using Flash for navigation is almost as bad. People prefer predictable navigation and static menus.

Nielsen is right that Flash can have useful applications, but as he also points out, most of the time it’s used just for the “wow” effect. And with Google’s creativity showing how far one can go with “Ajax”-based apps, the number of situations in which Flash is necessary is shrinking.

What I dislike about Flash the most and what makes it an anomaly on the Internet is that it’s a proprietary standard. You have to run software made by Macromedia in order to view Flash. Unfortunately, when Macromedia decides it doesn’t want to port Flash to a given operating system (as it has done with mine, Linux 64-bit), then users are out in the cold. The number of those users is bound to increase, as mobile phones with web access become more common. Almost no other significant web technology is proprietary. From serving web pages to browsing them, you can do it all with open-source applications. Why should Flash be the exception?

Now that Firefox has become the first viable contender to Microsoft Internet Explorer in years, its popularity has brought with it some unwanted attention. Last week’s premature disclosure of a zero-day Firefox exploit came a few weeks after a zero-day exploit for Internet Explorer appeared on the Internet. Firefox not only has more vulnerabilities per month than Internet Explorer, but it is now surpassing Internet Explorer for the number of exploits available for public download in recent months

Ou presents two charts showing that in the last seven months Firefox has had 40 vulnerabilities to Internet Explorer’s 10 and 11 exploits to IE’s 6.

As you can see, the facade that Firefox is the cure to the Internet Explorer security blues is quickly fading. It just goes to prove that any popular software worth hacking that has security vulnerabilities will eventually have to deal with live working exploits. Firefox mostly managed to stay under the radar from hackers before April of 2005. Since that time, new exploits are being released almost on a monthly basis.

I don’t think it makes me rabidly pro-Firefox to suggest that there are some good reasons to take these numbers with a grain of salt.

• For one, Firefox was officially released only in 2004, whereas Internet Explorer 6 has been around since 2001 (and that’s not counting previous versions). That’s given everyone a lot more time to find and patch major IE problems.
• Furthermore, Firefox’s open source makes it easier to find and fix vulnerabilities than IE, so in the long run it should be less open to attack.
• Also, according to the Secunia vulnerability reports to which Ou links, the severity of the Firefox vulnerabilities has been less than those of IE. During the same period of time, 14% of Secunia advisories regarding IE were rated “Extremely” critical, but none of the Firefox advisories were. Indeed, 77% of Firefox advisories were only “Moderately” to “Not” critical, compared to only 56% of IE advisories.
• According to the Secunia charts, twice the percentage of IE advisories have gone unpatched compared to those of Firefox.

And if you use Subversion, you can get the latest version from http://svn.wp-plugins.org/filosofo-comments-preview/. For example, on a Linux machine you might type

• Requiring ActiveX. What’s the point? There’s no reason McAfee couldn’t offer a straightforward download with a program that requires a unique activation key.
• Browser-sniffing. McAfee shouldn’t be trying to discern browsers (especially if it’s going to do it so badly); rather, if it must use ActiveX, it should be concerned only about whether a browser is using it.

If it weren’t free I wouldn’t even consider it. No doubt web design is in a separate department from the anti-virus and firewall development, but might this say something about the competence of the company overall?