[whatwg] Autofocus readonly Input Elements

Ryosuke Niwa rniwa at webkit.org
Sun Sep 25 08:40:52 PDT 2011

On Sat, Sep 24, 2011 at 11:17 PM, Kaustubh Atrawalkar <kaustubh at motorola.com
> wrote:
> On Sat, Sep 24, 2011 at 9:38 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> On Fri, Sep 23, 2011 at 1:27 PM, Ojan Vafai <ojan at chromium.org> wrote:
>>> On Fri, Sep 23, 2011 at 11:49 AM, Ian Hickson <ian at 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.

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

 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

- Ryosuke

More information about the whatwg mailing list