Compare Revisions

How to build custom form widgets

Revision 337661:

Revision 337661 by BYK on

Revision 337663:

Revision 337663 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 337661
Revision 337663
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 people wh>ior. This is especially true in a team environment when people wh
>o define the behavior are different from the ones who implement 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 fun example: what will happen if the user hits the u
>t the down and up key while the widget is in its open state? Yeah>p or down arrow keys while the widget is in the open state? Yeah,
>, it is a little bit trickier. On the one hand, if you consider t> it is a little bit trickier. If you consider that the active sta
>hat the active state and the open state are completely different,>te and the open state are completely different, the answer is aga
> the answer is "nothing will happen" because we did not defined a>in "nothing will happen" because we did not define any keyboard i
>ny keyboard interaction when the widget is in its open state. On >nteractions when for the opened state. On the other hand, if you 
>the other hand, if you consider that the active state and the ope>consider that the active state and the open state are a bit overl
>n state are overlapping, the value will change but the option wil>apping, the value may change but the option will definitely not b
>l not be highlighted accordingly, once again because we forget to>e highlighted accordingly, once again because we did not define a
> define any keyboard action over the option when the widget is in>ny keyboard interactions over options when the widget is in its o
> its open state (we have just define what's happen at the moment >pened state (we have only defined what should happen when the wid
>the widget is open, but nothing after that).>get is opened, but nothing after that).

Back to History