On 8/07/11 10:21 PM, Sean Hogan wrote:
On 8/07/11 8:28 AM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 3:21 PM, John J Barton
<johnjbar...@johnjbarton.com> wrote:
Jonas Sicking wrote:
We are definitely
short on use cases for mutation events in general which is a problem.
3. Client side dynamic translation. Intercept mutations and replace or
extend them. This could be for user tools like scriptish or stylish,
dev
tools to inject marks or code, or for re-engineering complex sites
for newer
browser features.
I don't fully understand this. Can you give more concrete examples?
A couple of comments on these use-cases:
- MathJax (http://mathjax.org) is a JS lib that facilitates putting
math onto the web by converting LaTeX or MathML markup in a page to
HTML. By default MathJax triggers off the onload event to run this
conversion on the page. When content containing math is dynamically
added to the page, MathJax must be called manually to convert the new
content. A DOM insertion listener could potentially be used to handle
this conversion automatically.
- A similar use-case is element augmentation too complex for CSS
:before and :after
The previous cases respond to content being inserted into the page by
(potentially) adding more content. Ideally these additional insertions
wouldn't trigger additionally mutation listeners. I guess the current
event system facilitates this with stopPropagation().
- ARIA support in JS libs currently involves updating aria-attributes
to be appropriate to behavior the lib is implementing. Attribute
mutation listeners would allow an inverse approach - behaviors being
triggered off changes to aria-attributes.
As has been mentioned, listening for attribute mutations is horrendously
inefficient because your handler has to receive every mutation, even if
only interested in one attribute.
- DOM insertion and removal listeners could facilitate the
implementation of automatically updating Table-of-* (Headings / Images
/ etc).
