Bugzilla

(In reply to Mats Palmgren (:mats) from comment #7)
> Created attachment 9200156 [details]
> Simple tree using grid layout
> 
> This is a mockup of a Grid layout that could be used for simple cases of XUL trees like for example the History Sidebar etc.

Thanks! This solves the layout bit in a way that can be integrated in custom elements (since it keeps the DOM structure). Unfortunately, there are other bits too:

Basic things that would need to be taken care of:
* ability to select rows
* rewriting styling (:-moz-tree-* pseudos)
* porting XULTreeAccessible, this relies heavily on the layout frames, but I guess the CE can set the right aria roles if we used DOM elements.
* porting nsITreeSelection/nsITreeView usages: the whole tree CE relies on these for keyboard navigation, handling clicks, populating content and other things. This will probably need a better API to be more suited for real DOM elements.
* potentially perf (notably for bookmarks/history stuff)

There are more specific features too, that only certain places use:
* context menus (I *think* only the places-tree derived CE uses those, so it could be generated there)
* resizable columns (this can probably be done with some listeners that change the `grid-template-columns` or simply go away)
* checkbox cells, these are used mostly in <richlistbox> style usages (zero-depth), in about:preferences mainly
* editable cells (afaik only the search engine tree in about:preferences#search use them): that tree could potentially re-use the "Add new engine" dialog, but in an editing state
* <treecolpicker>: allows showing/hiding columns, but not sure that's really important.

Overall, given the complexity of trees, a lot will need a rewrite. So it's worth looking closely at what feature set the replacements would have. The prototype is well suited for tree-table type things, but most usages are either trees or tables, so rewriting them may be faster.

Though, one thing that could be sorted out now is maybe making <treecol> use CSS grid when it's not inside a <tree> (many places do that).

(In reply to Mats Palmgren (:mats) from comment #7)
> Created attachment 9200156 [details]
> Simple tree using grid layout
> 
> This is a mockup of a Grid layout that could be used for simple cases of XUL trees like for example the History Sidebar etc.

Thanks! This solves the layout bit in a way that can be integrated in custom elements (since it keeps the DOM structure). Unfortunately, there are other bits too:

Basic things that would need to be taken care of:
* ability to select rows
* rewriting styling (:-moz-tree-* pseudos)
* porting XULTreeAccessible, this relies heavily on the layout frames, but I guess the CE can set the right aria roles if we used DOM elements.
* porting nsITreeSelection/nsITreeView usages: the whole tree CE relies on these for keyboard navigation, handling clicks, populating content and other things. This will probably need a better API to be more suited for real DOM elements.
* potentially perf (notably for bookmarks/history stuff)

There are more specific features too, that only certain places use:
* context menus (I *think* only the places-tree derived CE uses those, so it could be generated there)
* resizable columns (this can probably be done with some listeners that change the `grid-template-columns` or simply go away)
* checkbox cells, these are used mostly in <richlistbox> style usages (zero-depth), in about:preferences mainly
* editable cells (afaik only the search engine tree in about:preferences#search use them): that tree could potentially re-use the "Add new engine" dialog, but in an editing state
* reordering/dropping rows (for bookmarks)
* <treecolpicker>: allows showing/hiding columns, but not sure that's really important.

Overall, given the complexity of trees, a lot will need a rewrite. So it's worth looking closely at what feature set the replacements would have. The prototype is well suited for tree-table type things, but most usages are either trees or tables, so rewriting them may be faster.

Though, one thing that could be sorted out now is maybe making <treecol> use CSS grid when it's not inside a <tree> (many places do that).