Re: Should events be preferably sent to the Window or the nearest object?
On Thu, 10 Apr 2014, at 0:01, Arthur Barstow wrote: > Perhaps it would be good then to file a bug for the Screen Orientation > spec and/or to add a related note to the ED. WDYT? https://www.w3.org/Bugs/Public/show_bug.cgi?id=25310 -- Mounir
Re: Should events be preferably sent to the Window or the nearest object?
On 4/7/14 5:33 PM, ext Mounir Lamouri wrote: On Tue, 8 Apr 2014, at 8:37, Ian Hickson wrote: On Mon, 7 Apr 2014, Marcos Caceres wrote: On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote: On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. wrote: Agreed. The exact target isn't very important here, and so being consistent with legacy event firing for the same system is probably a good idea. Agree. Let's go with consistency, even though it feels a bit weird. Ian, would it be possible to have some kind of hook in HTML to give us this behaviour for free? That is, given an event handler IDL attribute on some interface, we get the HTML attribute equivalent on body element (all wired up and ready to be used). That would be useful in that we wouldn't need to define the HTML onorientationchange attribute in the Orientation Lock spec (and all future specs). This could really help with consistency. I'm very happy to add any such attributes to the HTML spec, just file a bug once you're confident that it won't change. When we will be in LC and close to CR, I will file a bug to remove the monkey patching I am doing on the HTML spec. Perhaps it would be good then to file a bug for the Screen Orientation spec and/or to add a related note to the ED. WDYT? -AB
Re: Should events be preferably sent to the Window or the nearest object?
On Tue, 8 Apr 2014, at 8:37, Ian Hickson wrote: > On Mon, 7 Apr 2014, Marcos Caceres wrote: > > On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote: > > > On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. wrote: > > > > Agreed. The exact target isn't very important here, and so being > > > > consistent with legacy event firing for the same system is probably > > > > a good idea. > > > > > > Agree. Let's go with consistency, even though it feels a bit weird. > > > > Ian, would it be possible to have some kind of hook in HTML to give us > > this behaviour for free? > > > > That is, given an event handler IDL attribute on some interface, we get > > the HTML attribute equivalent on body element (all wired up and ready to > > be used). That would be useful in that we wouldn't need to define the > > HTML onorientationchange attribute in the Orientation Lock spec (and all > > future specs). This could really help with consistency. > > I'm very happy to add any such attributes to the HTML spec, just file a > bug once you're confident that it won't change. When we will be in LC and close to CR, I will file a bug to remove the monkey patching I am doing on the HTML spec. -- Mounir
Re: Should events be preferably sent to the Window or the nearest object?
On Mon, 7 Apr 2014, Marcos Caceres wrote: > On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote: > > On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. wrote: > > > Agreed. The exact target isn't very important here, and so being > > > consistent with legacy event firing for the same system is probably > > > a good idea. > > > > Agree. Let's go with consistency, even though it feels a bit weird. > > Ian, would it be possible to have some kind of hook in HTML to give us > this behaviour for free? > > That is, given an event handler IDL attribute on some interface, we get > the HTML attribute equivalent on body element (all wired up and ready to > be used). That would be useful in that we wouldn't need to define the > HTML onorientationchange attribute in the Orientation Lock spec (and all > future specs). This could really help with consistency. I'm very happy to add any such attributes to the HTML spec, just file a bug once you're confident that it won't change. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Should events be preferably sent to the Window or the nearest object?
On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote: > > > On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: > > > Agreed. The exact target isn't very important here, and so being > > consistent with legacy event firing for the same system is probably > > a good idea. > > Agree. Let's go with consistency, even though it feels a bit weird. Ian, would it be possible to have some kind of hook in HTML to give us this behaviour for free? That is, given an event handler IDL attribute on some interface, we get the HTML attribute equivalent on body element (all wired up and ready to be used). That would be useful in that we wouldn't need to define the HTML onorientationchange attribute in the Orientation Lock spec (and all future specs). This could really help with consistency.
Re: Should events be preferably sent to the Window or the nearest object?
On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: > > Agreed. The exact target isn't very important here, and so being > consistent with legacy event firing for the same system is probably > a good idea. Agree. Let's go with consistency, even though it feels a bit weird.
Re: Should events be preferably sent to the Window or the nearest object?
On Thu, Mar 20, 2014 at 8:33 AM, Ian Hickson wrote: > On Fri, 21 Mar 2014, Mounir Lamouri wrote: >> I would love to gather the opinion of public-webapps on a discussion >> Hixie and I had for two different APIs recently: if an array |foo| can >> change, should the change event be fired on its parent or the window >> (its grandparent)? The two cases we discussed with Hixie were >> navigator.languages and screen.orientation for which Hixie thinks the >> change events should be fired on the window so developers can do > onlanguagechange="..." onorientationchange="..."> but I feel that having >> the change event sent on the parent would make things more >> self-contained. >> >> I would love to hear people's opinion on this. >> >> (Note: sending an orientationchange event to the window object would >> have other implications because there is a proprietary API that does >> that but this is entirely orthogonal.) > > To be clear, my opinion is just that we should be consistent. If the event > is related to the Document, then we should fire it at the Document. If > it's related to the , we should fire on the . Some objects are > already EventTargets, including many new objects. I'm just saying that for > existing objects that aren't EventTargets, and for which events have > historically been sent to the Window, we should continue to send events to > the Window, so that we don't end up sending some events to the object and > some to the Window. In the case of Navigation, "online" and "offline" > events go to the Window. In the case of Screen, "resize" and "scroll" > events go to the Window. So it makes sense to put new events there too. Agreed. The exact target isn't very important here, and so being consistent with legacy event firing for the same system is probably a good idea. ~TJ
Re: Should events be preferably sent to the Window or the nearest object?
On Fri, 21 Mar 2014, Mounir Lamouri wrote: > > I would love to gather the opinion of public-webapps on a discussion > Hixie and I had for two different APIs recently: if an array |foo| can > change, should the change event be fired on its parent or the window > (its grandparent)? The two cases we discussed with Hixie were > navigator.languages and screen.orientation for which Hixie thinks the > change events should be fired on the window so developers can do onlanguagechange="..." onorientationchange="..."> but I feel that having > the change event sent on the parent would make things more > self-contained. > > I would love to hear people's opinion on this. > > (Note: sending an orientationchange event to the window object would > have other implications because there is a proprietary API that does > that but this is entirely orthogonal.) To be clear, my opinion is just that we should be consistent. If the event is related to the Document, then we should fire it at the Document. If it's related to the , we should fire on the . Some objects are already EventTargets, including many new objects. I'm just saying that for existing objects that aren't EventTargets, and for which events have historically been sent to the Window, we should continue to send events to the Window, so that we don't end up sending some events to the object and some to the Window. In the case of Navigation, "online" and "offline" events go to the Window. In the case of Screen, "resize" and "scroll" events go to the Window. So it makes sense to put new events there too. IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Should events be preferably sent to the Window or the nearest object?
Hi, I would love to gather the opinion of public-webapps on a discussion Hixie and I had for two different APIs recently: if an array |foo| can change, should the change event be fired on its parent or the window (its grandparent)? The two cases we discussed with Hixie were navigator.languages and screen.orientation for which Hixie thinks the change events should be fired on the window so developers can do but I feel that having the change event sent on the parent would make things more self-contained. I would love to hear people's opinion on this. (Note: sending an orientationchange event to the window object would have other implications because there is a proprietary API that does that but this is entirely orthogonal.) Thanks, -- Mounir
