348764 - Reorder Dom Node Viewer Tree Columns

Status: RESOLVED WONTFIX

(Other Applications :: DOM Inspector, defect)

Description

[Shawn Wilsher :sdwilsh]

Related to Bug 348668 Comment 4.

We should make the ordering make sense, and allow for horizontal scrolling so having all those columns enabled could be useful.

Sadly, that means we'll have to hard code minWidths into the columns because flex doesn't prompt the scroll bar to appear.

Open to suggestions on what the "right" order should be.

Comment 1

[Jason Barnabe (np)]

In general, I'd expect it to be in the order that it would appear in the source.

Comment 2

[mozilla]

(In reply to comment #1)
> In general, I'd expect it to be in the order that it would appear in the
> source.

Not everything is stated in the XML with the attribute, some are deducted from other places in the code, though i agree source order should not be broken.

I'd like namespaceURI,localName,value next to each other in that order, because the namespaceURI is what gives the effect, prefix is 'merely' a way to allow for quicker reading and typing of code.

Comment 3

[[e-mail]]

As a reminder, the existing DOM node tree provides the default column order of
nodeName [localName] [prefix] [namespaceURI] [nodeType] [nodeValue] id class.
The existing DOM attribute column order is [namespaceURI] nodeName nodeValue.
Bug 348668 suggested changing this to [namespaceURI] prefix localName nodeValue
for as Shawn pointed out the prefix column should precede the localName.

Comment 4

[[e-mail]]

My current preference is nodeName prefix localName namespaceURI {others} although I can see a case for putting the namespaceURI first by default.

(In reply to comment #2)
>I'd like namespaceURI,localName,value next to each other in that order, because
>the namespaceURI is what gives the effect, prefix is 'merely' a way to allow
>for quicker reading and typing of code.
FYI our existing setAttributeNS implementation actually uses the nodeName.

Comment 5

[Shawn Wilsher :sdwilsh]

(In reply to comment #3)
> The existing DOM attribute column order is [namespaceURI] nodeName nodeValue.
> Bug 348668 suggested changing this to [namespaceURI] prefix localName nodeValue
> for as Shawn pointed out the prefix column should precede the localName.

Actually, the newest patch I did it how you had indicated in Bug 348668 Comment 4 as nodeName [localName] [prefix] [namespaceURI] nodeValue

----------
So, based on other comments thus far, it looks like we have two options:
1) Leave it how Attachment 233839 [details] [diff] is for Bug 348668 with a minor adjustment
   nodeName [prefix] [localName] [namespaceURI] nodeValue
2) Have namespaceURI up front
   [namespaceURI] nodeName [prefix] [localName] nodeValue

Personally, I prefer the second option because I can see the namespaceURI to be significantly more useful farther left, but then I don't work with this stuff all the time.  There's also the fact that you can drag these to new places and the DOMI remembers where you put it.

----------
Nobody has discussed the horizontal scrollbar issue yet either.  While playing around with the code for Bug 348668, I found that having the flex attribute prevents the horizontal scrollbar from appearing.  So, we need to specify a width, or probably a minWidth would be a better idea.  I'm not sure if that's considered a bad thing to do however, so input would be appreciated :)

Comment 6

[mozilla]

(In reply to comment #3)

What do you mean by id in this case? (see https://bugzilla.mozilla.org/show_bug.cgi?id=275196 )
Do you mean both id and xml:id ?
A somewhat similar question could be asked about class actually, what class?, in what namespace ?

As long as all things are available for both nodes and attributes, visible by default or not, everybody can be happy.
Especially when the order is configurable 

my preference for default column ordering:
node tree:
namespaceURI [prefix] localName [nodeName] [nodeType] [nodeValue] id? [class]
attribute:
namespaceURI [prefix] localName [nodeName] nodeValue.

Comment 7

[timeless]

ok, personal opinion. if we can do this:


                           ._______________________________________________.
Namespace prefix localName |nodeType| nodeName    |nodeValue|id|class    |v|
                           |--------+-------------+---------+--+-----------|
                           |doctype | . HTML      |         |  |         |^|
                           |document| - HTML      |         |  |         |%|
                           |element | |- HEAD     |         |  |         | |
                           |element | ||+ TITLE   |         |  |         | |
                           |comment | ||+ #COMMENT|         |  |         | |
                           |element | |\+ LINK    |         |  |         | |
                           |element | \- BODY     |         |  |         | |
                           |text    |  |. #TEXT   |         |  |         | |
                           |.............................................| |
                           |________|_____________|_________|__|_________|v|
                           |<_____________________________==============>|_|

Yes, I have all 3 of the interesting columns offscreen left.

Of course, the next question is what happens if someone wants to turn off the nodeName.

Otherwise, i'd rather stick them to the far right. my goal is to not stick stuff between the tree and the value/id/class. I'm betting that on average a user doesn't really need to see the node type or namespace and friends, and given how long they are, having them anywhere between the useful tree and the class list would be fairly annoying.

note that i don't really feel strongly about this. i would encourage someone to attach safari's UI so people can see it (i'm not a fan, for the record).

Comment 8

[timeless]

oops. wrong pane. sorry. um, i'd stick the namespace hidden on the left (not scrolled, just hidden), i think.

it's too wide to be very useful in general. we're almost better off letting users define icons for well known namespaces and showing them instead.

we might also want to consider a multirow view (akin to outlook)....

Comment 9

[Colby Russell :crussell (no longer Mozilla-ing)]

The horizontal scrollbar is covered by bug 112832.

WONTFIXing for the column ordering; just drag them around.