<xul:label value="foo" /> uses a custom layout frame that can't really be replicated with HTML/CSS. <xul:label>foo</xul:label> is a Custom Element extending XULTextElement: https://searchfox.org/mozilla-central/rev/ea63a0888d406fae720cf24f4727d87569a8cab5/toolkit/content/widgets/text.js#43.

For the latter, I think we could expose the functionality (including access key underlining) to HTML using a mixin or helper functions.

It could be either something like:

customElements.define("moz-label",
 class extends MozElements.MozElementMixin(HTMLLabelElement) { },
 { extends: "label" });

// <html:label is="moz-label">

Or just a customized HTML element like

customElements.define("moz-label", class extends MozHTMLElement {});
// <html:moz-label>

Needs a bit of investigation, but this would unblock removing XUL labels (and maybe chrome priv) for some HTML UIs like about:addons (seee https://phabricator.services.mozilla.com/D53761).

I think <html:label is="moz-label"> would be preferable even if it is more verbose, since there is some a11y code linked to it.

I made a test HTML page with a ported version of xul:label which seems to work pretty well. We can't read the various prefs, so we'd need to choose defaults or have some other way to configure it to work in an unpriv environment, but something like this seems totally plausible for supporting the textContent variation of xul label.

This patch creates a custom element that extends the built-in label element to ad some custom styling and handling of accesskeys. This should align with the current functionality provided by the XUL label (which this code intetntionally copies and doesn't differ much from, since the XUL label is definitely battle tested).

More specifically, this patch:

• adds fallbacks/defaults for pref controlled values so this will mostly work as expected even in less privileged contexts (like about:logins, etc.)
• adds tests for the new label element
• creates a Storybook entry for the label element (note that activating the accesskey won't work as expected in Storybook, likely due to Bug 1819469)

We'll likely have to iterate on this a bit as we try to use it in all the places XUL label is currently used, but I think this is at a point where it can unblock the menu work happening in Bug 1801324.

This isn't a pressing need, but it helps us get around the browser_all_files_referenced test issue. Also you can set accesskeys on the toggles in about:preferences to see this working in the wild.

Just a small enhancement I noticed we can make to the tooling, which should also help if we try to document custom elements outside of toolkit/widgets.

https://hg.mozilla.org/mozilla-central/rev/7fa77779a5f2
https://hg.mozilla.org/mozilla-central/rev/0072b22733a2
https://hg.mozilla.org/mozilla-central/rev/8366b28600de