On 10/13/2014 07:06 PM, Joshua Cranmer 🐧 wrote:
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.
There are many lazy-rendering infinite tree/table/infinite list
implementations out there:
For example:
- Dojo: TreeGrind/LazyTreeGrid
http://dojotoolkit.org/reference-guide/1.10/dojox/grid/TreeGrid.html
- dgrid (Dojo related): http://dojofoundation.org/packages/dgrid/
- tree examples
- column hider extension:
https://github.com/SitePen/dgrid/blob/v0.3.15/doc/components/extensions/ColumnHider.md
- the things that the dgrid website provides in its comparison table
- Sencha (which is GPLv3 but has a weird library style exception it
seems): http://dev.sencha.com/ext/5.0.1/examples/tree/locking-treegrid.html
- React (just a list, but an example of how easy such a component is in
React): https://github.com/orgsync/react-list
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.
The performance-sensitive parts of the XUL tree view widget is that it
paints synchronously and does not do any smart caching on its own.
These are deficiencies of the C++ XUL tree implementation that an HTML
implementation need not share. (In fact, I've never seen any that would
have the same performance problems; you'd have to write your own widget
from the ground up in Canvas to reproduce them.)
For the bug 213945 Thunderbird use-case, the existing C++ nsITreeView
interface implemented by the mailnews DBView could easily be used by a
Dojo Store adapter/etc. Any calls made by C++ code to update the tree
view can (and already do) call JS code to cause proper invalidation of
the JS/HTML-exposed data-model. I say this as someone with expensive
experience working with that area of the Thunderbird codebase and who
considered our options and decided that an HTML-based widget was the way
to go.
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,
The examples I give above I believe all support these features.
d) could be used or made usable from C++ without too much effort
As noted above, I don't think Thunderbird's use-case actually requires
C++ code to meaningfully interact with the tree widget in a way that
can't be compensated for in JS.
e) already existed and were generally maintained in toolkit/
This is a weird, NIH-ish requirement. Why should Mozilla create and
maintain an HTML tree widget when there are so many open source
implementations that already exist?
f) were properly accessible
A good concern and something that should be used for evaluation of any
library options. Since the widgets above all use the HTML DOM, it's a
question of making sure they are using the appropriate HTML and ARIA
attributes (ex: aria-posinset).
Andrew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
