and make use of the FRC `elementWrapperClassName`, since they way we did it before – custom `className` strings on the element – was not working. Fixes#749.
It appears that the `required` field is not applied in the way we'd like it to be for the custom checkbox group and custom phone input fields, so do a `required` check on form submission. Additionally, this adds in a few style fixes. Fixes#695, #694, #693, #691
From review of the style with @carljbowman
Requires a bit of magic, where the Form component manually adds the "all" value. But without a major overhaul of the validation system, I don't see how else to put the general error among the other fields.
/cc @carljbowman
One issue we ran into is that our `frameless` configuration is in `em` rather than `rem`, making it difficult to have an aboslute grid applied uniformly at all hierarchies. For now, we're using straight `rem` calculations instead of `$cols{1,8}` in the styling until we can refactor `frameless` to use `em`.
# By Ray Schamp
# Via Andrew Sliwinski (2) and Ray Schamp (2)
* 'develop' of https://github.com/LLK/scratch-www:
Fix GH-168: Rehabilitate the `Modal` props.style
Fix GH-162: Show "user deletion canceled" modal
Clean up activity item rendering logic
Add some padding to the empty message
Make sure boxes aren't transparent
Add empty state for What's Happening box
# Conflicts:
# src/components/registration/registration.jsx
Only attach the message listener when the modal is displaying. This prevents multiple listeners being set up by multiple registration components on the page.
Also, scope the `onMessage` handler to that component's iframe, so that we don't respond to other component's messages.
This makes it more sane, and consistent with the way the react-modal `Modal` works. The old way made multiple modals on the page have the same `style` prop.
