JQuery UI Mask Demo Ready

[Andrew Powell]

Hello All,

I'm completed the direct port of Josh Bush's maskedinput plugin
(digitalbush.com) to the jq-ui widget framework. I've also added a few
modifications that I made to his original script; most notably
allowing partial input and the ability to apply the mask to non-input
elements.

( As discussed @
http://groups.google.com/group/jquery-ui-dev/browse_thread/thread/cbea8bb21df8b9be/0b052693861b61cb?lnk=gst&q=maskedinput#0b052693861b61cb
)

You can find it at http://jquery-ui.googlecode.com/svn/branches/dev/mask.
The demo for it is located at
http://jquery-ui.googlecode.com/svn/branches/dev/mask/demos/mask/index.html
The source file is located at
http://jquery-ui.googlecode.com/svn/branches/dev/mask/ui/ui.mask.js

I've run this through the ringer on IE 7, Firefox 3.0.7 and the latest
versions of Opera, Safari and Chrome. My VPC is acting up at the
moment, so I havent been able to get testing done on IE6 or IE8. I
would greatly appreciate some more eyes on this. Please also feel free
to add more demos. I'm not sure who to ask or who to go to, but if the
testers could beat this plugin up, it would be greatly appreciated.
I'd love to see this mature to the point that we could include it in
1.8.

Thanks,
Andrew

[Scott González]

Hey Andrew,

I've only looked at this very briefly, but here are my notes:

The demo looks good.  The most important step I see at this point is to fully flesh out the docs on the planning wiki.  This is the first thing that will be looked at when considering a plugin for inclusion in a release.  If the planning wiki isn't fully written, we won't know if there are any outstanding questions or if the plugin is implemented properly.

I've only glanced over the code, but here are some comments:
- try to remove all browser checks
- plugins must work regardless of what options are passed (don't bail out of init - just because a plugin in instantiated without a mask doesn't mean it won't be modified to have one later)
- you must use jQuery.ui.keyCode instead of numeric values
- you should use full variable/function names, don't use abbreviations, e.g., options instead of opts
- there shouldn't be an event that will destroy an instance

[Maggie Wachs]

> - try to remove all browser checks
> - plugins must work regardless of what options are passed (don't bail out of init - just because a plugin in instantiated without a mask doesn't mean it won't be modified to have one later)
> - you must use jQuery.ui.keyCode instead of numeric values
> - you should use full variable/function names, don't use abbreviations, e.g., options instead of opts
> - there shouldn't be an event that will destroy an instance

Scott, should all widgets be coded like this? If so, these points
(and any others like them) should be added to the Developer Guide
(http://docs.jquery.com/UI/Developer_Guide).

-- Maggie

On Mar 23, 8:08 pm, Scott González <scott.gonza...@gmail.com> wrote:
> Hey Andrew,
>
> I've only looked at this very briefly, but here are my notes:
>
> The demo looks good.  The most important step I see at this point is to
> fully flesh out the docs on the planning wiki.  This is the first thing that
> will be looked at when considering a plugin for inclusion in a release.  If
> the planning wiki isn't fully written, we won't know if there are any
> outstanding questions or if the plugin is implemented properly.
>
> I've only glanced over the code, but here are some comments:
> - try to remove all browser checks
> - plugins must work regardless of what options are passed (don't bail out of init - just because a plugin in instantiated without a mask doesn't mean it won't be modified to have one later)
> - you must use jQuery.ui.keyCode instead of numeric values
> - you should use full variable/function names, don't use abbreviations, e.g., options instead of opts
> - there shouldn't be an event that will destroy an instance
>

> On Mon, Mar 23, 2009 at 6:51 PM, Andrew Powell <powe...@gmail.com> wrote:
>
> > Hello All,
>
> > I'm completed the direct port of Josh Bush's maskedinput plugin
> > (digitalbush.com) to the jq-ui widget framework. I've also added a few
> > modifications that I made to his original script; most notably
> > allowing partial input and the ability to apply the mask to non-input
> > elements.
>
> > ( As discussed @
>

> >http://groups.google.com/group/jquery-ui-dev/browse_thread/thread/cbe...
> > )
>
> > You can find it athttp://jquery-ui.googlecode.com/svn/branches/dev/mask.

> > The demo for it is located at

> >http://jquery-ui.googlecode.com/svn/branches/dev/mask/demos/mask/inde...

[Scott González]

On Tue, Mar 24, 2009 at 9:40 AM, Maggie Wachs <fg.m...@gmail.com> wrote:

> - try to remove all browser checks
> - plugins must work regardless of what options are passed (don't bail out of init - just because a plugin in instantiated without a mask doesn't mean it won't be modified to have one later)
> - you must use jQuery.ui.keyCode instead of numeric values
> - you should use full variable/function names, don't use abbreviations, e.g., options instead of opts
> - there shouldn't be an event that will destroy an instance

Scott, should all widgets be coded like this?  If so, these points
(and any others like them) should be added to the Developer Guide
(http://docs.jquery.com/UI/Developer_Guide).

Yes, they'll be part of the coding standards that need to be written.

[Scott Jehl]

This plugin is pretty neat. Nice work, Andrew.

I have a question about it: how will this affect accessibility? Changing the input value on the fly seems like it might be a little jarring on a screenreader. 

Should this plugin actually use several inputs that look like one and keep the original input updated as the user types (perhaps even make it hidden)?

Anyone have any thoughts on this?

Thanks,

Scott

[Maggie Wachs]

Are they accurate enough so that we could start a list in the dev
guide (to be reorganized in the coding standards later)? I'm happy to
add these to the docs if you're focused on other things right now.

Sorry for the tangent, I just want to make sure we're documenting
these things as we go -- the sooner we have stuff written down, the
sooner you and the other UI devs can avoid the inevitable rework. :)

-- Maggie

On Mar 24, 9:51 am, Scott González <scott.gonza...@gmail.com> wrote:

[Richard D. Worth]

On Tue, Mar 24, 2009 at 10:02 AM, Scott Jehl <sc...@scottjehl.com> wrote:

Should this plugin actually use several inputs that look like one and keep the original input updated as the user types (perhaps even make it hidden)?

Anyone have any thoughts on this?

I worry this would prevent using the keyboard and mouse as easily as you can now. For example

keyboard
- put the carat at the second-to-last position
- hold the shift key
- press the left arrow 5 times
- press delete or backspace or start typing

mouse
- place the carat at the second position
- drag a selection of all characters up to but not including the last one
- press delete or backspace or start typing

You might be able to make either or both of these work with more than one input, but I don't think it would be worth the trouble.

- Richard

[Scott González]

I've thrown together a quick page that has these notes on it.  I'll flesh it out over the next week or two.

http://wiki.jqueryui.com/Coding-standards

[Andrew Powell]

@ Scott J, Richard

I've done very little work with accessibility on the web. So please do
share your experience here. If we can do something to make this easier
for people, that would be great. Are we worried about about screen
readers in the input or output sense?

@ Scott G.

How do we resolve issues where only one browser effects functionality?
127 represents backspace only on the iphone. Catching the same keycode
for other browsers would be incorrect in that context.


2009/3/24 Scott González <scott.g...@gmail.com>:

[Scott González]

On Tue, Mar 24, 2009 at 10:29 AM, Andrew Powell <pow...@gmail.com> wrote:

@ Scott J, Richard

I've done very little work with accessibility on the web. So please do
share your experience here. If we can do something to make this easier
for people, that would be great. Are we worried about about screen
readers in the input or output sense?

We're worried about screen readers in every part of using a page that has a masked input.  Specifically the point Scott brought up is when you place focus on an input, the value is being modified to contain the mask.  Screen readers speak the value on focus.  I'll test this out later and let you know the exact behavior that is occurring.

@ Scott G.

How do we resolve issues where only one browser effects functionality?
127 represents backspace only on the iphone. Catching the same keycode
for other browsers would be incorrect in that context.

Every case is slightly different, you can check out jQuery core to see how they're populating the jQuery.support hash for some various tricks.  Figuring out which key code represents backspace does sound challenging though.  We don't explicitly support the iPhone right now, so I'd actually lean toward not supporting it in the mask plugin over performing a browser check.

[Andrew Powell]

@ Scott G

Re: Browser Checks. That's completely reasonable. When I commit the
modifications later today, I'll remove that particular check.

2009/3/24 Scott González <scott.g...@gmail.com>:

[David Muir]

Haven't tried, and might be completely off the mark, but here goes.

Part of what Sizzle does is check feature compatibility rather than a browser check. It also tests the feature to see if it works correctly (to work around browser bugs).
Is it possible to do something like this for a backspace key? Loop through keycodes to find ones that remove characters or something?

David