- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Sun, 25 Sep 2011 08:40:52 -0700
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 any. 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 auto-focusable. - Ryosuke
Received on Sunday, 25 September 2011 08:40:52 UTC