Issue #5: Add radio group component.

[jcfranco]

Related Issue: #5

This adds the RadioGroup and RadioGroupItem components.

API

interface CalciteRadioGroup {
  name: string;
  selectedItem: CalciteRadioGroupItem | null;
  theme: "light" | "dark";

  // events
  calciteRadioGroupChange: EventEmitter;
}

interface CalciteRadioGroupItem {
  checked: boolean;
  value: any;

  // events - internal
  calciteRadioGroupItemChange: EventEmitter;
}

// CSS vars
--calcite-radio-group-color
--calcite-radio-group-color-hover
--calcite-radio-group-color-active
--calcite-radio-group-border-color
--calcite-radio-group-text-color
--calcite-radio-group-text-color-active

Questions

• Since item components are not meant to be used outside, would it be cleaner to hide the internal event and rename the group's event to calciteRadioGroupChange? Changed to calciteRadioGroupChange.
• Would selected instead of checked be a better fit since there's no visual checkmark in this design?
• Can I get some feedback on the public CSS vars? Do we need fewer/more?

Notes

• Has some placeholder styles for the dark theme. @julio8a Could you tweak?
• Complies w/ https://www.w3.org/TR/wai-aria-practices-1.1/#radiobutton with the following exceptions:
  • Labeling of <calcite-radio-group> is left to users (via aria-labelledby or <label>). Alternatively, we could introduce <calcite-radio-group-title>, design permitting.
  • No handling of For Radio Group Contained in a Toolbar section.
• Uses hidden input for form compatibility.
• Calling focus() on the group component does not work as expected. I'll create a separate issue for this.

[paulcpederson]

I like how you've broken up the tests into sections 👌

[paulcpederson]

@jcfranco if you use npm run build it should generate the markdown docs for your component if you'd like those to be part of this pull request.

[paulcpederson]

Also, you asked for feedback on css vars: I am not totally sure what our strategy should be. In loader and slider I just gave devs enough to change the main branded color (ie. change blue to green) but didn't open up the various neutrals/grays for customization. My thought is that by far the most common thing most people will want to do is change the active color to their branded color. I don't think we should allow devs to completely override all the colors of a component, but maybe we should?

We could also have a css var that operates library-wide, allowing people to theme these components really easily by setting the one spot color to their branded color and having it cascade all the way through the components.

[driskull]

👍

[paulcpederson]

@jcfranco I just noticed that the external inputs appear in the tab order, even though they are hidden.

[jcfranco]

@paulcpederson On it!

[jcfranco]

@paulcpederson Fixed. The external inputs were still being rendered in the DOM.

[jcfranco]

• Updated vars and colors (both light and dark)
• Renamed calciteRadioGroupItemSelect to calciteRadioGroupChange.