Adds input styles

[helrond]

Adds styles for checkboxes, selects, text and textarea inputs.

Along with other general review, a couple of things came up when pulling this together:

• In DIMES, we've used a custom HTML element which is styled to look like a select, but is really a button with a ul. Do we want to use the HTML select element, or do we want to go with a more custom approach across the board? On library.rockarch.org we opted for the select element. The implication here is that it's not possible to style the select options.
• These questions are also noted in the change tracking document, but there are some fundamental decisions we need to make about default HTML structure and display of inputs and labels:
  • Should inputs be wrapped in a div? This would allow us to treat a label and an input as a unit, but it does add another HTML element to the page.
  • Should inputs take up the full width of their parent element by default, and should input labels stack on top of inputs by default? This is related to the above question.

fixes #58 fixes #65 fixes #69

[HaSistrunk]

1. custom select: I was just reading this article on native v. custom select inputs by Sarah Higley, which is useful context and I think this may be an important guiding thought:

While pure aesthetic preference is a common reason to roll a custom select component, it is not a good reason. Accessibility and usability should drive aesthetic choices, not the reverse. So many accessibility tradeoffs are involved in a custom solution that there must be a correspondingly strong reason to need one; “it should look prettier” just ain’t it.

2. I would vote yes, let's standardize labels stacking on top of inputs. I'm not sure about taking up the full width of the parent element by default, though. The selects and checkboxes don't generally do this in our implementation, right?

[HaSistrunk]

One other thing:

• I'm noticing it's difficult to quickly distinguish which checkbox goes with which label in the grouped checkboxes. can we add some space between the label and the checkbox to its right that is not associated? OR these could be vertical instead of horizontal.

[helrond]

Hold on I still need to do the thing with labels.

[helrond]

OK, so in 001f82b I have added a width of 100% to selects, inputs, and textareas. This means that the labels will sit on top of those inputs, BUT it also means that the inputs will expand to fill the full width of their parent element. I think this will likely require some HTML changes in existing sites, and may not be as flexible as we'd like (for example if we want inline forms), but a more flexible approach would (I think) require a wrapping div.

[bonniegee]

Not sure if other folks think this is an issue, but the text seems to be slightly lower than the checkboxes in the grouped checkboxes:

[helrond]

Grrr, the joys and perils of flexbox.

I'm struggling a little bit with this checkbox group because, as far as I know, we don't actually have this implemented anywhere, so it feels weird to make this "look right" in isolation of knowing what the actual application is.

[HaSistrunk]

Yeah. Actually, you prompted me to wonder if we should be using fieldset groupings for the dimes filters:

Maybe that's a model to base this on?

[helrond]

OK, so what I've done here is add a wrapper to checkboxes, which improves alignment of the label and the checkbox across multiple layouts. As per @HaSistrunk's suggestion, I've also styled the fieldset element so it more closely matches the facets in DIMES.

[HaSistrunk]

Awesome.

And regarding the width of 100% on selects, inputs, and textareas, I'm good with that although I admit I don't have a good sense yet of how much we'll have to change existing sites when we implement, and if the lack of flexibility is going to be a barrier.