Bug 145807

Summary: Web Inspector: Better truncation for DOM tree navigation bar
Product: WebKit Reporter: Nikita Vasilyev <nvasilyev>
Component: Web InspectorAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: graouts, inspector-bugzilla-changes, jonowells, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
See Also: https://bugs.webkit.org/show_bug.cgi?id=145810
Attachments:
Description Flags
[Image] DOM tree path bar none

Description Nikita Vasilyev 2015-06-09 10:27:12 PDT
Created attachment 254577 [details]
[Image] DOM tree path bar

"E" icons take out space and they are not very informative. AFAIK, all but the last element in the path always have the "E" icon. I understand that it’s inspired by Xcode, but for this particular case it isn’t useful.

I propose to either:
– don't use any icons at all
– show icon only for the last element in the path

Yea or nay?
Comment 1 Radar WebKit Bug Importer 2015-06-09 10:28:07 PDT
<rdar://problem/21302898>
Comment 2 Brian Burg 2015-06-09 10:43:41 PDT
+1, I would also propose truncating components after the tag name when not enough space is available.

I guess a somewhat related usability issue is using <select> elements instead of our own styled widget makes any differences among siblings (in icon, or othrewise) pretty hard to see.
Comment 3 Timothy Hatcher 2015-07-30 11:52:32 PDT
I disagree with this change. In small window situations, you will deal with primarily truncated text, which isn't useful either.

We should stay consistent in our icon use. These icons appear in other places where we refer to DOM nodes, and it is a good visual cue that ties them together. Just like we want to make all function or native function have distinct icons, and not just a function name. The icon communicates what it is.
Comment 4 Timothy Hatcher 2015-07-30 11:53:52 PDT
(In reply to comment #2)
> +1, I would also propose truncating components after the tag name when not
> enough space is available.
> 
> I guess a somewhat related usability issue is using <select> elements
> instead of our own styled widget makes any differences among siblings (in
> icon, or othrewise) pretty hard to see.

We should make the selects support icons and nested submenus. Maybe add support for HTML5 <menu> for that?