[whatwg] Autofocus readonly Input Elements
ojan at chromium.org
Fri Sep 23 13:27:56 PDT 2011
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
> > User agents may also change the scrolling position of the document, or
> > perform some other action that brings the element to the user's
> > 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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg