tree behavior without @role="wairole:group" for subordination?

Recently I took a action item to create an alternative tree widget which
uses a 'hidden' attribute to make the current 'group' role unnecessary.

I want to claim failure.  I'm just not developing my script skills fast enough.
So I am going to describe an approach in words and see if someone else
cares to a) explain why it won't work or b) show that it does with
a working example.

First, why?

It arose out of the idea of a "tree grid."  This is a common feature.  It
is something where there are several columns of information but the
rows are grouped and show or hide as groups are expanded or collapsed,
as indicate by the state of a row head cell (and the expand/collapse
control in that cell).

One can do this with a tree of DIVs and layout that emulates a table.

But you can't do it with the group-using tree structure and HTML tables
for the table layout (even if the data makes sense as a data table)
because you can't slip the <div role="wairole:group"> around groups of
<TR> elements.  One could support
a single level of expand/collapse function with <tbody role="wairole:group">
but then you can't nest those.

So we are looking for something where the elements bearing the
aaa:expanded attributes that control show/hide are associated by
explicit ID reference arcs with the elements bearing the aaa:hidden
attributes that control display:none vs. display:block show/hide
behavior.

I am going to suggest that those references flow from the element bearing
the 'expanded' to the elements bearing the 'hidden', and that they be
either 'owns' or 'controls' arcs.  I don't know which is better or if 
neither is
OK.

But the point here is that you don't have to collect the hidden-on-collapsed
subordinate tree items by a 'group' container; you can collect them in the
list of elements that the super-ordinate tree item 'owns' or 'controls'.

The scripts would be responsible, when the super-ordinate tree item changes
its 'expanded' state to set the 'hidden' property on its direct subordinate
tree items appropriately.  The style rules converting @aaa:hidden="true" to
display:none would then hide sub-ordinate tree items and any contents thereof.
[Do we have to ask the script to flow down the @aaa:owns arcs recursively
to set aaa:hidden on items that are visually included but not 
textually included?
Maybe we do.]

But that is the basic idea.

This kind of wiring would, I think, allow us to have an arbitrary 
nest of topics as
values in a single column of TH cells in a table, with arbitrarily deep nesting
of expand/collapse behavior for collections of rows.

In the expanding/collapsing <TABLE> application, the elements bearing
the 'expanded' attribute would be <TR> elements and optionally
<TBODY> elements. The elements bearing the aaa:hidden attributes
would be again <TR> and optionally <TBODY> elements. The elements
that are sensitive and display the state of the 'expanded' attribute
would be <TH> elements. So the control and the 'expanded' property
are not on the same element. I don't know if it makes more sense to
have the focus go directly to the <TH role="aaa:button"> element or
to make it a managed descendant of the enclosing <TR> or <TBODY>. One
or both of these could perhaps work?

In a news or mail reader, this would allow one to expand and collapse
categories in whatever column one had sorted by, without moving that
field to the left hand column of the display.  This would be very useful
to enable the reader to expand several related threads while collapsing
un-related threads that had appeared between the threads of interest.
Or in a sort by "From:" originator, collapsing collections from some
people and expanding all messages from others.  All these folding
options can [I suppose] be done with the "tree of <DIV>s" structure that we now
have, with enough attention to the CSS for the tabular layout.  It just
seems more straightforward to organize the information in an HTML <TABLE>
and overlay the expand/collapse behavior with a web of ID reference
relationships and aaa: attributes.

Sorry I haven't reduced this to working code; there's what has been
in my mind, if it's legible.

Al

Received on Saturday, 28 April 2007 15:59:39 UTC