Form focus

[alephex]

Further to #244, #249 and #250

Current behaviour

When a page is loaded, the first input of the first form is automatically focused.

Problematic behaviour

If the first form is below the fold, web browsers automatically scroll down to the focused element. This means that, in some cases, a user may load a page and immediately be sent down to wherever the form is. This issue is particularly apparent on mobile/responsive pages.

Proposed solution

Forms are to have an additional argument to determine if input focusing should be done automatically, manually or not at all. In the case of manual focusing, child input fields of the form will have an additional argument to determine if they are to receive focus.

Forms can take an additional argument when they are created.
focus_form = 'auto' | 'manual' | 'off'
This results in the form being rendered with a HTML attribute data-deform-focus-form with any of the above values.

The javascript function focusFirstInput will perform the following.

focus_form	action
'auto'	First input of the first form is focused
'manual'	First input with manual_focus set is focused
'off'	No focusing is done
omitted	Same as 'auto'

Examples

Default

class SchemaInputDefault(colander.Schema):
    name = 'Default Input Focus'
    input = colander.SchemaNode(
    colander.String(),
    title = 'Input',
    missing = '')

class TestForm():
    def __init__(self, request):
        schema = SchemaInputDefault(validator=self.validate).bind(request=request)
        self.form = deform.Form(schema, buttons=(button,))

Auto

class SchemaInputAuto(colander.Schema):
    name = 'Auto Input Focus'
    input = colander.SchemaNode(
                  colander.String(),
                  title = 'Input',
                  missing = '')

class TestForm():
    def __init__(self, request):
        schema = SchemaInputAuto(validator=self.validate).bind(request=request)
        self.form = deform.Form(schema, buttons=(button,), focus_form='auto')

Manual

class SchemaInputManual(colander.Schema):
    name = 'Manual Input Focus'

    input1 = colander.SchemaNode(
                    colander.String(),
                    title = 'Input 1',
                    missing = '')

    input2 = colander.SchemaNode(
                    colander.String(),
                    title = 'Input 2 (Will be focused)',
                    missing = '',
                    manual_focus = 'on')

    input3 = colander.SchemaNode(
                    colander.String(),
                    title = 'Input 3',
                    missing = '')

class TestForm():
    def __init__(self, request):
        schema = SchemaInputManual(validator=self.validate).bind(request=request)
        self.form = deform.Form(schema, buttons=(button,), focus_form='manual')

Off

class SchemaInputOff(colander.Schema):
    name = 'No Input Focus'
    input = colander.SchemaNode(
                 colander.String(),
                 title = 'Input',
                 missing = '')

class TestForm():
    def __init__(self, request):
        schema = SchemaInputOff(validator=self.validate).bind(request=request)
        self.form = deform.Form(schema, buttons=(button,), focus_form='off')

Results

• Default behaviour is unchanged
• On page load, the first input field of the first form receives focus (default)
• Any one input field can be chosen to receive focus
• Automatic focusing can be disabled on a per-form basis

---

Existing nose tests pass. Some basic tests were added (checking defaults etc). I'm not sure if this is a big enough change to warrant any extra examples on deformdemo, but I can put together a pull request for that if it might be worthwhile.

[tisdall]

I'm not sure I see the need for both "manual" and "off". I think it should just be "manual" and then it focuses on the first field that it finds that's marked as requiring focus. "off" would be covered by using "manual" but just not giving any item focus.

Or, alternatively... The default is to autofocus="on" and the first field is given focus if no specific field is marked for focus, if a field is specified for focus then the first one specified is used, the last option is autofocus="off" to the Form object to stop all focusing. That avoids confusing combinations like specifying on a field to give it focus but you set autofocus to "auto" and it's not used.

@stevepiercy @mcdonc @tseaver @mmerickel - what's your opinion on how to best implement this?

[alephex]

I'm not sure I see the need for both "manual" and "off".

It's pretty trivial to get rid of "off", but I think it would be better to have the ability to explicitly switch off focusing on a particular form.

The current process:

form.focus_form	field.manual_focus	action
n/a	n/a	focus the first input of the first form

This pull request:

form.focus_form	field.manual_focus	action
omitted	n/a	focus the first input of the first form
'auto'	n/a	focus the first input of the first form
'manual'	'on'	focus on the first input of this form with 'manual_focus' set
'manual'	omitted	no focus on this form
'off'	n/a	no focus

@tisdall alternative:

form.focus_form	field.manual_focus	action
omitted	n/a	focus the first input of the first form
'auto'	n/a	focus the first input of the first form
'manual'	'on'	focus on the first input of this form with 'manual_focus' set
'manual'	omitted	focus on the first input of this form
'off'	n/a	no focus

The difference between this PR and the alternative is how we want to failover if the user does not set field.manual_focus either by forgetting or by cut-and-paste without realising it's 'manual' rather than 'auto'.

Given that, in the context of this 'browser scrolling on load' problem, automatically focusing an input below the fold is very undesirable. If done unintentionally, it effectively screws up the user's initial view of the page. As such, I think it will be better to fail safe with no focus if field.manual_focus is omitted.

[tisdall]

Actually my first paragraph was saying this (effectively merge "manual" and "off"):

form.focus_form	field.manual_focus	action
'auto' or omitted	n/a	focus the first input of the first form
'manual'	'on'	focus on the first input of this form with 'manual_focus' set
'manual'	omitted	no focus

and my "alternative" was this:

form.focus_form	field.manual_focus	action
'on' or omitted	omitted	focus the first input of the first form
'on'	'on'	focus on the first input of this form with 'manual_focus' set
'off'	n/a	no focus

I think my later suggestion is most clear. So, "on" means there's always an autofocus of some sort, and "off" means never auto focus.

[alephex]

I think my later suggestion is most clear. So, "on" means there's always an autofocus of some sort, and "off" means never auto focus.

That makes a lot more sense. I'll throw that together in this PR in a few minutes.

[alephex]

Current Process

form.focus_form	field.manual_focus	action
'on' or omitted	omitted	focus the first input of the first form
'on' or omitted	'on'	focus on the input with manual_focus='on'
'off'	n/a	no focusing

Current Examples

Default (form.focus_form ='on' or omitted; field.manual_focus omitted)

class SchemaInputDefault(colander.Schema):
    name = 'Default Input Focus'
    input = colander.SchemaNode(
    colander.String(),
    title = 'Input (receives focus)',
    missing = '')

class TestForm():
    def __init__(self, request):
        schema = SchemaInputDefault(validator=self.validate).bind(request=request)
        self.form = deform.Form(schema, buttons=(button,))

Manual (form.focus_form='on', field.manual_focus='on')

class SchemaInputManual(colander.Schema):
    name = 'Manual Input Focus'

    input1 = colander.SchemaNode(
                    colander.String(),
                    title = 'Input 1',
                    missing = '')

    input2 = colander.SchemaNode(
                    colander.String(),
                    title = 'Input 2 (Will be focused)',
                    missing = '',
                    manual_focus = 'on')

    input3 = colander.SchemaNode(
                    colander.String(),
                    title = 'Input 3',
                    missing = '')

class TestForm():
    def __init__(self, request):
        schema = SchemaInputManual(validator=self.validate).bind(request=request)
        self.form = deform.Form(schema, buttons=(button,), focus_form='on')

Off (form.focus_form='off')

class SchemaInputOff(colander.Schema):
    name = 'No Input Focus'
    input = colander.SchemaNode(
                 colander.String(),
                 title = 'Input',
                 missing = '')

class TestForm():
    def __init__(self, request):
        schema = SchemaInputOff(validator=self.validate).bind(request=request)
        self.form = deform.Form(schema, buttons=(button,), focus_form='off')

[tisdall]

manual is no longer a valid value

[tisdall]

Maybe this is just preference on my part, but I kind of prefer the name "focus" for the argument on the Form constructor. At the very least the "form" part of "focus_form" is kind of redundant.

Also, on the individual widgets maybe it should be "autofocus" instead of "manual_focus" to better match the HTML attribute name (whether it's being used or not, it accomplishes the same function).

What's your opinion?

[alephex]

I'm agreeable to the constructor name changes. They're more succinct and don't lose any information.

The HTML attributes should still be data-something though for the sake of producing valid HTML.

How does this sound?
form.focus and field.autofocus
<form data-deform-focus ... and <input data-deform-autofocus ...

[tisdall]

Yeah, that looks good.

[tisdall]

Have you thought at all about using something like this: https://gist.github.com/terkel/1236495

It's basically a polyfill to allow HTML5 autofocus to work properly in older browsers.

[alephex]

Not a bad idea. We could scrap automatic focusing entirely and just let the user add field.autofocus to whatever input they like and use that polyfill in deform.js to support older browsers. The downside is, if the user omits field.autofocus from all inputs, no focusing is done. This changes default behaviour.

If I was the only one using deform, I would be ok with it. The whole reason I forked deform was to find out why my pages were scrolling all over the place and stop it. But there may be many people for whom the current default focusing behaviour is desired in their UX. It's probably better to leave the default as is.

[tisdall]

hmm.. I was thinking of just doing what you're currently doing, but use autofocus instead of data-__ and utilize the polyfill. We'd still need to ensure only one field had the autofocus on it, and we'd also have to maintain backwards-compatibility by putting a autofocus on the first field by default.

[alephex]

That's not a bad idea. Moving all the deform.js:focusFirstInput() logic to field.py would leave everything nice and neat. (in terms of js anyway). The only HTML attribute set would be <input autofocus="autofocus" ....

One downside is deform does not (and cannot) know how many forms will be rendered on a page. This could result in more than one input having the autofocus attribute set. Default behaviour for a page with two forms would have autofocus set on (form 1, input 1) and (form 2, input 1). That doesn't meet the HTML5 spec but browsers will degrade gracefully and focus only the first input.

It's fairly trivial to implement this kind autofocus setup. However, we'll first need to decide if default behaviour in a fairly common use case (multiple forms) which technically fails to meet HTML5 specifications is acceptable. We could just document the behaviour and leave it up to the user.

Options:

1. Use data-* attributes and js
   • + Produces valid HTML
   • - Cluttered
   • - More js to run on document.ready
2. Add an autofocus attribute on rendering with no js (except for the polyfill) and leave the decisions to the user
   • + Much cleaner
   • + Uses autofocus attr. for its intended purpose
   • - Does not meet HTML5 spec in certain cases by default

Thoughts?

[tisdall]

I think you've outlined it pretty clearly... unfortunately this is where someone with the ability to commit the changes needs to pipe in.

For me, I'd prefer the autofocus option with some documentation to warn people about avoiding having more than one autofocus on a page.

[tisdall]

Right now you have 3 PR's open for this same issue. If this one is the preferred one, can you close the other 2?

[alephex]

Fair enough. I'll leave this PR as it is and close the "default to no autofocus" and "selectable autofocus" PRs. This one performs form focusing with javascript. I have another branch that can be merged with this one which takes the alternate approach (focusing via autofocus HTML attributes).

We can go either way, but someone with write access will have to make a decision at some point on which direction to take.

[alephex]

While I think of it, I may as well merge that branch now. We can always roll back later.

I have not included the js autofocus polyfill yet. While looking up which browsers support autofocus attributes, I found that that Safari on iOS does not support it because Apple decided autofocusing inputs on mobile was undesired (triggering keyboards etc).

[rbu]

Thanks for the work on this. Hoping this gets merged.

[piotr-dobrogost]

Any reason this hasn't been merged, yet?

[stevepiercy]

For starters, @piotr-dobrogost @alephex this branch has conflicts with master that must be resolved before merging.

You could try contacting the package maintainer.

[alephex]

this branch has conflicts with master that must be resolved before merging.

This PR has been sitting here for almost a year. There were no conflicts then but master has had a few changes in the mean time. I've moved away from using deform myself, but if a maintainer or someone with write access wants to merge this PR, I'll try to resolve them. But until I hear from a maintainer that they want to merge, I won't waste time on it.

[miohtama]

Thank you for your pull request.

I am the new Deform project maintainer. I apologize the issue of this pull request not being commented earlier. Deform project is again under activate maintenance.

This is issue tracker / pull request clean to prepare a new release.

I am willing to merge this pull request. However looks like the original author is no longer championing this change. Just to clean up the issue tracker I am closing this pull request. If there is motivation to push this change through I'll reopen the pull request.

[piotr-dobrogost]

@alephex

But until I hear from a maintainer that they want to merge, I won't waste time on it.

In case you missed it, now you can be sure your time won't be wasted as the new maintainer miohtama wrote I am willing to merge this pull request. above.

[stevepiercy]

@ericof @miohtama it appears that @alephex has abandoned this PR and @castaf abandoned theirs in #337. To get this code merged, what needs to be done? Does someone else just fork the branch alephex:form_focus and pick up from there? It seems there's no follow-through by the people submitting the PRs.

We just had a request in IRC for this again. Please let us know. Thank you!

[ericof]

@stevepiercy I will tackle that on the next few days.

[stevepiercy]

@ericof there's a person in IRC who also expressed interest in doing the work, but we are not sure of the process or licensing issues, if any. Can you elaborate?

1. For the process, should the branch in the PR be forked, updated, and submitted in a new PR?
2. For licensing, is it OK to take someone else's work from the PR submitted here who did not sign CONTRIBUTORS.txt?

There's no rush. It would be good to bring in new contributors. Thank you!

[tisdall]

@stevepiercy - there's a signature in CONTRIBUTORS.txt in this PR. I think it's okay to use this PR and then just adjust it as needed.

[stevepiercy]

@tisdall so there is. Yes, we're OK to use this work.

If they had not, someone else could reimplement the work and that could be a legal grey area between the two contributors, but from our perspective it's a non-issue.

[mamalos]

Hi guys, I've tried to make the least-necessary changes for @alephex's PR to be merged with master in PR #365. Hope it works this time.