Support flex CSS property better

[zpao]

Firs, it's unitless. I've seen a hack where the value is being specified as '1;' to make it pass the isNaN check and skip our adding of 'px'.

Further, flex is actually a shorthand property, so we should support the expansion into the right properties.

[sophiebits]

I don't think we need to do anything special for shorthand properties except for the list shorthandPropertyExpansions needed only for IE8.

[chenglou]

related: there are also some obscure css properties that can be unitless: http://stackoverflow.com/a/2130116
Edit: + widow, - counter-*

[sophiebits]

While we're at it, widows is also unitless. The counter properties mentioned in the above link don't actually take a single number.

[syranide]

@zpao @spicyj

I'm not saying it's a great idea, just putting it out there... but what if we switched over to widthPx: 5, fontSizeEm: 2.5, lineHeight: 1.2, lineHeightPx: 12, lineHeight: 12 + 'px', etc.

Not the prettiest, but perhaps prettier than fontSize: X + 'em' 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 px. 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 styleProcessor where we can supply our own behavior and leave all of this outside of React itself, if you want to auto-suffix px, use the addon. And this is a bad idea as well as it would prevent reliably sharing components.

---

lineHeight is currently ambiguous as it supports unitless and px and thus we cannot auto-suffix it...

[vjeux]

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.

[syranide]

@vjeux I agree, my only issue with that is that we would explicitly break with the CSS standard then.

[vjeux]

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.

[zpao]

It doesn't conflict today (probably never will but still). Also, do we now want to add lineHeightEm, lineHeightEx, lineHeightRem (and so on for each numeric unit)?

I think I'm more likely to go for forcing a unit if you want one. (eg, height: 12 doesn't get converted to height: 12px, you have to put the px in yourself).

[syranide]

@zpao 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 Em, Px 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 @vjeux 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.

[sophiebits]

Fixed by #861 -- we can discuss units more on a separate issue if needed.