Re: [whatwg] Web forms 2, input type suggestions
On Sat, 14 Jul 2007, Martin Atkins wrote: Benjamin Joffe wrote: type=address Indicates that the input should represent an address, the user agent may aid by displaying data from a GPS or use an online map etc. I have a little more trouble with this idea, for a number of reasons: * Address formats vary from region to region. * Sites usually want items like the postal code, state, county or town separated from the street address for various reasons. This is not catered for by your proposal. * To do anything special for this field beyond just displaying a big text box some sort of external data source is required, but it is not at all obvious what that data source would be or what a good UI for this field type might be. Yeah, I don't see why type=text isn't enough here. type=location Same as above but instead of sending an address string it would send latitude/longitude information, this (as opposed to the above) would send a well-formed string. Perhaps coordinates/geocoordinates or something else would be a more suitable name for the latter. I have similar reservations about this one, but at least there is a more obvious UI: mobile devices with built in GPS recievers could concievably provide an option to fill in the current coordinates. However, I'm not sure that submitting geographic coordinates is a common enough case to warrant an input type of its own. Part of me wants to generalize it to be type=2dvector and type=3dvector, which can then represent any 2D or 3D coordinates. I'm not really sure what a UA would do to such a field that would be any more useful than two or three type=text elements, though. We used to have type=location, long ago. It was removed due to the problems involved in providing this information. Now that the W3C is working on a Geolocation API, I think we should defer this for now and only if there is still a clear need for this in a few years should we reconsider it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Oct 30, 2008, at 2:19 PM, Tab Atkins Jr. wrote: I have no problem with input type=email. type=address would be very confusing (see what people think about the address element today!), and worse, can legitimately be thought to be for inputting physical addresses. No one will ever think that type=email is for composing an email - it's a single piece of information (composing an email requires several) and it's in the input family which is for small pieces of information (an entire email is much larger than the natural size of an input). In the multiple case, I'm fine with either [type=emails] or [type=email][multiple=multiple]. aolMe too./aol Are there any other situations where adding a multiple attribute could work similarly, other than select? -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
Indeed, INPUT[type=email] is confusing as well. I would add [type=address] and [type=address-list] as candidates because an e-mail address is the most common type of an address on the Web (the e-mail part can be omitted IMHO). Using INPUT[multiple=multiple] seems like a good idea as well. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eduard Pascual Sent: Thursday, October 30, 2008 3:28 AM To: Matthew Paul Thomas Cc: WHAT working group Subject: Re: [whatwg] Web forms 2,input type suggestions (Michael A. Puls II) What about multi-email, email-list or email-addresses? The last one is the one I most like, and the most explicit, with the only (minor) drawback that it's the longest. Anyway, that's just a suggestion. BTW, the same argument could be made on type=email, since someone could easily think it expects an entire message.
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Thu, Oct 30, 2008 at 1:47 PM, Kristof Zelechovski [EMAIL PROTECTED]wrote: Indeed, INPUT[type=email] is confusing as well. I would add [type=address] and [type=address-list] as candidates because an e-mail address is the most common type of an address on the Web (the e-mail part can be omitted IMHO). Using INPUT[multiple=multiple] seems like a good idea as well. Chris I have no problem with input type=email. type=address would be very confusing (see what people think about the address element today!), and worse, can legitimately be thought to be for inputting physical addresses. No one will ever think that type=email is for composing an email - it's a single piece of information (composing an email requires several) and it's in the input family which is for small pieces of information (an entire email is much larger than the natural size of an input). In the multiple case, I'm fine with either [type=emails] or [type=email][multiple=multiple]. ~TJ
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Sun, 15 Jul 2007, Alex Vincent wrote: I've held off on commenting about the new types suggested for input so far, but I should mention this: Web Forms 2 as it currently stands has twenty-four different types of input elements. Ten from HTML 4, fourteen new ones in this spec. Please, please, don't overload it any more than is absolutely necessary. We're down to 20 total, 10 from HTML4 and 10 new ones, 6 of which are date-related, 2 of which are numeric, and 2 of which are text-based. We'll probably add type=color soon, and maybe type=emails or some such some time after that. In general though I agree that we should keep things to a minimum, just as with all parts of the Web platform. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Oct 29, 2008, at 6:40 PM, Kristof Zelechovski wrote: Declare INPUT[type=mailing-list] instead of INPUT[type=emails], please. Type=emails is ugly and confusing (as it seems to expect messages). ... emails is indeed ugly, but mailing-list would be even worse. A mailing list usually has a single address. -- Matthew Paul Thomas http://mpt.net.nz/ ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)---
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Thu, Oct 30, 2008 at 1:16 AM, Matthew Paul Thomas [EMAIL PROTECTED] wrote: On Oct 29, 2008, at 6:40 PM, Kristof Zelechovski wrote: Declare INPUT[type=mailing-list] instead of INPUT[type=emails], please. Type=emails is ugly and confusing (as it seems to expect messages). ... emails is indeed ugly, but mailing-list would be even worse. A mailing list usually has a single address. What about multi-email, email-list or email-addresses? The last one is the one I most like, and the most explicit, with the only (minor) drawback that it's the longest. Anyway, that's just a suggestion. BTW, the same argument could be made on type=email, since someone could easily think it expects an entire message.
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On 10/30/08, Eduard Pascual [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2008 at 1:16 AM, Matthew Paul Thomas [EMAIL PROTECTED] wrote: On Oct 29, 2008, at 6:40 PM, Kristof Zelechovski wrote: Declare INPUT[type=mailing-list] instead of INPUT[type=emails], please. Type=emails is ugly and confusing (as it seems to expect messages). ... emails is indeed ugly, but mailing-list would be even worse. A mailing list usually has a single address. What about multi-email, email-list or email-addresses? The last one is the one I most like, and the most explicit, with the only (minor) drawback that it's the longest. Anyway, that's just a suggestion. BTW, the same argument could be made on type=email, since someone could easily think it expects an entire message. INPUT[type=email][multiple=1] c.f. SELECT[multiple=1]
Re: [whatwg] Web forms 2, input type suggestions
I am not so concerned about the location inputs I suggested but colour is a clear must. The recent introduction of a colour picker into one of the major javaScript libraries (YUI) [0] indicates that there is a demand for this sort of input control. [0] http://developer.yahoo.com/yui/colorpicker/ On 7/16/07, Martin Atkins [EMAIL PROTECTED] wrote: Lachlan Hunt wrote: Martin Atkins wrote: Lachlan Hunt wrote: http://www.haymespaint.com.au/haymes/colourcentre/ http://www.ficml.org/jemimap/style/color/wheel.html http://wellstyled.com/tools/colorscheme2/ These are some rather contrived examples. How can you possibly call them contrived, when they are real world examples of colour selection applications? The first is asking users to select real-world (i.e. paint) colours, while this proposal was for screen colours in RGB format. (At least, that was my understanding based on the reference to six-digit hex encoding.) I think it indicates a limitation with the proposed solution, and a perfect example of why we need to start with *problems* and *use cases* instead of solutions. We need to devise a solution that fits the use cases, not reject use cases that don't fit the solution. Applications for exploring colour spaces already have a satisfactory solution, as in your examples. Since their focus is on colour selection they implement a more elaborate UI that fits their purpose exactly. Likewise, applications such as Google Calendar implement their own UI for exploring the calendar rather than relying on the UI provided by input type=date However, applications whose focus is not on dates or colours but which still need to accept such values as inputs benefit from commodity controls; the specifics of how these controls are implemented matter little as long as they produce results in a suitable format for processing by the application. A web search for DHTML Colour Picker (US or UK spelling) turns up hundreds of distinct implementations of an RGB colour picker widget, which indicates to me that there is a clear need for such a thing. However, I cannot find any general-purpose DHTML colour widgets for selecting paint colours that could be classed as reusable components, so I'm left to assume that this is a very speciality need which needs to be custom-developed in each case. In short, I am not rejecting use cases that don't fit the solution, I'm rejecting use cases that do not fit the scope of the problem as I see it. You may percieve the problem differently, of course.
Re: [whatwg] Web forms 2, input type suggestions
Martin Atkins wrote: Lachlan Hunt wrote: http://www.haymespaint.com.au/haymes/colourcentre/ http://www.ficml.org/jemimap/style/color/wheel.html http://wellstyled.com/tools/colorscheme2/ These are some rather contrived examples. How can you possibly call them contrived, when they are real world examples of colour selection applications? The first is asking users to select real-world (i.e. paint) colours, while this proposal was for screen colours in RGB format. (At least, that was my understanding based on the reference to six-digit hex encoding.) I think it indicates a limitation with the proposed solution, and a perfect example of why we need to start with *problems* and *use cases* instead of solutions. We need to devise a solution that fits the use cases, not reject use cases that don't fit the solution. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Web forms 2, input type suggestions
At 01:31 +1000 UTC, on 2007-07-16, Lachlan Hunt wrote: Benjamin Joffe wrote: Have the following possible values for the TYPE attribute been considered for the INPUT element? The major problem with all of your proposals is that you have not described any problem that they solve, nor provided any use cases for them. I wrote earlier A use case I can imagine is an authoring tool that let's users create CSS rules. Simply clicking the wanted colour avoids the risk of (syntactically) incorrect color values. Other problems it would solve - works more across browsing environments (because lack of javascript, Flash, etc dependancies). - provides the user with a consistent UI across sites - much less work for authors, not having to write javascript/Flash solutions [...] Here's a few sites I found that ask the user to select colours. http://www.haymespaint.com.au/haymes/colourcentre/ http://www.ficml.org/jemimap/style/color/wheel.html http://wellstyled.com/tools/colorscheme2/ I can't figure out how any of those would benefit from the new input type. [...] All of these are Flash and/or javascript dependant, and thus not accessible in every browsing environment. inpute type='color' would not have that problem (and probably fallback gracefully in environments that cannot present a color picker). All provide their own unique, different UI, which is confusing to users. Users would benefit from a UI that works the same across sites. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Web forms 2, input type suggestions
Benjamin Joffe wrote: Have the following possible values for the TYPE attribute been considered for the INPUT element? type=color The user agent would display an appropriate colour picker and would send a hexidecimal string represting that colour to the server. I like this idea. It's simple and it's something I've implemented (and seen implemented) dozens of times. type=address Indicates that the input should represent an address, the user agent may aid by displaying data from a GPS or use an online map etc. I have a little more trouble with this idea, for a number of reasons: * Address formats vary from region to region. * Sites usually want items like the postal code, state, county or town separated from the street address for various reasons. This is not catered for by your proposal. * To do anything special for this field beyond just displaying a big text box some sort of external data source is required, but it is not at all obvious what that data source would be or what a good UI for this field type might be. type=location Same as above but instead of sending an address string it would send latitude/longitude information, this (as opposed to the above) would send a well-formed string. Perhaps coordinates/geocoordinates or something else would be a more suitable name for the latter. I have similar reservations about this one, but at least there is a more obvious UI: mobile devices with built in GPS recievers could concievably provide an option to fill in the current coordinates. However, I'm not sure that submitting geographic coordinates is a common enough case to warrant an input type of its own. Part of me wants to generalize it to be type=2dvector and type=3dvector, which can then represent any 2D or 3D coordinates. I'm not really sure what a UA would do to such a field that would be any more useful than two or three type=text elements, though.
Re: [whatwg] Web forms 2, input type suggestions
Martin Atkins schreef: Benjamin Joffe wrote: Have the following possible values for the TYPE attribute been considered for the INPUT element? type=color The user agent would display an appropriate colour picker and would send a hexidecimal string represting that colour to the server. I like this idea. It's simple and it's something I've implemented (and seen implemented) dozens of times. I like this one too. It should have an pallet attribute that defines the color pallet. I'm not shure how though, cause on one hand I'd like to be able to choose easily from standard pallets, but on the other hand I'd like the option to create custom pallets. Perhaps pallet=custom combined with a datalist could be an option here. type=address Indicates that the input should represent an address, the user agent may aid by displaying data from a GPS or use an online map etc. I have a little more trouble with this idea, for a number of reasons: * Address formats vary from region to region. * Sites usually want items like the postal code, state, county or town separated from the street address for various reasons. This is not catered for by your proposal. * To do anything special for this field beyond just displaying a big text box some sort of external data source is required, but it is not at all obvious what that data source would be or what a good UI for this field type might be. I agree, far too many formats. And I'm not sure whether a map/GPS can really help as there can be a lot of addresses situated on top of each other. cheers, Sander
Re: [whatwg] Web forms 2, input type suggestions
At 21:08 +0200 UTC, on 2007-07-14, Sander wrote: Martin Atkins schreef: Benjamin Joffe wrote: [...] type=color The user agent would display an appropriate colour picker and would send a hexidecimal string represting that colour to the server. I like this idea. It's simple and it's something I've implemented (and seen implemented) dozens of times. I like this one too. Same here. A use case I can imagine is an authoring tool that let's users create CSS rules. Simply clicking the wanted colour avoids the risk of (syntactically) incorrect color values. However, to make it complete it would have to work both ways: if the form defines a color (input type=color value=#66f), that colour should be presented s selected by the UA's color picker. Perhaps that's something to leave entirely up to the UA, but I'd like it better if the at least suggests that they may do. I wonder what the fallback mechanism should be though. What should UAs that do not/can not provide a color picker do? Some testing (iCab, Opera, Firefox, Safari) sugests that UAs that don't support type=color would simply dislplay the value in a text field. If that's true for all legacy UAs, that'd be OK I suppose. It should have an pallet attribute that defines the color pallet. I'm not shure how though Could be useful if you'd need to allow the user to choose only from a limited list of options, yes. If there already is a standard that describes colour palettes, that might be useful. If not, this might be too complicated. -- Sander Tekelenburg The Web Repair Initiative: http://webrepair.org/
Re: [whatwg] Web forms 2, input type suggestions
On 7/13/07, Benjamin Joffe [EMAIL PROTECTED] wrote: Have the following possible values for the TYPE attribute been considered for the INPUT element? type=color The user agent would display an appropriate colour picker and would send a hexidecimal string represting that colour to the server. I think it'd be cool at least. -- Michael
