It seems like the options here are that all attributeFilter values have

1) An implicit null namespace
2) An implicit * namespace

This bug is suggesting that (1) is preferable. What's the reason?

Jonas wanted this...

The argument on IRC was that you could not distinguish between "xlink:value" and "value", but this API works on the attribute's name, not it's local name, so that argument does not hold.

Er, that sounds like a bug. The API was supposed to work on localName, at least
that was the original idea.

And both Gecko and Webkit seem to operate on localName.

Jonas?

Given how very rare namespaced attributes are, I really see very little reason to make "sugar features" like the attribute filter work with them.

If someone really needs to observe a namespaced attribute they can do that by not having a filter.

Making the filter work on the name rather than localName doesn't seem to help people that want to do the right thing, since then you should be observing a specific localName+namespace.

To answer comment 1, the reason an implicit * namespace doesn't make sense is that there no more commonalities between attributes with a "value" localName, but different namespaces, than attributes whose name end with "er".

If someone requests to only be notified about changes to the "value" attribute, they are unlikely to check that the change was to an attribute in the null namespace, and so would get tripped up by changes to an "xlink:value" attribute.

Right, but they would not get tripped up if you do not observe the attribute's local name, but its name. And given we have a few "namespaced attributes" in HTML where the attribute's name is fixed (e.g. xlink:href, otherwise it would not work with the HTML parser), that seems more useful to me.

Both current implementations work on localName - if my test is correct and does 
the right thing also in webkit - and I actually ended up adding this
namespace handling limitation to gecko implementation, since I thought this 
wouldn't be controversial at all.


(In reply to comment #8)
> Right, but they would not get tripped up if you do not observe the attribute's
> local name, but its name. And given we have a few "namespaced attributes" in
> HTML where the attribute's name is fixed (e.g. xlink:href, otherwise it would
> not work with the HTML parser), that seems more useful to me.
How so? You can add xlink:href to for example svg using
setAttributeNS using no namespace prefix.

http://www.whatwg.org/C#adjust-foreign-attributes

(In reply to comment #10)
> http://www.whatwg.org/C#adjust-foreign-attributes

That is only about parsing.


Another option is to support prefixes in the filters, so that
when the filter is set, prefixes are resolved using the
observed node as ns resolver. But that gets just complicated.
We want to get rid of namespaced attributes eventually.

ok. I'm convinced. WebKit bug here: https://bugs.webkit.org/show_bug.cgi?id=83496

I can see a value in supporting namespaced attribute names in the filter for SVG, MathML, etc... but they can just observe all attribute changes as Jonas and Olli have pointed out so I'm fine with that as well.

Although, in that case, maybe we want some way to exclude style attribute and SVG animation attributes not to make the performance pathological.

The problem I have with this is that the ideal Attr API is Attr.name and Attr.value. MutationRecord is in fact based on this using attributeName.

Now unfortunately Attr.name is not the local name of Attr, but local name plus a prefix. Making "name" sometimes stand for one thing and sometimes for the other is confusing I think.

When I wanted records to have attributeNamespace, I certainly had in mind that
attributeName would refer to localName.
Since the record has both namespace and name, I think it shouldn't be
too confusing to which name the attributeName refers to.
(Implementors both seemed to think localName.)

http://dvcs.w3.org/hg/domcore/rev/8ec7c5b30498
http://dvcs.w3.org/hg/domcore/rev/108ddf1d9234

Please review though. These are kind of icky changes.