-
Notifications
You must be signed in to change notification settings - Fork 611
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic Awesomplete? #17174
Labels
Comments
An alternative might be to use a custom element Web Components but the browser support isn't as good. |
Wishful thinking here, but why is the mutation observer interface
limited to listening for a generic change to an element? Wouldn't it
make sense to have observers for creation, deletion, and perhaps
mutation of nodes matching a *selector*? The browser is already
implementing such observation, since it has to update its rendering any
time such a mutation occurs. There just needs to be a way to piggyback
on that observation to trigger a listener.
…On 1/30/19 11:03 AM, Lea Verou wrote:
@karger <https://github.com/karger> just brought this up. He was using
an Awesomplete input as an editor template for Mavo and it wasn't
working, since these awesomplete elements were created after startup.
It is possible (and fairly easy) to use a MutationObserver to observe
for new elements that match |input.awesomplete| and have not been
initialized yet and initialize them. However, that means we'd need to
have a mutation observer on the entire |<body>| element that listens
for every single node being added (|subtree: true|), which worries me
performance-wise.
Another way to do it would be to have an event listener on |<body>|
for the |input| event, which would be used for both Awesomplete
functionality as well as to check if the target matches
|input.awesomplete| and has not been initialized yet. This is likely
more performant (since it's throttled by biology), but trickier to
implement and still listens to events on the entire document. Also,
keeping inputs uninitialized until first used may have unintended
consequences for some use cases.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17174>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ABFpXgaHPJROVUCViLD7bPWuPS48v-lJks5vIcJZgaJpZM4aahQb>.
|
@karger If you want to argue that case, argue it to the WHATWG guys who can actually do something about it: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@karger just brought this up. He was using an Awesomplete input as an editor template for Mavo and it wasn't working, since these awesomplete elements were created after startup.
It is possible (and fairly easy) to use a MutationObserver to observe for new elements that match
input.awesomplete
and have not been initialized yet and initialize them. However, that means we'd need to have a mutation observer on the entire<body>
element that listens for every single node being added (subtree: true
), which worries me performance-wise.Another way to do it would be to have an event listener on
<body>
for theinput
event, which would be used for both Awesomplete functionality as well as to check if the target matchesinput.awesomplete
and has not been initialized yet. This is likely more performant (since it's throttled by biology), but trickier to implement and still listens to events on the entire document. Also, keeping inputs uninitialized until first used may have unintended consequences for some use cases.The text was updated successfully, but these errors were encountered: