Working together for standards The Web Standards Project

Using a sledgehammer to crack a nut

By Ian Lloyd | October 25th, 2006 | Filed in Web Standards (general)

When is a login form not a login form? When it relies totally on JavaScript to let you login, that’s when.

Skip to comment form

Hopefully you’re all familiar with the phrase in the heading and it’s not some strange quirky British turn of phrase that’s got many of you scratching your heads. It is, though, the perfect phrase for describing what I feel about Ma.gnolia‘s sign in screen. It’s not the first time I’ve had issues with over complicated log in pages (complicated in terms of how it’s built) and I dare say it won’t be the last. And just like last time I posted on this topic, I’m expecting that I’ll get comments that will range from "You’re right, this is way over complicating the process – have they not heard of web standards?", through "It’s actually very hard to build sites that use progressive enhancement propely without massive amounts of code forking" to "stop blaming frameworks". But please read on before heading straight to the comments.

So, why am I picking on Magnolia (I’m dropping the ‘.’ in the name from here on in) and what eaxactly is wrong with it?

In the last week or so, us WaSPs have been discussing various options for sharing links so that we do not necessarily have to write a full post that may look forced ("We have all this space to fill, let’s pad it out!"). It’s nothing ground-breaking, all the cool kids do it. But what system do we use? We could use WordPress’ built-in functionality, or or we could use Magnolia. My feeling was basically "Meh, whatever". It’s all the same to me – as long as I get a login, I’m not bothered which service is used as they all essentially do a fairly simple thing and the output would be identical. Magnolia seemed to be gathering steam as the favourite tool, so I registered while at home and got added to the group. When I tried logging on at my workplace it was a different matter. Like a number of sites/apps, it didn’t work for me because part of the script was being blocked by the company firewall. I’ve actually come to expect that with each new web site redesign, there is a good chance that some level of functionaility will be blocked.

This is the point where the JavaScript developers and framework lovers start spitting at the screen, I believe. Something along the lines of "You can’t blame us for your company’s firewall settings or some other anally retentive security setting that I couldn’t possibly know about!" Guess what? You’re dead right! I’m not blaming you for using JavaScript but consider this: I am not the only person working for a company that takes security seriously and blocks external JS files that appear to be calling ActiveX Objects or creating Java instances or whatever. I’m representing a large number of people here.

So, back to the point at hand: using a sledgehammer to crack a nut. The ‘nut’ in this instance is a form login. It could be done as simply as this:

<form action="/processlogin/" method="post">
 <label for="username">User name</label>
 <input type="text" name="username" id="username" />
 <label for="pass">User name</label>
 <input type="password" name="pass" id="pass" />
 <input type="submit" value="login" />

And here’s the sledgehammer approach (snipped for ‘brevity’ and with some forced carriage returns to make it fit):

<script src=""
<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>
<script src="" type="text/javascript"></script>

<form action="" id="signin_form" method="post">
 <h1>Please sign in Below</h1>
 <p><label for="signin">Email Address or Screen Name:</label><br />
 <input class="text" id="signin" name="signin" size="30" type="text" /></p>
 <p><label for="user_password">Password:</label><br />
 <input class="text" id="password" name="password" size="30" type="password" value="" /></p>
 <p><a class="button green" href="#" id="submit_button"
 onclick=" ; submit_form=true; $('submit_button_718533').click();
 $('submit_button_718533').disabled = 'disabled';
 this.className='button green disabled';; return false;"
 <span>Sign& nbsp; In</span></a>
 <input class="hidden_submit" id="submit_button_718533"
 src="" type="image" />

 <a href="">Forgot Your password?</a>

So my questions are "why is it necessary to have all these scripts for a lowly login screen" (possible answer: it’s just to preload them into cache on a simple screen) but more importantly, why not just use a simple form as demonstrated earlier? Why use that proverbial sledgehammer to crack that nut?

One of the arguments against using, or rather requiring, JavaScript is device-independence. Many mobile devices have flaky or no JavaScript support, yet a service as simple as a bookmark sharing site should (in theory) work quite nicely on these devices. However, with the JavaScript roadblock up, many will be turned away.

As it stands, if I want to use Magnolia at my place of work (and I’m more likely to spot something standards-related while browsing over lunch or whatever). I have to do the following, using something like the Web Developer Toolbar:

  1. Disable JavaScript in my browser
  2. Disable CSS (to reveal the hidden login input of type image)
  3. Tab to the hidden button which is still pretty much hidden (it’s the old ‘clear gif’ routine) as I cannot see it on the screen to mouse to it

But frankly I’d rather use

The bottom line is that where I previously thought "meh" about which service to use, I had started to get a very uncomfortable feeling about using a service that complicates matters so much and could so easily have done what I’d have done: used a simple login form that could be used without JavaScript, could be used on a mobile device, could be used without having to make any changes to the browser setup to workaround environment issues.

Now it’s over to you. And go easy with those nut-crackers, all.

Your Replies

#1 On October 25th, 2006 4:46 am