- From: Zibi Braniecki <notifications@github.com>
- Date: Mon, 12 Oct 2015 09:52:18 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Message-ID: <whatwg/dom/issues/77/147459440@github.com>
Yeah, I see your point. I believe that the problem with MutationObserver is that most use cases I saw in our platform are the opposite of what MutationObserver API is designed for. It seems to be designed to help in cases where the mutation observer callback is interested in vast majority of nodes under given root element. I see MutationObserver as a tool for scenarios where the number of nodes of interest compared to amount of "traffic" is very, very low. L10n here is an exceptionally high ratio scenario, because one can argue that a lot of elements are localizable in a fully localizable UI. But MutationObserver is also the only way to properly shim a color picker, file picker, any other widget, mentioned `intl` API etc. and those will literally affect 4-5 elements in a document that may contain hundreds of nodes. In order to use MutationObserver efficiently as a shim, one would also want to enable it before parser is done with DOM and get the DOM from the Parser filtered. But that increases the number of nodes that can get mutations unless we can improve the filtering. So, while I agree with the concern, I believe that MutationObserver is special here - an API with a great potential to enhance the Web stack, that currently enables doing so at an unreasonable cost. --- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/77#issuecomment-147459440
Received on Monday, 12 October 2015 16:52:47 UTC