In order to support moving more of our frontend to HTML, I'd like to propose that we change the way `hidden` and `collapsed` attributes and properties work on XUL elements and rewrite frontend consumers to adapt.
Currently, hidden and collapsed in XUL behave like: * Only a value of true hides or collapses the element in the XUL markup. This is done in CSS rules (https://searchfox.org/mozilla-central/rev/1fe0cf575841dbf3b7e159e88ba03260cd1354c0/toolkit/content/minimal-xul.css#30-38) and there's also platform code that specifically looks for "true" on the attribute. * Setting el.hidden = true or any truthy value will set hidden="true" in the markup * Setting el.hidden = false or any falsy value will remove the hidden attribute If we want to support more easily porting non Custom Element XUL elements (like <hbox>) to HTML without requiring a Custom Element, I think we should switch the behavior to more closely match HTML: * Setting any value to the hidden/collapsed HTML attribute will hide the element (we’d add CSS rules matching those in minimal-xul.css but in xul.css targeting html elements with the existence of the attribute instead of checking for “true”). * el.collapsed is not a thing: we’d rewrite consumers from `el.collapsed = val` to `el.toggleAttribute(“collapsed”, val)` * Setting el.hidden = true or any truthy value will set hidden="" in the DOM * Setting el.hidden = false or any falsy value will remove the hidden attribute * The recommended way to write things in HTML markup is <div hidden>. <div hidden=“hidden”> and <div hidden=“”> are also acceptable but <div hidden=“true”> or any other value is _not_ acceptable as per https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#boolean-attributes . * The recommended way to write things in XHTML markup is <div hidden=“hidden”> Things I know we need to look more closely at before making a change: * Check consumers that use XULStore to persist these values to make sure that they don't explicitly store [hidden=false] as a way to indicate that it's visible. Are there reasons not to make this change, or things that need further investigation? Note that this came out of a suggestion from ntim in https://phabricator.services.mozilla.com/D51168 - there's some more background in that patch. Thanks, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
