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

Reply via email to