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