Could you suggest the best way to keep focus on a particular input field on page?
What I am trying to say is, no matter where user clicks on the screen, the focus should return back to this one particular input.
I am thinking of a timer function that would check for focus every 500ms and if its not there, then bring it back.
Also the best way to submit this input field without making use of any button
Any other and best solution for this?
Even if I don't like the idea, thinking about usability and user experience. Anyway, to answer your question, your best shot probably is to set the focus initially to that input element and watch for the
blur event. Addionally you might want to check for outside click events.
That might look like this:
$('#test').bind('focusout', function(e) {
if($(this).val() !== 'releaseme') {
setTimeout(function() {
$(e.target).focus();
}, 25);
}
});
That would force the focus to that input (with the ID "test") 25ms after it lost the focus. To check for the additional outside-click check this link.
Example link: http://www.jsfiddle.net/FX79h/
Again, this sounds not usefriendly. You might want to think about whatever you are trying to do.
Would be a major impediment to disabled accessibility consideration. Remember, some people don't use mice to navigate, and you'd render the site useless to them.
As to allowing submit, you could trap the enter keystroke via Javascript...there's several tutorials on how to do it. However, this would also negatively affect the expected user interaction pattern and disrupt accessibility aids. The button text is the only thing telling a blind user's screen reader that they can submit to the site. Without it, your site is a black hole to them.
I'm all for experimentation and pushing the envelope, but there are reasons that you see so many common elements across the web. Think about it like this--would you stop for a triangular blue stopsign? How about a square pink one? Believe it or not, familiar patterns make for a more comfortable experience. How you "push" familiarity is what determines your success as a UI person. I might add that there's a LOT of bad UI out there....
Related
I have a single page application. There is a page with products and on the bottom a link to go to the next page. Upon clicking this "next" link the list of products in the DOM is replaced. While the link clicked has stayed the same and maintains focus from the click. Is it better for me to do something like document.activeElement.blur() is that case? Or should I just leave focus on that as is?
I'm unsure what best practice is as with normal server routed pages the focus would be reset with the page load. But I haven't seen any information indicating manually resetting focus on client routing would be the best experience from an accessibility point of view.
Never ever use blur. It's just bad, random and possibly frustrating.
IN a native application, you should always exactly know where the focus is, and the focus should always be at a precise place; otherwise keyboard accessibility is broken.
If you consider your web application as being a true application, you should observe the same rigour.
So, never use blur, since you don't know at all where the focus is going to move afterwards. If you are going to remove something from the DOM that currently has focus, you should first place it in another place that make sense.
IN your case: clicking on a link, you have two reasonable options:
Leave the focus on the link (reasonable as long as you don't move, hide or remove it from the DOM)
Move the focus at the beginning of the new content that just appeared / has just been replaced
You may ask users of your application which solution they think is the best, or deduce the answer by observing them during a test session.
Let's summarize quickly: whether you are making an old-style website with different pages, and you don't have to matter much about focus, or you are making a real application and in that case you should be as rigourous as if you were developing a native app.
Terribly simple.
Lets imagine we have this sample code:
<input type="text" onblur="blurHandler()" />
<div class="results">
<ul>
<li>sampleText</li>
</ul>
</div>
Lets say you have currently focus on your input tag, and you hover to the "a" tag and click it. The browser will handle the onblur event first.
The task of the blur event is that it should hide the results div, but you still want to be able to click the link in the results div before that happens.
In blurHandler, use setTimeout() to delay hiding your div.
function blurHandler() {
setTimeout(function () {
//close the div
}, 100);
//do whatever else needs to be done
}
jsFiddle Demo
Another option would be to play with the mouseenter/mouseleave events on the link, and use a common flag between the event handlers so that they know about each other.
And one more: you can hide the div with a short animation, so it is actually still there when the click happens. Something like this:
$('.results').hide(1000);
jsFiddle Demo
Note: you should take a look at advanced event handling, inline event handlers can really mess up your HTML quickly. Separation of concerns helps others and your future self. If you use jQuery (seeing the tags under your question), you should use jQuery's event handling methods, which use the advanced model already.
I agree with Marcell's comment, though perhaps more from a usability perspective.
Assigning a timeout (as suggested by bažmegakapa) means you're choosing an arbitrary time limit that may or may not fire before the user has processed what they are supposed to do before that time limit is over. Unless your UI somehow makes it clear that they must react within a given time frame, this is likely to lead to frustrated users.
Even taking for granted that the users have had time to process the directions on screen, there's also transition time between moving from keyboard to mouse (or touch, where it's even worse as you have to deal with the UI shifting to hide the soft-keyboard), which means there's even more variance between different users' and their ability to follow the directions before the time limit you've chosen is over.
Just something to think about, in regard to how your interactivity is set up.
I want a way to capture the keypress events on my controls and if it's an Enter, set focus to the next control.
We had to do this once in a simple ASP.NET application to allow users to navigate through the controls by pressing enter on a Web Environment. We used a simple JavaScript back then.
Is there a way to accomplish this? If it envolves creating custom controls, are the LightSwitch control's classes available so I can inherit them all or something like that?
If you need to do it for a large number of controls, you'd be better of creating a custom control (preferably a control extension - binding is automatic), but you're going to need to create several different controls I'd imagine, not just a TextBox.
Of course it's up to you, but you might find it easier to just explain to/teach your end-users that "Tab" goes to the next control, "Enter" does not. This is the way that most Windows applications work, so you'd be going with the flow, instead of against it. There's a reason it's called "tab order".
Sorry, I know it's probably not what you wanted to hear, and you're not the first to ask for a way to do this, but as I said, you'd be going against the way that most, if not all, modern Windows software works, and it's not simple thing to do.
I need to send bunch of commands to the server on timer - like:
put(0,"hello")
del(4,1)
put(4," is around the corner")
so I need to monitor and record all of the user input and compile/flush it on the timeout (idle), something like macros.
I can record all things happening onKeyUp/onKeyDown/onMouseDown/onMouseUp using textarea cursor position and keys information (and make it cross-browser some time later) but I can't handle things like pasting using mouse right button and selecting 'Paste' or pasting from the menu (I can handle onChange, but I will have no information is it pasted or already recorded as pressed keys and it fires only after focus change). Even pasting from context menu fires some useful info, but the menu from the browser is the only thing, giving nothing for Javascript.
Is there any plugin for jQuery or something like that and do I really have no other ways to implement it without comparing current-document and document-a-second-before?
Upd.: There are events for handling cut/copy/paste: http://www.quirksmode.org/dom/events/cutcopypaste.html , but what about
the undo one?
P.S. I will show a macro-recording code when I'll finish, if someone really needs it. And to finish it properly, I just need the undo handling possibility. Current version is here: http://code.google.com/p/sametimed/source/browse/WebContent/module-editor.js, look for compileCommands method.
There are events for cut/copy/paste you may listen to, depending on browser. So if they are triggered you may use them, otherwise fall back to more tedious work-around.
See: http://www.quirksmode.org/dom/events/cutcopypaste.html
All I need is to be able to detect when text is dropped into a Textarea. I then take that text and do stuff with it and clear the textarea. There may be many of these textareas and very high UI expectations, so polling is a last resort.
For IE, "onfocus" does the trick, since this event is fired after the user drops stuff into the textarea.
For Firefox, I can't find an event that works. I've tried onmouseup and onchange.. don't know what else to try from there. I'd hate to have to poll the textarea for content. Help much appreciated. Thanks.
Edit: For clarification, "dropped" means the user selects text (usually) from the page, but it doesn't matter where, drags it, and drops it into the textarea. This is not the same as Ctrl+V, or right click pasting (which take two different methods of detection, BTW), or (obviously) typing into the textarea. Specifically, it is the "drop" aspect of drag and drop. I really don't know how else to phrase it.
I feel this question was stated rather accurately. To humor me, assume that I meant any of the other operations on a textarea that you all have chosen to share. If I meant "pasting", don't you think I would have mentioned something about pasting in the title or content of my question? Same goes for typing in a textarea. But, perhaps, you all just don't know me well enough to know that I type what I mean, rather than mistakingly typing things only somewhat related to what I mean.
For Firefox, this works for me:
window.addEventHandler("dragdrop", function(event) {alert("Drop it like it's hot!")}, true)
Does not work in Safari, however. Haven't tried IE.
Polling seems to be the only way to go.
When a Drag+Drop operation is started within the browser, it seems to cancel out everything else that's going on. You can witness this by putting "onmouseover" events on something on the page, then starting a DnD operation and dragging over it. The events will not fire.
It seems only a coincidence of how the browser internally handles "drag and drop" that it causes onfocus() to be fired for the textarea in IE and Safari. I doubt there is much defined in the W3 specification... not that it matters, W3 is crap, and besides nobody adheres to it completely.
In my question I stated the luxury of emptying out the textarea after each use, so I feel that polling for: textarea.value.length>0 is hardly any cost and shouldn't be much of a performance concern.
But, alas, it specifically has to do with dropping content into a textarea.
Down-mod away to sooth your pain.
If you want your textarea to react to text being dropped, pasted or typed, your only solution would be a button. Even a timer polling the content will not help you.
You mention that you want the user to be able to type text in the textarea. And you mention that you want to clear the text whenever the event is fired. There is no possible way for the browser to know that the user has finished typing. You must rely on a specific action.
Now for the drop or paste, you can rely on the mouseup and keyup events in order to detect that.
What do you mean by "dropped"? Are you talking about a paste (^V) operation? If so Aron's answer is indeed correct, you will get keydown/keyup (and the value will be readable in keyup).
A generic callback that will happen on any update to an input is 'onchange' - you could try that. Note that when typing, it doesn't get called until you finish and unfocus the input, so if you need instant updates on both typing and other forms of input, you still need 'onkeyup' as well.
Edit re clarification: IMO 'onchange' should be fired when a drag-and-drop causes content to be added to a text area; I consider it a browser bug that it is not (in Firefox at least). I can only concur in this case that polling is all you have left.