1858003 - [meta] Switch remaining XHTML chrome/about documents to HTML

Status: NEW

(Firefox :: General, task)

Description

[:Gijs (he/him)]

Originally, we had XUL documents.

After bug 1579952 and bug 1550801, we now have only HTML and XHTML documents. The difference is that the XHTML ones get parsed as XML (syntax errors are fatal) and the HTML ones get parsed with the HTML parser (syntax errors are not fatal).

There are still about 147 of these (non-test) XHTML files left in the tree: https://searchfox.org/mozilla-central/search?q=&path=.xhtml%24&case=false&regexp=false .

XHTML is badly supported by tooling, is effectively dying as a web technology, and is at this point holding us back vs. using HTML.

There are a few reasons this is not as trivial as a file rename and removing some /> self-closing elements:

• we use XML processing instructions (xml-stylesheet) to load styles. Those need switching over to HTML link elements.
• we use something called the 'prototype cache' to speed up loading these documents. We should quantify what this gives us and come up with either an alternative approach (e.g. using a singleton JS module and providing cloned parsed markup from there) or make the prototype cache be able to deal with non-XML docs.
• we use a bunch of XUL elements (by means of namespaces) in markup, which won't parse correctly as HTML. Namespaces are confusing, but effectively what happens e.g. here in browser.xhtml is that we tell Gecko there's an HTML body tag, and that it should assume the namespace for all the content in it that doesn't explicitly have a namespace, is the XUL namespace. So everything inside body is treated as a XUL element, unless its start tag looks something like <html:blah>. To work with this we'd have to do some combination/variation of:
  • stop using XUL entirely (huge project, unlikely to happen as quickly as we'd like to make this switch, and not obviously possible/advantageous for things like menus and panel support)
  • allow the HTML parser to recognize some XUL tags in system privileged documents and treat them the same way as the XHTML parser treats XUL-namespaced elements
  • switch XUL elements to "normal" HTML ones where possible (e.g. vbox/hbox are just div with a default flex direction) and/or where the tagnames are identical (both XUL and HTML have label and menuitem, unfortunately)
  • stop using namespacing and/or the parser to define XUL elements (e.g. wrap XUL elements in an HTML custom element that creates the "real" XUL element from code, where we can "just" call .createXULElement).

There may be other reasons I'm not aware of... in which case please add comments.

Comment 1

[Brian Grinstead [:bgrins]]

(In reply to :Gijs (he/him) from comment #0)

• we use a bunch of XUL elements (by means of namespaces) in markup, which won't parse correctly as HTML. Namespaces are confusing, but effectively what happens e.g. here in browser.xhtml is that we tell Gecko there's an HTML body tag, and that it should assume the namespace for all the content in it that doesn't explicitly have a namespace, is the XUL namespace. So everything inside body is treated as a XUL element, unless its start tag looks something like <html:blah>. To work with this we'd have to do some combination/variation of:

• stop using XUL entirely (huge project, unlikely to happen as quickly as we'd like to make this switch, and not obviously possible/advantageous for things like menus and panel support)

I'm almost certain I had a discussion with bz at some point about supporting menu/panel/browser and so on with some kind of a "chrome privileged html element", but I'm unable to find a thread / bug / doc about it at the moment.

• allow the HTML parser to recognize some XUL tags in system privileged documents and treat them the same way as the XHTML parser treats XUL-namespaced elements

Note there are currently a couple special cases for xul custom elements (see Bug 1596530) that might affect parser approaches, so worth considering (and/or rewriting frontend code relying on it) if we pursue this option further.

• switch XUL elements to "normal" HTML ones where possible (e.g. vbox/hbox are just div with a default flex direction) and/or where the tagnames are identical (both XUL and HTML have label and menuitem, unfortunately)

now that we have CSS flexbox everywhere, this would be a lot easier style-wise than when we were doing emulation (the relevant styles in https://searchfox.org/mozilla-central/rev/5ad226c7379b0564c76dc3b54b44985356f94c5a/toolkit/content/xul.css could get copied into widgets.css or similar and things should "just work"). It would still be finicky on the markup side though, since you'd need to make sure the vbox'es are html namespaced while (presumably) their children remain XUL. You can do this like https://searchfox.org/mozilla-central/rev/5ad226c7379b0564c76dc3b54b44985356f94c5a/browser/base/content/browser.xhtml#137, but it's ugly / verbose.

• stop using namespacing and/or the parser to define XUL elements (e.g. wrap XUL elements in an HTML custom element that creates the "real" XUL element from code, where we can "just" call .createXULElement).

I could imagine something with display: contents and mirroring attributes back and forth, but I think (a) it'd likely break a bunch of scripts that traverse parentElement and so on (b) there would likely be a performance impact.

A similar option would be wrapping the entire contents of a body into a <template> or <script> element and have the page pipe it into parseXULToFragment and append on load. That might be a way to at least work around some of the long tail where we have documents that aren't as performance sensitive or needing to deal with complex lifecycles.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.