I'd be interested to see how big the whitelist would be, but I like the idea.

I'd be interested to see how big the whitelist would be, but I like the idea.

Yeah, i guess that is the key, what list would be bigger.

This is a mess, we're adding more & more stuff to this array and it'll always be a problem as CSS is expanding.

The same argument could be applied to the whitelist too :/

Not exactly the same as:

1. As I mentioned, if sth is not on a whitelist, 'px' would not be auto-appended which is trivial to fix - just append 'px' by yourself. If, on the other hand, it's erroneously appended, the fix is not that simple: one has to first figure out jQuery is appending 'px', one has to discover the blacklist is modifiable at jQuery.cssNumber and one has to modify the jQuery global state by appending the property name to this array. This is a much bigger mental overhead.
2. I'd like to not list all the properties that don't accept bare numbers but only a few popular ones, just to avoid the biggest breakages. I'm basically treating this "feature" as a mis-feature and keeping back compat only as little as necessary so that all hell doesn't break loose. In the future we might even drop this whole "feature" completely.

Sounds reasonable, although, i don't think we had a lot of issues with that list, there isn't a lot of those properties, burden that we have to update it once in a while.

So i think whitelist strategy would be easier for the user to fix, as you said, but there should be a lot of widely used items in it, otherwise if not, it might confuse a lot of people.

In the future we might even drop this whole "feature" completely.

I suppose that is a different topic

Bottom line for me - i agree on the whitelist sounding more cool but only if it would be sufficient enough that it wouldn't cause the confusion and wouldn't affect the size too much.

I suppose that is a different topic

The decision if we want to drop it is a separate topic but for me it's slightly related because if you treat this as a mis-feature, you start thinking about it in terms of how can we restrict it while not breaking 90% of the code. If you think of it as about a nice feature, you might want to have the list comprehensive.

My first approximation would be to take top, bottom, left, right, width, height and they all prepended by anything ending with a dash (like margin-bottom or border-top-width). We might want to include some of the other popular ones like font-size but I'd like to try to narrow this list down as much as possible.

Because it sounds like a little experiment, though, we might want to wait with that for the first 4.0.0 alpha so it'll take a while.

Thoughts?

I'd like to not list all the properties that don't accept bare numbers but only a few popular ones, just to avoid the biggest breakages. I'm basically treating this "feature" as a mis-feature and keeping back compat only as little as necessary so that all hell doesn't break loose. In the future we might even drop this whole "feature" completely.

This is similar to the browser strategy as well (e.g., note that elem.style.fontSize = "12" works but elem.style.outlineWidth = "12" does not, although things get dicey with detached elements).

But there may be a way for us to eat our cake and have it too: we could set and immediately read back inbound CSS numbers on the style of a private element... any property that preserves the number goes on the "px" blacklist (which might be empty initially or might contain only lineHeight, since AFAIK no other property accepts both <length> and <number> values). And anyone who doesn't like it can follow best practices by providing strings (with units where applicable) instead of numbers.

That said, I do feel like this is a misfeature, and would be open to cutting it off.

I also like the idea of eliminating the blacklist for .css() and making it so people provide units with some sort of backfill for high-profile cases that break. I don't know how much breakage this will cause but we could deprecate as of 3.0 and have Migrate start warning on it. We should try to keep the whitelist small and only big enough to avoid massive breakage if there is any.

Methods such as .width() or .outerHeight() should still return and accept numbers without units so they can round-trip, but that shouldn't be a problem. Just doing that may avoid most problems.

Next step is to see a PR, but this will probably be 4.0.