the local-name function uses prefixed names instead of local names about wicked-good-xpath HOT 7 CLOSED

Well, I found the code. ^^'

http://code.google.com/p/wicked-good-xpath/source/browse/trunk/functionCall.js
Line 345:
  LOCAL_NAME: wgxpath.FunctionCall.createFunc_('local-name',
      wgxpath.DataType.STRING, false, true, false,
      function(ctx, opt_expr) {
        var node = opt_expr ? opt_expr.evaluate(ctx).getFirst() : ctx.getNode();
        return node ? node.nodeName.toLowerCase() : '';
      }, 0, 1, true),


I would just go ahead and fix this, but I'd like someone to verify that, yes, 
local-name SHOULD return DOM's localName instead of the potentially prefixed 
nodeName.

Thanks for the report. Please attach a sample HTML page to this issue on which 
the bug can be reproduced.

Here you go.

This HTML page contains some prefixed nodes, and then outputs their respective 
local-names and names.
As a bonus, each node tries to query itself using the syntax 
"self::ns:element", which doesn't work in wgxpath and seems to be related to 
this local-name thing.

The output in Firefox, Chrome and Opera is:
<wgx:element>
  [object Element]
  XPath local-name():
    element
  DOM localName:
    element
  XPath name():
    wgx:element
  DOM nodeName:
    wgx:element
  XPath self::wgx:element:
    [object Element]

(Which, as far as I can tell, is in accordance with the spec.)

Whereas the output in IE11 is:

<wgx:element>
  [object Element]
  local-name():
    wgx:element
  DOM localName:
    element
  name():
    wgx:element
  DOM nodeName:
    wgx:element
  self::wgx:element:
    null

(I am especially bugged by the last point, since that is what is currently 
breaking my app. ^^')

Thanks for looking into this!

(Ah, that last comment was by me, forgot to switch accounts, sorry. ^^')

For this bug to be exhibited the document has to be XML (like XHTML) not HTML, 
so this falls partially under the "support for XML documents" feature request. 
This is fairly low-hanging fruit to fix, though, so I'll do it, and then maybe 
make further progress toward completing that feature request.

...oh. Sorry, it's been a while since I've worked with text/html, I wasn't even 
aware that XPath's functions (or the DOM attributes related to them) behave 
differently there.

For the sake of completion, here is the same test case as HTML. Here, wgxpath 
does indeed behave almost identical to the XPath Implementations of Firefox and 
company.
Namely, the namespace prefix is part of the local name, and querying by prefix 
doesn't work. Differences in upper/lowercase fall under HTML's YOLO philosophy, 
I guess.

Fixed in the latest install file.