Re: [whatwg] [WF3] Web Forms 3.0 Feature List
On Thu, 22 Feb 2007, Matthew Raymond wrote: I'll start: * XForms Tiny's |calculate| attribute * |required| attribute with expression values (formerly XForms Tiny's |needed| attribute) * |valid| (formerly XForms Tiny's |constraint| attribute) * |disabled| attribute with expression values (formerly XForms Tiny's |relevant| attribute, without the hidden presentation) These all seem to be possible from script; it's not clear to me what defining a simple expression language gains us here. * |placeholder| attribute * input type=color (color picker) Will reply to these in separate threads. * input type=move (drag control for moving items in a repetition block) Dropped the repetition block structure altogether, so this is not longer really relevant. * altinput Responded to this recently. Basically I think that we shouldn't introduce features specifically for the transition period. On Thu, 22 Feb 2007, carmen wrote: don't you see cc1_exp_year as a bit of a problem? i hope webforms3 addresses the name hacking that has become standard in web frameworks to flatten multiple db tables, columns, keys, usernames, records, etc into a single name field. requiring regex is not so cool.. WF2 referenced RFC3106, but nobody seemed interested in this, so I've dropped that in HTML5. On Fri, 23 Feb 2007, Mihai Sucan wrote: I'm not sure if this is appropriate thread to make a wish, but the subject is WF3 feature list. Please don't forget about extending input type=email to allow a list of multiple emails, comma separated. Will cover that separately. On Sun, 25 Feb 2007, Keryx Web wrote: More food for thought can be found at http://friendlybit.com/js/improving-interactivity-with-javascript/ At least three of them seem to not be in WF 2: Drag and drop, Image handling and Sortable Items. Auto validation seems like a usable feature as well, but is perhaps left to JS as server-side validation often is necessary. We've done many of those now. Rich tooltips, and declaratively saying which controls affect each other, aren't possible in HTML5, but I'm not sure what to do about those. Better looking form fields are a CSS issue. I'm not really sure what we can do about autosaving, image handling, and search-based or structured navigation. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
Mihai Sucan wrote: No. I really meant commas, not semicolons. This is because I use commas to separate multiple email addresses in the To: field in Opera M2. I'm quite certain it also works in Outlook, Incredibly (at least last time I looked) it only works when you check a particular checkbox hidden deep in the prefs, which is off by default. Why they don't just make it work, I have no idea. Gratuitious incompatibility? One should also take into consideration the following: Given a list of emails (separated by commas or semicolons), e.g.: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] In Opera I can select this list and copy/paste it into the To field. This just works.™ I find it hard to believe that does *not* work in Thunderbird. It does - but see below. Now ... if the web application is made with a markup as you've provided, one has to manually copy/paste (or write) each email address in a single To: field. This is more than boring. 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. Gerv
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
Le Sun, 25 Feb 2007 11:58:20 +0200, Gervase Markham [EMAIL PROTECTED] a écrit: Mihai Sucan wrote: No. I really meant commas, not semicolons. This is because I use commas to separate multiple email addresses in the To: field in Opera M2. I'm quite certain it also works in Outlook, Incredibly (at least last time I looked) it only works when you check a particular checkbox hidden deep in the prefs, which is off by default. Why they don't just make it work, I have no idea. Gratuitious incompatibility? Yes. Yet, it's long time since I used Outlook. I don't know it very well now. One should also take into consideration the following: Given a list of emails (separated by commas or semicolons), e.g.: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] In Opera I can select this list and copy/paste it into the To field. This just works.™ I find it hard to believe that does *not* work in Thunderbird. It does - but see below. Now ... if the web application is made with a markup as you've provided, one has to manually copy/paste (or write) each email address in a single To: field. This is more than boring. 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. Also, what Thunderbird does is not always desirable: having 50+, 150+ emails takes too much screen space (too many rows). Keeping all of them in a single input is a lot more compact. 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). Point is, what you guys suggested is what I define fancy - it's too much work to do quickly, but I agree, it can be done and it's quite good. However for something simple such functionality needs too much 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. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
More food for thought can be found at http://friendlybit.com/js/improving-interactivity-with-javascript/ At least three of them seem to not be in WF 2: Drag and drop, Image handling and Sortable Items. Auto validation seems like a usable feature as well, but is perhaps left to JS as server-side validation often is necessary. Lars Gunther
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
On Sun, 25 Feb 2007 20:21:44 +0100, Keryx Web [EMAIL PROTECTED] wrote: More food for thought can be found at http://friendlybit.com/js/improving-interactivity-with-javascript/ At least three of them seem to not be in WF 2: Drag and drop, Partially addressed by the draggable= attribute in HTML5. Image handling canvas? and Sortable Items. Not sure how this works... Auto validation seems like a usable feature as well, but is perhaps left to JS as server-side validation often is necessary. Auto validation is already covered... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [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
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
Hello! Thank you for the reply. Le Sat, 24 Feb 2007 04:17:30 +0200, Matthew Raymond [EMAIL PROTECTED] a écrit: Mihai Sucan wrote: I'm not sure if this is appropriate thread to make a wish, but the subject is WF3 feature list. Please don't forget about extending input type=email to allow a list of multiple emails, comma separated. See my request: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-January/008986.html I presume you mean separated by semicolons, as you would do in Microsoft Outlook. No. I really meant commas, not semicolons. This is because I use commas to separate multiple email addresses in the To: field in Opera M2. I'm quite certain it also works in Outlook, and semicolons also work in Opera - it's most likely a matter of taste picking which char to use. I think the following is a better idea: | p repeat=template id=row | label for=emailsTo:/label | input type=email id=emails name=emails_[row] | button type=removeDelete Email/button | /p | pbutton type=add template=rowNew Email/button/p Adding and removing semicolon-separated items in a text box is highly cumbersome. I much prefer something similar to a Thunderbird-style email address entry, where new rows are added for each email. In fact, Thunderbird-like email entry is pretty simple to mark up: | p repeat=template id=row | select id=emailtypes name=emails_[row]_type | option value=toTo:/option | option value=ccCc:/option | option value=bccBcc:/option | /select | input type=email id=emails name=emails_[row]_address | button type=removeDelete Email/button | /p | pbutton type=add template=rowNew Email/button/p Using a single control with semicolon may be cheaper from a markup standpoint, but when was the last time you saw it used for anything but email addresses? It's harder to see a specific address, harder to select and delete it, and if you're using a single-line text box, it's a real pain to reach an email address on one end of the line or the other. Plus, as you just illustrated, it may not be clear to the user what character to use as a separator. Not to mention the fact that the server has to parse addresses out of a single string when the form is submitted. I do agree with you on this. The server has to split the string based on commas and semicolons, needing to take into account many more possibilities than a single input type=email field. Also, keep in mind that the |type| email isn't necessarily just a text box with an email pattern. It may, for instance, offer autocompletion based on your address book. Having all emails in a string with separator characters may limit what features can be offered by user agents. Opera offers autocomplete based on the known contacts list (the address book). This works in input type=email. And... getting to my point: the Email composer has a single To: field, where you can type multiple email addresses, separated by commas, with autocomplete. Thus, Opera has the capability of providing autocomplete for emails even in a single text box. Besides, you can use the |pattern| attribute to accomplish about the same effect anyways, so there's no real benefit to supporting a new |type| value. I agree with your point of view. The provided markup is a lot more safer than what I have done at the time of writing the email, however it's more than sufficient in the context of the web application I've done. One should also take into consideration the following: Given a list of emails (separated by commas or semicolons), e.g.: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] In Opera I can select this list and copy/paste it into the To field. This just works.™ I find it hard to believe that does *not* work in Thunderbird. I'm quite certain this email client also allows multiple email addresses in a single To: field - based on a logical POV (people generally use this, and, if Thunderbird is supposed to be easy to use, such a capability must be available). I never used Thunderbird. Now ... if the web application is made with a markup as you've provided, one has to manually copy/paste (or write) each email address in a single To: field. This is more than boring. Hence, even in your case the need for allowing comma separated (and/or semicolon) email addresses still stands. You did not eliminate the need, you've just made it (a) harder for the user to input multiple email addresses, or (b) you just added multiple To: input fields which still need to be parsed as I said. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
Le Fri, 23 Feb 2007 05:55:02 +0200, Matthew Raymond [EMAIL PROTECTED] a écrit: I'll start: * XForms Tiny's |calculate| attribute * |required| attribute with expression values (formerly XForms Tiny's |needed| attribute) * |valid| (formerly XForms Tiny's |constraint| attribute) * |disabled| attribute with expression values (formerly XForms Tiny's |relevant| attribute, without the hidden presentation) * |placeholder| attribute * input type=color (color picker) * input type=move (drag control for moving items in a repetition block) * altinput Hello! The color picker is my favorite in this list. I'm not sure if this is appropriate thread to make a wish, but the subject is WF3 feature list. Please don't forget about extending input type=email to allow a list of multiple emails, comma separated. See my request: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-January/008986.html Thank you. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
Mihai Sucan wrote: I'm not sure if this is appropriate thread to make a wish, but the subject is WF3 feature list. Please don't forget about extending input type=email to allow a list of multiple emails, comma separated. See my request: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-January/008986.html I presume you mean separated by semicolons, as you would do in Microsoft Outlook. I think the following is a better idea: | p repeat=template id=row | label for=emailsTo:/label | input type=email id=emails name=emails_[row] | button type=removeDelete Email/button | /p | pbutton type=add template=rowNew Email/button/p Adding and removing semicolon-separated items in a text box is highly cumbersome. I much prefer something similar to a Thunderbird-style email address entry, where new rows are added for each email. In fact, Thunderbird-like email entry is pretty simple to mark up: | p repeat=template id=row | select id=emailtypes name=emails_[row]_type | option value=toTo:/option | option value=ccCc:/option | option value=bccBcc:/option | /select | input type=email id=emails name=emails_[row]_address | button type=removeDelete Email/button | /p | pbutton type=add template=rowNew Email/button/p Using a single control with semicolon may be cheaper from a markup standpoint, but when was the last time you saw it used for anything but email addresses? It's harder to see a specific address, harder to select and delete it, and if you're using a single-line text box, it's a real pain to reach an email address on one end of the line or the other. Plus, as you just illustrated, it may not be clear to the user what character to use as a separator. Not to mention the fact that the server has to parse addresses out of a single string when the form is submitted. Also, keep in mind that the |type| email isn't necessarily just a text box with an email pattern. It may, for instance, offer autocompletion based on your address book. Having all emails in a string with separator characters may limit what features can be offered by user agents. Besides, you can use the |pattern| attribute to accomplish about the same effect anyways, so there's no real benefit to supporting a new |type| value.
[whatwg] [WF3] Web Forms 3.0 Feature List
I'll start: * XForms Tiny's |calculate| attribute * |required| attribute with expression values (formerly XForms Tiny's |needed| attribute) * |valid| (formerly XForms Tiny's |constraint| attribute) * |disabled| attribute with expression values (formerly XForms Tiny's |relevant| attribute, without the hidden presentation) * |placeholder| attribute * input type=color (color picker) * input type=move (drag control for moving items in a repetition block) * altinput Also, new example for altinput: | altinput for=cc1 type=creditcard required=required | fieldset | legendlabel for=cc1Credit Card/label/legend | input type=hidden id=cc1 name=cc1 | plabel | Card Type: | select name=cc1_type | optionVisa/option | optionMastercard/option | optionDiscover/option | /select | /label/p | p | Card Number: | input type=number name=cc1_1 - | input type=number name=cc1_2 - | input type=number name=cc1_3 - | input type=number name=cc1_4 | /p | p | Expiration: | select name=cc1_exp_month[...]/select / | select name=cc1_exp_year[...]/select | /p | /fieldset | /altinput I made a slight change in the definition of altinput. If the |type| replacement is successful, only the input should be visible, but I'm changing that to the input _and_ it's associated label.
Re: [whatwg] [WF3] Web Forms 3.0 Feature List
| input type=number name=cc1_4 | select name=cc1_exp_month[...]/select / | select name=cc1_exp_year[...]/select don't you see cc1_exp_year as a bit of a problem? i hope webforms3 addresses the name hacking that has become standard in web frameworks to flatten multiple db tables, columns, keys, usernames, records, etc into a single name field. requiring regex is not so cool..
