Tree: rendering problem in IE with long node names

[[email protected]…]

I've been working quite extensively with the TreeV3 code in one of my proof of concept applications at my place of employment. I've uncovered what appears to be an annoyance bug within the TreeV3 rendering logic that occurs only on IE. Basically, I have an application which uses SplitContainer? to divide up the view into a tree and data panes. When the Tree node names become long enough, I have the CSS set so that is should provide me scroll bars. It does. But something else also happens ... the tree rendering goes wrong. Normally you would expect the tree render to look like:

+-Node Name One

Node Name Two

And so on. But in IE, when the node name exceeds the viewable width of the SplitContainer? (ContentPane?) section, it ends up rendering somewhat like this:

+ Node Name One

NodeName? two

It seems to insert a new line between the graphic attach line and the node name. This only happens on IE 5.5 and IE 6. Fire Fox 1.5, Mozilla 1.7.X, and Opera 9, all render this correctly. I have a simple testcase which demonstrates the issue that I will upload shortly. It has been tried against all the latest nightlies for the past week or so with the same rendering result. I've also tried many different CSS attributes against it, and even tried to adjust how the node name is even assigned to the tree with no luck on resolving this rendering problem.

If you have any quiestions regarding this, I will check back on the ticket and my gmail account. Thank you for your time and the excellent toolkit.

Sincerely,

Jared Jurkiewicz

[[email protected]…]

Testcase demonstration of the rendering problem.

[Douglas Hays]

The problem is that the div with a background image only that represents the expand/collapse navigation is seen as whitespace and therefore a small client area will cause a line break - and also IE5/6 ignores white-space:nowrap. The easiest solution is to change the background image to a real img and replace the empty div - then it works everywhere. If its really important to keep the background image, then you can still replace the div with an img element, but set the img src to a 1 pixel transparent dot sized to the same width as the expand/collapse background image added to the img class.

[ilia]

I'm little lost...

doughays: does your answer mean, that I should change something ?

[Douglas Hays]

combine expandNode and contentNode

[Douglas Hays]

Ilia, please review the attached patch to make sure I didn't break anything. I'd like to commit this into 0.4.1

[ilia]

This solution needs careful review, I can't accept it right now.

expandNode was split away from contentNode on purpose, at early development stages.

[ilia]

The possible solution can be 'TreeDisableWrapExtension?'

[ornus]

the patch changes layout. I understand ilia experimented with different ways to show the tree and he uses div with background on purpose (among other things it makes it easier to have custom icons for different nodes). changing this can lead to other problems appearing. like ilia suggested 'TreeDisableWrapExtension?' should fix the problem

[ilia]

Yeah, the solution is promising, but which possible side effects and restrictions that may follow ?

[Douglas Hays]

ilia, I could find no side-effects after a few simple tests but I wanted you to support this patch being committed. I think less nodes is better if it works everywhere. Is TreeDisableWrapExtension? still needed with this patch?

[ilia]

There must be a bunch of side-effects for exactly this patch.

The first side-effect is expand/collapse node after clicking on empty space.. See dojo/tests/widget/treeV3/markup3.html

Of course I'll support the patch once it is ready. Its just not there yet.

[ilia]

Maybe we could fix controller check by placing event coordinate check there ? contentNode left-upper 18x18 box is expandNode..

[Douglas Hays]

refreshed patch with Ilia's click region suggestion implemented

[Douglas Hays]

ilia to resolve remaining issues

[ilia]

I checked TreeDocIcon?.. We can add one more TreeContent? node that will have icon instead of expand sign, but there is a need of grid from this icon.

The only way I see is to add one _more_ div for grid, so we'll have 2 extra nested divs for each node (with TreeDocIcon? extension enabled).

Any ideas of a better layout ?

[Douglas Hays]

Needs to be deferred to 0.5 so that all the a11y issues can be resolved.

[Douglas Hays]

should be assigned to the new tree owner

[bill]

Unfortunately we can't combine everything into one node (like 1728.patch above) because there's the expando, the icon, and the label... and since the expando node and the icon are in sprite images they each need their own div (or img, as Doug suggested).

The current design uses float:left CSS, and that's not good because it requires special rules for BIDI support. But we have to see if we can get white-space:nowrap or nowrap="nowrap" HTML attribute to work on IE (or alternately use a table).

[bill]

(In [14095]) Make tree items nowrap. Main problem seems to have been the float:left on the open/close icon, which doesn't seem to be needed. (I hope I'm not missing something.) After removing that and adding white-space:nowrap, things seem to work. The tree icons still need to be vertically aligned w/the text, which perhaps requires switching them to use <img> nodes (pointing to blank.gif and having the real image specified via background-image CSS). Fixes #1728. !strict

[bill]

(In [14096]) Fix regression in a11y mode (from previous checkin) and remove unneeded rule. Refs #1728.