[whatwg] Autofocus readonly Input Elements

[Kaustubh Atrawalkar]

On Sat, Sep 24, 2011 at 1:57 AM, Ojan Vafai <ojan at chromium.org> wrote:

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