Re: [webkit-dev] focusin/focusout events
On Tue, Jul 27, 2010 at 10:37 AM, Darin Adler da...@apple.com wrote: This sequence doesn’t sound too terrible to me. But I don’t fully understand the proposal. At the time the focusin event fires we won’t yet know what item is getting focus? I think we do know this and it wouldn't be too hard to implement. It's just a question of what we think the best behavior is. Specifically, in Document::setFocusedNode, we know both the new focused node and the old focused node when firing these events. The “we” I meant is the JavaScript code on the webpage. I see. I hadn't thought about this part. As per the current state of the DOM 3 spec for the target/relatedTarget event object: target relatedTarget blur/DOMFocusOut element losing focus element losing focus focus/DOMFocusIn element receiving focus element receiving focus focusin element receiving focus element losing focus focusout element losing focus element receiving focus The spec looks reasonable to me and I think we could implement it without worry about web compatibility since we would only be modifying the focusin/focusout events, which we just added recently. The only thing I'd like to change in the spec is that focusin/focusout are not cancelable, but that's a whole separate issue and something that should be addressed on www-dom first. Anyone object to that? Specifically, the proposal is to change our event order to match the spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent-event-orderand to change the focusin/focusout events to have target/relatedTarget values as above. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] focusin/focusout events
I think the order as specced at
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent-event-order
is fine. It seems to solve the ordering from a backwards compatibility
case.
The spec leaves out when document.activeElement is changed though.
erik
On Mon, Jul 26, 2010 at 18:32, Ojan Vafai o...@chromium.org wrote:
There are a few concerns on the table:
1. We don't match the DOM3 spec. I'm not too worried about this. Neither
does anyone else. We could probably get the spec to change if noone is going
to implement it as is.
2. We don't match other browsers. It's not clear to me what changes are
worth making here.
3. There's no way to get the selection *before* an element is blurred.
The third one is the only one I really care about solving, in the short term
anyways. I'd like there to be a blur-like event that we fire *before*
clearing the selection. With our current ordering of events, that would mean
clearing the selection after the blur event or the focusout event or both,
which no browser does. That said, it might be safe to just change this.
Since no browser has a selection during the blur event and only IE has one
during focusout, we might be able to get away with just changing that as
noone should be depending on the selection at that point. Perhaps that's
worth trying?
On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler da...@apple.com wrote:
You mention activeElementId, but there must be other side effects that
matter.
The only other side effects I can think of are the focus outline (which
could probably be tested via getComputedStyle?) and clearing the selection.
In non-IE the selection isn't cleared if focus is moving across frames. But
when focus moves within the same document, you get the following:
IE 8: The selection is cleared after the focusout event and before focusin,
blur, focus.
WebKit Opera: It's cleared before any events are fired.
FF 3.6: It's cleared before any events are fired unless focus is moving to a
textarea/input (not contentEditable!).
It's a bit gross, but the only solution I can think of is to fire the
following events in WebKit (in this order):
focusout
focusin
{remove focus and clear selection as appropriate}
blur
domfocusout
{add focus to new node and set selection as appropriate}
focus
domfocusin
This sequence doesn’t sound too terrible to me. But I don’t fully
understand the proposal. At the time the focusin event fires we won’t yet
know what item is getting focus?
I think we do know this and it wouldn't be too hard to implement. It's just
a question of what we think the best behavior is. Specifically,
in Document::setFocusedNode, we know both the new focused node and the old
focused node when firing these events.
Is the design that the focusin event’s target knows it will be getting
focused? What about focus changes that come about along with selection
changes? Or is there no such thing?
Sounds like some differences are:
1) The blur event in Opera and IE will see the new focused node as the
active element, but in WebKit and Firefox will see no active element at all.
2) Same for DOMFocusOut, but IE and Firefox are not affected.
3) IE fires focusout before the selection is cleared if the element being
focused is the body (e.g. click from a contentEditable onto a non-focusable
element).
Is there a good reason to do blur the Firefox way instead of the Opera/IE
way? Maybe because it’s the legacy WebKit way, and hence likely to be
depended on by WebKit-tested or WebKit/Firefox-tested content?
My only concern was backwards compatibility, but I have no evidence that it
is or isn't a valid concern.
Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] focusin/focusout events
On Jul 26, 2010, at 6:32 PM, Ojan Vafai wrote: On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler da...@apple.com wrote: You mention activeElementId, but there must be other side effects that matter. The only other side effects I can think of are the focus outline (which could probably be tested via getComputedStyle?) and clearing the selection. Style changes specified using the :focus pseudo-style is another type of side effect. This sequence doesn’t sound too terrible to me. But I don’t fully understand the proposal. At the time the focusin event fires we won’t yet know what item is getting focus? I think we do know this and it wouldn't be too hard to implement. It's just a question of what we think the best behavior is. Specifically, in Document::setFocusedNode, we know both the new focused node and the old focused node when firing these events. The “we” I meant is the JavaScript code on the webpage. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] focusin/focusout events
On Jul 21, 2010, at 5:24 PM, Ojan Vafai wrote:
Opera 10.6: blur, domfocusout, focus, domfocusin
Moves activeElement immediately before firing any events.
WebKit nightly: blur, (dom)focusout, focus, (dom)focusin
Clears activeElement before blur/focusout, sets active element before
focus/focusin
FF 3.6:blur, focus
Clears activeElement before blur, sets active element before focus.
IE 8: focusout, focusin, blur, focus
Moves activeElement immediately before firing any events.
You mention activeElementId, but there must be other side effects that matter.
It's a bit gross, but the only solution I can think of is to fire the
following events in WebKit (in this order):
focusout
focusin
{remove focus and clear selection as appropriate}
blur
domfocusout
{add focus to new node and set selection as appropriate}
focus
domfocusin
This sequence doesn’t sound too terrible to me. But I don’t fully understand
the proposal. At the time the focusin event fires we won’t yet know what item
is getting focus? Is the design that the focusin event’s target knows it will
be getting focused? What about focus changes that come about along with
selection changes? Or is there no such thing?
Sounds like some differences are:
1) The blur event in Opera and IE will see the new focused node as the
active element, but in WebKit and Firefox will see no active element at all.
2) Same for DOMFocusOut, but IE and Firefox are not affected.
Is there a good reason to do blur the Firefox way instead of the Opera/IE way?
Maybe because it’s the legacy WebKit way, and hence likely to be depended on by
WebKit-tested or WebKit/Firefox-tested content?
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] focusin/focusout events
On Wed, Jul 21, 2010 at 5:24 PM, Ojan Vafai o...@chromium.org wrote:
Opera 10.6: blur, domfocusout, focus, domfocusin
Moves activeElement immediately before firing any events.
WebKit nightly: blur, (dom)focusout, focus, (dom)focusin
Clears activeElement before blur/focusout, sets active element before
focus/focusin
FF 3.6:blur, focus
Clears activeElement before blur, sets active element before focus.
IE 8: focusout, focusin, blur, focus
Moves activeElement immediately before firing any events.
It's a bit gross,
I agree. Very inconsistent.
The only solution I can think of is to fire the following events in WebKit
(in this order):
focusout
focusin
{remove focus and clear selection as appropriate}
blur
domfocusout
{add focus to new node and set selection as appropriate}
focus
domfocusin
That's the exact sequence defined by the spec, right? IMHO, conforming to
the spec is always a good thing unless the spec itself is wrong /
unrealistic.
I'd like to say we could get rid of DOMFocusOut/DOMFocusIn or blur/focus,
but I expect too many sites would break.
I wouldn't push that either for the backward compatibility.
I care more about meeting the use-case listed above than matching the spec.
If we can meet the above use-case differently, I expect we could get the
spec modified.
I'd really like to conform to the spec especially because all UAs are
inconsistent now. If we conform to the spec, we can justify any
backward compatibility issues caused by the change and start nagging other
vendors to fix their browsers instead.
Best,
Ryosuke Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] focusin/focusout events
On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler da...@apple.com wrote: Sounds like some differences are: 1) The blur event in Opera and IE will see the new focused node as the active element, but in WebKit and Firefox will see no active element at all. 2) Same for DOMFocusOut, but IE and Firefox are not affected. Is there a good reason to do blur the Firefox way instead of the Opera/IE way? Maybe because it’s the legacy WebKit way, and hence likely to be depended on by WebKit-tested or WebKit/Firefox-tested content? The spec seems to require that: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-blur A user agent must dispatch this event when an event target loses focus. The focus shall be taken from the element before the dispatch of this event type. This event type is similar to focusout, but is dispatched after focus is shifted, and does not bubble. Best, Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] focusin/focusout events
There are a few concerns on the table:
1. We don't match the DOM3 spec. I'm not too worried about this. Neither
does anyone else. We could probably get the spec to change if noone is going
to implement it as is.
2. We don't match other browsers. It's not clear to me what changes are
worth making here.
3. There's no way to get the selection *before* an element is blurred.
The third one is the only one I really care about solving, in the short term
anyways. I'd like there to be a blur-like event that we fire *before*
clearing the selection. With our current ordering of events, that would mean
clearing the selection after the blur event or the focusout event or both,
which no browser does. That said, it might be safe to just change this.
Since no browser has a selection during the blur event and only IE has one
during focusout, we might be able to get away with just changing that as
noone should be depending on the selection at that point. Perhaps that's
worth trying?
On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler da...@apple.com wrote:
You mention activeElementId, but there must be other side effects that
matter.
The only other side effects I can think of are the focus outline (which
could probably be tested via getComputedStyle?) and clearing the selection.
In non-IE the selection isn't cleared if focus is moving across frames. But
when focus moves within the same document, you get the following:
IE 8: The selection is cleared after the focusout event and before focusin,
blur, focus.
WebKit Opera: It's cleared before any events are fired.
FF 3.6: It's cleared before any events are fired unless focus is moving to a
textarea/input (not contentEditable!).
It's a bit gross, but the only solution I can think of is to fire the
following events in WebKit (in this order):
focusout
focusin
{remove focus and clear selection as appropriate}
blur
domfocusout
{add focus to new node and set selection as appropriate}
focus
domfocusin
This sequence doesn’t sound too terrible to me. But I don’t fully
understand the proposal. At the time the focusin event fires we won’t yet
know what item is getting focus?
I think we do know this and it wouldn't be too hard to implement. It's just
a question of what we think the best behavior is. Specifically,
in Document::setFocusedNode, we know both the new focused node and the old
focused node when firing these events.
Is the design that the focusin event’s target knows it will be getting
focused? What about focus changes that come about along with selection
changes? Or is there no such thing?
Sounds like some differences are:
1) The blur event in Opera and IE will see the new focused node as the
active element, but in WebKit and Firefox will see no active element at all.
2) Same for DOMFocusOut, but IE and Firefox are not affected.
3) IE fires focusout before the selection is cleared if the element being
focused is the body (e.g. click from a contentEditable onto a non-focusable
element).
Is there a good reason to do blur the Firefox way instead of the Opera/IE
way? Maybe because it’s the legacy WebKit way, and hence likely to be
depended on by WebKit-tested or WebKit/Firefox-tested content?
My only concern was backwards compatibility, but I have no evidence that it
is or isn't a valid concern.
Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
