My favorites | Sign in
Project Home Wiki Issues
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 2497: No sane way to figure out the namespace of a node or attribute
4 people starred this issue and may be notified of changes. Back to list
Project Member Reported by, Nov 18, 2009
There is no sane way to figure out what the namespace of a given node or
attribute is. In DOM Inspector the former is listed automatically when
inspecting a node, and the latter is easily reachable via the "edit" option
in the context menu on attributes...

Notes from the e-mails I sent john at some point:

Ideally, the namespace would be copy/pastable.

Even more ideally, Firebug would know about the common namespaces, and flag
cases where the namespace is similar to a common one but not identical
(e.g. extra trailing '/' or missing trailing '/', since the W3C namespaces
are not consistent on whether that should be present). 

Trying to use the DOM sidebar for this is a huge pain, since it involves at
the very least scrolling down to get to namespaceURI, for each node.
Nov 18, 2009
Project Member #1 sroussey
Any ideas on a UI?
Cc: sroussey
Nov 18, 2009
Project Member #2 sroussey
(No comment was entered for this change.)
Status: New
Owner: ---
Cc: bzbarsky
Labels: Type-Enhancement html 1.5
Nov 19, 2009
Project Member #3
A screen shot from DOMi would help to understand what currently works.

UI issue: need to be able to copy the namespace as I understand it.

Tooltip would be feasible, not currently used in HTML panel it seems.
Context menu would be ok? eg tooltip for read, Context menu for Copy Namespace.

Another idea would be a DOM side panel option Show Namespaces. If this is selected,
and nothing else, then the DOM panel would show just the namespace. Plus it could
show just a few other things related, based on users like Boris.
Status: Triaged
Nov 19, 2009
Project Member #4 sroussey
Based on the other issue, one of the things was to recognize bad namespaces. Boris,
what are the good namespaces to recognize? One option is to recognize the namespaces
that Firefox can render (xhtml/svg/mathml -- are there others?) and have them color
coded so you can spot them immediately. And color code un-recognized as red.

Another thing is that we could add another tab (possibly via extension), or a header
area for the DOM tab of the html panel (optional) that gives the very basic: node
type, namespace, and tag name (like DOMi). 

My preference would be the optional header idea for DOM. And color-coding. :)
Nov 19, 2009
Project Member #5 sroussey
Capture from DOMi
6.0 KB   View   Download
Nov 23, 2009
Project Member #6 sroussey
Of course, I forgot that Fx also has XUL and other internal structures. Any others
missing? Thoughts on comment #5?
Cc: -bzbarsky
Nov 23, 2009
Project Member #7
In terms of namespaces to recognize, the XUL one is ok; other than that you want
probably xhtml, xlink, xmlns, xml, svg, mathml as a good start.

Not sure what thoughts I can have on comment 5 other than "it shows more info than
firebug does, and is exactly the info I want, modulo mis-spelled namespace stuff".

Maybe I mis-remembered; it sounds like the xhtml/svg/xlink/mathml namespaces at least
have no trailing '/'; it's wort explicitly flagging a namespace that differs from
those by having a trailing '/', since that's where you end up if you search for these
Oct 27, 2010
Am I missing something here? Because tags and attributes with namespaces are already shown inside the node view (tested with FF 3.6.11 + FB 1.6 (SVN)). Use as an example. Isn't that enough?
The only thing, that could be changed is to be able to seperately edit the namespace of a node or attribute. This should be covered in issue 2645.
Oct 27, 2010
Project Member #9
> Am I missing something here?

Apparently, yes.

> Use as an example.

Using that, I don't see the XUL namespace listed for the <script> that's the child of <window>, say.  This is in the "HTML" panel.  So where are you seeing namespaces, exactly?
Oct 27, 2010
Project Member #10
Oh, I'm using 1.6b2, btw.
Oct 27, 2010
Ok, so this issue is about showing the namespace  for all nodes and attributes even for the default namespace (XUL in the example).
Then I would agree with John's suggestion (tooltip + context menu option) in comment 3.
Another way would be to show it inline, but so, that it's not interfering with the nodes. Also the difference between explicitly defined namespaces (<html:h1> in the example) and the ones mentioned above should be clear. Therefore an option "Show Namespaces" for the HTML panel would switch between the current node view and the one described.
Oct 27, 2010
Project Member #12
It's about showing the namespace the node is in.  The concept of "default namespace" is a parse-time only concept; if I create a DOM tree using createElementNS there might be nodes in namespaces all over, with no xmlns attributes anywhere.

> Also the difference between explicitly defined namespaces (<html:h1> in the example)
> and the ones mentioned above should be clear.

Oct 27, 2010
Project Member #13 sroussey
Hmmm... I forgot all about this. I looked at the "DOM"/Object property viewer code recently, and can now probably do this. It would be for the DOM side panel to the HTML panel only.
Oct 27, 2010
>> Also the difference between explicitly defined namespaces (<html:h1> in the example)
>> and the ones mentioned above should be clear.
> Why?

Because the node view is showing the source as it is and I think this shouldn't be changed. If needed, I can create a mockup of how I am imagining this.
Oct 28, 2010
Project Member #15
> Because the node view is showing the source as it is

No, it's not.  It's showing some serialization of the DOM, and possibly a nonsensical one, depending on how it's generated.

In particular, for elements created with createElementNS what it's showing now may well have nothing to do with reality.  Because what it shows is the node's _prefix_ and not the node's _namespace_.  But prefixes are irrelevant per se; what matters is the namespace they map to.  It's an annoying feature of XML, but it's there.

Here's a small HTML file that shows what I'm talking about.  The node has prefix "barprefix" and an xmlns:barprefix attribute which maps that prefix to the namespace "bar".  But the node itself is in namespace "foo", and the default namespace for the node is "baz".  The string "foo" is what matters for figuring out how the node will behave, and is the one thing Firebug is NOT showing.  It's prominently showing the string "barprefix", but that string is only meaningful at parse time, and only using the namespace mappings present at parse time (e.g. if a node is moved in the DOM it'll keep its prefix and namespace, but the namespace the prefix maps to depends on the parents and can change when the node is moved).

Showing the actual node prefix for a DOM is, imo, actively harmful...

Now showing common namespaces as their canonical prefixes might not be a bad idea at all, on the other hand.  Would help people catch spelling errors in them, possibly.
304 bytes   View   Download
Oct 28, 2010
Ok, that's the problem when the people are not using the same terminology. I'm sorry, I didn't clearly seperate between prefixes and namespaces in my former comments, though I think we meant the same.
Non-the-less the question is still: Show the namespace inline, as tooltip or inside a side panel as John was stating in comment 3? I think showing this inside the DOM side panel or a seperate side panel is not the best choice, because attribute can be of another namespace.
Oct 28, 2010
Project Member #17 sroussey
Boris, how would you like it to show? Mockup?
Oct 28, 2010
Project Member #18
 R8203 post pends namespaceURI to xpath for HTML panel  for 1.7a5 next Monday

Does this relate to the request ?
Oct 28, 2010
Project Member #19
screen shot after r8203
7.4 KB   View   Download
Oct 28, 2010
Project Member #20
> Boris, how would you like it to show? Mockup?

I'm not in the UI design business, sorry, for good reason.  I've tried it before, and things that seem to work for me seem to be disasters for others.  So all I ask for is that the information be available; I'm not going to dictate UI.

The screenshot is reasonable if that text can be copied and pasted.
Oct 28, 2010
I could create a mockup for the inline version, but I think the simple solution of John is already good enough.
Oct 29, 2010
Project Member #22
I don't know of any way to copy the tooltip into the clipboard.

I looked into XPath to see if we could upgrade our Copy XPath to include namespaces, but I can't find any info on how XPath qualifies path elements with namespaces.

I suppose we could extend right click Copy XPath, that would result in either the string I put in the tooltip or fully expanded XPath (if we knew how to format the latter).

Or we could right click Copy Namespace, just the URL.
Oct 29, 2010
Project Member #23 sroussey
I think we can add a header area to the DOM panel when node is not in the same namespace as the document root. That would show some of this vital information (which is not vital when all nodes are the same, which is the common case). This would be in addition to the tooltip (the tooltip is nice since you don't have to first click and select the node you want info on). See attachment for example of selecting a math element inside an xhtml document.

The other idea is to do what I do in my extension, since this same sort of thing bothers me: prioritize certain properties to show up at the top. I do this myself -- you can see an example in the Properties side-panel here:
17.1 KB   View   Download
Nov 7, 2010
Project Member #24 sroussey
Hey Boris, here you go. Just add this extension to Firefox and another side panel with appear in the HTML panel. It is not pretty, but it works in Firebug and Chromebug. And the source is tiny, so it should be easy to customize.
4.4 KB   Download
Nov 15, 2010
Project Member #25
(No comment was entered for this change.)
Cc: odvarko
Dec 3, 2010
Project Member #26 sroussey
Oops, the elementinfo.xpi extension needed a change to firebug I forgot to commit. See r8642.
Mar 23, 2013
Project Member #27
(No comment was entered for this change.)
Sign in to add a comment

Powered by Google Project Hosting