Skip to main content

Bug Tracker

Side navigation

#7900 closed enhancement (wontfix)

Opened January 05, 2011 04:05AM UTC

Closed February 09, 2011 06:25PM UTC

Create and document interface to jQuery.event.props

Reported by: boaz Owned by: boaz
Priority: low Milestone: 1.6
Component: event Version: 1.4.4
Keywords: Cc:
Blocked by: Blocking:

jQuery.event.props maintains a list of properties to copy to the jQuery event object. This is done for efficiency reasons, so that only the necessary properties for jQuery to perform common tasks.

Sometimes, however, a jQuery developer will want to use jQuery to bind to a native event that has an uncommon property, like the dataTransfer property available in the callback of a drop event.

Currently, developers have to manually push such a property onto jQuery.event.props. This is not ideal, because this makes code rely on internal structures that may change in the future.

Even if the the event copying system does not change over time, it is not good practice for jQuery developers to be accessing internal structures within jQuery.

Therefore, jQuery should create and document a public interface for developers to manipulate this list.

Attachments (0)
Change History (7)

Changed January 05, 2011 04:50AM UTC by ajpiano comment:1

component: unfiledevent


Providing documented interfaces to underlying internals that are subject to change is probably a good approach to solving this and other similar problems.

Changed January 05, 2011 04:47PM UTC by rwaldron comment:2

Related to #7808

Changed January 18, 2011 01:43PM UTC by rwaldron comment:3

priority: undecidedhigh

Changed February 01, 2011 12:24AM UTC by snover comment:4

owner: → boaz
status: newpending

I’m confused. jQuery.event.props is documented at as a mechanism for doing this, as is the originalEvent property. Is that an insufficient mechanism?

Changed February 01, 2011 12:38AM UTC by boaz comment:5

status: pendingnew

I did not see that documentation at the time of posting.

I think that this architecture should be documented in an "internals documentation", and that users should be encouraged to use a setter API for interacting with it in production code.

Accessing an internal property directly is a precarious API. Given the changing landscape of the Document API, a setter interface should be used for adding properties to the jQuery.event.props.

Changed February 06, 2011 03:50PM UTC by snover comment:6

priority: highlow

Well, I guess my point is that this is no longer an internal data structure since it is documented on the api site, and as such is not subject to change without a long and laborious process of deprecation and so on and so forth. originalEvent is *certainly* not going to change or go away in any case.

I’m also not sure what the benefit of creating an entirely new interface for this would be, since it is pretty edge-casey (not a lot of people are wanting to retrieve arbitrary event object properties like this); I would think it makes more sense to just add any new and useful HTML5 event properties to the default list of props instead.

Changed February 09, 2011 06:25PM UTC by rwaldron comment:7

resolution: → wontfix
status: newclosed