Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Thu, 5 Jul 2012, Glenn Maynard wrote: > On Fri, Jun 29, 2012 at 4:24 PM, Ian Hickson wrote: > > On Tue, 21 Feb 2012, Glenn Maynard wrote: > > > > > > I don't think the existence of implicit submit should depend on > > > platform conventions, though, for interop on forms without visible > > > submit buttons. The form implicit submit takes is a platform > > > convention, but it should be required to exist in some form or > > > another. > > > > User agents aren't actually required to let users input anything, so > > it doesn't make much sense to require submission be possible... > > This is only relevant for UAs which don't care if forms are usable, > which is most of them. If forms are expected to work in the first > place, then there needs to be an implicit submit mechanism. Every > browser I'm aware of has one, and lots of pages depend on this, so it > seems like this should be required somewhere (even if it's conditional > upon something like "if user form entry is supported"). I added some text to point implementors in that direction. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, Jun 29, 2012 at 4:24 PM, Ian Hickson wrote: > On Tue, 21 Feb 2012, Glenn Maynard wrote: > > > > I don't think the existence of implicit submit should depend on platform > > conventions, though, for interop on forms without visible submit > > buttons. The form implicit submit takes is a platform convention, but it > > should be required to exist in some form or another. > > User agents aren't actually required to let users input anything, so it > doesn't make much sense to require submission be possible... > This is only relevant for UAs which don't care if forms are usable, which is most of them. If forms are expected to work in the first place, then there needs to be an implicit submit mechanism. Every browser I'm aware of has one, and lots of pages depend on this, so it seems like this should be required somewhere (even if it's conditional upon something like "if user form entry is supported"). -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 6/29/12 7:20 PM, Ian Hickson wrote: The main difference was that Chrome and Firefox differ in what input types they support, which affects which they allow to affect the implicit submission thing. Oh, ok. Yeah, that's a bit of a mess... ;) Oh, wow, yeah, the spec was just bogus there, sorry about that. I never got around to updating it to handle the activation behaviour stuff properly after fixing that a few years back. Fixed. Looks good, thanks. -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, 29 Jun 2012, Boris Zbarsky wrote: > On 6/29/12 6:19 PM, Boris Zbarsky wrote: > > In any case, I believe the spec is wrong in one aspect: in the case > > that there is a default button, what needs to happen is a click event > > on that button, not just a triggering of its activation behavior. In > > particular, onclick handlers need to fire and the activation behavior > > should only happen if preventDefault is not called on the event. > > Note that depending on how defines handling of click > events, we may get the right thing happening with it for free. > Unfortunately, I'm failing to find where the spec talks about the actual > behavior of @disabled on submit controls. :( It's a bit of a tortuous route. The definition of says: # The disabled attribute is used to make the control non-interactive and # to prevent its value from being submitted. - http://www.whatwg.org/specs/web-apps/current-work/#the-input-element ...which links to: # A form control is disabled if its disabled attribute is set [...] - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-disabled This is used in the element section: # When an input element is disabled, it is immutable. - http://www.whatwg.org/specs/web-apps/current-work/#concept-input-immutable This is then used in the type=submit definition: # If the element is immutable, it has no activation behavior. - http://www.whatwg.org/specs/web-apps/current-work/#submit-button-state-(type=submit) And now the implicit submission section says: # If the platform supports letting the user submit a form implicitly (for # example, on some platforms hitting the "enter" key while a text field is # focused implicitly submits the form), then doing so for a form whose # default button has a defined activation behavior must cause the user # agent to run synthetic click activation steps on that default button. # # Consequently, if the default button is disabled, the form is not # submitted when such an implicit submission mechanism is used. (A button # has no activation behavior when disabled.) - http://www.whatwg.org/specs/web-apps/current-work/#implicit-submission HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, 29 Jun 2012, Boris Zbarsky wrote: > On 6/29/12 5:24 PM, Ian Hickson wrote: > > Let me know if it's not quite right. I wasn't sure exactly what weird > > things to test. I mostly relied on WebKit's (specifically Chrome's) > > behaviour here since they were apparently the ones most recently > > affected by real compat reasons to implement something here so maybe > > they are the closest to what the Web today actually needs (?). > > What were the differences between Chrome and Gecko here, if you recall? > I'm somewhat interested. The main difference was that Chrome and Firefox differ in what input types they support, which affects which they allow to affect the implicit submission thing. > In any case, I believe the spec is wrong in one aspect: in the case that > there is a default button, what needs to happen is a click event on that > button, not just a triggering of its activation behavior. In > particular, onclick handlers need to fire and the activation behavior > should only happen if preventDefault is not called on the event. For > example, this testcase: > > > http://w3.org";> > > > > > should alert and not submit. Yes, I know this is totally screwy. :( Oh, wow, yeah, the spec was just bogus there, sorry about that. I never got around to updating it to handle the activation behaviour stuff properly after fixing that a few years back. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 6/29/12 6:19 PM, Boris Zbarsky wrote: In any case, I believe the spec is wrong in one aspect: in the case that there is a default button, what needs to happen is a click event on that button, not just a triggering of its activation behavior. In particular, onclick handlers need to fire and the activation behavior should only happen if preventDefault is not called on the event. Note that depending on how defines handling of click events, we may get the right thing happening with it for free. Unfortunately, I'm failing to find where the spec talks about the actual behavior of @disabled on submit controls. :( -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 6/29/12 5:24 PM, Ian Hickson wrote: Let me know if it's not quite right. I wasn't sure exactly what weird things to test. I mostly relied on WebKit's (specifically Chrome's) behaviour here since they were apparently the ones most recently affected by real compat reasons to implement something here so maybe they are the closest to what the Web today actually needs (?). What were the differences between Chrome and Gecko here, if you recall? I'm somewhat interested. In any case, I believe the spec is wrong in one aspect: in the case that there is a default button, what needs to happen is a click event on that button, not just a triggering of its activation behavior. In particular, onclick handlers need to fire and the activation behavior should only happen if preventDefault is not called on the event. For example, this testcase: http://w3.org";> should alert and not submit. Yes, I know this is totally screwy. :( -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, 21 Feb 2012, Boris Zbarsky wrote: > On 2/21/12 10:47 PM, Dimitri Glazkov wrote: > > I made WebKit match this behavior a couple of years ago: > > https://bugs.webkit.org/show_bug.cgi?id=9756 > > Ah, interesting. Some of the links in that bug indicate that people are > in fact depending on this behavior I've tried to define this in the spec. It's a bit esoteric, but... Let me know if it's not quite right. I wasn't sure exactly what weird things to test. I mostly relied on WebKit's (specifically Chrome's) behaviour here since they were apparently the ones most recently affected by real compat reasons to implement something here so maybe they are the closest to what the Web today actually needs (?). On Tue, 3 Apr 2012, Boris Zbarsky wrote: > On 4/3/12 5:14 PM, Glenn Maynard wrote: > > Ten years later it's still giving me headaches, when I try to do a > > trivial two-input login form without a browser submit button, and find > > that every obvious way of hiding the submit button breaks implicit > > submit in one browser or another. Do I really need to stick the > > submit button in an overflow: hidden, 0x0 div? I know I found a less > > ugly workaround for this the last time I hit this... > > Well, the fact that display:none makes it not submit is clearly a > browser bug in the browsers it happens in. Indeed. On Tue, 21 Feb 2012, Glenn Maynard wrote: > > I don't think the existence of implicit submit should depend on platform > conventions, though, for interop on forms without visible submit > buttons. The form implicit submit takes is a platform convention, but it > should be required to exist in some form or another. User agents aren't actually required to let users input anything, so it doesn't make much sense to require submission be possible... On Thu, 24 May 2012, Rob Crowther wrote: > On 22/02/12 00:35, Ian Hickson wrote: > > I've changed the spec to be clearer that CSS cannot be taken into > > account when determining the default. The default button is just > > always the first submit button in the form. > > What about the situation where there isn't a button? Implicit > submission still seems to happen on forms which have just a single > element, for example: > > http://www.boogdesign.com/examples/forms2/test-validate-1.html > http://www.boogdesign.com/examples/forms2/test-validate-2.html > > These both trigger the form validation algorithm in Firefox, Opera & > Chrome if you just hit return. This form with two inputs doesn't > trigger implicit submission: > > http://www.boogdesign.com/examples/forms2/test-validate-3.html > > But add a submit button and it does: > > http://www.boogdesign.com/examples/forms2/test-validate-4.html > > Because in 4.10.22.2 everything hinges on the 'default button' this > behaviour doesn't seem to be covered. Is this intentional? I've updated the spec to hopefully better match this, as noted above. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 22/02/12 00:35, Ian Hickson wrote: I've changed the spec to be clearer that CSS cannot be taken into account when determining the default. The default button is just always the first submit button in the form. What about the situation where there isn't a button? Implicit submission still seems to happen on forms which have just a single element, for example: http://www.boogdesign.com/examples/forms2/test-validate-1.html http://www.boogdesign.com/examples/forms2/test-validate-2.html These both trigger the form validation algorithm in Firefox, Opera & Chrome if you just hit return. This form with two inputs doesn't trigger implicit submission: http://www.boogdesign.com/examples/forms2/test-validate-3.html But add a submit button and it does: http://www.boogdesign.com/examples/forms2/test-validate-4.html Because in 4.10.22.2 everything hinges on the 'default button' this behaviour doesn't seem to be covered. Is this intentional? Rob
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 4/3/12 5:14 PM, Glenn Maynard wrote: Ten years later it's still giving me headaches, when I try to do a trivial two-input login form without a browser submit button, and find that every obvious way of hiding the submit button breaks implicit submit in one browser or another. Do I really need to stick the submit button in an overflow: hidden, 0x0 div? I know I found a less ugly workaround for this the last time I hit this... Well, the fact that display:none makes it not submit is clearly a browser bug in the browsers it happens in. The only question is whether just not having a button at all should also submit. -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, Feb 21, 2012 at 7:36 PM, Boris Zbarsky wrote: > Not offhand. Again, it's been a while since I looked into this, but at > the time this was being implemented in Gecko we carefully made the > two-input-no-submit case not submit. I thought that was for good reason, > but reskimming the bugs now I can't find the reason. It's been over 10 > years, so the details are a bit hazy in my mind. :( > Ten years later it's still giving me headaches, when I try to do a trivial two-input login form without a browser submit button, and find that every obvious way of hiding the submit button breaks implicit submit in one browser or another. Do I really need to stick the submit button in an overflow: hidden, 0x0 div? I know I found a less ugly workaround for this the last time I hit this... -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 2/21/12 10:47 PM, Dimitri Glazkov wrote: I made WebKit match this behavior a couple of years ago: https://bugs.webkit.org/show_bug.cgi?id=9756 Ah, interesting. Some of the links in that bug indicate that people are in fact depending on this behavior -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, Feb 21, 2012 at 5:36 PM, Boris Zbarsky wrote: > On 2/21/12 7:35 PM, Ian Hickson wrote: >> >> On Sun, 25 Sep 2011, Boris Zbarsky wrote: >>> >>> >>> Not doing that last is actually a requirement for web compat, last I >>> looked at this. >> >> >> Do you have any links to pages that break if a form with more than one >> text field supports implicit submission? > > > Not offhand. Again, it's been a while since I looked into this, but at the > time this was being implemented in Gecko we carefully made the > two-input-no-submit case not submit. I thought that was for good reason, > but reskimming the bugs now I can't find the reason. It's been over 10 > years, so the details are a bit hazy in my mind. :( I made WebKit match this behavior a couple of years ago: https://bugs.webkit.org/show_bug.cgi?id=9756 :DG< > > >>> For those who want to mess with the spec for this behavior, >>> https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and >>> https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and >>> https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but >>> probably not sufficient) reading. >> >> >> I read those bugs, but can't see the reason why submitting a form with two >> text fields and no buttons would break the Web. Can you elaborate? > > > https://bugzilla.mozilla.org/show_bug.cgi?id=22526 is the other bug that > needs reading, but it doesn't help either. I didn't look at the various > (and somewhat numerous) duplicates of the various bugs involved... > > I suppose we could try submitting the "more than one text input, no submit > button" case and see what happens... > > -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Tue, Feb 21, 2012 at 6:35 PM, Ian Hickson wrote: > > (It also explicitly says that if implicit submit is supported but > there's no submit button in the form, the implicit submit must still > > happen. That doesn't sound like it could be followed, since lots of > > pages are probably depending on the absence of a submit button > > suppressing implicit submit. That's just backwards-compatibility, not > > platform conventions, though.) > > Do you have any such pages to point to? > Nope, only the assumption that the weird browser behavior related to this could only be for that reason. I'll be happy if this proves unnecessary; this ugliness has caused me headaches in the past. On Sun, 25 Sep 2011, Ryosuke Niwa wrote: > > Why is this authoring question? As an user, I'd like to know whether > > pressing enter in my text field triggers implicit submission or not. > > Whether it does or not should be based on the conventions of the platform. > I don't think the existence of implicit submit should depend on platform conventions, though, for interop on forms without visible submit buttons. The form implicit submit takes is a platform convention, but it should be required to exist in some form or another. -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 2/21/12 7:35 PM, Ian Hickson wrote: On Sun, 25 Sep 2011, Boris Zbarsky wrote: Not doing that last is actually a requirement for web compat, last I looked at this. Do you have any links to pages that break if a form with more than one text field supports implicit submission? Not offhand. Again, it's been a while since I looked into this, but at the time this was being implemented in Gecko we carefully made the two-input-no-submit case not submit. I thought that was for good reason, but reskimming the bugs now I can't find the reason. It's been over 10 years, so the details are a bit hazy in my mind. :( For those who want to mess with the spec for this behavior, https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but probably not sufficient) reading. I read those bugs, but can't see the reason why submitting a form with two text fields and no buttons would break the Web. Can you elaborate? https://bugzilla.mozilla.org/show_bug.cgi?id=22526 is the other bug that needs reading, but it doesn't help either. I didn't look at the various (and somewhat numerous) duplicates of the various bugs involved... I suppose we could try submitting the "more than one text input, no submit button" case and see what happens... -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sat, 24 Sep 2011, Kaustubh Atrawalkar wrote: > On 24-Sep-2011, at 12:24 AM, Ian Hickson wrote: >> On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote: >>> >>> If the form has submit button with display property as none, will that >>> form should be implicitly submitted on pressing enter key? This works >>> in Opera & Firefox but does not work in IE & Safari as of now. What is >>> the expected behavior for this? > >> The strict answer is that it's up to the browsers; the spec allows >> browsers to do whatever they think is appropriate per their platform's >> conventions. So both behaviours are compliant. > > But then this might result in website compliance issue. A website having > username, password field with hidden submit button expecting to login on > enter key using forms implicit submission will work on FF & Opera but > may not work on IE & Safari. Yes. Similarly, some browsers might provide spelling checking, and others might not. Some might support tabbing from field to field, others might not. The thing is, if a platform does not have the concept of implicit submission, presumably the user wouldn't try to implicitly submit anything in the first place, so it doesn't matter if the browser does it or not. >> The guidelines in the spec do not say anything about the behaviour >> being different for elements that are display:none or otherwise hidden, >> though, so I don't see any reason to consider the visibility of a >> button in making the decision as to which button is the default. > > Second to your opinion, on the last line of the specs paragraph it says > - "If the form has no submit button, then the implicit submission > mechanism must just submit the form element from the form element > itself." > http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission This does not contradict what I wrote. It just says what to do if there IS an implicit submission mechanism, but there's no button at all. On Sat, 24 Sep 2011, Ryosuke Niwa wrote: > > WebKit's behavior is very confusing here. It does implicit submission in the > following conditions: > >- One text fields >- One text field with one visible submit button >- Two text fields with one visible submit button >- Two text fields with one visibility:hidden submit button >- One text field with one display:none submit button > > However, it doesn't submit when we have: > >- Two text fields That's non-conforming currently. >- Two text fields with one display:none submit button That's not really sensible, but it was technically within the spec's language. (You were allowed to not pick a default button if there was one to pick from but you didn't like it for some reason.) I've changed the spec to make this no longer allowed. The first button will now always be the default. > Given that WebKit implicitly submits form even in the presence of a > visible submit button or an invisible submit button (visibility: hidden, > or display: none with exactly one text field), I don't see why we should > avoid implicit submission only when there are multiple form controls and > a display:none submit button. Agreed. On Sat, 24 Sep 2011, Ryosuke Niwa wrote: > > IE9 does implicit submission in the following conditions: > >- One text field >- One text field with one visible submit button >- One text field with one display:none submit button >- Two text fields with one visible submit button > > It does not do implicit submissio in the following conditions: > >- Two text fields >- Two text fields with one visibility:hidden submit button >- Two text fields with one display:none submit button > > Basically, IE9 only does implicit submission when there is exactly one > text field (you can have checkbox, hidden, etc...) or there is a visible > button (i.e. not diplay: none nor visibility: hidden). If you submit with one text field and no button, then you are required to also submit with two text fields and no button. So this is non-conforming. > Firefox 5 does implicit submission in the following conditions: > >- One text field >- One text field with one visible submit button >- One text field with one display:none submit button >- Two text fields with one visible submit button >- Two text fields with one visibility:hidden submit button >- Two text fields with one display:none submit button > > It does not do implicit submissio in the following conditions: > >- Two text fields > > In summary, Firefox special cases one text field (can have checkbox, > hidden, etc...) like MSIE and requires a submit button with more than > two text fields regardless of presence of visibility: hidden or display: > none. On Sun, 25 Sep 2011, Kaustubh Atrawalkar wrote: > > Opera - Does Implicit submission in following cases - > * One text field > * One text field with one visible submit button >
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 12/9/11 6:06 PM, Ryosuke Niwa wrote: Given that both IE and WebKit have been disabling implicit form submission for years when the button has display: none, I don't think we can change our behavior here. Why, given that neither Gecko nor Opera have, and as far as I know have gotten precisely 0 bug reports about that? -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
Given that both IE and WebKit have been disabling implicit form submission for years when the button has display: none, I don't think we can change our behavior here. Best, Ryosuke Niwa Software Engineer Google Inc. On Wed, Oct 12, 2011 at 11:33 PM, Kaustubh Atrawalkar wrote: > > On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard wrote: > >> On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa wrote: >> >>> The current Trident/WebKit behavior has a nice side-effect to (without >>> scripts) require a visible submit button to enable implicit form submission. >>> >> >> I don't find that nice. As a user, it's very annoying when implicit form >> submission doesn't work for some obscure reason (like not having a submit >> control), forcing me to use the mouse instead of it behaving like any other >> form. It makes the UI inconsistent and unpredictable. >> >> Also, the single-text-input-with-no-submit-button case doesn't follow the >> above. >> >> The "without scripts" is also a fatal caveat. Users can't be expected to >> understand things like "you can press enter to submit the form if you see a >> browser-native submit button, but not if the button is actually scripted >> markup". >> >> In principle, *all* forms should allow implicit submit, unless the site >> explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't >> support it. That ship sailed years ago, but the visibility of the submit >> button shouldn't enter into it. >> >> > Should this be made to for all browser compliance and browser to allow > implicit submission irrespective of visibility of submit button? A web-dev > can always stop this by either disabling the submit button or through > script. Browser can give control back to onsubmit handler on enter key > press if there is enabled submit button. >
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard wrote: > On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa wrote: > >> The current Trident/WebKit behavior has a nice side-effect to (without >> scripts) require a visible submit button to enable implicit form submission. >> > > I don't find that nice. As a user, it's very annoying when implicit form > submission doesn't work for some obscure reason (like not having a submit > control), forcing me to use the mouse instead of it behaving like any other > form. It makes the UI inconsistent and unpredictable. > > Also, the single-text-input-with-no-submit-button case doesn't follow the > above. > > The "without scripts" is also a fatal caveat. Users can't be expected to > understand things like "you can press enter to submit the form if you see a > browser-native submit button, but not if the button is actually scripted > markup". > > In principle, *all* forms should allow implicit submit, unless the site > explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't > support it. That ship sailed years ago, but the visibility of the submit > button shouldn't enter into it. > > Should this be made to for all browser compliance and browser to allow implicit submission irrespective of visibility of submit button? A web-dev can always stop this by either disabling the submit button or through script. Browser can give control back to onsubmit handler on enter key press if there is enabled submit button.
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard wrote: > On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa wrote: > >> The current Trident/WebKit behavior has a nice side-effect to (without >> scripts) require a visible submit button to enable implicit form submission. >> > > I don't find that nice. As a user, it's very annoying when implicit form > submission doesn't work for some obscure reason (like not having a submit > control), forcing me to use the mouse instead of it behaving like any other > form. It makes the UI inconsistent and unpredictable. > > Also, the single-text-input-with-no-submit-button case doesn't follow the > above. > > The "without scripts" is also a fatal caveat. Users can't be expected to > understand things like "you can press enter to submit the form if you see a > browser-native submit button, but not if the button is actually scripted > markup". > > In principle, *all* forms should allow implicit submit, unless the site > explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't > support it. That ship sailed years ago, but the visibility of the submit > button shouldn't enter into it. > > Reopening discussion - In case of single Input box and disabled (but visible button) forms still gets submitted on implicit submission. This is again something weird and happens in IE & Webkit but not in FF & opera. IMHO, the implicit submission should have straight away algorithm - 1) If submit button is there but not disabled implicit submission should happen on enter key press 2) If submit button is there and disabled implicit submission should not happen on enter key press Both logic should be irrespective of number of input button OR visibility of submit button. - Kaustubh
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 9/25/11 5:35 PM, Ryosuke Niwa wrote: So Gecko fires a click event on a button even if it had display: none or visibiliy: hidden? In this situation, yes. Just like as if you called dispatchEvent on it. Of course you can't trigger click events on such a button using an actual mouse, since it can't be hit-targeted. -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sep 25, 2011 11:48 AM, "Boris Zbarsky" wrote: > On 9/24/11 4:45 PM, Ryosuke Niwa wrote: >> It does not do implicit submissio in the following conditions: >> >>- Two text fields > > Not doing that last is actually a requirement for web compat, last I looked at this. > > Furthermore, a requirement for web compat is that in the two-textfield case the submission happen via triggering a click event on the default submit element for the form and then allowing that to trigger submission as it would normally (or not trigger it, if the page prevents its default action, etc). I expect this event-firing business is why IE has any sort of dependency on styles for the submit button, and I would not be surprised if that's why WebKit has it too. This is a good point. So Gecko fires a click event on a button even if it had display: none or visibiliy: hidden? > For the one-text-input case, as I recall IE does NOT click the default submit, at least as of 2002; Gecko used to have that behavior but we opted for more consistency. So the current Gecko behavior is to submit via clicking the default submit input if there is one, else to submit only if there is only one text control (where the definition of "text control" is especially interesting, since it of course includes controls of unknown types, so as new form control types are added things get _really_ exciting before browsers implement them). Right, determining whether there is excatly one text field is tricky. > For those who want to mess with the spec for this behavior, https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but probably not sufficient) reading. Thanks for the pointer! This is very helpful. - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa wrote: > The current Trident/WebKit behavior has a nice side-effect to (without > scripts) require a visible submit button to enable implicit form submission. > I don't find that nice. As a user, it's very annoying when implicit form submission doesn't work for some obscure reason (like not having a submit control), forcing me to use the mouse instead of it behaving like any other form. It makes the UI inconsistent and unpredictable. Also, the single-text-input-with-no-submit-button case doesn't follow the above. The "without scripts" is also a fatal caveat. Users can't be expected to understand things like "you can press enter to submit the form if you see a browser-native submit button, but not if the button is actually scripted markup". In principle, *all* forms should allow implicit submit, unless the site explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't support it. That ship sailed years ago, but the visibility of the submit button shouldn't enter into it. -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 9/25/11 11:46 AM, Ryosuke Niwa wrote: Given the combined market share of Trident and WebKit, I'm not convinced we can safely change our behavior without causing compatibility issues. As a data point, we (Gecko) have never had a compat issue I know of from submitting on enter when the default submit is display:none or visibility:hidden. -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On 9/24/11 4:45 PM, Ryosuke Niwa wrote: Basically, IE9 only does implicit submission when there is exactly one text field (you can have checkbox, hidden, etc...) or there is a visible button (i.e. not diplay: none nor visibility: hidden). Firefox 5 does implicit submission in the following conditions: - One text field - One text field with one visible submit button - One text field with one display:none submit button - Two text fields with one visible submit button - Two text fields with one visibility:hidden submit button - Two text fields with one display:none submit button It does not do implicit submissio in the following conditions: - Two text fields Not doing that last is actually a requirement for web compat, last I looked at this. Furthermore, a requirement for web compat is that in the two-textfield case the submission happen via triggering a click event on the default submit element for the form and then allowing that to trigger submission as it would normally (or not trigger it, if the page prevents its default action, etc). I expect this event-firing business is why IE has any sort of dependency on styles for the submit button, and I would not be surprised if that's why WebKit has it too. For the one-text-input case, as I recall IE does NOT click the default submit, at least as of 2002; Gecko used to have that behavior but we opted for more consistency. So the current Gecko behavior is to submit via clicking the default submit input if there is one, else to submit only if there is only one text control (where the definition of "text control" is especially interesting, since it of course includes controls of unknown types, so as new form control types are added things get _really_ exciting before browsers implement them). Submitting forms with no submit on enter in a single text control is also required for web compat, of course. There is also the separate issue of _which_ controls enter triggers submission in (e.g. it works in checkbox or radio in Gecko, iirc, but of course not in textarea). For those who want to mess with the spec for this behavior, https://bugzilla.mozilla.org/show_bug.cgi?id=99920 and https://bugzilla.mozilla.org/show_bug.cgi?id=109463 and https://bugzilla.mozilla.org/show_bug.cgi?id=147850 are necessary (but probably not sufficient) reading. Also necessary is a decent test matrix and testing in all 4 relevant engines, of course. -Boris
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 9:51 AM, Kaustubh Atrawalkar wrote: > > On Sun, Sep 25, 2011 at 10:10 PM, Ryosuke Niwa wrote: > >> On Sat, Sep 24, 2011 at 11:06 PM, Kaustubh Atrawalkar < >> kaust...@motorola.com> wrote: >>> >>> My perspective would be absence of submit button (with either >>> visibility:hidden OR display:none) would give user to create more enhanced >>> pages that will allow implicit submission like just username & password hit >>> enter and done and not having mandatory for Sign In button. (just a use >>> case) >>> >> >> Authors can already do this by injecting script although I'd argue that >> such an UI is not "enhanced" at all because users may not know pressing >> enter result in form submission. >> >> > Yes, but author can just reduce his scripting by using default behavior > provided by the browser engine. I agree that user may not know pressing > enter results in general form submission, but in case of search he does. > Just we can make it generic instead of just for one/two input elements. > I haven't seen a search engine that requires two text fields by default. And implicit submission already works on all browsers when there is exactly one text field. The current Trident/WebKit behavior has a nice side-effect to (without scripts) require a visible submit button to enable implicit form submission. - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 12:51 PM, Kaustubh Atrawalkar wrote: > Yes, but author can just reduce his scripting by using default behavior > provided by the browser engine. I agree that user may not know pressing > enter results in general form submission, but in case of search he does. > Just we can make it generic instead of just for one/two input elements. > That would have been nice, but there's already interop here: in all four browsers I tested, two text inputs with no submit button never implicitly submits. No browser vendor would change that and break what little consistency there is, and web compatibility would likely veto it anyway. See http://zewt.org/~glenn/test-form-submission/table.html, column 4. But ironing out the bizarre corner cases (eg. columns 7, 8) would be nice, if compatibility will allow it. -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 10:10 PM, Ryosuke Niwa wrote: > On Sat, Sep 24, 2011 at 11:06 PM, Kaustubh Atrawalkar < > kaust...@motorola.com> wrote: >> >> My perspective would be absence of submit button (with either >> visibility:hidden OR display:none) would give user to create more enhanced >> pages that will allow implicit submission like just username & password hit >> enter and done and not having mandatory for Sign In button. (just a use >> case) >> > > Authors can already do this by injecting script although I'd argue that > such an UI is not "enhanced" at all because users may not know pressing > enter result in form submission. > > Yes, but author can just reduce his scripting by using default behavior provided by the browser engine. I agree that user may not know pressing enter results in general form submission, but in case of search he does. Just we can make it generic instead of just for one/two input elements. - Kaustubh
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sat, Sep 24, 2011 at 11:06 PM, Kaustubh Atrawalkar wrote: > > My perspective would be absence of submit button (with either > visibility:hidden OR display:none) would give user to create more enhanced > pages that will allow implicit submission like just username & password hit > enter and done and not having mandatory for Sign In button. (just a use > case) > Authors can already do this by injecting script although I'd argue that such an UI is not "enhanced" at all because users may not know pressing enter result in form submission. I personally find implicit form submission to be annoying, and always wished I could disable it (also backspace triggering backward navigation). Another outlier: Android's WebKit, at least in 2.3.5, seems to always allow >> user submit when editing a text input, via the "Go" button in the input >> method, regardless of any submit buttons or their state. >> > > Yes, this reminds me more use case for tablets/mobiles where use need to > scroll the page and click on the Submit button instead he can just use the > Go button on the input may be. > This seems like a great example for why each platform/UA wants to behave differently. - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 11:46 AM, Ryosuke Niwa wrote: > On Sun, Sep 25, 2011 at 7:49 AM, Glenn Maynard wrote: > >> This is an authoring question, not a user one; either the page's author >> intends the form to be submittable or he doesn't. Having visibility: hidden >> affect this is even more surprising to me as an author than display: none. >> > > Why is this authoring question? As an user, I'd like to know whether > pressing enter in my text field triggers implicit submission or not. > How is that related to the presence or lack of a submit button? In most cases there's no correlation. Where there is one, it's inconsistent, because authors work around the lack of autosubmit by implementing it manually; and even when they don't it's still inconsistent, with the strange dependency on the number of inputs. (Including hidden ones; because of this, enabling CSRF form tags in a framework actually changes the UI of forms.) It's an authoring question whether the form is one which is submittable, or one which is, for example, saved automatically on each change, such as some preference pages. -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 7:49 AM, Glenn Maynard wrote: > This is an authoring question, not a user one; either the page's author > intends the form to be submittable or he doesn't. Having visibility: hidden > affect this is even more surprising to me as an author than display: none. > Why is this authoring question? As an user, I'd like to know whether pressing enter in my text field triggers implicit submission or not. Of course, display: none having an impact here is strange, too. The > stylesheet shouldn't have this sort of behavioral side-effect. Both of these > are weird exceptions, and happen only in IE and WebKit. Definite agreement > with fixing WebKit to line up with FF/Opera in case #7. > Given the combined market share of Trident and WebKit, I'm not convinced we can safely change our behavior without causing compatibility issues. - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 1:39 AM, Ryosuke Niwa wrote: > This makes the least sense of all to me. visibility: hidden shouldn't have > a side-effect like this. > > Why? From user's perspective, not having submit button, having a submit > button with display: none, having a submit button with visibility: hidden > all look the same. > This is an authoring question, not a user one; either the page's author intends the form to be submittable or he doesn't. Having visibility: hidden affect this is even more surprising to me as an author than display: none. Of course, display: none having an impact here is strange, too. The stylesheet shouldn't have this sort of behavioral side-effect. Both of these are weird exceptions, and happen only in IE and WebKit. Definite agreement with fixing WebKit to line up with FF/Opera in case #7. -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 5:25 AM, Glenn Maynard wrote: > On Fri, Sep 23, 2011 at 2:52 PM, Ian Hickson wrote: > > The strict answer is that it's up to the browsers; the spec allows > > browsers to do whatever they think is appropriate per their platform's > > conventions. So both behaviours are compliant. > > Nothing in "4.10.22.2 Implicit submission" seems to allow implicit > submission to vary based on whether a submit button is displayed or not... > > (It also explicitly says that if implicit submit is supported but there's > no submit button in the form, the implicit submit must still happen. That > doesn't sound like it could be followed, since lots of pages are probably > depending on the absence of a submit button suppressing implicit submit. > That's just backwards-compatibility, not platform conventions, though.) > > My perspective would be absence of submit button (with either visibility:hidden OR display:none) would give user to create more enhanced pages that will allow implicit submission like just username & password hit enter and done and not having mandatory for Sign In button. (just a use case) > > On Sat, Sep 24, 2011 at 12:47 PM, Ryosuke Niwa wrote: > >> However, it doesn't submit when we have: >> >> - Two text fields with one display:none submit button >> > ... >> > > Another outlier: Android's WebKit, at least in 2.3.5, seems to always allow > user submit when editing a text input, via the "Go" button in the input > method, regardless of any submit buttons or their state. > > Yes, this reminds me more use case for tablets/mobiles where use need to scroll the page and click on the Submit button instead he can just use the Go button on the input may be. > IE9 does implicit submission in the following conditions: >> - Two text fields with one visible submit button >> >> >> Just to add more analysis Opera - Does Implicit submission in following cases - * One text field * One text field with one visible submit button * One text field with one display:none submit button * Two text fields with one visible submit button * Two text fields with one visibility:hidden submit button * Two text fields with one display:none submit button Only in following case it does not - * Two text fields http://www.w3schools.com/browsers/browsers_stats.asp Just to consider market shares of browsers - Increasing share of Firefox (more than 40%) and decreasing share of IE (less than 25%) & also for Mobiles & Tablets there is Opera Mini which is increasing.
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sat, Sep 24, 2011 at 4:55 PM, Glenn Maynard wrote: > On Sat, Sep 24, 2011 at 12:47 PM, Ryosuke Niwa wrote: > >> However, it doesn't submit when we have: >> >> - Two text fields with one display:none submit button >> > ... >> > > Another outlier: Android's WebKit, at least in 2.3.5, seems to always allow > user submit when editing a text input, via the "Go" button in the input > method, regardless of any submit buttons or their state. > > IE9 does implicit submission in the following conditions: >> - Two text fields with one visible submit button >> >> >> It does not do implicit submissio in the following conditions: >> - Two text fields with one visibility:hidden submit button >> > > This makes the least sense of all to me. visibility: hidden shouldn't have > a side-effect like this. Why? From user's perspective, not having submit button, having a submit button with display: none, having a submit button with visibility: hidden all look the same. - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, Sep 23, 2011 at 2:52 PM, Ian Hickson wrote: > The strict answer is that it's up to the browsers; the spec allows > browsers to do whatever they think is appropriate per their platform's > conventions. So both behaviours are compliant. Nothing in "4.10.22.2 Implicit submission" seems to allow implicit submission to vary based on whether a submit button is displayed or not... (It also explicitly says that if implicit submit is supported but there's no submit button in the form, the implicit submit must still happen. That doesn't sound like it could be followed, since lots of pages are probably depending on the absence of a submit button suppressing implicit submit. That's just backwards-compatibility, not platform conventions, though.) On Sat, Sep 24, 2011 at 12:47 PM, Ryosuke Niwa wrote: > However, it doesn't submit when we have: > > - Two text fields with one display:none submit button > ... > Another outlier: Android's WebKit, at least in 2.3.5, seems to always allow user submit when editing a text input, via the "Go" button in the input method, regardless of any submit buttons or their state. IE9 does implicit submission in the following conditions: > - Two text fields with one visible submit button > > It does not do implicit submissio in the following conditions: > - Two text fields with one visibility:hidden submit button > This makes the least sense of all to me. visibility: hidden shouldn't have a side-effect like this. On Sat, Sep 24, 2011 at 4:59 PM, Dimitri Glazkov wrote: > Hi folks -- I wrote a fairly comprehensive test suite to capture al > this a while back: > > http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/implicit-submission.html > I adjusted this to work in other browsers and ran it in a few of them, after adding some display: none and visibility: none cases: http://zewt.org/~glenn/test-form-submission/ http://zewt.org/~glenn/test-form-submission/table.html I had to make it run without data: to work around IE9. These were run in Windows; I suppose they may behave differently in Linux and OSX. I didn't spend the time to convince browsers to cache everything, so it'll be a little slow (roundtrips per test). -- Glenn Maynard
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
Hi folks -- I wrote a fairly comprehensive test suite to capture al this a while back: http://trac.webkit.org/browser/trunk/LayoutTests/fast/forms/implicit-submission.html Hope it helps! :DG< On Sat, Sep 24, 2011 at 1:52 PM, Ryosuke Niwa wrote: > On Sat, Sep 24, 2011 at 9:47 AM, Ryosuke Niwa wrote: >> >> WebKit's behavior is very confusing here. It does implicit submission in >> the following conditions: >> >> - One text fields >> - Two text fields >> >> > Correction. WebKit does NOT do implicit submision for two text fields when > there are no submit buttons. > > - Ryosuke >
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sat, Sep 24, 2011 at 9:47 AM, Ryosuke Niwa wrote: > > WebKit's behavior is very confusing here. It does implicit submission in > the following conditions: > >- One text fields >- Two text fields > > Correction. WebKit does NOT do implicit submision for two text fields when there are no submit buttons. - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
FYI, I checked Firefox 5's & Internet Explorer 9's behaviors as well. IE9 does implicit submission in the following conditions: - One text field - One text field with one visible submit button - One text field with one display:none submit button - Two text fields with one visible submit button It does not do implicit submissio in the following conditions: - Two text fields - Two text fields with one visibility:hidden submit button - Two text fields with one display:none submit button Basically, IE9 only does implicit submission when there is exactly one text field (you can have checkbox, hidden, etc...) or there is a visible button (i.e. not diplay: none nor visibility: hidden). Firefox 5 does implicit submission in the following conditions: - One text field - One text field with one visible submit button - One text field with one display:none submit button - Two text fields with one visible submit button - Two text fields with one visibility:hidden submit button - Two text fields with one display:none submit button It does not do implicit submissio in the following conditions: - Two text fields In summary, Firefox special cases one text field (can have checkbox, hidden, etc...) like MSIE and requires a submit button with more than two text fields regardless of presence of visibility: hidden or display: none.
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, Sep 23, 2011 at 10:10 PM, Kaustubh Atrawalkar wrote: > > > > If the form has submit button with display property as none, will that > > > form should be implicitly submitted on pressing enter key? This works > in > > > Opera & Firefox but does not work in IE & Safari as of now. What is the > > > expected behavior for this? > > > > The strict answer is that it's up to the browsers; the spec allows > > browsers to do whatever they think is appropriate per their platform's > > conventions. So both behaviours are compliant. > > But then this might result in website compliance issue. A website having > username, password field with hidden submit button expecting to login on > enter key using forms implicit submission will work on FF & Opera but may > not work on IE & Safari. > WebKit's behavior is very confusing here. It does implicit submission in the following conditions: - One text fields - Two text fields - One text field with one visible submit button - Two text fields with one visible submit button - Two text fields with one visibility:hidden submit button - One text field with one display:none submit button However, it doesn't submit when we have: - Two text fields with one display:none submit button Given that WebKit implicitly submits form even in the presence of a visible submit button or an invisible submit button (visibility: hidden, or display: none with exactly one text field), I don't see why we should avoid implicit submission only when there are multiple form controls and a display:none submit button. - Ryosuke
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
> > > > > If the form has submit button with display property as none, will that > > form should be implicitly submitted on pressing enter key? This works in > > Opera & Firefox but does not work in IE & Safari as of now. What is the > > expected behavior for this? > > The strict answer is that it's up to the browsers; the spec allows > browsers to do whatever they think is appropriate per their platform's > conventions. So both behaviours are compliant. > > But then this might result in website compliance issue. A website having username, password field with hidden submit button expecting to login on enter key using forms implicit submission will work on FF & Opera but may not work on IE & Safari. > The guidelines in the spec do not say anything about the behaviour being > different for elements that are display:none or otherwise hidden, though, > so I don't see any reason to consider the visibility of a button in making > the decision as to which button is the default. > > Second to your opinion, on the last line of the specs paragraph it says - "If the form has no submit button, then the implicit submission mechanism must just submit the form element from the form element itself." http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission - Kaustubh
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote: > > There is an issue regarding form submit button which is little unclear > from the specs [...] > > If the form has submit button with display property as none, will that > form should be implicitly submitted on pressing enter key? This works in > Opera & Firefox but does not work in IE & Safari as of now. What is the > expected behavior for this? The strict answer is that it's up to the browsers; the spec allows browsers to do whatever they think is appropriate per their platform's conventions. So both behaviours are compliant. The guidelines in the spec do not say anything about the behaviour being different for elements that are display:none or otherwise hidden, though, so I don't see any reason to consider the visibility of a button in making the decision as to which button is the default. HTH. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTMLForms: Implicit Submission with {display:none} button
Hi, There is an issue regarding form submit button which is little unclear from the specs mentioned in here http://www.whatwg.org/specs/web-apps/cu ... submission If the form has submit button with display property as none, will that form should be implicitly submitted on pressing enter key? This works in Opera & Firefox but does not work in IE & Safari as of now. What is the expected behavior for this? Thanks & Regards - Kaustubh Atrawalkar
