Comment 1 Boris Zbarsky [:bz] (TPAC) 2011-04-13 07:14:25 PDT

Is this web-compatible?  I thought browsers had converged on getAttribute and getAttributeNS returning "" and the DOM spec just hadn't been errata'd accordingly (and that Web DOM Core was going to make that change).

Comment 2 :Ms2ger (⌚ UTC+1/+2) 2011-04-13 07:55:03 PDT

Almost. Browsers have converged on getAttribute returning null, while DOM specs required the empty string. (<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-666EE0F9>.) IIRC, there was no consensus either way for getAttributeNS, but it seems to make more sense to have them consistent.

Comment 3 Boris Zbarsky [:bz] (TPAC) 2011-04-14 12:28:04 PDT

Oh, ok.  so I just had it backwards.  Gotcha.

Comment 4 :Ms2ger (⌚ UTC+1/+2) 2011-06-13 12:47:51 PDT

*** Bug 382786 has been marked as a duplicate of this bug. ***

Comment 5 Peter Van der Beken [:peterv] 2011-10-17 06:54:58 PDT

Comment on attachment 525645 [details] [diff] [review]
Patch v1

How woudl you feel about doing this in GetAttr instead? There shouldn't be too many implementations of that.

Comment 6 :Ms2ger (⌚ UTC+1/+2) 2011-10-18 10:53:24 PDT

That works for me. (I understood void strings to be frowned upon except for passing to JS directly, though.)

Comment 7 :Ms2ger (⌚ UTC+1/+2) 2012-01-08 05:58:02 PST

Created attachment 586800 [details] [diff] [review]
Patch v2

Comment 8 :Ms2ger (⌚ UTC+1/+2) 2012-01-10 01:18:42 PST

Comment on attachment 586800 [details] [diff] [review]
Patch v2

Yeah, no. This makes reflected attributes return null, and that breaks the web.

Comment 9 :Ms2ger (⌚ UTC+1/+2) 2012-03-11 03:17:38 PDT

https://hg.mozilla.org/mozilla-central/rev/1eab6ae9e060

Comment 10 Eric Shepherd [:sheppy] 2012-04-29 10:56:32 PDT

Docs updated:

https://developer.mozilla.org/en/DOM/element.getAttributeNS

Mentioned on Firefox 13 for developers.