Compare Revisions

How to build custom form widgets

Revision 337657:

Revision 337657 by BYK on

Revision 337659:

Revision 337659 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 337657
Revision 337659
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 looks obvious but the fact is, because it's>k, the right behavior seems obvious but the fact is, because it's
> not said, you could forget to code this behavior. This is especi> not defined in our specs, it is very easy to overlook this behav
>ally true if it's a team work when the people who define the beha>ior. This is especially true in a team environment when the peopl
>viors are different from the ones who code them. Another example >e who define the behaviors are different from the ones who code t
>for the fun: what will happen if the user hit the down and up key>hem. Another example for the fun: what will happen if the user hi
> while the widget is in its open state? Yeah, it is a little bit >t the down and up key while the widget is in its open state? Yeah
>trickier. On the one hand, if you consider that the active state >, it is a little bit trickier. On the one hand, if you consider t
>and the open state are completely different, the answer is "nothi>hat the active state and the open state are completely different,
>ng will happen" because we did not defined any keyboard interacti> the answer is "nothing will happen" because we did not defined a
>on when the widget is in its open state. On the other hand, if yo>ny keyboard interaction when the widget is in its open state. On 
>u consider that the active state and the open state are overlappi>the other hand, if you consider that the active state and the ope
>ng, the value will change but the option will not be highlighted >n state are overlapping, the value will change but the option wil
>accordingly, once again because we forget to define any keyboard >l not be highlighted accordingly, once again because we forget to
>action over the option when the widget is in its open state (we h> define any keyboard action over the option when the widget is in
>ave just define what's happen at the moment the widget is open, b> its open state (we have just define what's happen at the moment 
>ut nothing after that).>the widget is open, but nothing after that).

Back to History