Bug 16563 - attributeFilter should apply only to non-namespaced attributes
attributeFilter should apply only to non-namespaced attributes
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: DOM
unspecified
PC Linux
: P2 normal
: ---
Assigned To: Anne
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-28 22:36 UTC by Olli Pettay
Modified: 2012-04-23 08:09 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olli Pettay 2012-03-28 22:36:05 UTC
Namespaced attributes are rare, and if someone really wants to
observe changes to namespaced attributes, it is always
possible to observe all the changes.
Comment 1 Rafael Weinstein 2012-03-29 01:53:40 UTC
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?
Comment 2 Olli Pettay 2012-03-29 04:09:58 UTC
Jonas wanted this...
Comment 3 Anne 2012-03-29 07:09:16 UTC
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.
Comment 4 Olli Pettay 2012-03-29 14:04:27 UTC
Er, that sounds like a bug. The API was supposed to work on localName, at least
that was the original idea.
Comment 5 Olli Pettay 2012-03-29 14:11:38 UTC
And both Gecko and Webkit seem to operate on localName.
Comment 6 Rafael Weinstein 2012-03-29 16:46:14 UTC
Jonas?
Comment 7 Jonas Sicking 2012-04-06 21:45:07 UTC
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.
Comment 8 Anne 2012-04-07 08:04:29 UTC
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.
Comment 9 Olli Pettay 2012-04-07 08:17:10 UTC
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.
Comment 11 Olli Pettay 2012-04-07 09:04:12 UTC
(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.
Comment 12 Rafael Weinstein 2012-04-09 19:14:30 UTC
ok. I'm convinced. WebKit bug here: https://bugs.webkit.org/show_bug.cgi?id=83496
Comment 13 Ryosuke Niwa 2012-04-09 20:43:53 UTC
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.
Comment 14 Anne 2012-04-21 10:32:09 UTC
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.
Comment 15 Olli Pettay 2012-04-21 11:02:36 UTC
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.)
Comment 16 Anne 2012-04-23 08:09:21 UTC
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.