Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Login input fields with static text, like ones on facebook? 2

Status
Not open for further replies.

MrMiyagi

Technical User
Feb 11, 2009
43
FI
Hello,

My problem is that i would like to have login input fields with text inside, like facebook has:

(email & password fields)

The email text input field has the text "email" in it statically until start to type something else, and password input field has text "password".

Facebook front/login page has also a functionality to select the email field straight away on refresh, so that the user does not have to select it, but can just start typing login info. How can i do this function?

for example password field html:
<input type="password" class="inputpassword" id="reg_passwd__" name="reg_passwd__" value="" />
From this i can see that the word typed inside the value field will come visible to the password field, but facebook html code has an empty value="" so the words email & password must come from somewhere else...javascript?

<input type="password"/>
This will make the inputted text into censoring balls

<input type="text" value="password"/>
This will bring the word password on the input field on every refresh.

Facebook input field has html input tag type=password value="" and the censoring balls appear when start to type. How is this done?

Thank you very much for all the answers!
 
I've heard great things about jQuery, but I'm one of those coders who like to write his own scripts - sure I get ideas from other places, but I still prefer to have full control over what's going on and try to discourage my sites from having excessive code that will never be used.

Here's my example (i've written my own short and simple dollar sign function)


^ that took me all of 5 minutes to write and it works 100% exactly how I want it to.

Before going into production with something like this, I'd set the onfocus and onblur events for each input box within the onload event as well.

I just want to re-itterate, I think jQuery is a great library and it has tonnes of features to make sites very dynamic. I've gone through the site on numerous occasions to get ideas on writing my own scripts.
 
I was just thinking on this further and, in the spirit of progressive enhancement, really the initial HTML should be a password input.

The Javascript should then turn it into a text input with the necessary text in it etc.



Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.
 
Foamcow,

why would you want to turn your password field into a regular text field when the user starts typing? The whole idea of masking the characters is so the person sitting over your shoulder can't read your password by simply looking at the screen.

The way it is right now, it says "password" which means you don't need a label - the text field version of the field becomes your label.

TIP: trying googling the answer before posting, you'll find that more times than not someone else somewhere has had the same request and posted an answer online.
 
You misunderstand.

If you create the starting HTML using a password field then in the event of javascript not being available it is still a password field but lacks the enhancement of the starting text, auto clearing etc.

If you then use javascript to turn that into a text field on page load then you can put the starting text in there and attach an event listener to create the functionality required by the OP.

If you don't do it this way and Javascript isn't available then the password field will be plain text as you describe, which is obviously undesirable.

The page should work "properly" without any javascript. The javascript should add some extra functionality - in this case the Facebook style text acting as a label...


ah... labels.
Strictly speaking you should have a label for each input for accessibilty reasons.
To that end, the methods we've created here kind of fail.
Again you could employ progressive enhancement and create your starting HTML with <label> tags but then use Javascript to remove them from the DOM.


So, consider the 2 scenarios of Javascript loading or not loading.

1. Javascript doesn't load or isn't available
Our page consists of a label tag with an input password field and functions as normal.


2. Javascript loads
Our page consists of an input text field containing a 'faux-label'. A click on this field clears the 'faux-label' and turns it into a password field (with masking). A blur event performs a check on the content of the field and if it is empty turns it back into a text field and reinserts the 'faux-label'. Otherwise the form submits as normal.

Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.
 
I've updated my jQuery version to demonstrate what I mean.


Code:
$(document).ready(function(){
		
		// remove label tags from dom
		$('#password').siblings('label').remove();
		
		// add a faux-label
		$('#password').replaceWith('<input type="text" name="password" id="password" value="Password" />');
		
	    // capture the initial click and bind a custom function to it
	    $('#password').bind('click',fieldcheck);
	
		function fieldcheck(el){
			if($(this).attr('type')=='text'){
				$(this).val('');
				$(this).replaceWith('<input type="password" name="password" id="password" />')
				$('#password').focus();
				$('#password').bind('blur',fieldcheck);
				
			}
			
			if($(this).attr('type')=='password'){
				if($(this).val()==''){
					$('#password').replaceWith('<input type="text" name="password" id="password" value="Password" />');
					$('#password').bind('click',fieldcheck);
				}
			}
		}
	   
	});

Try with Javascript on and again with it off. If you have the Firefox Webdeveloper plugin, view the generated source or examine the DOM and you will see that the label tags are destroyed.

Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.
 
i think the key to this is: initially, the field is set to type="text", thus making it readable as the word 'password', then when there's focus on the field, the type changes to type="password". this might be the way they're doing it.
 
Hi

Seeing all that code, I would choose a different approach.
CSS:
input#email,input#password {
  background-repeat: no-repeat;
  background-position: center left;
}
JavaScript:
window.onload=function() {
  document.getElementById('email').onblur()
  document.getElementById('password').onblur()
}
HTML:
<input type="text" id="email" onfocus="this.style.backgroundImage='none'" onblur="if(!this.value)this.style.backgroundImage='url(email.png)'">
<input type="password" id="password" onfocus="this.style.backgroundImage='none'" onblur="if(!this.value)this.style.backgroundImage='url(password.png)'">

Feherke.
 
I see what you're getting at but that's even less accessible.
No labels and no readible text.

Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.
 
Hi

I somehow agree. I read some articles about this concept.

But I strongly believe that the [tt]value[/tt] attribute was not designed to improve accessibility.
Foamcow said:
No labels and no readible text.
I posted only the essential part.
HTML:
[red]<label for="email">E-mail</label>[/red]
<input type="text" id="email" onfocus="this.style.backgroundImage='none'" onblur="if(!this.value)this.style.backgroundImage='url(email.png)'">
[red]<label for="password">Password</label>[/red]
<input type="password" id="password" onfocus="this.style.backgroundImage='none'" onblur="if(!this.value)this.style.backgroundImage='url(password.png)'">


Feherke.
 
I very much agree that the value attribute is not to aid accessibility.

It is true that you could use a background image to show the 'faux-label' but this will produce no 'actual' text. For instance, if the image failed to load, or images were disabled then the user would be presented with a pair of blank inputs (assuming the label tags were removed).

My last example uses javascript to apply the desired effect to a properly formatted, accessible snippet of HTML.

The labels exist but are removed by Javascript and the value attribute is used to show a 'faux-label'.

We have basic HTML that will provide all the info needed to the user and function accordingly. We then apply niceities and effects using Javascript and CSS.

<shrug>

Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.
 
You need to take a step back and look at this from a user's perspective, not a programmers/designer/developer perspective.

I used to work with a guy who was always very strict about his source code. He always used to say "when people right click on a page and view my source code, I want it to be clean and concise"....I always said hogwash to this. As a developer myself, sure I look at other people's source code, but I seriously doubt that the 10-15 year old kids that are looking at sites like facebook or myspace go through the hassel of turning off their javascript or css to see what the site looks like.

It's like saying I'm not going to use Google or Wikipedia because i viewed their source code and they use in-line styles and table based layouts as opposed to putting all their styles into a CSS file.

I don't know of any user (except for us programmers/developers) who even know what CSS and Javascript all, let alone how to turn them on/off.

TIP: trying googling the answer before posting, you'll find that more times than not someone else somewhere has had the same request and posted an answer online.
 
I don't know of any user (except for us programmers/developers) who even know what CSS and Javascript all, let alone how to turn them on/off.

It is absolutely NOTHING to do with being a developer or looking at source code. As developers we should understand exactly why we should cater for the lowest common denominator when coding for user interaction.

I don't know of any user (except for us programmers/developers) who even know what CSS and Javascript all, let alone how to turn them on/off.

Correct. In fact I only turn CSS or Javascript off to test things. Great. But I also realise that not all people use the same browser/computer/font-style or anything the same as I do. The beauty of the web is that we deliver raw info and it's presented in whatever way suits the person at the other end. Or at least that's the theory. Sadly that idea is lost on a lot of developers.

There are a significant number of people that use browsers/devices that don't take any notice of CSS and Javascript? Do we ignore them?

The whole idea behind Progressive Enhancement is that it caters for that lowest specced user and ADDS functionality in layers. The key being that without the layers the core function of the thing still works perfectly. For something like the topic of this thread it's really little extra work but does require a bit of thought and consideration - as shown by the revisions to code in this thread.


The notion of accessibility and progressive enhancement has been rather prominent for a number of years now. As developers "we" should be more than aware of the reasons to build accessible interactions as it's often just a case of thinking something 'from the other end' as it were. If anyone reading this doesn't 'get' that or believe it's relevant then please, please, please do some more reading, research and testing.

Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.
 
There are a significant number of people that use browsers/devices that don't take any notice of CSS and Javascript? Do we ignore them?

~95% of the users out in cyber world use IE6/7 or FF 2+ as their browser of choice. All of those browsers support CSS.

There are ony 5% of users in Jan 2009 that had Javascript turned off. Every year, since 2005 that number has decreased and with the way the world is going, it's going to decrease even more by the end of this year.

^ those numbers don't seem very significant to me.

Talking about trends and upcoming technologies, one of the biggest buzz words out there is still AJAX which everyone wants - are you going to seriously suggest to a client that they shouldn't use it because a handful of users won't be able to utilize the feature set? Or are you going to tell your client it's going to cost them double because the 10 visitors per year they get have javascript turned off so you need to build them a seperate section? Give me a break...

I tell my clients this - at the start of your application, if people have Javascript turned off re-direct them to a page letting them know they have to upgrade their browser - simple as that.

If it's so important that 100% of users can access your site,forget about CSS layouts / styles and go back to the 90's when everyone was using Tables and Font Tags - those are 100% guaranteed to work in any browser dating back to when Netscape Navigator was still around.



TIP: trying googling the answer before posting, you'll find that more times than not someone else somewhere has had the same request and posted an answer online.
 
vicvirk
Suggest you have a look at which most pro web designers will be familiar with. It deals with Web accessibility and addresses other access methods (such as text readers)

If you want the best response to a question, please check out FAQ222-2244 first.
'If we're supposed to work in Hex, why have we only got A fingers?'
Drive a Steam Roller
 
vicvirk said:
There are ony 5% of users in Jan 2009 that had Javascript turned off. Every year, since 2005 that number has decreased and with the way the world is going, it's going to decrease even more by the end of this year...those numbers don't seem very significant to me.
And if you were visually-impaired and your screenreader didn't support Javascript, or you turned off Javascript because it was only partially supported in your screenreader (and thus created more problems than benefits)? Unfortunately, it's not just a numbers game. We should be aiming to give everyone equal opportunity to access a web resource.
vicvirk said:
...are you going to seriously suggest to a client that they shouldn't use it [Ajax] because a handful of users won't be able to utilize the feature set? Or are you going to tell your client it's going to cost them double because the 10 visitors per year they get have javascript turned off so you need to build them a seperate section? Give me a break...
Neither. The key is not to develop a separate section, but to start with something that works for all, then progressively enhance. Therefore, users who have browsers that support the Ajax techniques you use can benefit, whilst those that don't still have something that functions. Admittedly, this does take more thought and planning upfront in the development process.




Clive
Runner_1Revised.gif

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To err is human, but to really foul things up you need a computer." (Paul Ehrlich)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get the best answers from this forum see: faq102-5096
 
...are you going to seriously suggest to a client that they shouldn't use it [Ajax] because a handful of users won't be able to utilize the feature set? Or are you going to tell your client it's going to cost them double because the 10 visitors per year they get have javascript turned off so you need to build them a seperate section? Give me a break...

You don't get it.
Stretchwickster does get it.

It doesn't need to cost anything more, let alone double. That just shows that you aren't understanding the point being made.

The point is that what you build should work without Ajax but is made "better" if Ajax functionality is available.

If you think 5% isn't significant then consider having a site that gets 100,000 users a day. 5% of 100,000 is 5000 users! That's not an insignificant number is it?
Now consider that your site is selling something - those 5000 users represent a potentially large amount of missed revenue. Even if you take the numbers down to 1000 visitors a day that's still 50 users you are potentially alientating.
You can avoid that for what amounts to quite a minimal amount of lateral thinking and not necessarily any more code or costs.

Going back to my original (revised) method of answering the question. How is there any more work in that than in doing it in what I consider the 'wrong' way? All I did was think about it slightly differently.

Tek-Tips Forums is Member Supported. Click Here to donate

<honk>*:O)</honk>

Tyres: Mine's a pint of the black stuff.
Mike: You can't drink a pint of Bovril.
 
Foamcow, I never said your way was the wrong way, I simply stated that you don't need to go that far.

If you want to have javascript on your site, you simply don't allow people in who don't have javascript enabled.

Facebook won't let you even register for their site without javascript and some of google's tools (i.e. maps) don't work without javascript - are you saying you are a better developer than the ones employed by those two giants?

Look at it from a business standpoint, If I open a bakery, I'm not going to put a hot dog vending machine in one corner and a popcorn making machine in the other because 5% of the visitors that come into my store may have a desire to buy something other than sweets. That's what the grocery store across the street is for.

I always take W3C Standards into consideration, but if Microsoft can't build a standards complient browser (and like it or not, that stats still say IE is the most used browser out there), I'm not going to build my sites to be 100% complient.

I remember 10 years ago, our office went through 3 months of work switching all of our font tags to css classes on thousands of pages because the font tag was deprecated and new browsers were not going to render it anymore - guess what? Here we are 10 years later with 15 different versions of 15 different browsers and they all still render that tag the same way they used to.

Go ahead, put this in an HTML document and run it in IE6, FF3 or Google Chrome and see what happens...

Code:
<font color="red">Hello</font>

I'm not saying I still use the font tag - I don't (really, I don't). Look at this page and view the source:


I'll ask you this - could you find one site that manages to meet the needs of every single type of visitor they could get to their site? I seriously doubt it.





TIP: trying googling the answer before posting, you'll find that more times than not someone else somewhere has had the same request and posted an answer online.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top