In Chrome, I have created form input elements that has a label, when focused, float above the input field. This works and executes perfectly.
When I use the chrome autofill for the username and password, the browser populates the input field with the yellow prefilled text. The issue I am having is the label JS does not execute and float to the upper right when the yellow prefilled text is visible. It does auto-correct the issue if you click anywhere on the page. Any thoughts or solutions? I do need the autocomplete feature to be set.
When Chrome autofills an input, it won't trigger the :focus state that your CSS currently relies on. Unfortunately, no such pseudo-selector exists in CSS for detecting whether an input is filled or not (learn more here).
Your best option is using jQuery to detect whether each of your inputs has a value and add a class if true. See the example here. Then revise your animation effect so that it applies to input.has-data-class, for example.
Related
Is it possible to set the validation error color on form fields manually? I couldn't really figure out how it was doing the validation on their site. Seems like the browser is doing it automatically based on the type attribute. But what CSS would I need to attach to trigger that state? I need to do a custom validation on a text field and the one that browser does automatically is not enough.
As I already wrote as a comment.
You just need to add the invalid class to your element.
Next time you could use the inspect element tool which is built-in in Chrome.
Autocomplete="off" on textarea fields doesn't seem to work as it does with input fields. I couldn't find anything about this on Google. Is there a difference?
Specifically, I have a page that has half normal input fields, and the other half dynimically generated via javascript. When I navigate away from the page and then navigate back, the text that was in the dynamically generated fields overwrites that which is in the normal fields. This only happens when I navigate away and then click back. If I just refresh the page, it doesn't happen. Autocomplete="false" solved this problem for input fields, but it did not for textareas.
The autocomplete attribute or property is limited to input elements, both according to Microsoft description of the feature and according to the HTML5 draft description proposed to standardize the feature. So you should expect browsers to ignore it for other elements, including textarea.
Apparently, autocomplete is not the real question, just an assumed approach, which is a wrong one. But the real problem was not really described.
I'm working on an online enrolment form for a training organisation. The labels for the text input boxes have been placed inside the inputs themselves using the solution at http://attardi.org/labels/
It works perfectly in Chrome, Firefox, IE9 and IE8, but for some reason in IE7 there's a problem coming up (surprise, surprise!)
If I click on the input field in the area where the label is, the browser does not focus on the input. The input field will only go live if I click on the white space after the label, or bizarrely, if I click slightly below the input field.
Is this a CSS or a JavaScript issue, and can anyone suggest a solution?
You can access the form in it's entirety at http://testing.xenongroupadmin.com/enrolment but beware - the HTML, CSS and HTML files are very hefty and could take some time to sift through!
Ditch the script you've linked to.
Use regular html5 placeholder attribute (http://davidwalsh.name/html5-placeholder) - it's the cleanest solution to get what you need in most browsers. To handle IE7/8 you can use javascript shiv, like this one: http://dipaksblogonline.blogspot.com/2012/02/html5-placeholder-in-ie7-and-ie8-fixed.html
I am trying to get a checkbox with a label to function so that when you have text selected in a contenteditable div, clicking on the label will not lose the selection from the div. The label still needs to apply the standard checkbox tick/untick upon clicking it, but keep the focus & selection intack on the div.
Doing a simple focus() on the div won't help as the selection will be gone (and caret is at the beginning). I could of course look into a way for storing the selection object and trying to assign it back after the label click, but isn't there any simpler way of keeping the selection?
(the reason I need to do this with label & checkbox is because I will be using jQuery UI buttons and I will need the the toggle functionality of them)
On a similar note, if you click the checkbox, you usually still keep the selection in the div, but at least on FF4, if you press the checkbox very frequently (<1s), it will lose the selection. Any idea what's going on there? answered below
example: http://jsfiddle.net/niklasvh/gULM9/
It's a Firefox bug marked 490367.
According to the bug description, double-click functionality on input fields will act unusually when there is a contenteditable div on the page.
I noticed the strange behavior while trying to replicate it manually so I guessed it was a bug. I don't know of any workarounds.
This is a 2 part question:
1)
click on one of the demo dropdowns on this page. when you tab over to the next input, the text is selected/highlighted in firefox. how can i prevent this from happening?
2) bonus: can you review my code that is hosted on google and tell me what i can improve?
Well, that is just default behavior on Firefox. A possible workaround is to have the input fields execute a JavaScript or jQuery function on select, have the function blur the field (which would deselect the text) and then refocus on the field. Very basic and I'm sure it'd need a couple extra hacks. Unfortunately without scripting, no there is nothing you can do to prevent that.
I honestly recommend that you leave it alone. That functionality was put in place so you wouldn't have to use your mouse when typing into forms, hitting tab would select all the text so you can easily retype it or hit the right arrow key to go to the end of the field. Removing the functionality will only irritate some of your visitors. If they're using the tab key to get to the next field, they probably want that functionality.