235901 - XUL trees should allow anonymous content to define columns, cells, children

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Alex Vincent [:WeirdAl]]

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.

Comment 1

[Nigel McFarlane]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> 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....

Comment 3

[[e-mail]]

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?

Comment 4

[Alex Vincent [:WeirdAl]]

Attachment: 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?

Comment 5

[[e-mail]]

Well treeitems don't display, so they don't have a frame, so no binding...

Comment 6

[[e-mail]]

Also, what's wrong with the way bookmarksTree.xml does it?

Comment 7

[Nigel McFarlane]

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.

Comment 8

[Alex Vincent [:WeirdAl]]

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.

Comment 9

[Alex Vincent [:WeirdAl]]

XUL trees are on their way out, and there's been no action on this for ten years...