Remove ALL special meanings of "." in keys for $.fn.data

[Darsain]

$.fn.data() doesn't behave the same way how $.data() does when using a key namespacing.

Example: if you have a data key "name.key" and it doesn't exist, the $.fn.data() will return the "name" key instead, while $.data() returns undefined, which is what I'd expect to get

Test: ​http://jsfiddle.net/pNCP8/3/ (test is for 1.6.4, but 1.7b2 has the same issue)

Fix:

@@ -1943,9 +1943,7 @@
 				data = dataAttr( this[0], key, data );
 			}
 
-			return data === undefined && parts[1] ?
-				this.data( parts[0] ) :
-				data;
+			return data;
 
 		} else {
 			return this.each(function() {

Now, since I see that it is deliberately coded that way, I don't know if this is a bug, or a "feature". I've asked on #jquery-dev, but after a few hours of no reply I'm just posting it here. In case of a "feature" decision, I'd like to know the resoning behind it :)

[addyosmani]

Our docs don't appear to state whether or not namespaced keys are officially supported, but let me find out and I'll post back on this ticket (unless someone is able to answer before that).

[addyosmani]

Confirmed with @gnarf that this is a bug. CC'ing DaveMethvin for further input.

[gnarf]

Actualy, seems I was wrong about it being a bug... I'm not sure WHY we are doing this, but it is a unit tested feature:

Unit tests are here:

​https://github.com/jquery/jquery/blob/f2c1d2e016018ba14cd3f1612f9a1803d5e1709e/test/unit/data.js#L246-283

I can't seem to find the trac ticket that details this feature.

It is currently not documented, so we should document it if we plan on keeping it around. I'm not sure how many people are using it.

Personally, I don't think we should be supporting "namespaced" data

[gnarf]

After a discussion in IRC with timmy and dave, we have tentatively decided that the potential for dependency on this behavior is quite high, especially considering this behavior extends as far back as jQuery 1.2.6: ​http://jsfiddle.net/gnarf/pNCP8/4/ We also agree that this behavior is broken, and should be removed.

Our current strategy is to mark this "namespaced data" and the special meaning the dot has in the getData and setData events as deprecated as of 1.7. We will document the current (deprecated) behavior - and then set it up for removal in 1.8.

[gnarf]

As a workaround for the OP of this bug ticket. You can always get your key via .data()["foo.bar"]

[addyosmani]

Following a further discussion on IRC, it appears that we *may* opt to add a notice about this being deprecated in the 1.7 release post as opposed to having it mentioned in the docs. Given that the behaviour we have now was never documented, this probably makes the most sense.

Something along the lines of 'Using data keys that have a "." in them in jQuery 1.7 and below can cause some strange behaviors. These strange behaviors are being deprecated and will be removed in 1.8.' with specific references to namespacing if we want to be technically correct :)

JohnResig had some further concerns with this which may be mentioned at the next -meeting. Will update if the resolution changes.

[dmethvin]

We're deprecating data events in 1.8 and removing them in 1.9 so this will sort itself out naturally.

[dmethvin]

To be removed in 1.9 when data events die of natural causes. They were never documented so they don't need to be un-documented.

[Dave Methvin]

Fix #10544. Remove deprecated .data() event namespaced triggering.

Data events were horribly slow, never documented, and caused strange interpretation of data items with dots in them.

Changeset: e8cf41a051a62bf1f19beab1a5c1d643f121e28e