Currently, the code to mark up a tree (without any special views) looks like this: <tree> <treecols> <treecol label="One"/> <treecol label="Two"/> <treecol label="Three"/> </treecols> <treechildren> <treeitem> <treerow> <treecell label="Primary"/> <treecell label="Secondary"/> <treecell label="Tertiary"/> </treerow> <treechildren> <treeitem> <treerow> <treecell label="Un"/> <treecell label="Deux"/> <treecell label="Trois"/> </treerow> </treeitem> </treechildren> </treeitem> </treechildren> </tree> Using anonymous content bindings, it should be possible to reduce this to: <tree> <treeitem firstCol="Primary" secondCol="Secondary" thirdCol="Tertiary"> <treeitem firstCol="Un" secondCol="Deux" thirdCol="Trois"/> </treeitem> </tree> However, in testing such anonymous content bindings, I found it simply did not work. Implementing this sort of anonymous content support would make it possible to shorten a lot of XUL tree code, within and without the chrome. Testcase available upon request.
For sanity, it would be great to work with templates too. If not, learners are faced with (yet another) arbitrary special case within the tree / template / tree+template headspace. Understanding builders is challenging enough as it is without having varied anon. content support as well. - N.
> Testcase available upon request. You mean like the requests in the "how to file a bug report" documents? ccing some people who actually know something about trees....
Perhaps we could make the content view look for the named attribute on the treeitem/row as an alternative to the value of the appropriate treecell?
Created attachment 142635 [details] testcase I think there are actually two bugs here, not one. The first is a problem with handling the overriding of the tree element's binding with a compatible anonymous content binding. The second is more serious. The <xul:treeitem/> element will not accept a XBL binding. I am not kidding. If you look at the testcase from DOM Inspector, the same CSS block sets a binding on a foo element and also on a treeitem element, via two separate selectors which only a comma separates. But only the foo element gets the binding. Mr. McFarlane, I've not had enough experience working with RDF-based trees to construct an appropriate testcase for that. Would you be kind enough to provide one?
Component: XP Toolkit/Widgets: XUL → XP Toolkit/Widgets: Trees
Well treeitems don't display, so they don't have a frame, so no binding...
Also, what's wrong with the way bookmarksTree.xml does it?
As Neil points out, content associated with trees is not rendered by the normal route - no XBL inside the <tree> tag currently. What this bug is requesting? Is this bug a request for: 1. XBL support inside trees, whether templated or not? 2. A shorthand way to specify tree content in XUL? 3. More display: -moz.. style support for tree tags? The idea of some kind of shorthand for tree content is appealing - the "simple syntax" for templates is an argument in favour. Tree implementation is vexed with a number of design issues that likely make 1. several steps away at this point. The way I read Alex' comments, bookmarksTree.xml is no solution for this bug because it fully describes a widget, rather than providing a shorthand. - N.
Actually, the way I saw it was per comment 7, doing #2 by way of #1... :) The shorthand would be document-specific, preferably provided by an author's XBL binding.
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.