Code change:
Firs, it's unitless. I've seen a hack where the value is being specified as to make it pass the check and skip our adding of 'px'. Further, is actually a shorthand property, so we should support the expansion into the right properties.
I don't think we need to do anything special for shorthand properties except for the list needed only for IE8.
related: there are also some obscure css properties that can be unitless: Edit: + widow, - counter-*
While we're at it, is also unitless. The properties mentioned in the above link don't actually take a single number.
I'm not saying it's a great idea, just putting it out there... but what if we switched over to , , , , , etc. Not the prettiest, but perhaps prettier than and you can now access unmodified traditional CSS behavior and if you want to use the short-hand style, it's obvious and unambiguous, and not limited to just . It doesn't modify expected behavior, it doesn't conflict... philosophically that's up to you. :) ...speaking with people in the chat, I agree that it's a bad idea... however, seeing other peoples gripes with how React doesn't vendor-prefix, etc, etc. Perhaps the real solution is for React to export a settable where we can supply our own behavior and leave all of this outside of React itself, if you want to auto-suffix , use the addon. And this is a bad idea as well as it would prevent reliably sharing components. is currently ambiguous as it supports unitless and and thus we cannot auto-suffix it...
line-height 'px' is used 15x-50x more times than unitless, em or percentage on fb codebase. I feel like this should be the default and we should provide a more verbose way to use it in an unitless way.
I agree, my only issue with that is that we would explicitly break with the CSS standard then.
My view on this is that the CSS standard is only using strings. So if you say '1.5', React is just going to output '1.5'. Now if you say 23 (the number), then React is going to be able to add any convenience it wants, such as adding 'px' as it's the most common use case.
It doesn't conflict today (probably never will but still). Also, do we now want to add , , (and so on for each numeric unit)? I think I'm more likely to go for forcing a unit if you want one. (eg, doesn't get converted to , you have to put the in yourself).
My idea with having the units as a suffix of the name is that it could be a universal test for all properties (for simplicity). If , or whatever is at the end the property name, we remove it and add it to the value instead. That way the only thing we would need to hard-code is which units are allowed, so the implementation would be minimal and barring any new units, future proof. While it theoretically could conflict, I don't see how it ever could, the units have very non-wordy names (case would obviously be taken into account as it already is). However, a practical issue is what to do if there are multiple units specified for the same property. So I definitely see that this may not be the favored way to go, just putting it out there :) I like idea, but I feel like it would be hair thin separation of the two and possibly "dangerous"... but it is neat, and likely what the user intended.
Fixed by -- we can discuss units more on a separate issue if needed.

Related discussion:
text: * CSS properties which accept numbers but are not in units of "px". */ var isUnitlessNumber = { <ins> columnCount: true, </ins> fillOpacity: true, <ins> flex: true, flexGrow: true, flexShrink: true, </ins> fontWeight: true, lineHeight: true, opacity: true, <ins> order: true, </ins> orphans: true, <ins> pitchRange: true, richness: true, stress: true, volume: true, widows: true, </ins> zIndex: true, zoom: true };