[whatwg] Autofocus readonly Input Elements

Ojan Vafai 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
> 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.   `._.-(,_..'--(,_..'`-.;.'
>


More information about the whatwg mailing list