[webkit-dev] Unprefixed and prefixed DOM events.

Rick Byers rbyers at chromium.org
Sat Jan 12 15:42:12 PST 2013


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 <abarth at 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 <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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130112/b7029eb3/attachment.html>


More information about the webkit-dev mailing list