On Mon, 28 Apr 2014, Evan Stade wrote:
> > On Thu, 24 Apr 2014, Evan Stade wrote:
> > > Ian wrote:
> > > > Why would this only apply to requestAutocomplete()? Surely it 
> > > > would be just as important for the case where the user agent is 
> > > > filling in a form without using that API.
> > >
> > > That is true, but I don't know of a better way to convey this 
> > > information from the page to browser. Additional attributes on the 
> > > cc-number field?
> >
> > Well, if we're going to use type=hidden fields to expose the username, 
> > we could also use it to expose the amount and currency. Would that 
> > work?
> I agree with those upthread who said that overloading autocomplete= to 
> provide information to the user agent is confusing. If we introduce 
> something like autocomplete="transaction-currency" then it's easy to 
> misinterpret that as the site asking the browser what the currency is 
> for the payment method, then having a site author use 
> transaction-currency in a non type=hidden input.

Is that so bad?

What I ended up going with (based on discussion in the relevant bug) is 
the type=hidden proposal, along with making transaction-currency a 
first-class autofill field type.

On Mon, 5 May 2014, Matthew Noorenberghe wrote:
> In Firefox, we save the form values after validation but before the 
> submit event is dispatched to content. This way we successfully save the 
> form fields in form history when a script is handling the actual 
> submission. This also helps against sites who try to manipulate the form 
> fields upon submission to avoid having them saved (see 
> https://bugzilla.mozilla.org/show_bug.cgi?id=257781 ). We've been doing 
> this for a long time and I don't recall any complaints as long as I've 
> been working on password and form manager for Firefox (since 2009).

Assuming that by "form history" you mean the back-forward behaviour, this 
isn't really consistent with the way the spec is written currently. If you 
think we should change the spec, please don't hesitate to file a bug on 
this. (http://whatwg.org/newbug)

> There are many websites that use click handlers on buttons outside forms 
> instead of using form submission and those fields don't get saved in 
> Firefox.

Per spec, for session history purposes they would get saved during 
navigation, IIRC. They wouldn't get saved for autofill though, right.

> I suspect web developers don't realize that they are losing out on form 
> history and other benefits like being able to submit the form with the 
> Enter key from a text input. I don't see sites that are not having their 
> fields saved by not using form submission switching to calling a new API 
> when they can instead use an onsubmit handler which has other benefits. 
> Given that Firefox already saves values with preventDefault inside form 
> submit handlers and click handlers on submit buttons, and the other 
> benefits of sites using form submission, I don't think a new API is 
> needed.

I agree that a new API isn't needed for saving fields for autofill if 
pages can rely on browsers saving the values during submission, but I 
think that the issue of when to store values for autofill and when to 
store values for the session history are independent issues.

> > >    https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238
> It seems like more evangelism is needed to let authors know that 
> preventDefault inside a form submission handler is the better way to 
> handle forms where navigation isn't wanted. The benefits are: form 
> history, password management, better UX (allowing submission via <Enter> 
> when inputs are in a <form>), and possibly better accessibility(?).
> I've been thinking about cases where we could detect the pattern of fake 
> forms (using text <input>s and <button>s with click handlers together 
> without a <form>) and provide notices in developer tools to help 
> evangelize but it's looking to be tricky.

Yeah, I'm not sure how to do that usefully, unfortunately.

On Fri, 16 May 2014, Garrett Casto wrote:
> The problem right now is that there are two legitimate reasons that a 
> site may return false from the submit handler, either because the 
> submission failed validation in some way or because submission is being 
> handled via script. Browsers can either ignore this distinction (e.g. 
> Firefox) or try and separate the two heuristically (e.g. Chrome). Both 
> are reasonable approaches given the current state of the world, but 
> neither are ideal. We should allow sites to make this distinction.
> I agree that we shouldn't necessarily add contortions for sites that 
> don't use form submission, but currently there isn't a right way to do 
> this even if the site wants to.

We could add a new method="" like method="dialog" to handle this. Or we 
could just tell people to use action="javascript:" (which does nothing).

On Tue, 6 May 2014, Evan Stade wrote:
> If a country experiences political turmoil and changes the number of 
> types of administrative divisions it has, I guess it's reasonable to 
> redefine "level4" to the former "level3", and add a new "level5" which 
> is the former "level4".

Maybe. This could cause quite the mess.

I guess we'll handle this in due course on a case-by-case basis. It's hard 
to see how we could predict all the various ways this might change.

In the end (as part of the related bug) I did spec the four level values.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply via email to