RFC(web-components): Shorthand components for complex field assemblies?

[davatron5000]

As part of the rollout of elementInternals the shape of our form field API has become a bit more verbose. Here's an example I came across...

BEFORE:

<fluent-radio-group>
  <fluent-label slot="label">Please select an option</fluent-label>
  <fluent-radio value="1">Option 1</fluent-radio>
  <fluent-radio value="2">Option 2</fluent-radio>
  <fluent-radio value="3">Option 3</fluent-radio>
</fluent-radio-group>

AFTER:

<fluent-field>
  <label slot="label">Please select an option</label>
  <fluent-radio-group id="demo-options" slot="input" orientation="vertical">
    <fluent-field label-position="after">
      <label for="option-one" slot="label">Option 1</label>
      <fluent-radio id="option-one" slot="input" name="demo-options" value="1"></fluent-radio>
    </fluent-field>
    <fluent-field label-position="after">
      <label for="option-two" slot="label">Option 2</label>
      <fluent-radio id="option-two" slot="input" name="demo-options" value="2"></fluent-radio>
    </fluent-field>
    <fluent-field label-position="after">
      <label for="option-three" slot="label">Option 3</label>
      <fluent-radio id="option-three" slot="input" name="demo-options" value="3"></fluent-radio>
    </fluent-field>
  </fluent-radio-group>
</fluent-field>

I 100% agree with the decision to leverage Field and native <label> elements (as a workaround for the platform limitations with labels). I feel that design is correct, but the authoring experience suffers a bit and creates a lot more work and manual wiring of fields, labels and IDs. It would be nice if we could provide some of these higher level authoring experiences that "generate" the <fluent-field> code behind the scenes in the Shadow DOM.

SOFT PROPOSAL:

<spicy-radios
    id="form-field-id" 
    orientation="vertical|horizontal" 
    label-position="top|bottom|before|after"
>
  <label slot="label">Please select an option</label>
  <fluent-radio value="1">Option 1</fluent-radio>
  <fluent-radio value="2">Option 2</fluent-radio>
  <fluent-radio value="3">Option 3</fluent-radio>
</spicy-radios>

QUESTIONS:

1. Is this a good idea? Bad idea?
2. Is this a different project?
3. Any risks we should consider?

[marchbox]

Maybe a new element, e.g. <fluent-radio-field slot="input" value="1">Option 1</fluent-radio-field> as a shorthand for:

<fluent-field label-position="after">
  <label for="option-one" slot="label">Option 1</label>
  <fluent-radio id="option-one" slot="input" name="demo-options" value="1"></fluent-radio>
</fluent-field>

and generate the longhand structure in the light DOM?

[eljefe223]

In this example does fluent-radio-field replace fluent-radio-group? If so is the only distinction between the two is that fluent-radio-field has label slot and fluent-radio-group does not?

[marchbox]

Ah, you are right. My example should've been:

<fluent-field>
  <label slot="label">Select an option</label>
  <fluent-radio-group slot="input">
    <fluent-radio-field value="1">Option 1</fluent-radio>
    <fluent-radio-field value="2">Option 2</fluent-radio>
    <fluent-radio-field value="3">Option 3</fluent-radio>
  </fluent-radio-group>
</fluent-field>

Basically the same structure as the new way, but using <fluent-radio-field> as a "placeholder" to add the full structure in the light DOM to save some manual author works.

[marchbox]

Double posting here:

I know I proposed it before but now (especially after working on Dropdown/DropdownList) I think it may not be a good idea for a custom element to update the light DOM/author code. Updating light DOM to decorate the author content into a component-ready structure is how we used to do JS-required UI components (all the old carousels components), but I think web components/custom elements gave HTML components a new paradigm (components now could work the same way as built-in elements, which don't change author code), and my concern of changing light DOM is more around mixing these 2 paradigms can negatively impact the usability of the library for authors (both paradigms are valid, but maybe not when they are mixed together), e.g. if an author expects all components behave the same (as they should), they may want to do some DOM manipulation on the custom elements without knowing the DOM may change.

[davatron5000]

if an author expects all components behave the same (as they should), they may want to do some DOM manipulation on the custom elements without knowing the DOM may change.

Is this just a documentation fix to me? And there's nothing really stopping someone from manipulating an open shadowroot either. Maybe I'm not able to come up with a good example in my head of where someone would need to do this (in a form control or Dropdown)

I think here (and elsewhere in form controls) we should be open to the option of using Light DOM components at least until referencetarget is widely available.

[marchbox]

Is this just a documentation fix to me?

We can document. But I often find a library is easy to use because it's consistent and predictable, e.g. after you learn how to use one component, the other components work somewhat the same. For example, many of Fluent components share the appearance, size, block, etc. attributes.

And there's nothing really stopping someone from manipulating an open shadowroot either.

Technically no. But from an API standpoint, the shadow root is part of the private API, if author choose to touch it, we are not responsible to their usage. With that said, we do need to improve our current documentation, e.g. we currently don't have CSS Parts, slots, or events documented.

I think here (and elsewhere in form controls) we should be open to the option of using Light DOM components at least until referencetarget is widely available.

I'm personally going back and forth on this. I feel part of my struggle comes from the incompleteness of the current custom element API. But also, if as a library, we embrace using Light DOM fully, I'm all for that. I'm just a bit skeptical about mixing both.