RE: One more possible hole in UI?

Another thing that is bad with overloading <textbox> for passwords is that
passwords shouldn't really be able to have more than one row (in the typical
password use-case anyway). HTML 4 textarea wouldn't work as an interim
rendering component for textboxes that are also passwords due to this. So I
agree that a separate <password> element is the best solution. 

-Kelly

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Friday, March 23, 2001 2:12 PM
> To: tvraman@almaden.ibm.com; XForms Mailing List
> Subject: Re: One more possible hole in UI?
> 
> 
> "T. V. Raman" wrote:
> > 
> > the two choices I am presently considering are:
> > 1) Have a <password>...</password>
> > element analogous to textbox
> > 
> > 2) (preference as of last two days)
> > <textbox echo="*">...</textbox>
> > (default value of echo echoes chars as you type --echo ="*"
> > displays '*' echo ="#" displays '#'
> > 
> > Since you say you're implementing this, what would your
> > preference be?
> 
> It's alot easier to map a <xform:password>...</xform:password> to an
> <input type="password"/>.  The other requires a more complicated
> aproach that not all browsers would support (combining javascript and
> CSS).  In fact, if the second approach were adopted--the only way
> to be sure that the characters aren't rendered is to test for the
> "echo" attribute and convert to the <input type="password"/>.
> 
> That last approach (for converting XForms to XHTML) is limited in
> functionality because no matter what is specified in "echo", the
> asterisk will be displayed.  Anything else will require a full
> plugin support for browsers, or worse applet support.
>

Received on Friday, 23 March 2001 16:45:38 UTC