On 01/17/2017 12:05 AM, Dave Townsend wrote:
Trees! I knew I was forgetting something, thank you. Yeah those are things
we're going to need some sane replacements for.
AS far as XBL goes, while I suspect it works from HTML documents I think we
want to be phasing out use of XBL too for pretty much the same reasons as
XUL. Web components seem like an obvious alternative and I understand that
they are only preffed off right now. If we can have them work in chrome
documents they could be the right replacement.
The Shadow DOM implementation v0 we have in tree will be replaced with v1.
Those aren't quite compatible in
API level. We must not pref on the current shadow DOM implementation.
On Mon, Jan 16, 2017 at 1:28 PM, Matthew N. <ma...@mozilla.com> wrote:
Trees are the big thing that come to mind. I've heard about three non-XUL
re-implementations (IIRC mostly in devtools) which sounds like a
maintainability issue and potentially redundancy. I would rather keep using
XUL trees than have even more different tree implementations (though I'd be
fine with a one or two simpler replacements since many uses of a xul:tree
don't need a lot of the feature like nesting) which brings me to my next
point:
What about XBL? Does it just work from XHTML documents? Is our
implementation of Web Components ready to replace it and riding the trains?
I think it would be good to implement drop-in replacements (or as close as
possible) for some simple XBL bindings or native XUL elements to prove that
Web Components are a replacement. Once the Web Component version is working
we can transition to it everywhere. Perhaps something like <preference>
would be a good candidate.
Matthew
On Mon, Jan 16, 2017 at 12:43 PM, Dave Townsend <dtowns...@mozilla.com>
wrote:
One of the things I've been investigating since moving back to the
desktop team is how we can remove XUL from the application as much as
possible. The benefits for doing this are varied, some obvious examples:
* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.
* Further integration of Servo code may require dropping XUL altogether.
The necessary first step of reducing XUL use is to stop adding any more
UI that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?
Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:
* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.
What other features do we depend on in XUL that I haven't listed?
_______________________________________________
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
