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.

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 del.icio.us 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" /> </form>

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

…

<form action="http://ma.gnolia.com/signin" 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="http://gnolia.cachefly.net/images/clear.gif?1158369449" type="image" /> <a href="http://ma.gnolia.com/password">Forgot Your password?</a> </p> </form>

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:

Disable JavaScript in my browser
Disable CSS (to reveal the hidden login input of type image)
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 del.icio.us.

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 Sérgio N replied:

Please consider building a “specialized” search engine using – http://googleblog.blogspot.com/2006/10/eureka-your-own-search-engine-has.html

It would be great to have a search engine specialized in “web standards” :)

#2 On October 25th, 2006 8:11 am Stephen Clay replied:

Step 1. Make accessible form.
Step 2. Alter form behavior/look w/ JS.

They skipped a step; I’m sure they’ll fix it now :) One way to get around the firewall-blocking-js game would be to attach all your behaviors via functions defined externally:

// call $() only if $ defined:
$ && $(document).ready(function(){
// jquery is loaded, alter form
});

#3 On October 25th, 2006 8:34 am Shelley replied:

Your point is valid, and so is Stephen Clay’s comment:

The first priority is not to turn people away. How do you turn people away? By making your page non-accessible to those using specialized user agents, or those with JS turned off (or, as you say, those behind a firewall).

No geegaw is worth accessibility.

#4 On October 25th, 2006 9:17 am Chris replied:

The pitfalls of embedding code. Would that developers adopt Hijax as best practise.

#5 On October 25th, 2006 10:21 am WaSP Member lloydi replied:

There I was talking about peculiar British-isms, and then you go and say something like ‘geegaw’, Shelley! Never heard of that, so I looked it up: “Cheap showy jewellery or ornament on clothing”. So I take that comment to mean that something that’s showy for the sake of it isn’t worth the effort to make it accessible? Would that be right?

#6 On October 25th, 2006 10:51 am Todd Sieling replied:

Good article, Ian, and the points are well taken. Not being a programmer I can’t comment on why there is so much JS in the sign in page, but I’ll look into it and see how we can simplify it.

Though I wish it were different, the reality is that a lot of people work behind firewalls that will block javascripting at some point, and I think we should be doing what we can to make life easier for those people, as well.
Thanks for the comments.

#7 On October 25th, 2006 11:44 am Martijn ten Napel replied:

I’ve read a lot about web standards javascript evangelists preaching unobstrusive javascript. Some of them might even be WaSP members.

I guess that would be the answer to things like this; having javascript in place to do some pre-checks if available and if not, fall back to server side processing.

I guess the javascript WaSP’s have to buzz a little louder, like the CSS WaSP’s have before.

#8 On October 25th, 2006 12:39 pm William Lindmeier replied:

Hey Ian. I am a developer at Ma.gnolia so I can address your points directly. You’re right that there is a lot of javascript overhead in this simple page, a lot of which isn’t used for the purposes of this specific form. This page is taking advantage of our sites template, and these scripts make other things on our site work. It would be impractical to craft a unique set of includes for every page, depending upon the specific JS calls that that page makes. Furthermore, I would argue that because you’ll probably be using these scripts on whatever page you’re logging into, the signin page is a fine place to load them into your cache (if they aren’t already), since there is very little to load otherwise. Loading these with a content rich page would extend the render time, so this approach evens those out.

The reason for the javascript in the form is actually to make the form more accessible. We are using styled text links for our “buttons” across the site and this submit button happens to be one of them. Some browsers wont submit a form when you hit the “Enter” key if there isn’t a submit button proper, or an image input. The hidden image input stands in for the “submit” key for that reason. The line of javascript simply submits the form from the text link and adds a style to the visible button. This is to give the user feedback that their action has been received, but as you’ve discovered yourself, this form works fine with javascript and css disabled. You don’t even have to tab to the clear image input. Just hit enter. The form itself is really not much different than the example you provided. One ‘onclick’ function, and a hidden image to satisfy our unique needs (mentioned above). Every website has unique needs, and the most generic possible markup for anything will work for almost no one.

#9 On October 25th, 2006 6:42 pm Steve Tucker replied:

@William: Yes, you may have unique needs. But in the face of all the evidence pointing towards traditional tried and tested methods why go out on such a limb? Forms especially have been researched and wrote about so heavily it would seem somewhat strange why you would take such an unnecessary detour. Especially, like Ian Lloyd says, on just a login screen.

#10 On October 25th, 2006 8:24 pm Chris replied:

William, your point on accessibility seems hopelessly lost when this user (the article’s author) has Javascript enabled, yet cannot download nor cache the necessary scripts.

Using the Hijax approach (def. in comment #4), you could start with a base form, then use external JS to switch out the submit button for your link method. You can be sure that a) the replacement button appears with all the JS dependencies it needs; or b) there will be no switch and the submit button works as before.

#11 On October 25th, 2006 10:14 pm Dylan replied:

I’ve never understood why developers ever replace the standard submit button provided specifically for the purpose of submitting forms with a flaky link which depends on JS. It just doesn’t make any sense to me.

@William: your explanation still doesn’t take into account why you’ve unnecessarily replaced a built-in method for form submission with an onclick handler on a link. The only reason I could think of would be to provide visual consistency across the site via using an A element rather than an INPUT (which doesn’t allow for :hover styling on IE), but really, this could have been solved any number of other (better) ways.

#12 On October 26th, 2006 8:48 am Kaan replied:

I think what Martijn says is true. Javascript is useful when making checks before submission.

#13 On October 26th, 2006 9:38 am Rory replied:

If you’re using that much JS how hard would it be to add some simple empty field checking before a postback to the server?
William your argument is flawed in that while you have explained your reasons for the implementation you haven’t given a direct explanation to the authors original problem, end result? you sound like a polititian….

#14 On October 26th, 2006 3:46 pm Bob replied:

@ Ian L.
“So I take that comment to mean that something that’s showy for the sake of it isn’t worth the effort to make it accessible? Would that be right?”

I didn’t get that sense. I think it means, “It isn’t worth sacrificing accesibility for something that’s just bling bling.” Or as a user’s internal dialogue might sound, “Wow, what a fancy pretty sexy login page! Beautiful! Too bad I can’t use it from behind my firewall. If only they just made it functional instead of sticking all that ‘design’ into it…”

At the same time however, in order to build something exciting, it’s sometimes necessary to require a certain level of compliance with platforms or whatever. Want to use Windows Update? You need to have Windows installed. Want to run OSX? You better have a recent Mac. Want to use Gmail? All that AJAX means you need javascript enabled and well-supported. And if you build something that excludes a certain portion of potential users, say with screen readers, well, maybe it won’t matter if those vision impaired folks wouldn’t be able to play those Flash games anyway. They don’t use the Net for that sort of thing. Deaf users don’t visit iTunes very often I imagine, either.

#15 On October 27th, 2006 2:52 pm Todd Sieling replied:

As the PM for Ma.gnolia, this has been an eye-opening discussion for me, even if the more technical aspects aren’t completely clear (again, I’m not a programmer, so I need to trust people specializing in that field).

I want to point out that Ma.gnolia does have a lot going for it in terms of accessibility. We made it a priority when we contracted Happy Cog for the overall design, and more than once opted to forego the flashy for the more widely accessible. I think our hearts are in the right place, even if the signin page isn’t meeting expectations. Moreover, we’re willing to learn and change based on feedback like this. We talk a lot with the community that’s building up around Ma.gnolia, and they’ve been the drivers of almost every fix and tweak and new feature that we’ve worked on in the last few months.

To put a little substance behind that statement, we’ve already made one change to fix the most important problem identified here, which was that Ian was unable to sign in from behind his workplace firewall. The change (which will be deployed within a few days) will only modify the submit button if javascript is enabled. I think we’ll be able to get that empty field checking in there, too, Rory.

I’ve also asked the development team about providing appropriate warnings and substitute behavior where possible. Why do we change the submit button at all? Quite simply for consistency with the rest of the site. This is the front door to members, and it should look like it. Being accessible shouldn’t be contradictory with that goal.

I’d like to build on some of the advice in the post and the comments to make deeper changes and to refine our working strategy for future development. Ian, would it be alright for me to get in touch by email so we can go over some approaches that would work better for people who might have been frustrated like yourself? If anyone else here would like to contribute to that discussion, drop a line to me personally [email protected] and I’ll get you into any conversation that comes of this. Thanks for the comments, all. It’s the kind of discussion that we definitely learn from.

#16 On November 6th, 2006 3:46 am Ashley Bowers Blog » Using a sledgehammer to crack a nut replied:

[...] Using a sledgehammer to crack a nut [...]

#17 On November 6th, 2006 12:00 pm WaSP Member lloydi replied:

Todd, apologies for not getting back to you – not checked this thread for a while, nor have I checked magnolia since writing the original post. I am pleased with the responses here – that’s to say it’s nice that I didn’t get a bunch of crazies shouting me down and that people generally agreed with my point! Also it’s good to hear from two people behind the site who are willing to communicate about the issue.

I will drop you a line separately about the issues we have here. I am planning a meeting with our tech security/firewall bods to discuss the matter and learn more about it so once I’ve done that I’ll get back in touch with you.

#18 On November 6th, 2006 3:00 pm Todd Sieling replied:

Sounds good, Ian. Thanks for following up and I’ll catch up with you in email.

#19 On January 12th, 2007 7:56 am No Relation» Blog Archive » Accessibility and Usability: Can I always use a 100% AJAX Solution? replied:

[...] – Using a sledgehammer to crack a nut: Ma.gnolia’s case. – Blogger: Can I get in please? – Bloglines is broken! (at least for me) [...]

Return to top

Post a Reply

Comments are closed.

Working together for standards The Web Standards Project