mozilla

Compare Revisions

How to build custom form widgets

Change Revisions

Revision 337659:

Revision 337659 by BYK on

Revision 337661:

Revision 337661 by BYK on

Title:
How to build custom form widgets
How to build custom form widgets
Slug:
HTML/Forms/How_to_build_custom_form_widgets
HTML/Forms/How_to_build_custom_form_widgets
Tags:
"HTML", "Forms"
"HTML", "Forms"
Content:

Revision 337659
Revision 337661
t103      Let's stop here for our example; however, if you are a caret103      Let's stop here for our example; however, if you are a care
>ful reader, you'll notice that some behavior is missing. For exam>ful reader, you'll notice that some behavior is missing. For exam
>ple, what do you think will happen if the user hits the tab key w>ple, what do you think will happen if the user hits the tab key w
>hile the widget is in its open state? The answer is... nothing. O>hile the widget is in its open state? The answer is... nothing. O
>k, the right behavior seems obvious but the fact is, because it's>k, the right behavior seems obvious but the fact is, because it's
> not defined in our specs, it is very easy to overlook this behav> not defined in our specs, it is very easy to overlook this behav
>ior. This is especially true in a team environment when the peopl>ior. This is especially true in a team environment when people wh
>e who define the behaviors are different from the ones who code t>o define the behavior are different from the ones who implement t
>hem. Another example for the fun: what will happen if the user hi>hem. Another example for the fun: what will happen if the user hi
>t the down and up key while the widget is in its open state? Yeah>t the down and up key while the widget is in its open state? Yeah
>, it is a little bit trickier. On the one hand, if you consider t>, it is a little bit trickier. On the one hand, if you consider t
>hat the active state and the open state are completely different,>hat the active state and the open state are completely different,
> the answer is "nothing will happen" because we did not defined a> the answer is "nothing will happen" because we did not defined a
>ny keyboard interaction when the widget is in its open state. On >ny keyboard interaction when the widget is in its open state. On 
>the other hand, if you consider that the active state and the ope>the other hand, if you consider that the active state and the ope
>n state are overlapping, the value will change but the option wil>n state are overlapping, the value will change but the option wil
>l not be highlighted accordingly, once again because we forget to>l not be highlighted accordingly, once again because we forget to
> define any keyboard action over the option when the widget is in> define any keyboard action over the option when the widget is in
> its open state (we have just define what's happen at the moment > its open state (we have just define what's happen at the moment 
>the widget is open, but nothing after that).>the widget is open, but nothing after that).

Back to History