Re: [whatwg] Focus remains on Hidden Element
Thanks Ian for the clarification. What I understand from the comment is that, when focused element is made display:none in this case, the focus should be moved to body element if its there else we should blur the focused element. There is bug for the same issue https://bugs.webkit.org/show_bug.cgi?id=47182. I will link this thread there for fixing the same. - Kaustubh On Wed, Feb 22, 2012 at 10:57 AM, Ian Hickson i...@hixie.ch wrote: On Sat, 8 Oct 2011, Kaustubh Atrawalkar wrote: In a form element, If a form input element has a focus and its then made hidden using style property display:none the focus still remains on the hidden element. According to specs ( http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus-management- 4th point) hidden input elements can not be focused. But there is still inconstancy in the browsers. The spec requires that focus be dropped in this case: When an element that is focused stops being a focusable element, or stops being focused without another element being explicitly focused in its stead, the user agent should synchronously run the focusing steps for the body element, if there is one; if there is not, then the user agent should synchronously run the unfocusing steps for the affected element only. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms dont submit when disabling submit button
Thanks Ian for the comment. There is already a bug filed in webkit -
https://bugs.webkit.org/show_bug.cgi?id=14443 which i was working on. I
will attach this thread for clarification there. I will try to fix the
issue asap.
Regards
--
Kaustubh
On Fri, Jan 27, 2012 at 4:23 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Sep 2011, Kaustubh Atrawalkar wrote:
A simple use case -
form action=javascript:alert('SUCCESS')
input type=submit onclick=this.disabled=true; return true;
/form
(Note: This isn't a use case, it's a sample. A use case is a description
of the reason why an author or user wants to do something.)
This does not submit the form in IE, Opera or Webkit but in firefox it
does show alert. Considering generic behavior of HTML5 forms, until and
unless submit button is active submit action should also be followed by
onclick event on submit button. Just need to get what can be the exact
behavior here?
The this.disabled=true bit should have no effect on the submission
(since the click has already occurred), and the return true part of the
event handler should have no effect at all.
Thus, assuming the user only clicks once, the above should be equivalent
to:
form action=javascript:alert('SUCCESS')
input type=submit
/form
Thus, Firefox is correct here, and WebKit and Opera are wrong. (I didn't
test IE.)
I recommend filing bugs.
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 Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa rn...@webkit.org 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] Forms dont submit when disabling submit button
Reopening discussion. Just curious about what can be exact behavior expected
in this case?
I have attached the sample use case.
- Kaustubh
On Tue, Sep 27, 2011 at 11:35 PM, Kaustubh Atrawalkar kaust...@motorola.com
wrote:
A simple use case -
form action=javascript:alert('SUCCESS')
input type=submit onclick=this.disabled=true; return true;
/form
This does not submit the form in IE, Opera or Webkit but in firefox it does
show alert. Considering generic behavior of HTML5 forms, until and unless
submit button is active submit action should also be followed by onclick
event on submit button. Just need to get what can be the exact behavior
here?
According to specs, (
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state)
when button is activated, it should submit the form.
--
Kaustubh Atrawalkar
[whatwg] Focus remains on Hidden Element
Hi, In a form element, If a form input element has a focus and its then made hidden using style property display:none the focus still remains on the hidden element. According to specs ( http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus-management- 4th point) hidden input elements can not be focused. But there is still inconstancy in the browsers. Test case - http://xirc.chez.com/ie9-focus-display-none.html Rationale - Chrome 14 - Focus remains Firefox - Focus is removed MSIE 8 - Focus remains (Need to check on 9) Opera - Focus is removed Can we streamline it for consistency? Any comments would be great. Thanks Regards -- Kaustubh Atrawalkar
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa rn...@webkit.org 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
[whatwg] Forms dont submit when disabling submit button
A simple use case -
form action=javascript:alert('SUCCESS')
input type=submit onclick=this.disabled=true; return true;
/form
This does not submit the form in IE, Opera or Webkit but in firefox it does
show alert. Considering generic behavior of HTML5 forms, until and unless
submit button is active submit action should also be followed by onclick
event on submit button. Just need to get what can be the exact behavior
here?
According to specs, (
http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state)
when button is activated, it should submit the form.
--
Kaustubh Atrawalkar
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 5:25 AM, Glenn Maynard gl...@zewt.org wrote: On Fri, Sep 23, 2011 at 2:52 PM, Ian Hickson i...@hixie.ch 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 rn...@webkit.org 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] Autofocus readonly Input Elements
On Sat, Sep 24, 2011 at 9:38 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Sep 23, 2011 at 1:27 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Sep 23, 2011 at 11:49 AM, Ian Hickson i...@hixie.ch 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. 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.
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sun, Sep 25, 2011 at 10:10 PM, Ryosuke Niwa rn...@webkit.org 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] 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] Autofocus readonly Input Elements
On Sat, Sep 24, 2011 at 1:57 AM, Ojan Vafai o...@chromium.org wrote: On Fri, Sep 23, 2011 at 11:49 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote: Reference - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autofocus Here there is mentioned that Queue a task that checks to see if the element is focusable, and if so, runs the focusing steps for that element. User agents may also change the scrolling position of the document, or perform some other action that brings the element to the user's attention. As per this statement, every focus-able element should be autofocus-able. Does this applies to readonly input elements as well? Since it doesn't say otherwise, yes. 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. 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. hidden/disabled elements already are in the exception not to get autofocus as explained here http://www.whatwg.org/specs/web-forms/current-work/#the-autofocus. This draft is no more updated but still just for reference we can use it. And they have clearly mentioned - When a form control is inserted into a document, the UA must check to see if it has this attribute set. If it does, and the control is not disabled, and it is of a type normally focusable in the user's operating environment, then the UA should focus the control, as if the control's focus() method was invoked. UAs with a viewport should also scroll the document enough to make the control visible, even if it is not of a type normally focusable. Might be useful for deciding the expected behavior. But as far as readonly inputs are considered they are Kaustubh, it would help if you could see what the behaviors for disabled/hidden inputs are in various browsers as well. Checked with other browsers and none support autofocusing of disabled/hidden elements. As they might be following the specs above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Autofocus readonly Input Elements
Hi, Reference - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autofocus Here there is mentioned that Queue a task that checks to see if the element is focusable, and if so, runs the focusing steps for that element. User agents may also change the scrolling position of the document, or perform some other action that brings the element to the user's attention. As per this statement, every focus-able element should be autofocus-able. Does this applies to readonly input elements as well? 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. Thanks Regards -- Kaustubh Atrawalkar
[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
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
