Re: [whatwg] input type=country?
The idea of a control for countries was considered. However, it was rejected because I couldn't get agreement from UAs to implement it. They cited many of the reasons given in this thread, and some more, such as being worried about being sued (like Microsoft was when Windows 95 shipped with a country control in the datetime control panel). So. For the people who want this: if you want this in the spec, you first need to convince the browser vendors to agree to implement something like this. Until there are vendors who want to implement it, adding it to the spec is a waste of time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=country?
Sander Tekelenburg wrote: A good implementation would - know how to handle different spellings/synonyms (like US/USA, UK/England, Holland/The Netherlands/Nederland, etc.) - make proper use of the OS' language/location settings, if available, for its initial setting, but allow the user to override that (because, for example, many run their OS in american english even though their location or nationality may be something else.) A much simpler implementation would simply work like existing form autofill, matching values the values that the user has supplied to other country inputs in the past without needing any explicit setup. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] input type=country?
On Thu, 24 Aug 2006 18:44:26 +0200, Sander Tekelenburg [EMAIL PROTECTED] wrote: I agree with all the arguments against speccing this, but also this smells much more like a browser feature to me. I think a much more realistic approach would be for browser vendors to offer a setting to try to by default select the user's country when they encounter such a list in a page's form. Agreed. A good implementation would - know how to handle different spellings/synonyms (like US/USA, UK/England, Holland/The Netherlands/Nederland, etc.) - make proper use of the OS' language/location settings, if available, for its initial setting, but allow the user to override that (because, for example, many run their OS in american english even though their location or nationality may be something else.) Some people will probably argue that users won't bother to define their settings for this, but IMO that only means that the user apparently doesn't care then. Right. Or is like me and selects too many countries for too many different things to have a sensible default. I imagine the quickest way to get an implementation would be in the form of a Firefox plug-in. Actually, it should be possible as a user javascript, for anyone who can write javascript right. find select where option=$Locale remove selected from option selected in that select. Set option=$locale selected. or something like that. Hi Sander, BTW. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Dynamic content accessibility in HTML today
On Thu, 24 Aug 2006 19:36:53 +0200, James Graham [EMAIL PROTECTED] wrote: Matthew Raymond wrote: So [snip]ping lots of stuff that is kinda interesting but not in a very relevant way. The language of the |role| specification is actually unclear. The intro indicates that |role| can be used to describe the semantic meaning of elements, while Section 3 says the following: It is used by applications and assistive technologies to determine the purpose of UI widgets. OK, I think I hadn't appreciated just how vague the W3C document is. I propose we standardise the following: A role attribute which may appear on (only non-semantic?) elements to indicate that that element is part of a DHTML widget and not marked-up prose. The role attribute would not be namespaced (in HTML5, in XHTML5... well who knows). The role attribute would take certain predefined values (not those on the W3C page which are largely useless, e.g. banner, or otherwise covered in HTML5, e.g. navlist) corresponding to the various types of UI widgets understood by the accessibility toolkits. As far as possible we would stick to whatever Firefox currently implements, but we would simplify the syntax where necessary (e.g. avoid qnames wherever possible). Values outside the predefined list would make the document non-conforming. Does that sound reasonable or have I totally missed the point? About right except there is a mechanism in the W3C work for adding new values, which don't make it non-conforming. Given that people are pretty inventive, I think that is quite valuable. YMMV And it can appear on any element, although there is not much point adding it to things that use well-defined semantics already. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] Dynamic content accessibility in HTML today
Charles McCathieNevile wrote: About right except there is a mechanism in the W3C work for adding new values, which don't make it non-conforming. Given that people are pretty inventive, I think that is quite valuable. YMMV I don't see the point; if someone makes a value up and UAs don't support it then it is worthless, if UAs do support it then it should become part of the next HTML spec. I can't imagine how auto-discovery of new widget types would work (maybe I should read the RDF Taxonomy spec but I can't stomach it), and I can't think of any similar auto-discovery technology that is widely by authors. I guess allowing a predefined list of values and vendor extensions like role=ms-ribbon might be a suitable compromise between innovation and ease of use. And it can appear on any element, although there is not much point adding it to things that use well-defined semantics already. Indeed. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] Dynamic content accessibility in HTML today
On Thu, 24 Aug 2006 20:16:14 +0200, James Graham [EMAIL PROTECTED] wrote: Charles McCathieNevile wrote: About right except there is a mechanism in the W3C work for adding new values, which don't make it non-conforming. Given that people are pretty inventive, I think that is quite valuable. YMMV I don't see the point; if someone makes a value up and UAs don't support it then it is worthless, if UAs do support it then it should become part of the next HTML spec. I can't imagine how auto-discovery of new widget types would work (maybe I should read the RDF Taxonomy spec but I can't stomach it), Yes, if you want to know how this is expected to work I guess you should. The benefit is that it might be 8 months between new specs, and 8 days between new inventions and people suffering because they have no way to use them, and an auto-discovery mechanism that doesn't always rely on writing a new spec would be an improvement on that. and I can't think of any similar auto-discovery technology that is widely by authors. I guess allowing a predefined list of values and vendor extensions like role=ms-ribbon might be a suitable compromise between innovation and ease of use. The RDF solution at least provides for a workable auto-discovery mechanism. Which means that vendors don't just spend their time chasing down other vendors' extensions manually. I'm not sure that the gap between the two is worthwhile. In principle I would rather see things invalid than magic lists. In practice I suspecting I am making water towards the oncoming wind - vendors would do it anyway - which is why I support the RDF thing. (Plus I am one of those people who can write RDF easily, or find a tool to do it for me, but cannot stomach anything that says first just write a script...) Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk [EMAIL PROTECTED] Try Opera 9 now! http://opera.com
Re: [whatwg] input type=country?
At 17:54 +0100 UTC, on 2006-08-24, James Graham wrote: Sander Tekelenburg wrote: A good implementation would [...] A much simpler implementation would simply work like existing form autofill, matching values the values that the user has supplied to other country inputs in the past without needing any explicit setup. Agreed. That would probably work even better/simpler. -- Sander Tekelenburg, http://www.euronet.nl/~tekelenb/
Re: [whatwg] Forms and POST'ing to data: URL's
On Wed, 26 Jul 2006, Charles Iliya Krempeaux wrote:
form method=POST action=### DATA URL HERE ###
input type=text name=given_name /
input type=text name=family_name /
input type=submit value=generate letter /
/form
How would you get the value of given_name and family_name into the
data URL?
You can't, unless you use JavaScript, I think.
What I want is something like...
form method=POST action=data:,To whom it may concern. My give name is
'%%{given_name}' and my family name is '%%{family_name}'. Sincerely,
%%{given_name} %%{family_name}
Interesting. What's the actual use case? I hadn't really envisaged data:
being used for anything but debugging.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms and POST'ing to data: URL's
Hello Ian,One use case, from my point-of-view, was to allow for non-networked form submitsFor example, if you had a computer or device that did NOT have a network connection, and you did not have (and did not want to have or cannot have) a local HTTP server running. Then you could use such a data URL to make things happen.
Also, with the use of data URL's for img's, for object's, and for form's, you could have an entire HTML-based application contained in exactly one file. Which is again useful in situations where you do NOT have network access.
Also, it is useful to have the entire HTML-based application contained in one file when you want to put it into some other XML document. (Like in RSS, Atom, or XMPP/Jabber.)What really motivated me to think about it is that is that I was writing a blog post about how to create HTML e-mail signatures with hCards built into them.
I wanted to include a form to help them do this. The reader would fill in their name, e-mail address, etc, and it would generate HTML code they could use for their HTML e-mail signature.However, I didn't want the form to make a request back to my server. (Because people could be reading this in their feed reader were they have the blog post cached from my feed.) I wanted it to be entirely self contained within the blog post.
So, as you mentioned, one solution is _javascript_. However, _javascript_ has a couple problem. #1: It complex. (Yes... I'm lazy :-) ) #2: Not all blog readers will allow the execution of _javascript_.Also,... another reason against making a call on my server The blogging software I wrote works by having each blog post be a file. Each file is an Atom document. Not an Atom feed though. But an Atom entry. (And yes, it is legal to have an Atom entry as the root element.)
So having everything in one file is easier and simpler for me. (And again, yes, I'm lazy, and like things easy.) Preferably, I'd like to do form's, img's, and object's with data URL's.
See yaOn 8/24/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 26 Jul 2006, Charles Iliya Krempeaux wrote: form method=POST action="" DATA URL HERE ###input type=text name=given_name /
input type=text name=family_name /input type=submit value=generate letter / /form How would you get the value of given_name and family_name into the
data URL?You can't, unless you use _javascript_, I think. What I want is something like... form method=POST action="" whom it may concern.My give name is
'%%{given_name}' and my family name is '%%{family_name}'.Sincerely, %%{given_name} %%{family_name}Interesting. What's the actual use case? I hadn't really envisaged data:being used for anything but debugging.
--Ian Hickson U+1047E)\._.,--,'``.fLhttp://ln.hixie.ch/ U+263A/, _.. \ _\;`._ ,.Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
-- Charles Iliya Krempeaux,
B.Sc.charles @ reptile.ca
supercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/
___Make Television
http://maketelevision.com/
