Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers wrote: > On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard wrote: >> >> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers wrote: >> > I've been wondering about the implications of prefixed events. Do we >> > have >> > other examples of events that had prefixed names and were later >> > unprefixed? >> > >> >> We've never had such a case in the past. It's the first time we have >> to "unprefix" DOM events. >> >> > In particular, what are the composition implications of your solution? >> > When >> > you say "depending >> > if someone is listening to it or not" you mean whether there is a >> > handler >> > attached that will be triggered by this event, not whether there is a >> > handler for that type of event anywhere on the page, right? Is it >> > likely >> >> I'm not sure to understand this part. What is the difference you are >> talking about? Do you mean whether the user added an event listener on >> an element or on the document. If it's the case then WebKit event >> delivery code does not make any difference from what I can see. > > > Sorry, what I'm trying to ask is, what happens when: > - e1 has a 'webkitTransitiionEnd' handler, and > - e2 has a 'transitionend' handler > > You made it clear that if e1==e2 then you'd dispatch only transitionend. > But what about when e1 is neither an ancestor or descendant of e2? I.e. are > you looking at all handlers on the page to determine which events to > dispatch, or only some subset of them specific to the context of the event > being dispatched? In that particular case, from my testing e1 handler will be called and e2 handler too. The case I was raising is if you have an event handler installed on the same element for both events. > >> >> > that existing code might put handlers on the document (eg. maybe as a >> > sort >> > of polling mechanism when there are many elements that may be involved >> > in >> > transitions?), and if so are we likely to have trouble with different >> > libraries that used to co-exist peacefully in the same site no longer >> > working together? The philosophy of "forcing" a site to update to the >> > unprefixed name really only makes sense to me if you think of a site as >> > a >> > single application, not as a collection of separately maintained >> > libraries >> > and components. >> >> Well usually libraries tend to support multiple vendors so if we send >> the unprefixed version then I'm pretty sure it's handled somewhere. >> For example, Opera and Mozilla ship unprefixed for some time so I >> believe anyway the web is slowly updating. Worst I believe that >> because WebKit does not ship unprefixed transitions and animations >> they end up having code extra to support us. > > > Oh, if most important libraries have already updated to always listen for > the unprefixed events (and most important sites using those libraries have > updated to a version that does this), then I agree there shouldn't be any > such composition concerns. I don't have any data, but I just assumed with > the history of CSS animations on webkit-dominated mobile, that there could > still be a lot of deployed code (especially in the mobile space) that looks > only for webkitTransitionEnd. Adam proposed a solution to gather data, I think we should do it. > >> > >> > Rick >> > >> > On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth wrote: >> >> >> >> That does sound like a tricky problem. Your approach sounds >> >> reasonable to me. If you like, we can use the FeatureObserver [1] to >> >> estimate how often these various cases occur. >> >> >> >> Adam >> >> >> >> [1] >> >> http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html >> >> >> >> >> >> On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard >> >> wrote: >> >> > Hi all, >> >> > >> >> > As you know I'm working on unprefixing CSS transitions and I need a >> >> > few advice from the DOM experts. >> >> > >> >> > Problem : CSS Transitions when they finish to animate send a DOM >> >> > event >> >> > "transitionend" as specified there [1] to give the developer a notice >> >> > that the transition finished. Today WebKit sends the prefixed >> >> > counterpart "webkitTransitionEnd". Animations also have the same >> >> > event >> >> > and few more. So today the problem is when we should send the >> >> > prefixed >> >> > event and when we should send the unprefixed one, and if we should >> >> > send both. >> >> > >> >> > I think that sending both events will break content somewhere as JS >> >> > functions attached with addEventListener will be called two times. >> >> > >> >> > Sending only the unprefixed event will break WebKit-only content the >> >> > day we ship CSS Transitions unprefixed. I know they should not >> >> > produce >> >> > WebKit only code but it's not the point of the discussion. >> >> > >> >> > A solution is to send the prefixed or the unprefixed event depending >> >> > if someone is listening to it or not. Let me explain. >> >> > >> >> > Let say
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Mon, Jan 14, 2013 at 9:56 AM, Alexis Menard wrote: > On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers wrote: > > On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard > wrote: > >> > >> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers > wrote: > >> > I've been wondering about the implications of prefixed events. Do we > >> > have > >> > other examples of events that had prefixed names and were later > >> > unprefixed? > >> > > >> > >> We've never had such a case in the past. It's the first time we have > >> to "unprefix" DOM events. > >> > >> > In particular, what are the composition implications of your solution? > >> > When > >> > you say "depending > >> > if someone is listening to it or not" you mean whether there is a > >> > handler > >> > attached that will be triggered by this event, not whether there is a > >> > handler for that type of event anywhere on the page, right? Is it > >> > likely > >> > >> I'm not sure to understand this part. What is the difference you are > >> talking about? Do you mean whether the user added an event listener on > >> an element or on the document. If it's the case then WebKit event > >> delivery code does not make any difference from what I can see. > > > > > > Sorry, what I'm trying to ask is, what happens when: > > - e1 has a 'webkitTransitiionEnd' handler, and > > - e2 has a 'transitionend' handler > > > > You made it clear that if e1==e2 then you'd dispatch only transitionend. > > But what about when e1 is neither an ancestor or descendant of e2? I.e. > are > > you looking at all handlers on the page to determine which events to > > dispatch, or only some subset of them specific to the context of the > event > > being dispatched? > > In that particular case, from my testing e1 handler will be called and > e2 handler too. The case I was raising is if you have an event handler > installed on the same element for both events. > Perfect, thanks. I think that means the majority of composition scenarios I was worried about should be fine... > > >> > >> > that existing code might put handlers on the document (eg. maybe as a > >> > sort > >> > of polling mechanism when there are many elements that may be involved > >> > in > >> > transitions?), and if so are we likely to have trouble with different > >> > libraries that used to co-exist peacefully in the same site no longer > >> > working together? The philosophy of "forcing" a site to update to the > >> > unprefixed name really only makes sense to me if you think of a site > as > >> > a > >> > single application, not as a collection of separately maintained > >> > libraries > >> > and components. > >> > >> Well usually libraries tend to support multiple vendors so if we send > >> the unprefixed version then I'm pretty sure it's handled somewhere. > >> For example, Opera and Mozilla ship unprefixed for some time so I > >> believe anyway the web is slowly updating. Worst I believe that > >> because WebKit does not ship unprefixed transitions and animations > >> they end up having code extra to support us. > > > > > > Oh, if most important libraries have already updated to always listen for > > the unprefixed events (and most important sites using those libraries > have > > updated to a version that does this), then I agree there shouldn't be > any > > such composition concerns. I don't have any data, but I just assumed > with > > the history of CSS animations on webkit-dominated mobile, that there > could > > still be a lot of deployed code (especially in the mobile space) that > looks > > only for webkitTransitionEnd. > > Adam proposed a solution to gather data, I think we should do it. > > > > >> > > >> > Rick > >> > > >> > On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth > wrote: > >> >> > >> >> That does sound like a tricky problem. Your approach sounds > >> >> reasonable to me. If you like, we can use the FeatureObserver [1] to > >> >> estimate how often these various cases occur. > >> >> > >> >> Adam > >> >> > >> >> [1] > >> >> > http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html > >> >> > >> >> > >> >> On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard > >> >> wrote: > >> >> > Hi all, > >> >> > > >> >> > As you know I'm working on unprefixing CSS transitions and I need a > >> >> > few advice from the DOM experts. > >> >> > > >> >> > Problem : CSS Transitions when they finish to animate send a DOM > >> >> > event > >> >> > "transitionend" as specified there [1] to give the developer a > notice > >> >> > that the transition finished. Today WebKit sends the prefixed > >> >> > counterpart "webkitTransitionEnd". Animations also have the same > >> >> > event > >> >> > and few more. So today the problem is when we should send the > >> >> > prefixed > >> >> > event and when we should send the unprefixed one, and if we should > >> >> > send both. > >> >> > > >> >> > I think that sending both events will break content somewhere as JS > >> >> > functions attached with addEventListener will be called two ti
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard wrote: > On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers wrote: > > I've been wondering about the implications of prefixed events. Do we > have > > other examples of events that had prefixed names and were later > unprefixed? > > > > We've never had such a case in the past. It's the first time we have > to "unprefix" DOM events. > > > In particular, what are the composition implications of your solution? > When > > you say "depending > > if someone is listening to it or not" you mean whether there is a handler > > attached that will be triggered by this event, not whether there is a > > handler for that type of event anywhere on the page, right? Is it likely > > I'm not sure to understand this part. What is the difference you are > talking about? Do you mean whether the user added an event listener on > an element or on the document. If it's the case then WebKit event > delivery code does not make any difference from what I can see. > Sorry, what I'm trying to ask is, what happens when: - e1 has a 'webkitTransitiionEnd' handler, and - e2 has a 'transitionend' handler You made it clear that if e1==e2 then you'd dispatch only transitionend. But what about when e1 is neither an ancestor or descendant of e2? I.e. are you looking at all handlers on the page to determine which events to dispatch, or only some subset of them specific to the context of the event being dispatched? > > that existing code might put handlers on the document (eg. maybe as a > sort > > of polling mechanism when there are many elements that may be involved in > > transitions?), and if so are we likely to have trouble with different > > libraries that used to co-exist peacefully in the same site no longer > > working together? The philosophy of "forcing" a site to update to the > > unprefixed name really only makes sense to me if you think of a site as a > > single application, not as a collection of separately maintained > libraries > > and components. > > Well usually libraries tend to support multiple vendors so if we send > the unprefixed version then I'm pretty sure it's handled somewhere. > For example, Opera and Mozilla ship unprefixed for some time so I > believe anyway the web is slowly updating. Worst I believe that > because WebKit does not ship unprefixed transitions and animations > they end up having code extra to support us. Oh, if most important libraries have already updated to always listen for the unprefixed events (and most important sites using those libraries have updated to a version that does this), then I agree there shouldn't be any such composition concerns. I don't have any data, but I just assumed with the history of CSS animations on webkit-dominated mobile, that there could still be a lot of deployed code (especially in the mobile space) that looks only for webkitTransitionEnd. > > > Rick > > > > On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth wrote: > >> > >> That does sound like a tricky problem. Your approach sounds > >> reasonable to me. If you like, we can use the FeatureObserver [1] to > >> estimate how often these various cases occur. > >> > >> Adam > >> > >> [1] > >> http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html > >> > >> > >> On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard > wrote: > >> > Hi all, > >> > > >> > As you know I'm working on unprefixing CSS transitions and I need a > >> > few advice from the DOM experts. > >> > > >> > Problem : CSS Transitions when they finish to animate send a DOM event > >> > "transitionend" as specified there [1] to give the developer a notice > >> > that the transition finished. Today WebKit sends the prefixed > >> > counterpart "webkitTransitionEnd". Animations also have the same event > >> > and few more. So today the problem is when we should send the prefixed > >> > event and when we should send the unprefixed one, and if we should > >> > send both. > >> > > >> > I think that sending both events will break content somewhere as JS > >> > functions attached with addEventListener will be called two times. > >> > > >> > Sending only the unprefixed event will break WebKit-only content the > >> > day we ship CSS Transitions unprefixed. I know they should not produce > >> > WebKit only code but it's not the point of the discussion. > >> > > >> > A solution is to send the prefixed or the unprefixed event depending > >> > if someone is listening to it or not. Let me explain. > >> > > >> > Let say there is a listener on the prefixed event only then we deliver > >> > the prefixed event *only*. > >> > > >> > If there is a listener on the unprefixed event only we deliver the > >> > unprefixed event *only*. > >> > > >> > If there are listeners on both events then we send the unprefixed one > >> > *only* forcing people to rely on the unprefixed. > >> > > >> > It seems that this approach is an elegant one and allows us to remove > >> > later in the future the support for prefixed transitions
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers wrote: > I've been wondering about the implications of prefixed events. Do we have > other examples of events that had prefixed names and were later unprefixed? > We've never had such a case in the past. It's the first time we have to "unprefix" DOM events. > In particular, what are the composition implications of your solution? When > you say "depending > if someone is listening to it or not" you mean whether there is a handler > attached that will be triggered by this event, not whether there is a > handler for that type of event anywhere on the page, right? Is it likely I'm not sure to understand this part. What is the difference you are talking about? Do you mean whether the user added an event listener on an element or on the document. If it's the case then WebKit event delivery code does not make any difference from what I can see. > that existing code might put handlers on the document (eg. maybe as a sort > of polling mechanism when there are many elements that may be involved in > transitions?), and if so are we likely to have trouble with different > libraries that used to co-exist peacefully in the same site no longer > working together? The philosophy of "forcing" a site to update to the > unprefixed name really only makes sense to me if you think of a site as a > single application, not as a collection of separately maintained libraries > and components. Well usually libraries tend to support multiple vendors so if we send the unprefixed version then I'm pretty sure it's handled somewhere. For example, Opera and Mozilla ship unprefixed for some time so I believe anyway the web is slowly updating. Worst I believe that because WebKit does not ship unprefixed transitions and animations they end up having code extra to support us. > > Rick > > On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth wrote: >> >> That does sound like a tricky problem. Your approach sounds >> reasonable to me. If you like, we can use the FeatureObserver [1] to >> estimate how often these various cases occur. >> >> Adam >> >> [1] >> http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html >> >> >> On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard wrote: >> > Hi all, >> > >> > As you know I'm working on unprefixing CSS transitions and I need a >> > few advice from the DOM experts. >> > >> > Problem : CSS Transitions when they finish to animate send a DOM event >> > "transitionend" as specified there [1] to give the developer a notice >> > that the transition finished. Today WebKit sends the prefixed >> > counterpart "webkitTransitionEnd". Animations also have the same event >> > and few more. So today the problem is when we should send the prefixed >> > event and when we should send the unprefixed one, and if we should >> > send both. >> > >> > I think that sending both events will break content somewhere as JS >> > functions attached with addEventListener will be called two times. >> > >> > Sending only the unprefixed event will break WebKit-only content the >> > day we ship CSS Transitions unprefixed. I know they should not produce >> > WebKit only code but it's not the point of the discussion. >> > >> > A solution is to send the prefixed or the unprefixed event depending >> > if someone is listening to it or not. Let me explain. >> > >> > Let say there is a listener on the prefixed event only then we deliver >> > the prefixed event *only*. >> > >> > If there is a listener on the unprefixed event only we deliver the >> > unprefixed event *only*. >> > >> > If there are listeners on both events then we send the unprefixed one >> > *only* forcing people to rely on the unprefixed. >> > >> > It seems that this approach is an elegant one and allows us to remove >> > later in the future the support for prefixed transitions (including >> > the events). As a side note Opera is acting the same as the proposed >> > solution. >> > >> > Now obviously prefixed and unprefixed events in the DOM is something >> > new because it never happens in the past so we don't have support for >> > having such a mechanism for event delivery. >> > >> > I thought that we could somewhere in the Animation/Transition code be >> > smart and try to figure which event to send but it practically >> > impossible to access the EventListenerMap so I thought we could >> > support it somehow generically in the DOM events code. It will be >> > useful for the animations and maybe in the future (we're not really >> > sure if prefixed event will again show but who knows). >> > >> > So I did a first patch there [2] and I would like to gather feedback >> > whether the approach is correct (I don't know much the DOM related >> > code) or if somebody has a better idea on how to resolve the problem. >> > Also if I have missed something, please point it to me. The patch >> > doesn't include the support for HTML ontransitionend attribute which I >> > prefer to do in a later patch. >> > >> > Thanks. >> > >> > [1]
Re: [webkit-dev] Unprefixed and prefixed DOM events.
On Sat, Jan 12, 2013 at 10:07 PM, Ryosuke Niwa wrote: > What happens to corresponding event constructors (e.g. > WebKitTransitionEvent) and content attributes (e.g. onwebkittransitionend)? As I said in the mail we'll need to add them (could be done in a separate patch). There is also some objective-c bindings that I need to look at. > > On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard wrote: >> >> Hi all, >> >> As you know I'm working on unprefixing CSS transitions and I need a >> few advice from the DOM experts. >> >> Problem : CSS Transitions when they finish to animate send a DOM event >> "transitionend" as specified there [1] to give the developer a notice >> that the transition finished. Today WebKit sends the prefixed >> counterpart "webkitTransitionEnd". Animations also have the same event >> and few more. So today the problem is when we should send the prefixed >> event and when we should send the unprefixed one, and if we should >> send both. >> >> I think that sending both events will break content somewhere as JS >> functions attached with addEventListener will be called two times. >> >> Sending only the unprefixed event will break WebKit-only content the >> day we ship CSS Transitions unprefixed. I know they should not produce >> WebKit only code but it's not the point of the discussion. >> >> A solution is to send the prefixed or the unprefixed event depending >> if someone is listening to it or not. Let me explain. >> >> Let say there is a listener on the prefixed event only then we deliver >> the prefixed event *only*. >> >> If there is a listener on the unprefixed event only we deliver the >> unprefixed event *only*. >> >> If there are listeners on both events then we send the unprefixed one >> *only* forcing people to rely on the unprefixed. >> >> It seems that this approach is an elegant one and allows us to remove >> later in the future the support for prefixed transitions (including >> the events). As a side note Opera is acting the same as the proposed >> solution. >> >> Now obviously prefixed and unprefixed events in the DOM is something >> new because it never happens in the past so we don't have support for >> having such a mechanism for event delivery. >> >> I thought that we could somewhere in the Animation/Transition code be >> smart and try to figure which event to send but it practically >> impossible to access the EventListenerMap so I thought we could >> support it somehow generically in the DOM events code. It will be >> useful for the animations and maybe in the future (we're not really >> sure if prefixed event will again show but who knows). >> >> So I did a first patch there [2] and I would like to gather feedback >> whether the approach is correct (I don't know much the DOM related >> code) or if somebody has a better idea on how to resolve the problem. >> Also if I have missed something, please point it to me. The patch >> doesn't include the support for HTML ontransitionend attribute which I >> prefer to do in a later patch. >> >> Thanks. >> >> [1] >> http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property >> [2] https://bugs.webkit.org/show_bug.cgi?id=105647 >> -- >> Software Engineer @ >> Intel Open Source Technology Center >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev > > -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixed and prefixed DOM events.
What happens to corresponding event constructors (e.g. WebKitTransitionEvent) and content attributes (e.g. onwebkittransitionend)? On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard wrote: > Hi all, > > As you know I'm working on unprefixing CSS transitions and I need a > few advice from the DOM experts. > > Problem : CSS Transitions when they finish to animate send a DOM event > "transitionend" as specified there [1] to give the developer a notice > that the transition finished. Today WebKit sends the prefixed > counterpart "webkitTransitionEnd". Animations also have the same event > and few more. So today the problem is when we should send the prefixed > event and when we should send the unprefixed one, and if we should > send both. > > I think that sending both events will break content somewhere as JS > functions attached with addEventListener will be called two times. > > Sending only the unprefixed event will break WebKit-only content the > day we ship CSS Transitions unprefixed. I know they should not produce > WebKit only code but it's not the point of the discussion. > > A solution is to send the prefixed or the unprefixed event depending > if someone is listening to it or not. Let me explain. > > Let say there is a listener on the prefixed event only then we deliver > the prefixed event *only*. > > If there is a listener on the unprefixed event only we deliver the > unprefixed event *only*. > > If there are listeners on both events then we send the unprefixed one > *only* forcing people to rely on the unprefixed. > > It seems that this approach is an elegant one and allows us to remove > later in the future the support for prefixed transitions (including > the events). As a side note Opera is acting the same as the proposed > solution. > > Now obviously prefixed and unprefixed events in the DOM is something > new because it never happens in the past so we don't have support for > having such a mechanism for event delivery. > > I thought that we could somewhere in the Animation/Transition code be > smart and try to figure which event to send but it practically > impossible to access the EventListenerMap so I thought we could > support it somehow generically in the DOM events code. It will be > useful for the animations and maybe in the future (we're not really > sure if prefixed event will again show but who knows). > > So I did a first patch there [2] and I would like to gather feedback > whether the approach is correct (I don't know much the DOM related > code) or if somebody has a better idea on how to resolve the problem. > Also if I have missed something, please point it to me. The patch > doesn't include the support for HTML ontransitionend attribute which I > prefer to do in a later patch. > > Thanks. > > [1] > http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property > [2] https://bugs.webkit.org/show_bug.cgi?id=105647 > -- > Software Engineer @ > Intel Open Source Technology Center > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixed and prefixed DOM events.
I've been wondering about the implications of prefixed events. Do we have other examples of events that had prefixed names and were later unprefixed? In particular, what are the composition implications of your solution? When you say "depending if someone is listening to it or not" you mean whether there is a handler attached that will be triggered by this event, not whether there is a handler for that type of event anywhere on the page, right? Is it likely that existing code might put handlers on the document (eg. maybe as a sort of polling mechanism when there are many elements that may be involved in transitions?), and if so are we likely to have trouble with different libraries that used to co-exist peacefully in the same site no longer working together? The philosophy of "forcing" a site to update to the unprefixed name really only makes sense to me if you think of a site as a single application, not as a collection of separately maintained libraries and components. Rick On Fri, Jan 11, 2013 at 4:21 PM, Adam Barth wrote: > That does sound like a tricky problem. Your approach sounds > reasonable to me. If you like, we can use the FeatureObserver [1] to > estimate how often these various cases occur. > > Adam > > [1] > http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html > > > On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard wrote: > > Hi all, > > > > As you know I'm working on unprefixing CSS transitions and I need a > > few advice from the DOM experts. > > > > Problem : CSS Transitions when they finish to animate send a DOM event > > "transitionend" as specified there [1] to give the developer a notice > > that the transition finished. Today WebKit sends the prefixed > > counterpart "webkitTransitionEnd". Animations also have the same event > > and few more. So today the problem is when we should send the prefixed > > event and when we should send the unprefixed one, and if we should > > send both. > > > > I think that sending both events will break content somewhere as JS > > functions attached with addEventListener will be called two times. > > > > Sending only the unprefixed event will break WebKit-only content the > > day we ship CSS Transitions unprefixed. I know they should not produce > > WebKit only code but it's not the point of the discussion. > > > > A solution is to send the prefixed or the unprefixed event depending > > if someone is listening to it or not. Let me explain. > > > > Let say there is a listener on the prefixed event only then we deliver > > the prefixed event *only*. > > > > If there is a listener on the unprefixed event only we deliver the > > unprefixed event *only*. > > > > If there are listeners on both events then we send the unprefixed one > > *only* forcing people to rely on the unprefixed. > > > > It seems that this approach is an elegant one and allows us to remove > > later in the future the support for prefixed transitions (including > > the events). As a side note Opera is acting the same as the proposed > > solution. > > > > Now obviously prefixed and unprefixed events in the DOM is something > > new because it never happens in the past so we don't have support for > > having such a mechanism for event delivery. > > > > I thought that we could somewhere in the Animation/Transition code be > > smart and try to figure which event to send but it practically > > impossible to access the EventListenerMap so I thought we could > > support it somehow generically in the DOM events code. It will be > > useful for the animations and maybe in the future (we're not really > > sure if prefixed event will again show but who knows). > > > > So I did a first patch there [2] and I would like to gather feedback > > whether the approach is correct (I don't know much the DOM related > > code) or if somebody has a better idea on how to resolve the problem. > > Also if I have missed something, please point it to me. The patch > > doesn't include the support for HTML ontransitionend attribute which I > > prefer to do in a later patch. > > > > Thanks. > > > > [1] > http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property > > [2] https://bugs.webkit.org/show_bug.cgi?id=105647 > > -- > > Software Engineer @ > > Intel Open Source Technology Center > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Unprefixed and prefixed DOM events.
That does sound like a tricky problem. Your approach sounds reasonable to me. If you like, we can use the FeatureObserver [1] to estimate how often these various cases occur. Adam [1] http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard wrote: > Hi all, > > As you know I'm working on unprefixing CSS transitions and I need a > few advice from the DOM experts. > > Problem : CSS Transitions when they finish to animate send a DOM event > "transitionend" as specified there [1] to give the developer a notice > that the transition finished. Today WebKit sends the prefixed > counterpart "webkitTransitionEnd". Animations also have the same event > and few more. So today the problem is when we should send the prefixed > event and when we should send the unprefixed one, and if we should > send both. > > I think that sending both events will break content somewhere as JS > functions attached with addEventListener will be called two times. > > Sending only the unprefixed event will break WebKit-only content the > day we ship CSS Transitions unprefixed. I know they should not produce > WebKit only code but it's not the point of the discussion. > > A solution is to send the prefixed or the unprefixed event depending > if someone is listening to it or not. Let me explain. > > Let say there is a listener on the prefixed event only then we deliver > the prefixed event *only*. > > If there is a listener on the unprefixed event only we deliver the > unprefixed event *only*. > > If there are listeners on both events then we send the unprefixed one > *only* forcing people to rely on the unprefixed. > > It seems that this approach is an elegant one and allows us to remove > later in the future the support for prefixed transitions (including > the events). As a side note Opera is acting the same as the proposed > solution. > > Now obviously prefixed and unprefixed events in the DOM is something > new because it never happens in the past so we don't have support for > having such a mechanism for event delivery. > > I thought that we could somewhere in the Animation/Transition code be > smart and try to figure which event to send but it practically > impossible to access the EventListenerMap so I thought we could > support it somehow generically in the DOM events code. It will be > useful for the animations and maybe in the future (we're not really > sure if prefixed event will again show but who knows). > > So I did a first patch there [2] and I would like to gather feedback > whether the approach is correct (I don't know much the DOM related > code) or if somebody has a better idea on how to resolve the problem. > Also if I have missed something, please point it to me. The patch > doesn't include the support for HTML ontransitionend attribute which I > prefer to do in a later patch. > > Thanks. > > [1] http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property > [2] https://bugs.webkit.org/show_bug.cgi?id=105647 > -- > Software Engineer @ > Intel Open Source Technology Center > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unprefixed and prefixed DOM events.
Hi all, As you know I'm working on unprefixing CSS transitions and I need a few advice from the DOM experts. Problem : CSS Transitions when they finish to animate send a DOM event "transitionend" as specified there [1] to give the developer a notice that the transition finished. Today WebKit sends the prefixed counterpart "webkitTransitionEnd". Animations also have the same event and few more. So today the problem is when we should send the prefixed event and when we should send the unprefixed one, and if we should send both. I think that sending both events will break content somewhere as JS functions attached with addEventListener will be called two times. Sending only the unprefixed event will break WebKit-only content the day we ship CSS Transitions unprefixed. I know they should not produce WebKit only code but it's not the point of the discussion. A solution is to send the prefixed or the unprefixed event depending if someone is listening to it or not. Let me explain. Let say there is a listener on the prefixed event only then we deliver the prefixed event *only*. If there is a listener on the unprefixed event only we deliver the unprefixed event *only*. If there are listeners on both events then we send the unprefixed one *only* forcing people to rely on the unprefixed. It seems that this approach is an elegant one and allows us to remove later in the future the support for prefixed transitions (including the events). As a side note Opera is acting the same as the proposed solution. Now obviously prefixed and unprefixed events in the DOM is something new because it never happens in the past so we don't have support for having such a mechanism for event delivery. I thought that we could somewhere in the Animation/Transition code be smart and try to figure which event to send but it practically impossible to access the EventListenerMap so I thought we could support it somehow generically in the DOM events code. It will be useful for the animations and maybe in the future (we're not really sure if prefixed event will again show but who knows). So I did a first patch there [2] and I would like to gather feedback whether the approach is correct (I don't know much the DOM related code) or if somebody has a better idea on how to resolve the problem. Also if I have missed something, please point it to me. The patch doesn't include the support for HTML ontransitionend attribute which I prefer to do in a later patch. Thanks. [1] http://dev.w3.org/csswg/css3-transitions/#transition-shorthand-property [2] https://bugs.webkit.org/show_bug.cgi?id=105647 -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
