[webkit-dev] Unprefixed and prefixed DOM events.

Alexis Menard alexis at webkit.org
Mon Jan 14 06:56:27 PST 2013 

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.

>
>>
>> > 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

More information about the webkit-dev mailing list