Item10298: Handle foswikiFocus in jquery plugin

Too much hassle to require focus plugin for every random page you want focus on a field.

-- ArthurClemens - 29 Jan 2011

This is no good idea. It opens the door to have an even fatter document.ready over time. If you want the feature, then add the focus module to $Foswiki::cfg{JQueryPlugin}{DefaultPlugins} . That's the prefered way and the reason why things are modularized.

-- MichaelDaum - 30 Jan 2011

Problem is that css class foswikiFocus 'promises' that it will give focus to the input field with that class. As core css 'behaviour' class this "should just work".

By viewing this functionality as a jquery module only, these steps are required:

1. "focus" is one of the default plugins
2. the skin author must add %JQREQUIRE{"focus"}% to the skin

If the wiki administrator has switched off the focus plugin in configure, or the skin author has not loaded "focus", the person who has just added class foswikiFocus will have a hard time understanding why it doesn't work as advertised.

%SYSTEMWEB.AppendixCascadingStyleSheets lists these 4 behaviour classes:

• .foswikiFocus
• #foswikiNumberOfResultsContainer
• .foswikiChangeFormButton.
• input[type="text"].foswikiDefaultText

It is about weighing benefits. What do we gain by having everything strictly modularised?

-- ArthurClemens - 30 Jan 2011

Most important: never load javascript into every page by default just in case there might be use for it in a small subset of all pages.

focus serves as a good example for this rule, as small as this code fragment is.

What does harm is the extra travel through the dom tree. In the case of focus only those pages that (a) have a form and (b) where you want to enforce a input field to be focused benefit from this extra bit of code. These are very very few pages. In some cases this could even be of harm when two input fields in a page get the .jqForus or .foswikiFocus class but only one of them can actually finally be focused.

Designing user interaction on forms will always need a tight control, i.e. when handling errors. So a default behavior frankly doesn't cut it anyway.

For those people that by all means want to implement this behavior on every page we have the option to load the focus module into $Foswiki::cfg{JQueryPlugin}{DefaultPlugins} though I wouldn't recommend it.

-- MichaelDaum - 30 Jan 2011

In that case we need to change the 'promise' with instructions and help so to help users that expect foswikiFocus to work.

Changed summary from "Handle foswikiFocus in foswiki jquery plugin" to "Handle foswikiFocus in jquery plugin".

-- ArthurClemens - 30 Jan 2011

I have:

• added foswikiFocus next to jqFocus to create focus on the input field
• added foswikiFocus to the documentation in JQueryFocus
• added a note to use %JQREQUIRE{"focus"}% to AppendixCascadingStyleSheets ("as of Foswiki 1.2" - so no code changes are made)
• added a "Troubleshooting behaviour classes" section to AppendixCascadingStyleSheets

-- ArthurClemens - 30 Jan 2011

reverting changes to jquery.foswiki: focus related things are handled by the focus module, not the foswiki module

-- MichaelDaum - 17 Feb 2011

I thought I did that, but obviously I forgot.

-- ArthurClemens - 17 Feb 2011

Commenting is disabled while not logged in