I’ll click when I tell you to click. Or you’ll click when you tell me to click. One of those. — Pavel Maximovich Sokolov

While I’m admittedly desperate for ego-boosting website clicks, I’m currently working on a project where momentarily preventing the user from following links is desirable. More specifically, there are form controls on the page that trigger AJAX requests, after which a notification appears displaying the response from the server. The contents of the page change after every call; buttons that were previously disabled may become enabled, and vice versa. While this happens fairly quickly, there’s a short amount of time during which the user can click a button and trigger another call to the server before the last one has returned and modified the page accordingly.

One way to prevent eager users from clicking too fast is to set a JavaScript variable to false when the AJAX request is being made, and only allow new calls to be executed if that variable is true. The problem with doing this is that the user still sees visual confirmation of their click and expects something to happen as a result. Another solution is to disable all the buttons on the page while the request is being processed. The issue here is that the user sees a flash of disabled buttons, which isn’t exactly aesthetically pleasing.

Like all things worthy of a pay raise, this conundrum’s solution is a simple one. A property of HTML divs is that they capture mouse clicks, even when transparent. By overlaying an absolutely positioned div above the form controls, they become inaccessible. The user can attempt to click them, but they will not depress and generate a server request. By default, the div’s CSS is set to display: none. When the request is made, the JavaScript switches it to display: block. Only if the user attempts to click a button while a request is being processed will they be aware that something is blocking them from doing so.

Using my old crony jQuery, the code looks something like this:

And the HTML:

A simple solution to an obscure problem. Pass the A1.

Letters in motion, you say? What a splendid invention. — Eustice P. McGargle

Recently when reminiscing about that custodian of excellent web design that is was GeoCities, I decided to give the <blink> and <marquee> tags a whirl, for old time’s sake. Alas, Safari refuses to recognize these bastions of 90s tastefulness. Tears splashed on my keyboard as I mourned the death of greatness.

And then a user on the Unity forums asked about scrolling text in-game, to which I enthusiastically responded. Browser manufacturers may have made every attempt to kill the non-standard HTML elements so thoughtfully introduced by Netscape and Microsoft, but they can’t take away these innovations from video games. Class will live on.

Stay tuned for blinking text in Unity, for even greater user enjoyment.

Please stop butchering our song. I’m begging you man, just quit doing it. Please. — Kool & The Gang

Recently I built a browser-based window system using the most excellent MooTools JavaScript framework. It behaves similar to how your modern desktop windows work. That is, windows can be opened, closed, resized, and dragged around by their titlebar. When clicked on, a window will come to the front of the window stack. It’s a lot like the Mocha UI project, just not as good (mad props to the creators of Mocha, it rocks hard).

Anyway, to the point of this post: in one of these windows I later embedded a Unity game. Much to my dismay I discovered that having a div hovering over an embedded Unity game doesn’t work — the div will appear behind it, despite having a higher z-index. This means that I can’t have my windows properly overlapping each other, and any thought of decorating a Unity game (giving it rounded corners, perhaps) can be forgotten.

I’m told by intelligent people that this behaviour can be expected with any embedded object (Flash excluded). So, what’s the solution? Unfortunately there isn’t one that I’m aware of. As nice as it would be to place wacky animated GIFs overtop a well-polished Unity game (bring back 90′s web design!), you’re simply out of luck. Or I’m simply out of luck. Somebody is simply out of luck.

Stylesheets that won’t render are more tragic than Romeo’s inability to check a pulse. — R.B. Bennett

Two months ago I designed a website for the company I’m currently employed at. The site was pretty basic fare — four or five HTML pages, a few images, and a stylesheet to make it look sexy. The design was uploaded to the development server then uploaded to the live server once approved. All was well until the site was viewed in Firefox (I can’t recall how Safari and Opera behaved). For a reason unknown to all of us fine employees, the styles in the CSS file weren’t being applied. The .css file was most certainly there, and Internet Explorer displayed the site just peachy. Most perplexing was that the development server and live server are supposed to be identical, and no such wonkiness occurred on the dev side.

Luckily the problem was found quickly by one of my co-workers. Our live server is apparently powered by Netscape Enterprise Server, which came configured to serve .css files with the application/x-pointplus mime type (not good Netscape, not good at all). Some web browsers like Internet Explorer will ignore the server and treat the CSS file as text/css while others like Firefox will roll with application/x-pointplus and potentially show you a website that looks disastrously grotesque.

I’m not sure how popular Netscape Enterprise Server is, but if you happen to be using it and browsers are ignoring your stylesheets, make sure that your .css files are actually being served with the text/css mime type. Because that just makes sense.