[webkit-dev] Unprefixed and prefixed DOM events.

Adam Barth abarth at webkit.org
Fri Jan 11 13:21:51 PST 2013

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.


[1] http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html

On Fri, Jan 11, 2013 at 11:30 AM, Alexis Menard <alexis at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

More information about the webkit-dev mailing list