- From: Andrew Rottier <notifications@github.com>
- Date: Fri, 03 Apr 2020 11:57:03 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/398/608605490@github.com>
> For easy of use and consistency with [`attributeFilter`](https://dom.spec.whatwg.org/#dom-mutationobserverinit-attributefilter) which doesn't callout that it's a local name, I'd suggest `elementFilter` as the name of the filter. I am open to either name for this. > We'd now have to consider what happens when both attributeFilter and elementFilter are set. One interpretation is that they're independent. We'd be monitoring insertion and removal of elements of specific types, and any changes to a set of attributes. Alternatively, they combine. We'd be only observing changes to attributes on elements of specific types. I have drafted a PR that implements an intersection of elementHasAttributeFilter & elementLocalNameFilter when both are present. This applies the filter to the addedNodes and removedNodes field. Depending on which implementation strategy is chosen for integrating these features with attributeFilter, I believe it would be best to run each filter, one by one, on the nodes observed in the mutation event, asserting that either addedNodes or removedNodes list is not empty between after each filter that is applied. Regardless of what is favored for mixing filters (union or intersection), I think it should be consistent for all combinations of filters. Personally, I believe intersection is easier to use. Another option is to have an additional operand option which allows the implementor to chose how to combined filters themselves. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/398#issuecomment-608605490
Received on Friday, 3 April 2020 18:57:17 UTC