On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers <[email protected]> wrote: > On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard <[email protected]> wrote: >> >> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >> 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 >> >> > [email protected] >> >> > http://lists.webkit.org/mailman/listinfo/webkit-dev >> >> _______________________________________________ >> >> webkit-dev mailing list >> >> [email protected] >> >> http://lists.webkit.org/mailman/listinfo/webkit-dev >> > >> > >> >> >> >> -- >> Software Engineer @ >> Intel Open Source Technology Center > > -- Software Engineer @ Intel Open Source Technology Center _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
