Usability: Autofocus textfields
kkaefer - October 20, 2006 - 14:22
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | usability |
| Category: | feature request |
| Priority: | normal |
| Assigned: | kkaefer |
| Status: | needs work |
Description
This patch allows textfields and textareas to be focused automatically on page load by adding #autofocus => TRUE. Especially if you want to add a bunch of taxonomy terms, it’s really annoying to focus the text field manually. The patch adds #autofocus => TRUE to textfields where it makes sense, i.e. important text fields like titles, names etc. that usually appear at the top of a form.
Note: the focusing takes place at a very early stage so that your focus won’t be changed if you already click on a form element while the page is still being rendered.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| autofocus.patch | 11.68 KB | Ignored | None | None |
#1
#2
You can also do that by adding a tabindex field using
#attributes! For example<input type="text" tabindex="0" value="abc">, the form element with the lowest index will get focus on load. It's much more valueable to define a tab order than having a simple (boolean)#autofocusIMO.#3
Besides the fact that
tabindex="0"doesn’t work for me (I am using Safari),tabindexis considered evil. Have you ever been on a website that usestabindex? Some of them are really weird because if you tab, you will get to the field below instead of the field right next to it. Users are used to the source ordered tabbing of elements and they expect (at least I am) that the next visible element is focused when they tab.#4
I must admit I never used tabindex myself and YES it can be evil ;)
It seems that your code always focuses the first
#autofocusfield on the page, right? Thats great, because I dont need to ask what happens if there are multiple autofocus fields on a page! I guess this option must/should be used by module developers very carefully. But I like it and it can enhance usability a lot. But I think it needs some more reviews before RTBC.+1 on the idea and the patch
#5
Updated the patch. I will provide another patch that will allow users to disable certain JavaScript functionality.
#6
This is a simple and cleanly coded usability improvement.
The particular forms to add it to is no doubt debatable. The implementations done here, however, seem to make sense.
For consistency with #collapsible and #autocomplete_path, there should be a default
#autofocus => FALSEfor 'textfield' and 'textarea' insystem_elements().#7
Code looks good and this would be a very useful, yet simple addition.
My only concern, does "autofocus" make more sense then just "focus"? I think the latter might be a better choice...
#8
Do we still use drupal_add_js(.., 'core') ?
+1 for the feature and for applying it across core. This improves usability a lot.
Other places we could apply to:
- User login/register/password form and block
- Search page
#9
When using my Focus module which does the same thing the only drawback I've seen so far is that Opera is a bit slow when applying the focus which has some side effects. E.g. when creating a content type and scrolling down the page fast, it will jump up again when the "autfocous" is applied. I think this is due to the focus being applied after the core javascript (textarea, collapse). Firefox don't have this problem.
In this patch the focus is done first which removes most of the delay. My point is that the order of the (core) javascript files seems to be somewhat important. autofocus.js does come directly after drupal.js, but is that intentional?
+1 for this in core.
#10
quite nice. hope that recent comments are incorporated and we drive towards commit.
#11
very nicely done.
tested with firefox and safari on os x and firefox and IE 6 on pc.
#12
Rerolled the patch. While I was at it, I moved the autofocusing capability out of the theme function into a
#processfunction, my new favorite FAPI functionality ;). Also, the element that should be focused no longer gets a new class but the id of that element is passed as a setting in the header.#13
Rerolled the patch.
#14
I don't know why, but i am seeing apache segfault when adding a term with this patch applied. i don't know why. anyone else seeing this?
#15
in that case, its not ready
#16
Cool stuff, still moving to D7.
#17
Moving all usability issues to Drupal - component usability.
#18
Updated to most recent HEAD.
#19
Wonderful feature. I've applied the patch and I really enjoy it so far.
I'll review this more in depth soon.
#20
patch applies cleanly and works very well for all the forms I looked at.
It does mean that drupal.js will get sent to the user more often though. not sure how much of a concern that is.
#21
I think we woiuld be better off if these fields would get autofocus when they are empty. Most browser won't scroll using the arrow key if your cursor is inside a field. That's rather annoying when editing. When adding then sure, you want to start there, it's a very nice feature.
#22
Simple, elegant, and, simply put, it works; however, I completely agree with chx #21 in that autofocus should only take effect if the fields are empty.
#23
Agree with the suggestion in #21. Let's try and get this fixed within two years after opening the issue! :-)
#24
Caught this patch up to head, and made the autofocus only happen if input fields are empty.
And in line with #23, we only have 4 days to get this done ;)
#25
This is awesome! Patch applies with some fuzz on user.module & user.admin.inc, but that's not really a blocker imo.
But really, try adding some terms to a vocabulary, man, a life-saver! Marking as rtbc to get some core commiters attention.
#26
Looks good.
#27
This is a sweet little usability patch! Nice! :D
The discussion I wanted to have in #drupal is whether or not it makes sense to move this behaviour into FAPI so that it's automatic and module developers don't have to manually remember to do this. I can see a lot of follow-up patches resulting from forms going in that are missing this property, and contrib being very spotty about it.
It seems like the logic would be something like:
If this is the first time there's been a text field on this form and it is empty, then toggle its #autofocus property to TRUE.I am also very, very tired, so it's possible I'm on crack. ;)
Either way though, this also needs a changelog entry. :D So marking CNW.
#28
@Webchick, I understand the logic behind setting the first textfield to autofocus automatically, however, right now in my D7 test site, I have the search box also in my left region. Say I want to add new terms, I *think* (untested though), the autofocus will be set on the textfield of the search form while I really don't want that. My two cents of course, what do others think about this ?
#29
Usability-wise making this default behavior for primary forms is a good idea. It would be quite counter-intuitive if all forms created by core had auto-focusing, but suddenly a form provided by Module X doesn't.
On the other hand, that requires the auto-focusing behavior to detect which form item is the first of the Primary Form. Or we have to make sure that forms like the search field, simplenews subscription field, etc, explicitly set
#autofocus = FALSEon their form. In fact, that isn't all that bad, because this would only be tiny subset of the forms compared to the regular forms.#30
Ok, let's amend the logic:
If this is the first time there's been a text field on this form and it is empty, AND this is the first #autofocus property that's been set this page request, then toggle its #autofocus property to TRUE.Since search, etc. are in sidebar blocks, they would be rendered after the primary content (I think?) so this could work. Maybe? :)
#31
More or less. But we might only want to autofocus the textfield if it is empty, per #21.
Not always, depends on the theme, some themes have the left blockbar before the primary content. Also, some people place the search box in the top theme.
I think it is important that non-main forms like the search-block are actively prohibited from getting the #autofocus property.
On a related note, does somebody have experience with an anchor that is way below, while having an autofocus for something higher up? Does the page get shifted a lot then, or does the anchor have precedence over JS controled focus?
#32
When is a field considered empty? Some fields might have a default value that should be automatically selected. I currently can't think of one, but I'm sure there are some.
#33
Hm. The only one I can think of is site name on the install form. Ok, how about:
If the form element has its #autofocus explicitly set to TRUE, use it.
Otherwise:
If this is the first time there's been a text field on this form and it is empty, AND this is the first #autofocus property that's been set this page request, then toggle its #autofocus property to TRUE.
:P