[whatwg] [WF3] Web Forms 3.0 Feature List

Mihai Sucan wrote:
>> Not if it does the simple, smart thing that Thunderbird does - if you 
>> paste in a comma-separated list of addresses, turn it into a list of 
>> single entries.
> 
> You've now added even more work: parse the list of emails, and add the 
> new inputs for each email address.

You already have the code for adding new inputs, because you fire it 
when you press Enter after entering a single address. As for the rest:

var addresses = textbox.split(/[:,]\s*/);

> Also, what Thunderbird does is not always desirable: having 50+, 150+ 
> emails takes too much screen space (too many rows). 

This is what scrollbars are for. A web page is not a physical device. If 
you think the user will get tired scrolling past the 150 addresses they 
just added, put the address list into a <div style=overflow:scroll> with 
a height of approximately 10x the height of a text box.

> Keeping all of them 
> in a single input is a lot more compact.

And a lot harder to find a particular one and delete it.

> Isn't it easier, after all, to have a single simple <input type=emails> 
> ? Parsed only once when the form is submitted (either server-side, or 
> client-side, it does not really matter).

I don't think it's as easy to use or edit, and it makes it harder for 
the browser to do things like automatic address completion from a dropdown.

> JS+DOM work. The final result is basically allowing not only a single 
> <input type=emails> (as I suggested), but multiple such fields, as many 
> as the user wants - while all the work is done by the web author, not by 
> the UA.

Not all the work. They have <input type="email"> as a building block. 
But yes - webmail implementations are free to come up with their own 
excellent ideas about the best way to handle 150 email addresses in the 
UI. I'd call that a feature, not a bug.

Gerv

Received on Sunday, 25 February 2007 10:26:02 UTC