Especially once bug 17772 lands, it would be useful to display the "element#id.class" string from the breadcrumb bar on the node highlight itself. We may not want it to be visible by default, but would definitely be useful with a modifier key.
I like this idea! Always visible seems fine, or always when in Node Search mode.
This simple request needs thorough UI design (cross-platform, title layout/font, etc.)
Created attachment 63083 [details] [IMAGE] Screenshot of a node description displayed. This is a suggested description appearance: <nodeName#id.class1.class2...classN> [offsetWidth x offsetHeight]. Timothy, could you have a look at it and suggest something wrt the UI/data presentation?
Some quick comments: I think showing this note in the middle of the box would be better and be less likely to be clipped. If you show it in the middle I don' think it needs a box around it, maybe just bolder text or a text shadow. Showing the node text in <> is odd, since it is an invalid tag when there is an id or class name. Just drop the <> or something smarter. Don't use "x" for pixel size, use ×. It is odd to give just one size, since there are multiple deminisions when padding and margin, what does this size include?
(In reply to comment #4) Thanks for taking a look! > Some quick comments: > > I think showing this note in the middle of the box would be better and be less likely to be clipped. If you show it in the middle I don' think it needs a box around it, maybe just bolder text or a text shadow. Rendering the label in the middle risks obscuring border/margin rectangles for small elements (esp. narrow ones, should they have a lot of style classes) but I seem to have seen this approach elsewhere so this might work ok. Without any background, it's going to be quite messy since it may overlay some existing text or image containing a similar pattern in the label area, even with a shadow (I've tried it out). > Showing the node text in <> is odd, since it is an invalid tag when there is an id or class name. Just drop the <> or something smarter. Yes, we were just sitting there experimenting, and this was one state snapshot. I don't know if there's something good we can use to enclose the text, guess should just drop the <>. > Don't use "x" for pixel size, use ×. It is odd to give just one size, since there are multiple deminisions when padding and margin, what does this size include? This text is rendered in the native code (TextRun), so have to look up what × corresponds to. This size includes [offsetWidth x offsetHeight]. Do you have any suggestions on how to layout multiple sizes/more data in this "tooltip" area?
This bug is related to bug 17221
Created attachment 67781 [details] [IMAGE] Screenshot of a fixed node description. The new screenshot addressed the "times" and element identifier format issues. Please speak up.
PFELDMAN, PLEASE DO SPEAK UP :)
Looks good to me, send the patch for review!
Created attachment 67896 [details] [PATCH] Suggested solution
Attachment 67896 [details] did not build on chromium: Build output: http://queues.webkit.org/results/4022041
Created attachment 67898 [details] [PATCH] Chromium compilability fix
Comment on attachment 67898 [details] [PATCH] Chromium compilability fix View in context: https://bugs.webkit.org/attachment.cgi?id=67898&action=prettypatch > WebCore/ChangeLog:5 > + Show node description in inspector highlight Web Inspector: prefix. > WebCore/inspector/InspectorController.h:35 > +#include "FloatRect.h" Use forward declarations instead.
Committing to http://svn.webkit.org/repository/webkit/trunk ... M WebCore/ChangeLog M WebCore/inspector/InspectorController.cpp M WebCore/inspector/InspectorController.h Committed r67703