[webkit-dev] Unprefixed and prefixed DOM events.

Rick Byers rbyers at chromium.org
Mon Jan 14 07:10:32 PST 2013 

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

> On Mon, Jan 14, 2013 at 11:30 AM, Rick Byers <rbyers at chromium.org> wrote:
> > 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?
>
> 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 <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
> >
> >
>
>
>
> --
> Software Engineer @
> Intel Open Source Technology Center
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130114/e33e7bcc/attachment-0001.html>

More information about the webkit-dev mailing list