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

NEW
Unassigned

Status

()

Core
XUL
14 years ago
8 years ago

People

(Reporter: WeirdAl, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

8.95 KB, application/vnd.mozilla.xul+xml
Details
(Reporter)

Description

14 years ago
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

14 years ago
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....

Comment 3

14 years ago
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?
(Reporter)

Comment 4

14 years ago
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?
(Reporter)

Updated

14 years ago
Component: XP Toolkit/Widgets: XUL → XP Toolkit/Widgets: Trees

Comment 5

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

Comment 6

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

Comment 7

14 years ago
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.
(Reporter)

Comment 8

14 years ago
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.

Updated

9 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets

Updated

8 years ago
Assignee: hyatt → nobody
You need to log in before you can comment on or make changes to this bug.