Reorder Dom Node Viewer Tree Columns

RESOLVED WONTFIX

Status

Other Applications
DOM Inspector
RESOLVED WONTFIX
12 years ago
7 years ago

People

(Reporter: sdwilsh, Unassigned)

Tracking

(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

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

Comment 2

12 years ago
(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

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

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

Comment 5

12 years ago
(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 :)
Assignee: dom-inspector → comrade693

Comment 6

12 years ago
(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

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

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

Updated

12 years ago
Blocks: 363403

Updated

12 years ago
No longer blocks: 363403

Updated

12 years ago
Blocks: 363403
(Reporter)

Updated

11 years ago
Depends on: 212789
(Reporter)

Updated

11 years ago
Flags: blocking1.9?
Target Milestone: --- → mozilla1.9beta
QA Contact: timeless → dom-inspector
(Reporter)

Updated

11 years ago
Flags: blocking1.9?
(Reporter)

Updated

11 years ago
Target Milestone: mozilla1.9 M9 → Future
(Reporter)

Updated

10 years ago
Assignee: sdwilsh → nobody
The horizontal scrollbar is covered by bug 112832.

WONTFIXing for the column ordering; just drag them around.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Summary: Reorder Dom Node Viewer Tree Columns and Enable Horizontal Scrolling → Reorder Dom Node Viewer Tree Columns
You need to log in before you can comment on or make changes to this bug.