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
[whatwg] More on postMessage
In my previous email regarding HTML5's postMessage (section 6.4, cross-domain communication), I suggested changing the API to |yourWindow.postMessage(message, otherWindow)|. I have a few more questions/suggestions after playing around with an implementation of this in Mozilla (bug postMessage for anyone who cares); I somewhat hope to get this in 1.9. First, I think placing |otherWindow| as the first argument and |message| as the second is more aesthetically pleasing than the other way around, tweaking the suggestion I made last time. I don't have a strong reason for this beyond its being analogous to the traditional security model in the literature (which seems good enough to me in the absence of strong reasons going the other way): yourWindow . postMessage ( otherWindow , message ) ; actor doesverbto object Second, in the interests of explicitness, we should be clear about the exact values of event.domain and event.uri. Two concerns: how does setting document.domain interact with the computed value for event.domain, and what are the contents of event.domain in the presence of default and non-default ports? I think the answers to these two concerns must be as follows. Setting document.domain must have no effect on the value of event.domain, in the interests of web hosts who host content on subdomains of their main domain, e.g. myhomepage.webhost.com and webhost.com (else it would allow spoofing in pages which listened for cross-domain messages but didn't check the uri). The contents of event.domain must include the port number iff it is not the default port number for the protocol (80 for http, 443 for https) and must omit it otherwise. Third, with the modified API, the following is possible: // kidFrame is same-origin wrt window window.frames.kidFrame.postMessage(otherWindow, message); With the current design, this would basically allow a window to send an event which looks as though it has been created by another (same-origin, or joined-principals via document.domain) window, with a different event.uri. Since the two windows are same-session this probably isn't a real concern, but I think it's worth mentioning that the change makes it possible to send a message from a window different from the one currently executing the script. Fourth, and probably most importantly, is the event dispatched by postMessage dispatched synchronously (event fired and processed before postMessage returns) or asynchronously? I interpret the current wording to mean synchronously, in accordance with the DOM 3 Events section on reentrance, but I'd like to be clear that's the intended interpretation. Jeff
