I’ve experimented a bit with Seaside, jQuery and possibilities of setting the input focus to the first visible input element of a page after it has been rendered. This is of course and interesting problem from several perspectives:
- You need the code to focus a form element. Code snippets for this aren’t hard to find, especially in the context of jQuery. I especially liked this one:$(“input:visible:first”).focus();
- A page can have multiple forms. There might be a search option on your page and some other input fields spread over several forms on a typical page. So the end result of this snippet may be completely not what you want. For special cases, some more css magic in the form of additional classes on your input fields are needed. This is a problem I haven’t found a perfect solution for, but I know I can accomplish this with marking a certain for with a respective class and extend the css selectors in the above statement.
- Just a comment: the expression is not completely correct, because the $() returns a list of elements, even if the selector :first is used. So there may be problems waiting somewhere in the deepest details that I don’t even dare to think about. Unfortunately, a .get(0) didn’t work, for whatever reason (I’ve given up on such questions in the context of JS and jQuery – shrug, ask Google, continue).
- Then there’s the question of how to embed this script into your Seaside application so that it works on any page rendered. So far I’ve found the solution of adding this to my root component’s updateRoot: method:
anHtmlRoot context document addLoadScript: ‘$(“input:visible:first”).focus();’.
This seems to work perfectly, until I realized that if the first input element on a page is supposed to do something on getting focus, it won’t do so. Take a datepicker, for example. If the first input element is a its calendar won’t pop up. This sounds not to bad at first, because it would probably seem a bit strange if it opens up immediately, but on the other hand, there is no way of popping it up as long as the focus stays on the date picker. That’s probably the main reason why so many apps have an additional push button after the text input for this purpose.
Oh my, I need to experiment a little more. Maybe there even is a nice solution. If only these “little” things wouldn’t eat up so much time with so little tangible outcome. On the other hand, if the feel of a web page is bad or weird, people will realize immediately, so such things cannot be postponed for too long…