Fixing this is messier than I'd like because we have a unit test making some pretty crazy assertions. I'm not certain that aliasing one standard CSS property to another was the intended use case but that's what we're up against. Just a thought for 4.0.0, do we even need the mapping to vendor-specific properties at that point?

@dmethvin The unit test is just checking the mapping, I wouldn't expect anyone in real life aliasing top to left.

We need the mapping to cache vendor prefixed values which are still used by browsers, although not really for new APIs. There are lots of prefixed properties in IE 9+ and I think it's useful we handle it for users.

What we could do is to introduce another internal object that would be consulted if there is no match in jQuery.cssProps; we'd write vendor-prop resolved values to this separate object. This would influence the size slightly negatively but hopefully not too much?

Another solution: IIRC Migrate used to differentiate between user calls & jQuery internal ones by setting a certain flag at the beginning of a method that uses the deprecated thing and resetting it at the end (I don't remember what it was). Wouldn't something like that work here?