Text field component enhancements

[robertknight]

This brings the implementation of the text field component closer to the Polymer Paper elements version:

• Make the floating label color match the focused underline color when focused
• Implement the 'spill from point of interaction' effect when the field gains focus
• Implement the cursor block move & collapse animation when the field gains focus

I have a few general questions/thoughts:

• The material design specs specify pixel sizes very precisely. The styling in the Polymer Paper Elements components however seems to make more use of em rather than px-based units, presumably so that the controls still work at non-default sizes. I've changed some parts of the CSS to work more like the Polymer implementations. This has the upside that the components could work better at different font sizes. The downside is that it isn't so easy to verify that the implementation matches the material design specs just reading the code.
• What is the best way to allow clients to attach event handlers etc. to the input field in the same way they would if using directly? Ideally it would be useful if clients could treat the component as an extension of the field, similar to the Polymer <paper-input> control.
• What is the best way to support component-specific theming? eg. To set the label and focus colors. One approach might be to mirror the theming options provided by the corresponding Polymer component (eg. https://www.polymer-project.org/docs/elements/paper-elements.html#paper-input-decorator) but exposed via props.theme.
• Coding style - Do you have a preferred linter or tool and config for formatting code?

[robertknight]

The animations are working on mobile but the Polymer ones are smoother. Couple of things I notice from their code: 1) They are animating via translate3d() and scale3d() transforms rather than animating the font size and width. 2) They cache the transform for a field just before applying it for the first time. I don't know how important that is.

[SanderSpies]

Wow, animating from the mousedown position makes a ton of difference for this animation (certain others do this always from the center position). Looks nice!

1. I don't think we should use em, for now it's rather unclear where all the elements end up - and that could have unpredictable consequences. I would prefer to use rem with a fallback to px (IE8, although not TOO important). Also using constants could help with making it simpler.
2. passing events should be good enough in general, might need some changes in some cases where it makes sense. There should be an "escape-hatch" to access the DOM input element directly.
3. there is the idea to create a mixin within React Style which allows to do styles={{this.props.styles, somethingElse.styles]} which would solve the theming issues. Could be something for after the upcoming 0.4 release of React Style.
4. preferably Closure Compiler Linter Strict mode - but our current coverage is rather bad :-( The idea is to have react-material eventually building using Closure Compiler Advanced Mode.
5. mobile is definitely priority number 1 - so if we could improve there, that would be great.

PR looks like a good improvement, further improvements can be build upon this code.

[SanderSpies]

FYI. the upcoming react-style 0.4 will drop support for pseudo-classes, which is explained here: https://github.com/js-next/react-style/blob/0.4/CHANGES.md.