On 10/13/2014 5:28 PM, Robert O'Callahan wrote:
Bug 441414 has patches adding features to XUL trees. I'm sympathetic to the
desire for these features, but I do not think we should take these patches,
nor any other patches adding features to XUL. XUL is a dead-end technology
and investment in XUL provides minimal returns --- this includes effort
spent reviewing and maintaining XUL. Some amount of XUL maintenance is
necessary to support Firefox, Thunderbird and the Firefox addons ecosystem,
but we should keep it to a minimum. In most cases our apps and addons can
use standard Web platform technology instead, which continues to evolve
rapidly.
There may be some cases where small extensions to XUL provide great
benefits to the Mozilla project that we can't easily get any other way, in
which case we should allow it. I don't think bug 441414 is one of those
cases. With some effort you can build arbitrarily rich XUL-tree-like
functionality using HTML, and that's the way to go.
I nominally agree with this sentiment, but there are a few caveats:
1. nsITreeView and <xul:tree> exist and are usable in Mozilla code
today. No HTML-based alternative to these are so easily usable.
2. The main rationale for this feature (bug 213945, although I doubt the
approach currently taken in bug 441414 is actually usable for that
anyways) involves a tree view that is currently performance-sensitive
and comprises 13,446 lines of C++ code, so it can't easily move to JS.
Which means some sort of XPIDL API is going to be necessary anyways, and
that API would probably look vaguely similar to nsITreeView.
3. I've never done a lot of UI coding myself, so I don't know if my
recollection is correct anymore or even if it ever was, but I recall
hearing that XUL and HTML didn't get together terribly well.
So if we had an HTML tree implementation that:
a) supported lazy generation of row data
b) supported column pickers, rearrangeable columns, etc.
c) supported CSS queries similar to what <xul:tree> does already,
d) could be used or made usable from C++ without too much effort
e) already existed and were generally maintained in toolkit/
f) were properly accessible
g) had any other compatibility features I've neglected
I would happily agree with you. But without those, it does feel a little
bit like you're holding hostage real improvements on the basis that a
better solution theoretically exists.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
