jQuery Login Box

I need to build a login box satisfying the following requirements:

  • Build it as a UI Component that can be used in multiple locations on a site
  • Two instances of this component can exist on the same page
  • Use jQuery, HTML5 and CSS3
  • Your site supports IE9+ and current versions of Safari, Chrome, Firefox
  • Your site supports iOS6
  • Login form submits username and password data using AJAX to: api.yoursite.com/login

I’m trying to determine the best approach, but am struggling with the following:

  1. By “UI component” I’m assuming this is supposed to be done using jQuery UI? In that case, dialogue box seems like a viable option, but maybe I’ve overlooked something?
  2. If needing to exist in multiple locations on a site and/or two instances on the same page, should I take this as a cue to avoid IDs and only use classes, or are there larger implications beyond the CSS?
  3. This is a demo/test login page, so the site itself doesn’t actually exist. How can I go about testing various logins without hard-coding in some fake user IDs and passwords? Is that even possible?
  4. I’m confused by the URL provided: api.yoursite.com/login. Is it assumed that /login is tied to a PHP file?
  5. I don’t see how this can’t involve a server-side language, but the requirements only permit me to use jQuery, HTML and CSS. Is cross-domain Ajax the answer?

Here’s the HTML I’ve come up with. Pretty basic…

    <div class="loginContainer">
        <div class="loginModule">
            <form class="loginForm" method="post">
                <fieldset class="loginFields">
                <legend>User Login</legend>
                <h1>User Login</h1>
                    <input autofocus class="loginID" type="email" placeholder="Apple ID" required />
                    <input class="loginPassword" type="password" placeholder="Password" required />
                    <button class="loginSubmit" name="submit" type="submit" >Login to your account</button>

As for the jQuery, I have this:

        url: 'http://api.yoursite.com/login',
        type: 'POST',
        data: {
            username: $(".loginID").val(),
            password: $(".loginPassword").val();
        success: function (data) {
            if (data.success) {

            } else {


Keywords: encapsulation, re-usability.

var loginOne = new My.UI.LoginBox( '#loginOne' );
var loginTwo = new My.UI.LoginBox( '#loginTwo' );

NOTE: an HTML element can have both a class and an id attribute.

You don’t have to code everything from scratch, you’re using jQuery. But not jQuery UI. You should use HTML5 API (I’m guessing web sockets) and latest CSS, CSS3. You don’t need to test for IE8 and below or iOS 5 and below.

Just plain form submit rules, no server side response handling requested.

Thanks for the feedback. I have some follow-up questions:

  • Could you explain how this works in more detail? var loginOne = new My.UI.LoginBox( ‘#loginOne’ ); var loginTwo = new My.UI.LoginBox( ‘#loginTwo’ );
  • If one of the requirements is that the login box can have 2 instances on 1 page, then shouldn’t’ I avoid using IDs? (this also applies to the previous question)
  • What about web sockets I should know / be incorporating that I’m currently not?
  • Is there anything significant about accounting for iOS 6 and up? Anything important that iOS 6 introduced that would be easy to overlook? This is when iPhone 5 launched…
  • Let’s say there’s www.yoursite.com and api.yoursite.com, isn’t the latter technically in a different domain than the former? Am I making this more complicated than it needs to be?

Here’s the fiddle I’ve created: http://jsfiddle.net/manh2244/rwxq5/

Two instances on one page:

  • HTML: both login boxes have the same class, yet each one has it’s own unique id
  • JS: the programming logic behind the login box component needs to account for more than one User ID, Password or Submit button, i.e. be login box id specific (see HTML above)

The way your fiddle is right now, when you have two login forms on the page, with one submit button $(".loginSubmit") you are targeting both forms.

iOS 6 is a big step forward supporting HTML5 and CSS3. It actually makes you job easier by not asking you to be backward compatible.

api.yoursite.com is a subdomain for yoursite.com

And finally, forget about web sockets, I now see you have to AJAX. Maybe look for some other HTML5 stuff, like local storage for login details.

How do I go about checking the login credentials if no server side response handling is requested? I know how to validate the ID and password fields for correct formatting, but need to factor in username/password combos to test this out, no?

You create a JSON object which acts as a substitute for server-side database. Simulate the AJAX response with data from the JSON object.

I’ve updated the fiddle with my latest attempt. Does the JSON object I’m attempting to create come close to what you’re describing? And how would I go about simulating the AJAX response? Getting down to the wire, and would really appreciate any additional insights. Thanks for your help!


Stop making this about server-side, you are only required to build the front-end UI component that is independent of what the server-side is. So get rid of that /scripts/login.php and use what they asked you: api.yoursite.com/login

You don’t have a reusable component yet. So you can’t use two instances on the same page yet. Focus on that. Objects, anyone? :wink:

Alright, I changed url back to api.yoursite.com/login

As for the reusable component, I know I need to start with some code you provided earlier:

var loginOne = new My.UI.LoginBox( ‘#loginOne’ );
var loginTwo = new My.UI.LoginBox( ‘#loginTwo’ );

But I’m not sure what to do with this. I’ve worked with Objects, but not in the context of UI components. Could you point me in the right direction?

You can take your cue from here: http://ink.sapo.pt/js/ui
Or from here: http://www.html5rocks.com/en/tutorials/webcomponents/customelements/
Though web components are of the future, but you could impress your audience with this.

So I’m assuming I’ll need to use Ink.js for the job? I guess I could do so and still satisfy the requirements, but wanted to make sure that’s what you were getting at.

No :slight_smile:
You could follow Ink’s path to build your component.

I’ve looked into Ink.js and tried to figure out a workable solution for my login boxes. Here’s what I’m thinking:

  1. Each login box should be treated as a separate <form> instance, which means each will need an ID. I’m thinking an .each() function to dynamically assign the IDs would do the trick. (Although, if I only need to account for a max of 2 instances per page, this could make the ID assignment much simpler)
  2. I’ll be able to treat each as a separate UI component once there’s a unique identifier. I can then worry about loading a separate script for each component, which is how Ink.js handles multiple.
  3. After #s 1 and 2, the code you gave me earlier will be more applicable (i.e., var loginOne = new My.UI.LoginBox( ‘#loginOne’ ); var loginTwo = new My.UI.LoginBox( ‘#loginTwo’ );

Does this sound like a logical approach to you, or is there something I’m overlooking? Am I crazy?

Here’s what I’m thinking:

  1. Assign ID to <div> container of each separate form instance (using .each())
  2. Once each form has a unique ID, I can treat them as separate UI components and worry bout loading a different script file for each, which is what Ink.js does
  3. After #1 and #2, your code from earlier will be more applicable (i.e., var loginOne = new My.UI.LoginBox( ‘#loginOne’ ); var loginTwo = new My.UI.LoginBox( ‘#loginTwo’ ):wink:

Is this what you had in mind?

You have a single script. The script receives different HTML elements as parameters and manages separate state and common behavior for each of them. That’s what new is about, with different login boxes parameters. That’s what the requirement of having two instances of login boxes on the same page is about.

Alright, two separate <form> instances are now tied to a single script. I’ve changed a number of things, but I think my latest attempt encapsulates more and is easy to re-purpose. Do you see any issues with this approach?

Forgot to mention, it’s in the fiddle :slight_smile:


I’m not looking to burst your bubble or anything, but if this is for a job interview, I believe they expect a whole lot more from you. They gave you a deceivingly simple task and maybe I’m wrong here, but I think that they expect much more from you than a simple function and I think that they expect much more from you than a simple jQuery widget.

While any of the simpler approach would be enough to complete the task, I believe they expect you to be familiar with more advanced topics and techniques. Personally, I think that that’s why they mentioned jQuery together with IE9+. jQuery starting with v2 has dropped support for IE8- and is also supporting a modular approach.

They will asses your level depending on your approach. You seem to have trouble coping with terms like component, instances, domain. When you mix together OO, AMD and modular jQuery, for a JS newbie things start to get real crazy real fast. There’s a lot of ground to cover. Let me know how it goes, and, after New Year, if you still want, we could get into this.