- From: Ojan Vafai <ojan@chromium.org>
- Date: Fri, 23 Sep 2011 13:27:56 -0700
On Fri, Sep 23, 2011 at 11:49 AM, Ian Hickson <ian at 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. Kaustubh, it would help if you could see what the behaviors for disabled/hidden inputs are in various browsers as well. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Friday, 23 September 2011 13:27:56 UTC