Form-associated custom elements and interactive content

[domenic]

Similar to #5414 (about tabindex="0" and interactive content) but with less compat constraints.

Currently in the spec and in Chromium form-associated custom elements are not treated as interactive content. This is observable in how they affect <label> elements. See demo at https://boom-bath.glitch.me/face-interactive-content.html .

I think we should change the spec and Chromium, and add some tests, to fix this.

Thoughts, @TimothyGu @tkent-google @whatwg/components @whatwg/forms?

[domenic]

Hmm, I'm having second thoughts. Maybe this should be a separate toggle, not automatic with form-associated custom elements?

I noticed the following elements are form-associated but not interactive content:

• fieldset
• input with type="hidden"
• object without usemap=""
• output
• img without usemap=""

If we said that form-associated custom elements are automatically interactive content, then this would mean form-associated custom elements cannot emulate the behavior of elements like the above.

Maybe we should leave interactive content-or-not for WICG/webcomponents#762.

[zcorpan]

This is observable in how they affect <label> elements.

No. But labelable elements is observable from <label>.

If a form-associated element is also listed, it can show up in the form.elements API.

img is only form-associated so it can be accessed using form.imgNameOrId API, for compat. See:

44e3160
https://html.spec.whatwg.org/multipage/forms.html#the-form-element:supported-property-names

[domenic]

No. But labelable elements is observable from <label>.

Yes? Whether something is interactive contact or not observes how the element interacts with label's activation behavior. See #5414 for a recent instance where this is important.

[zcorpan]

Oh, I see. Sorry, I thought you were talking about what could be the label's control. I see this now:

The label element's exact default presentation and behavior, in particular what its activation behavior might be, if anything, should match the platform's label behavior. The activation behavior of a label element for events targeted at interactive content descendants of a label element, and any descendants of those interactive content descendants, must be to do nothing.

[zcorpan]

Having understood this issue better now, I agree with your second comment that interactive content shouldn't be implied by being form-associated.

Are there cases of form-associated custom elements that you think should be interactive content but wouldn't also be focusable?

[domenic]

I think anything wanting to emulate <fieldset>, <input type="hidden">, or <output> probably belong in that category.

[zcorpan]

They are not interactive content, though.

[tkent-google]

I wonder if changing 'descendant' to 'shadow-including descendant' is enough.

https://html.spec.whatwg.org/C/#the-label-element:activation-behaviour-2

The activation behavior of a label element for events targeted at interactive content descendants of a label element, and any descendants of those interactive content descendants, must be to do nothing.

[domenic]

They are not interactive content, though.

Oh, oops, you are right. OK, answering your actual question:

Are there cases of form-associated custom elements that you think should be interactive content but wouldn't also be focusable?

In the spec sense of "focusable", i.e. programmatically focusable, I can think of no such cases. (Note: they may not necessarily be sequentially or click focusable, especially on macOS.)

The spec doesn't currently enforce this relationship, since it leaves the question of what is focusable entirely up to the browser, but I think it's safe to say that the relationship must hold for custom elements. And perhaps we should even enforce the relationship for browsers too.

I wonder if changing 'descendant' to 'shadow-including descendant' is enough.

This seems like a separate issue from what's being discussed here, about form-associated custom elements. E.g., it wouldn't impact https://boom-bath.glitch.me/face-interactive-content.html.

But, we probably should consider changing it in the way you describe, as a separate fix.

[zcorpan]

OK so, if a custom element is both form-associated and focusable (because it has tabindex or otherwise), it seems reasonable to include it in "interactive content" and "labelable" categories, so it works right with <label>.

Right now all form-associated custom elements are "labelable" per spec afaict. Since there are native form-associated elements that aren't labelable, maybe they shouldn't be labelable when they aren't focusable (e.g. for custom-output or custom-fieldset).

[zcorpan]

Hmm, wait output is not focusable but is labelable. Same with progress and meter, which aren't form-associated. If we want to allow custom variants of these, labelable would need to be able to be set even if it's not form-associated or focusable. But the common case for labelable seems like form-associated and focusable, so they could still implicitly set labelable I think. The common case should be easy, folks have trouble using label at all.

[clshortfuse]

I'm currently tapping into FACE for the purpose of making a psuedo <fieldset> for my card components. With [inert], the usage is "good enough".

Given the following tree:

<x-card inert={disabled}>
  <slot>
    <x-button>Go</x-button>
  <slot>
</x-card>

The x-button will not inherit, disabled state but will be inert and tabskipped. Caveat is that those form elements didn't technically get disabled and will appear in forms.

[zcorpan]

So FACEs are already labelable, but not interactive. Making them also always interactive seems like it would solve this issue (except for progress and meter custom element variants).

[zcorpan]

I missed #5423 (comment)

Maybe allow an override, but make FACEs interactive by default?

[clshortfuse]

I wonder if whatever solution is devised (eg: :focusable) would link up with delegatesFocus. In other words, non-FACE that use delegatesFocus should probably get the same "interactive content" treatment.

Side note: delegatesFocus + :disabled + FACE has some vagueness that can be clarified. Firefox recently fixed a bug related to events not firing. Something clearer in spec could be useful.

[keithamus]

WCCG had their spring F2F in which this was discussed. You can read the full notes of the discussion (WICG/webcomponents#978 (comment)), heading entitled "Enhancements to Form-Associated Custom Elements".

The discussion concluded with present members of WCCG feeling as though FACEs should be labellable (and already are, per-spec), but interactivity will need changes to specification.