<div dir="ltr"><div>Do we have a concept of XUL base elements in C++? Presentation-wise I can find sXULTagData in nsCSSFrameConstructor [1]. For accessibility, I can find sXULMarkupMapList (the one kept in XULMap.h).<br></div><div><br></div><div>[1] <a href="https://dxr.mozilla.org/mozilla-central/rev/a79d460bf2a33fd79c6646236f9c4df78e66e7b7/layout/base/nsCSSFrameConstructor.cpp#4308">https://dxr.mozilla.org/mozilla-central/rev/a79d460bf2a33fd79c6646236f9c4df78e66e7b7/layout/base/nsCSSFrameConstructor.cpp#4308</a></div><div><br></div><div>If we want to go this route, should we start locking down that list? That would help us normalize XUL & XUL element inheritance.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 14, 2018 at 6:25 PM, Paolo Amadini <span dir="ltr"><<a href="mailto:paolo.02.prg@amadzone.org" target="_blank">paolo.02.prg@amadzone.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4/13/2018 5:17 PM, Brian Grinstead wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this case I don’t want ‘customized built-in’ exactly, but I want ‘customized autonomous custom element’ or something like that.<br>
</blockquote>
<br></span>
In fact my impression is that for XUL we'd need a combination of the two<br>
concepts, in order to make a more incremental transition from the<br>
current state to an implementation that is closer to HTML.<br>
<br>
As Brian mentioned, the localName is currently used by platform code to<br>
attach special behavior, for example accessibility, to elements like<br>
"listitem" and "richlisitem". We are also looking into subclassing<br>
XULElement in the platform to add C++-implemented methods to elements<br>
like "panel" and "menupopup". This would in fact make them analogous<br>
to "built-in elements" in HTML. My guess is that preserving this<br>
platform behavior, hard-coded on the localName, is why "customized<br>
built-in elements" exist for HTML in the first place.<br>
<br>
The only difference from HTML here is that the base element itself,<br>
the one without the "is" attribute, would also be implemented with a<br>
corresponding JavaScript class extending XULElement, or a more specific<br>
subclass for cases like "panel". This is basically the "non-dashed<br>
custom elements" idea that we applied to facilitate the transition.<br>
<br>
This also aligns with the concept that in the future some HTML elements<br>
may be implemented in the user agent as JavaScript classes similar to<br>
custom elements, either partially or entirely. So we would have:<br>
<br>
<br>
<br>
class Panel extends XULPanelElement<br>
class ArrowPanel extends Panel<br>
<br>
customElements.define("panel", Panel);<br>
customElements.define("arrow-p<wbr>anel", ArrowPanel, { extends: "panel" });<br>
<br>
<panel/><br>
<panel is="arrow-panel"/><br>
<br>
document.createElement("panel"<wbr>);<br>
document.createElement("panel"<wbr>, { is: "arrow-panel" });<br>
<br>
<br>
<br>
How much effort would it be to support this scenario in XUL?<br>
<br>
Cheers,<br>
Paolo<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
</div></div></blockquote></div><br></div>