Re: [whatwg] 'datetime-local' and 'datetime' comments
On 20/11/12 08:37, Nicolas Froidure wrote: On 20/11/2012 07:17, Ian Hickson wrote: a date/time picker that works just like the one without a timezone, except that it then converts the time you give into UTC. That's exactly the behavior i would like to have. From the server side it seems nice. The bad is that Javascript Date objects are initialized with local time and prints local time (toString https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toString). Web developers could expect the same behavior for date inputs and date objects. Aren't you looking for this: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toUTCString -- Mounir
Re: [whatwg] 'datetime-local' and 'datetime' comments
On 20/11/12 06:17, Ian Hickson wrote: FWIW, the UI I'd expect for today's datetime, maybe renamed to datetime-global, would be a date/time picker that works just like the one without a timezone, except that it then converts the time you give into UTC. So far example, I'm in the PST time zone, so if I said November 19th, 5pm, it would send that as November 20th, 1am UTC. Then, maybe a better naming could be datetime-utc? The idea is to be able to get a precise time from the user without having to worry about what time zone the user's in, and without the user having to worry about what time zone other users are in. This would be very useful for scheduling global events, e.g. when a hangout is to happen, or when a game is to start, etc. I really don't think this is a rare thing. In fact I think mostly it's the one to encourage people to use, which is why it's called datetime currently, with the one without timezones, which I think will overall be rarer, having the longer name. I feel like the main issue is that we disagree in which type is the most used. I guess it highly depends on who you ask. I tend to book way more often trains or flights than I arrange meetings. I agree that existing UIs are unfortunate, but they should be fixed. It would be unfortunate to push people towards the timezone-less control just because we screwed up the UI and then renamed the type in shame. What do you think would be a good UI? Does something that would allow selecting a date/time in the current user's TZ and then have the information sent to the server in UTC would be a good UI? But then, there would be no real difference between the datetime and the datetime-foo widget, right? If the main difference between datetime and datetime-foo is the format of the value we send to the server, can't we simply always send the timezone information? So, servers who care about the user's timezone could do the conversion, and others could simply ignore the information. Cheers, -- Mounir
Re: [whatwg] Forms-related feedback
On 20/11/12 22:51, Ian Hickson wrote: On Tue, 20 Nov 2012, Mounir Lamouri wrote: Currently stepUp(n) and stepDown(n) are very basic methods. They more or less do value += n * allowedValueStep; with n = -n; if stepDown() was called. In addition of being pretty dumb, there are a lot of reasons why they can throw. At Mozilla, we think that the main use case for stepUp() and stepDown() is to create a UI with spin buttons: clicking on the up arrow would call stepUp() and clicking on the down arrow would call stepDown(). Such a use case needs methods that do better than just adding n * allowedValueStep. In addition, we think that throwing is very often a bad idea and that should happen when the developer clearly did something wrong. So, we would like to change the stepUp()/stepDown() algorithm to match the following behaviour: - we only throw if the input type doesn't allow those methods or if there is no allowed value step; - if the value isn't a number (aka empty string), we should just exit the steps; - if the value is below the minimal allowed value and n is negative, we should exit the steps; - if the value is above the maximal allowed value and n is positive, we should exit the steps; - if the element is suffering from a step mismatch, and n is negative, the value should be changed to the next valid value. Otherwise, it should be changed to the previous allowed value; - newValue = value + n * allodValueStep; - if the newValue is below the minimal allowed value, the newValue should be equal the minimal allowed value; - if the newValue is higher than the minimal allowed value, the newValue should be equal the minimal allowed value. Such a behaviour creates a real added value in stepUp() and stepDown() that make those methods useful compared to simply do value += n * allowedValueStep; and prevent throwing when there is no need to. Done, though I described it in a different way. (I hope it's equivalent.) I think there are two behaviour that you seem to have described differently: - in step 12, if you take the example page [1], setting the value to 21 and calling stepDown() should change the value to 20 and setting it to 19 and calling stepUp() should change it to 20. This how it is implemented in Opera and Firefox and this how the Chrome's UI behaves. As far as I understand the spec you wrote, those two examples would give respectively 10 and 30. - I believe that when the value is set to below min and n 0, we should not change the value. Same thing for value below max and n 0. This is the behaviour all UA currently have with stepUp() and stepDown() (though, the previous spec was requiring that) and this is Chrome's UI behaviour. I think that behaviour makes more sense UX-wise because going down or up and having the value going the opposite way is just weird and unexpected. [1] The only difference between Chrome's spin buttons behaviour and our proposal is that when value is the empty string, it is setting value to 0 and continue to the next steps (unless the 0 is below the minimal allowed value and n 0, in that case value=min). It might be interesting to specify something better than do nothing if value=. I'm open to doing that too; what would you preference be? Maybe if value isn't valid, we could have it changed to the step base or |min + (max - min)/2| and exit the steps if stepDown() or stepUp() is called. (I think even if stepDown(hugeNumber) is called, we should still just set the value and do nothing else.) I would tend to prefer step base mostly because it would know set it to the default value if there is a default value. However, I think step base is quite a bad solution for some types. Maybe we could use the default value if there is such a concept for the type or the step base otherwise? [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918 Thank you for the prompt change, Ian. -- Mounir
Re: [whatwg] Make stepUp() and stepDown() more developer-friendly
On 20/11/12 22:55, Ian Hickson wrote: On Tue, 20 Nov 2012, Scott González wrote: Can you explain why these methods should be no-ops if the value is above the max or below the min? In jQuery UI, we decided that using these methods should always result in a valid value. I actually missed that in Mounir's suggestion, and the spec now rounds to the nearest allowed value in that case, rather than doing nothing. Mounir: is that ok? As said in my reply to Forms-related feedback thread, I think it is weird to have stepDown() going up or stepUp() going down. Users should understand that they can't go down if the down arrow isn't doing nothing. FWIW, this is the behaviour Opera and Chrome UI's have. This is also the behaviour stepUp() and stepDown() have in Gecko and Presto. I can list out the steps we take for all conditions, but I'd like to hear everyone's thoughts on the various cases where you're suggesting that the methods do nothing. Mostly I agree with Mounir here, but I'm curious about what you think should happen for the case where there's no value, and the case where the control isn't a numeric/date/time type. I could see an argument for stepping from the default in the former case (Mounir, what do you think about doing that?) but for the latter case I don't really see any point doing anything but throw an exception, as Mounir suggested. I also replied about the no value case in Forms-related feedback thread. I believe it might be better to set the value to something. I'm not sure which value should be used for that. Cheers, -- Mounir
[whatwg] Provide data chunk with the ProgressEvent
I'm currently working on a way to update UI before the all XHR datas to
be loaded (sample
http://server.elitwork.com/experiments/pagestream/index.html)
For that need i used the progress listener
http://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html#progressevent but
it's particularly unadapted to it's use.
Indeed, the only way to access to the data chunk loaded is to keep a
reference to the previous value of xhr.responseText.
I think it could be more usefull if the progress event was providing a
chunk property containing only the new datas loaded. So we could do that :
var myXhr=new XMLHttpRequest();
var mylist=document.getElementById('mylist');
myXhr.open(GET, entries.dat, true);
myXhr.onprogress=function(event)
{
var item=document.createElement('li');
item.innerHTML=event.chunk;
myList.appendChild(item);
}
myXhr.send(null);
Instead of :
var myXhr=new XMLHttpRequest();
var mylist=document.getElementById('mylist');
myXhr.open(GET, entries.dat, true);
var previousContentLength=0;
myXhr.onprogress=function()
{
var item=document.createElement('li');
item.innerHTML=myXhr.responseText.substr(previousContentLength);
previousContentLength=myXhr.responseText.length;
myList.appendChild(item);
}
myXhr.send(null);
Regards, Nicolas Froidure.
Re: [whatwg] URL: percent-encoded host
On Tue, Nov 20, 2012 at 3:38 AM, Boris Zbarsky bzbar...@mit.edu wrote: So I don't think we should require this behavior. Thanks, I went with requiring decoding per UTF-8 for now causing sequences such as %80 to turn into U+FFFD. I think that simplification over just decoding valid utf-8 sequences is justified because once you run the Punycode algorithm the original byte sequence meaning is lost anyway. -- http://annevankesteren.nl/
Re: [whatwg] Provide data chunk with the ProgressEvent
On Wed, Nov 21, 2012 at 5:07 PM, Nicolas Froidure froidure_nico...@yahoo.fr wrote: I think it could be more usefull if the progress event was providing a chunk property containing only the new datas loaded. The plan for this is that you set responseType to stream and use the Stream object returned by response for incremental updates. See http://xhr.spec.whatwg.org/ for details. -- http://annevankesteren.nl/
Re: [whatwg] Provide data chunk with the ProgressEvent
On 11/21/12 11:07 AM, Nicolas Froidure wrote: Indeed, the only way to access to the data chunk loaded is to keep a reference to the previous value of xhr.responseText. Nicolas, see http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html (implemented in Gecko as the moz-chunked-text and moz-chunked-arraybuffer response types so people can experiment with it). Would that address your use case? -Boris
Re: [whatwg] Provide data chunk with the ProgressEvent
On Wed, Nov 21, 2012 at 5:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: Nicolas, see http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html (implemented in Gecko as the moz-chunked-text and moz-chunked-arraybuffer response types so people can experiment with it). Would that address your use case? See http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0858.html for why we didn't go with that. -- http://annevankesteren.nl/
Re: [whatwg] Improving autocomplete
On 11/11/12 13:26, Charles McCathie Nevile wrote:
On Sun, 11 Nov 2012 07:50:48 +0100, Maciej Stachowiak m...@apple.com
wrote:
(1) If this API fills in a form completely based on stored data, and
not by completing the user's typing, then it is autofill rather than
autocomplete.
Yep.
(2) If this API provides the ability to get user information without
even having a visible form, then it's not clear that it is even really
autofill. It's just requestUserInformation() or something.
Right. It's like openly shared super-cookies...
(3) This API has important privacy and even security considerations.
Yes.
You have to tell the user exactly what you are going to fill in to the
site before they approve.
And because as soon as you put it into the input field the site can use
it, as a basic security measure it seems like you should never autofill
without explicit user confirmation.
Unfortunately, most won't read it.
Indeed.
If sites are asking for so much info that they have to split pages for
usability, then it seems likely the UI that tells the user what the
site is asking for will be impractical for most users to meaningfully
review.
Yes. This is a problem I face from time to time, and I think its
seriousness is underestimated. This process can be used to collect all
sorts of information before the user realises they didn't want to hand
it over.
This becomes especially dangerous if the mechanism can fill in credit
card info.
That assumes your most valuable info is about your credit card, which is
only the case for a certain proportion of people.
I would be very nervous if the browser could at any moment pop up a
dialog that would submit all my credit card info to a dubious site if
I slip and click the wrong button. Can you expand more on what thought
you have given to the security considerations?
I share the same concerns as Charles and Maciej (see above).
Especially, even if there is an unspoofable UI that is clearly
recognised as part of the browser chrome, any malicious author would be
a click close from getting your credit card number information. If I
understand it correctly, it would be as easy as writing a form with
some input autocomplete=cc-{number,name,...} and then call
requestAutocomplete(). If the user press OK, the page will got those
information, right?
This might be the same security mechanism as geolocation but the outcome
would be so tempting that people might try way harder to get your credit
card information than your location.
In addition, I wonder how valid the use cases of this feature are.
Nowadays, I feel like most websites will, by default or trough opt-in,
save all information so when you come back, you do not have to enter
your address, credit card information and anything else. Seems like
those websites have solved the issue themselves.
I feel like the real use case is when a user wants to make custom with a
web site for the first time. It might be indeed harder to get a good
transformation ration if the user has to write all those information.
However, I doubt we should add such a scary feature for that use case.
Cheers,
--
Mounir
Re: [whatwg] Provide data chunk with the ProgressEvent
There is something like this cooking in the form of
responseType = chunked-text
and
responseType = chunked-arraybuffer
For reference, see [1] and [2]. Would be cool to hear a status update on
specifying these. Anyway, apparently the right forum of discussion for this
is the webapps mailing list.
Cheers,
Jussi
[1]
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html(Jonas'
original suggestion to solve the problem)
[2]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0210.html(my
mail on the same subject as yours)
On Wed, Nov 21, 2012 at 6:07 PM, Nicolas Froidure froidure_nico...@yahoo.fr
wrote:
I'm currently working on a way to update UI before the all XHR datas to be
loaded (sample http://server.elitwork.com/**experiments/pagestream/index.
**html http://server.elitwork.com/experiments/pagestream/index.html)
For that need i used the progress listener http://dvcs.w3.org/hg/**
progress/raw-file/tip/**Overview.html#progresseventhttp://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html#progressevent
but it's particularly unadapted to it's use.
Indeed, the only way to access to the data chunk loaded is to keep a
reference to the previous value of xhr.responseText.
I think it could be more usefull if the progress event was providing a
chunk property containing only the new datas loaded. So we could do that :
var myXhr=new XMLHttpRequest();
var mylist=document.**getElementById('mylist');
myXhr.open(GET, entries.dat, true);
myXhr.onprogress=function(**event)
{
var item=document.createElement('**li');
item.innerHTML=event.chunk;
myList.appendChild(item);
}
myXhr.send(null);
Instead of :
var myXhr=new XMLHttpRequest();
var mylist=document.**getElementById('mylist');
myXhr.open(GET, entries.dat, true);
var previousContentLength=0;
myXhr.onprogress=function()
{
var item=document.createElement('**li');
item.innerHTML=myXhr.**responseText.substr(**
previousContentLength);
previousContentLength=myXhr.**responseText.length;
myList.appendChild(item);
}
myXhr.send(null);
Regards, Nicolas Froidure.
[whatwg] URL: query string
Writing and parsing currently distinguish between URLs that can be written relatively and those that cannot. URLs with a relative scheme http://url.spec.whatwg.org/#relative-scheme have a relative syntax and the others do not. Fragment makes sense to have on both, although for setting hash (not getting) I ended up special casing the scheme javascript because that would make little sense. For query I think I might have made the wrong judgment, it is currently not supported. mailto: I suppose is an obvious candidate where it does make sense to have it separate and not rely on the mailto: specific-processing for that, but for data: and javascript: (again) and also about: it is less clear. Does anyone know whether Internet Explorer supports about:blank?test? Always parsing query in the base URL parser is also closer to STD 66. (Browser support is all over the map. For mailto:test?test; Firefox gives neither pathname/search, Opera/Safari give pathname/search, Chrome only gives pathname, which is test?test. No access to Internet Explorer unfortunately.) -- http://annevankesteren.nl/
Re: [whatwg] URL: IPv6 parsing and model/serializing
On Thu, Nov 15, 2012 at 4:02 PM, Boris Zbarsky bzbar...@mit.edu wrote: Just to be clear, I don't necessarily object to normalizing IPv6 addresses. Especially since I'm no longer actively working on networking code, so it's not like it would be work for _me_. I just mentioned the only concern I had about your proposal, which in general sounds excellent. Thanks, I went with requiring the Chrome behavior for now as that matches the recommendation for IPv6 representation and is also more in line with the normalization that is already present for domain names. -- http://annevankesteren.nl/
Re: [whatwg] Provide data chunk with the ProgressEvent
Perfectly ! Thanks. Registered to webapps list too, sorry for the noise. On 21/11/2012 17:44, Boris Zbarsky wrote: On 11/21/12 11:07 AM, Nicolas Froidure wrote: Indeed, the only way to access to the data chunk loaded is to keep a reference to the previous value of xhr.responseText. Nicolas, see http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html (implemented in Gecko as the moz-chunked-text and moz-chunked-arraybuffer response types so people can experiment with it). Would that address your use case? -Boris
Re: [whatwg] Improving autocomplete
On Wed, Nov 21, 2012 at 9:00 AM, Mounir Lamouri mou...@lamouri.fr wrote: I feel like the real use case is when a user wants to make custom with a web site for the first time. It might be indeed harder to get a good transformation ration if the user has to write all those information. However, I doubt we should add such a scary feature for that use case. On the contrary, as a user I find that case extremely compelling. Maybe I'm too easily frustrated, but it's intensely annoying when I have to fill out all my personal information yet again just because I've gone to some new site to buy something. This is far harder on mobile because typing is just a huge pain there and the screen is small enough that I can only see a few fields at once. Existing UA autofill is nice but pages often defeat it due to the sorts of problems described in the original root post. It's already the case that Chrome can autofill my credit card number into a form that asks for it, so I'm not totally sure why the proposed capabilities here are viewed as new and scary. It seems like we're just trying to expose a slightly nicer event system for letting authors interact with the existing UA feature set. I totally agree that we should think hard about privacy and security issues with form autofilling. It's just that I think we're already in a world where we have to think about those concerns (indeed, have been so for awhile), and the specific proposals here don't really amount to a systematic difference in that respect. PK
Re: [whatwg] URL: query string
(Browser support is all over the map. For mailto:test?test; Firefox gives neither pathname/search, Opera/Safari give pathname/search, Chrome only gives pathname, which is test?test. No access to Internet Explorer unfortunately.) FWIW, according to http://dump.testsuite.org/url/inspect.html, IE10 gives pathname/search as test/?test in both IE10 and IE9 modes. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] URL: query string
On Wed, Nov 21, 2012 at 9:07 PM, James Ross sil...@warwickcompsoc.co.uk wrote: FWIW, according to http://dump.testsuite.org/url/inspect.html, IE10 gives pathname/search as test/?test in both IE10 and IE9 modes. Sweet, is that true for test:test?test, about:blank?test, and data:test?test too? In any case it sounds like this change should be made. -- http://annevankesteren.nl/
Re: [whatwg] URL: query string
On Wed, Nov 21, 2012 at 9:07 PM, James Ross sil...@warwickcompsoc.co.uk wrote: FWIW, according to http://dump.testsuite.org/url/inspect.html, IE10 gives pathname/search as test/?test in both IE10 and IE9 modes. Sweet, is that true for test:test?test, about:blank?test, and data:test?test too? In any case it sounds like this change should be made. Alas not quite; for test:test?test and data:test?test it works, but for about:blank?test it gives pathname=blank?test and search=. The behaviour change appears to be specific to the about: scheme (it happens no matter what I put after). It also doesn't split out the hash, if there is one, when the scheme is about:. -- James Ross sil...@warwickcompsoc.co.uk
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 16 Oct 2012, Ilya Sherman wrote: The payment instrument type is almost certainly appropriate to add -- it is included on almost every website that I've encountered that includes payment card fields. It was an oversight on my part to omit it from the initial proposal. It's redundant data, the credit card number itself says what type it is. More importantly, I don't know how to store the information. What values should we be expecting here? If a site has radio buttons v, m and a, and another has a select with 4, 5, and 3, and yet another has three buttons which set a type=hidden with the values visa, mastercard and amex, how is the user agent to figure out what's going on? This makes the magic needed around dates look positively easy. I agree that it's redundant data, but many websites ask for it separately anyway. One common reason for this is that the website only supports a subset of all possible credit card issuers -- for example, many do not support DiscoverCard. While the site *could* theoretically infer from the entered card number that the card is not supported, and show the user an error, most sites instead force the user to select the card type, and inform the user of unsupported card types by omitting them from the list. Regarding storing of the data: I think being able to fill the data is more important than being able to store it. For example, Chrome stores just the card number, and not the type; but Chrome supports filling the type by inferring it from the stored card number. For filling the card type, I think it's strictly easier than filling a select dropdown containing country names, since localization issues don't come into play as much. The user agent is presumably not going to be able to handle *every* case; but in my experience, it's not too hard to handle many/most of the real-world cases. Since this attribute is used just as a hint, esoteric difficult cases don't seem like enough reason to omit the card type as a known token in the spec. Finally, I have gotten a request to include a field type for bank account numbers, though I have only seen this info actually requested on a small handful of extremely prominent (and generally trusted) websites: Amazon, PayPal, and I think Google Wallet. Is there any reason we shouldn't just treat bank accounts like just another credit card, and use cc-number for these? Yes: Most websites that support credit card numbers as inputs do not support bank account numbers. The few websites that do support bank account numbers use separate fields for these vs. credit card number inputs. Labeling both fields identically would leave the browser unable to distinguish which field to fill with what info. On Wed, 31 Oct 2012, Dan Beam wrote: The experimental implementation [1] has been updated to dispatch an autocompleteerror as per convention/your feedback. autocompleteerror seems like it'd be fired for an error, not user cancelation. User cancelation is usually called either abort or cancel. I think autocompletecancel is fine. It's consistent with oncancel, which we used for dialog. (Fullscreen's error event is for a slightly different case, based on what the spec says.) There are also cases where we'd want to return actual errors. For example, in Chrome, we are only planning to support this dialog for sites served over HTTPS and without security errors. We might also want to fire an error in case the input fails to pass the form's validation requirements. Should we use autocompleteerror for the errors, and autocompletecancel for user cancelations? Firing separate events for cancelations vs. errors forces developers to check for each of these cases separately, which seems like a less convenient API than just checking for one sort of failure event. Perhaps we should have a single event named something like autocompletefail or something like that?
Re: [whatwg] Improving autocomplete
Peter Kasting pkast...@google.com schrieb am Wed, 21 Nov 2012 12:04:56 -0800: […] On the contrary, as a user I find that case extremely compelling. Maybe I'm too easily frustrated, but it's intensely annoying when I have to fill out all my personal information yet again just because I've gone to some new site to buy something. This is far harder on mobile because typing is just a huge pain there and the screen is small enough that I can only see a few fields at once. I have noticed this as well: Several platforms seem to intentionally make it harder to write text – mainly through removal of physical keyboards, taking away pressure feedback and, to a lesser extent modificator keys. The proper solution is to let people vote with their wallet for devices that are perceived as making input easier – not to hand over power to site users making it easier to sniff data. It's already the case that Chrome can autofill my credit card number into a form that asks for it, so I'm not totally sure why the proposed capabilities here are viewed as new and scary. It seems like we're just trying to expose a slightly nicer event system for letting authors interact with the existing UA feature set. Looks like an is-ought-problem to me. The descriptive (“It's already the case …”) can not tell us much about what should be done by virtue of its existence alone. Did you use „new and scary” to imply opponents appeal to tradition? What Chrome can do is started by users; even then a warning is given: http://support.google.com/chrome/bin/answer.py?hl=enanswer=142893 It's important that you use Autofill only on websites you trust, as certain websites might try to capture your information in hidden or hard-to-see fields. Back to your text: I totally agree that we should think hard about privacy and security issues with form autofilling. It's just that I think we're already in a world where we have to think about those concerns (indeed, have been so for awhile), and the specific proposals here don't really amount to a systematic difference in that respect. The systematic difference – for me – is that the proposed functionality may make easier to trick a user into agreeing to „autocomplete everything“ than the current functionality does. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Checkboxes that control other checkboxes
On Sun, 14 Aug 2011, Timo Beermann wrote: It should be able to implemet checkboxes, where by only activating/deactivating this single checkbox you can active/deactivate multiple other checkboxes. That is possible with scripting today, but it should be possible without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. I haven't added this yet, but it is already logged as a possible future extension, so it's possible it may be added in the future. What would be helpful though is examples of sites that do this kind of thing, so that we can study how necessary it is, and how to implement it. For instance, are the dependent fields always in a fieldset? Are they always other checkboxes? Is there more complex logic than just check box A is checked so those controls are enabled? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Improving autocomplete
Nils Dagsson Moskopp n...@dieweltistgarnichtso.net schrieb am Thu, 22 Nov 2012 02:11:38 +0100: […] The proper solution is to let people vote with their wallet for devices that are perceived as making input easier – not to hand over power to site users making it easier to sniff data. s/users/owners/g ☺ -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Improving autocomplete
On Wed, Nov 21, 2012 at 5:11 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: The proper solution is to let people vote with their wallet for devices that are perceived as making input easier – not to hand over power to site users making it easier to sniff data. This contains what I think are multiple false assumptions: (1) It's reasonable to discriminate against devices that don't make input as easy as my desktop computer with its full-size keyboard. Given the rise of mobile web usage, it seems clear that users will increasingly access the web with devices that physically can never be as accommodating as my desktop computer can. I don't think that allows us to simply say oh well and ignore the problem. (2) The proposals make it easier to sniff data. The entire point of my email was that IMO this is simply false. It's already the case that Chrome can autofill my credit card number into a form that asks for it, so I'm not totally sure why the proposed capabilities here are viewed as new and scary. It seems like we're just trying to expose a slightly nicer event system for letting authors interact with the existing UA feature set. Looks like an is-ought-problem to me. The descriptive (“It's already the case …”) can not tell us much about what should be done by virtue of its existence alone. Did you use „new and scary” to imply opponents appeal to tradition? No, I used it to make clear that, at least for some UAs, there is no new user data being exposed in these proposals, nor is existing data being exposed to whole new types of sites. A consideration of whether new APIs represent an additional security or privacy risk must take these factors into account. It is also possible that UAs with existing autofill capabilities (like Chrome) are already insecure today, in which case it'd be very useful to note existing problems so that these UAs can fix them and other vendors can avoid the problems. What Chrome can do is started by users; even then a warning is given: http://support.google.com/chrome/bin/answer.py?hl=enanswer=142893 It's important that you use Autofill only on websites you trust, as certain websites might try to capture your information in hidden or hard-to-see fields. And those same properties -- that these APIs require a user gesture, that the UA is in control of the presentation, and that ultimately it is up to users to use them responsibly -- are all true here as well. The systematic difference – for me – is that the proposed functionality may make easier to trick a user into agreeing to „autocomplete everything“ than the current functionality does. Please explain precisely how you see this occurring, because this is the key part of your argument that I don't grasp, but you've provided no explanation for it. An informative reply might be a detailed scenario complete with an explanation of why the malicious site in question could not accomplish a similar effect with existing UA capabilities. This would be very helpful in informing the design here. PK
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Wed, Nov 21, 2012 at 3:55 PM, Ilya Sherman isher...@chromium.org wrote:
On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 16 Oct 2012, Ilya Sherman wrote:
The payment instrument type is almost certainly appropriate to add -- it
is included on almost every website that I've encountered that includes
payment card fields. It was an oversight on my part to omit it from the
initial proposal.
It's redundant data, the credit card number itself says what type it is.
More importantly, I don't know how to store the information. What values
should we be expecting here? If a site has radio buttons v, m and a,
and another has a select with 4, 5, and 3, and yet another has
three buttons which set a type=hidden with the values visa, mastercard
and amex, how is the user agent to figure out what's going on? This
makes the magic needed around dates look positively easy.
I agree that it's redundant data, but many websites ask for it separately
anyway. One common reason for this is that the website only supports a
subset of all possible credit card issuers -- for example, many do not
support DiscoverCard. While the site *could* theoretically infer from the
entered card number that the card is not supported, and show the user an
error, most sites instead force the user to select the card type, and
inform the user of unsupported card types by omitting them from the list.
Regarding storing of the data: I think being able to fill the data is more
important than being able to store it. For example, Chrome stores just the
card number, and not the type; but Chrome supports filling the type by
inferring it from the stored card number. For filling the card type, I
think it's strictly easier than filling a select dropdown containing
country names, since localization issues don't come into play as much. The
user agent is presumably not going to be able to handle *every* case; but
in my experience, it's not too hard to handle many/most of the real-world
cases. Since this attribute is used just as a hint, esoteric difficult
cases don't seem like enough reason to omit the card type as a known token
in the spec.
Finally, I have gotten a request to include a field type for bank
account numbers, though I have only seen this info actually requested on
a small handful of extremely prominent (and generally trusted) websites:
Amazon, PayPal, and I think Google Wallet.
Is there any reason we shouldn't just treat bank accounts like just
another credit card, and use cc-number for these?
Yes: Most websites that support credit card numbers as inputs do not
support bank account numbers. The few websites that do support bank
account numbers use separate fields for these vs. credit card number
inputs. Labeling both fields identically would leave the browser unable to
distinguish which field to fill with what info.
On Wed, 31 Oct 2012, Dan Beam wrote:
The experimental implementation [1] has been updated to dispatch an
autocompleteerror as per convention/your feedback.
autocompleteerror seems like it'd be fired for an error, not user
cancelation. User cancelation is usually called either abort or
cancel. I think autocompletecancel is fine. It's consistent with
oncancel, which we used for dialog. (Fullscreen's error event is for a
slightly different case, based on what the spec says.)
There are also cases where we'd want to return actual errors. For example,
in Chrome, we are only planning to support this dialog for sites served
over HTTPS and without security errors. We might also want to fire an
error in case the input fails to pass the form's validation requirements.
Should we use autocompleteerror for the errors, and autocompletecancel for
user cancelations? Firing separate events for cancelations vs. errors
forces developers to check for each of these cases separately, which seems
like a less convenient API than just checking for one sort of failure
event. Perhaps we should have a single event named something like
autocompletefail or something like that?
I don't particularly care about the naming (fail vs. error), I just
knew we had a pre-existing *error event and agreed with Anne that I
might as well go with the convention (of 1). I can change it quite
easily to whatever the consensus is.
I definitely agree to a single event. It would be great to do this
and give enumerable failure reasons (if this is deemed secure enough).
An example:
enum ErrorCause {
FROM_FRAME,
NEEDS_GESTURE,
NOT_SECURE,
};
This could be a property on the event (event.cause, event.reason?)
argument passed to the error event (kind of like DOM exceptions).
This seems akin to event.property in CSS transition end events (and
disputably many other examples).
Re: [whatwg] restricted palette for input type=color
On Thu, 3 May 2012, Markus Ernst wrote: Am 03.05.2012 00:50 schrieb Ian Hickson: On Mon, 7 Mar 2011, Markus Ernst wrote: A content management or blog system for a corporate website allows to set font and background colors. The designers define allowed color sets the way that the corporate design guidelines are respected, and that the text is always readable - e.g. three light color shades for backgrounds, and two corporate colors and black for text. You don't really need a colour picker for that... it's more aselect than a colour picker. Or a series of radio buttons. If the presentation is more the concern, then we should probably rely on Web Components to solve the problem (styling aselect with a new presentation, e.g.). It is actually an input field that requires a valid color to be entered; whether it is presented as a color picker or a select box may be up to the UA. I don't see any consistency in having to use different HTML elements whether the selection of colors is defined by the UA (e.g. showing a picker with all colors of the web palette) or by the author. The difference is the same as the difference between: What kind of credit card do you have? input type=text name=cc ...and: What kind of credit card do you have? select name=cc.../select Anyway, 4.10.7.1.15 of the spec states in the bookkeeping details that the @list content and IDL attributes apply to input type=color - if I understand this correctly, it addresses my proposal. That provides a list of suggestions but doesn't restrict the input to only those values. - The fact that most CMS do not have restricted color sets so far, does not mean there is no demand for it, but rather shows the difficulty of customizing tools such as TinyMCE. It is a hassle for CMS implementors (who are often not highly skilled JS programmers), if they are expected to respect corporate design guidelines. I don't follow. Right now (before type=color is widely implemented) it's easier to provide a limited set of colours than all colours. Surely then we should see more CMSes have restricted colour sets if it's a matter of difficulty. The CMS I know are shipped with TinyMCE or KHTML or whatever rich text editors. They usually provide a color picker with a predefined set of colors (iirc it is mostly the web palette) by default, which is non-trivial to override or customize; IMHO this is the reason why customized color pickers are not widely used. There are definitely use cases for them. Ah, fair enough. Anyway, I don't disagree that there's a use case. It's already handled, using select. The thing that isn't handled is making it look more like a colour picker, and that's to be handled by Web Components. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 'datetime-local' and 'datetime' comments
On Wed, 21 Nov 2012, Mounir Lamouri wrote: On 20/11/12 06:17, Ian Hickson wrote: FWIW, the UI I'd expect for today's datetime, maybe renamed to datetime-global, would be a date/time picker that works just like the one without a timezone, except that it then converts the time you give into UTC. So far example, I'm in the PST time zone, so if I said November 19th, 5pm, it would send that as November 20th, 1am UTC. Then, maybe a better naming could be datetime-utc? I think that would mislead authors into thinking that the UI that users will see is one that asks for a UTC time. That kind of UI is the worst UI for this kind of feature, so that would be misleading. The idea is to be able to get a precise time from the user without having to worry about what time zone the user's in, and without the user having to worry about what time zone other users are in. This would be very useful for scheduling global events, e.g. when a hangout is to happen, or when a game is to start, etc. I really don't think this is a rare thing. In fact I think mostly it's the one to encourage people to use, which is why it's called datetime currently, with the one without timezones, which I think will overall be rarer, having the longer name. I feel like the main issue is that we disagree in which type is the most used. I guess it highly depends on who you ask. I tend to book way more often trains or flights than I arrange meetings. It's not a question of which is _used_ more, it's a question of which is _authored_ more. As far as I can tell, the use cases for floating times are basically cross-time-zone transport facilities, e.g. plane tickets, while the use cases for absolute times are anything involving coordination amongst multiple people in multiple time zones, e.g. meetings (in person or online), game events, product launches, online live streaming events... You might book more tickets than you organise meetings, but there are far more people doing cross-time-zone multi-person events than there are people selling plane and cross-continental plane tickets, IMHO. I agree that existing UIs are unfortunate, but they should be fixed. It would be unfortunate to push people towards the timezone-less control just because we screwed up the UI and then renamed the type in shame. What do you think would be a good UI? Does something that would allow selecting a date/time in the current user's TZ and then have the information sent to the server in UTC would be a good UI? That would probably be a reasonable first UI. A more mature UI would also let you pick the time for a specific other time zone (e.g. because you know you'll be there), or compare multiple time zones at the same time to pick a time convenient for multiple people, etc. But then, there would be no real difference between the datetime and the datetime-foo widget, right? There doesn't have to be a difference between any of the widgets. They could all just be a text field. I wouldn't recommend getting rid of all the values though. :-) If the main difference between datetime and datetime-foo is the format of the value we send to the server, can't we simply always send the timezone information? So, servers who care about the user's timezone could do the conversion, and others could simply ignore the information. I don't think the controls should be the same. Even if they were, I don't think we should encourage authors to consider the time zone field meaningful. That's just asking for errors. Time zone manipulation can get really complicated. Did you know that Libya just changed time zone this month? And if you start dealing with things like daylight savings time, it can become positively ridiculous, having to track the whims of goverments around the world. IMHO, we really want all the complicated time zone manipulation to happen either on the client (where we only have to worry about a small number of expert implementors), or in display code, where the impact of errors is just render-time, not in the database. Back-end code should really only have to worry about one time zone for everything. Also, it's really weird to have the client send a time and then intentionally ignore the time zone. That just seems wrong. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
