[webkit-dev] Unprefixed and prefixed DOM events.

Mon Jan 14 06:30:34 PST 2013

On Mon, Jan 14, 2013 at 6:19 AM, Alexis Menard <alexis at webkit.org> wrote:

> On Sat, Jan 12, 2013 at 8:42 PM, Rick Byers <rbyers at 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?

> > 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 <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
> >
> >
>
>
>
> --
> Software Engineer @
> Intel Open Source Technology Center
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130114/82612d5e/attachment.html>