I'd like to document an investigation of moving away from XBL and to Custom Element for UI widgets in the preferences page (things like labels, checkboxes, groupbox, caption, etc).

Custom Elements support hasn't landed natively yet, so I've modified the (Custom Elements polyfill)[https://github.com/webcomponents/custom-elements] to work inside of XUL documents: https://github.com/webcomponents/custom-elements/compare/master...bgrins:firefox-browser-chrome?expand=1. There's an open question about whether we should even attempt to do this in a XUL document, but at least for a prototype this has the advantage of allowing us to swap out one element at a time instead of all at once (since many of our XBL bindings for widgets are expecting to run in a XUL doc).

Just attached some patches that are not intended to be landed. It converts <label> to <firefox-label> and <checkbox> to <firefox-checkbox> without requiring changes to the preferences JS

Current Preferences search functionality is relying on using label.textContent to make inner text highlightable. Does <firefox-label> not to break our search highlight?

Leaving some open questions to answer before attempting to land anything here. 1) Custom Element support hasn’t landed in Firefox yet, and there aren’t current plans to natively support XUL documents. This means either: ** We need to 'cut over’ about:preferences to XHTML (which would break existing XBL bindings that rely on XUL document things like document.commandDispatcher) ** We need to continue using the forked polyfill (after measuring performance / reliability / etc), and/or support them natively in XUL docs. 2) If we landed a version of this, we'd end up with two versions of UI components until the rest of the browser chrome was migrated - the original XBL binding (used in other documents) and the translated Custom Element. So we’d need to think about either: ** Make it easy to update the Custom Element based on code changes to XBL bindings ** Attempt to do a browser-wide replacement of one XBL binding one at a time, removing the binding and switching to the Custom Element ** Don’t worry about exact semantics / behavior and porting updates to the Custom Elements. We wouldn’t even technically need to use Custom Elements at that point 3) Some of the bindings used in preferences (and throughout the browser) aren’t easy to directly translate to Custom Elements, like `tree` which implements `nsIDOMXULTreeElement` and has a pretty complicated API. We'll have to come up with a solution for these (for instance, writing a new UI component that doesn’t necessarily attempt to match the exact implementation). ** Generally, things that use the [implements] but don't map pretty directly back to an HTML tag are components that may fall into this category: https://bgrins.github.io/xbl-analysis/#implements

I think we should close this bug for now. The current plan for XBL migration to Custom Elements is to replace individual bindings tree-wide rather than replace all bindings component-by-component. IOW when a XBL binding gets replaced with a Custom Element (i.e. stringbundle in Bug 1411707), it will replace all the instances in the browser, including those in preferences.