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] Autofocus readonly Input Elements
On Sun, Sep 25, 2011 at 9:59 AM, Kaustubh Atrawalkar wrote: > > Unless user gives a readonly element autofocus attribute this wont be >>> triggered. And when user explicitly add autofocus he expects it to be >>> focused. But still, the question remains with which behavior we should >>> comply. >>> >> >> Having said that, I agree with you. If the author explicitly adds >> autofocus attribute, it seems more natural to think the element should be >> auto-focusable. >> >> > In this case there would be issue if there any sites which have readonly > elements made autofocus but still not expecting to be focused on page load > which would be very rare scenario. We can conclude to have readonly elements > respecting autofocus attribute ? > It'll be nice if we could get some statistics to back your hypothesis. But even without it, I don't think this behavior change would cause that much compat. issue since an user can always move the focus. - Ryosuke
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] Autofocus readonly Input Elements
> > Right. The question is whether read-only/disabled/hidden inputs should be focusable. >>> >>> Readonly elements are focusable both in IE and WebKit. >>> >> >> Agree, then they can be autofocus-able as well as per algorithm. >> > > No, I don't necessarily conclude that. Backward compatibility is more > important than the spec. The spec should reflect the reality of the Web if > any. > > Yes, true and accepted. Specs should reflect the user benefit and compliances rather than just one decided algorithm. > I don't personally see pros and cons in either direction, but I wanted to make sure there was agreement here before changing WebKit's behavior. >>> >>> The question is whether or not there's any backward compatibility issue >>> given the market share of IE and WebKit today. >>> >>> Unless user gives a readonly element autofocus attribute this wont be >> triggered. And when user explicitly add autofocus he expects it to be >> focused. But still, the question remains with which behavior we should >> comply. >> > > Having said that, I agree with you. If the author explicitly adds autofocus > attribute, it seems more natural to think the element should be > auto-focusable. > > In this case there would be issue if there any sites which have readonly elements made autofocus but still not expecting to be focused on page load which would be very rare scenario. We can conclude to have readonly elements respecting autofocus attribute ?
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] Autofocus readonly Input Elements
On Sat, Sep 24, 2011 at 11:17 PM, Kaustubh Atrawalkar wrote: > > On Sat, Sep 24, 2011 at 9:38 PM, Ryosuke Niwa wrote: > >> On Fri, Sep 23, 2011 at 1:27 PM, Ojan Vafai wrote: >> >>> On Fri, Sep 23, 2011 at 11:49 AM, Ian Hickson wrote: >>> > > There are no as such concrete use cases though, one use case can be >>> if >>> > > user want to get the element in focus (may be by scrolling the page >>> on >>> > > load). Currently, Firefox & Opera does focus the readonly elements on >>> > > autofocus whereas IE & Webkit does not. Need to clear the ambiguity. >>> > >>> > If they're focusable at all, I don't see why they wouldn't be >>> > autofocusable. Is there a use case for special-casing read-only ones? >>> > >>> >>> Right. The question is whether read-only/disabled/hidden inputs should be >>> focusable. >>> >> >> Readonly elements are focusable both in IE and WebKit. >> > > Agree, then they can be autofocus-able as well as per algorithm. > No, I don't necessarily conclude that. Backward compatibility is more important than the spec. The spec should reflect the reality of the Web if any. I don't personally see pros and cons in either direction, but I >>> wanted to make sure there was agreement here before changing WebKit's >>> behavior. >>> >> >> The question is whether or not there's any backward compatibility issue >> given the market share of IE and WebKit today. >> >> Unless user gives a readonly element autofocus attribute this wont be > triggered. And when user explicitly add autofocus he expects it to be > focused. But still, the question remains with which behavior we should > comply. > Having said that, I agree with you. If the author explicitly adds autofocus attribute, it seems more natural to think the element should be auto-focusable. - 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
