Skip to content
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

[Custom]: Clarify in informative note that cloning/importing also enqueues created callback (bugzilla: 28092) #144

Closed
hayatoito opened this issue Jul 6, 2015 · 6 comments

Comments

@hayatoito
Copy link
Contributor

Title: [Custom]: Clarify in informative note that cloning/importing also enqueues created callback (bugzilla: 28092)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28092


comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28092#c0
Dimitri Glazkov wrote on 2015-02-24 15:50:47 +0000.

"a conforming UA must run enqueue created callback whenever creating a custom element."

The section title and informative note only talk about parser-driven element creation, but it doesn't mention cloning/importing that is also affected by the normative statement.

@rniwa
Copy link
Collaborator

rniwa commented Mar 1, 2016

Per Jan F2F, this should happen for all other DOM APIs.

@annevk : perhaps DOM or WebIDL specs need to provide some hooks for custom elements to use here?

@rniwa rniwa added the v1 label Mar 1, 2016
@annevk
Copy link
Collaborator

annevk commented Mar 1, 2016

Yeah, we should add syntax to IDL that allows us to run callbacks when IDL wants to return a specification-defined value to JavaScript. @heycam would it be best to file an issue or a bug against IDL for that?

@domenic
Copy link
Collaborator

domenic commented Mar 1, 2016

I think since this spec is just a giant monkeypatch anyway we should define the IDL syntax here (and any monkeypatches to use it, unless we want to move those sooner rather than later). We can move it into IDL as part of the larger merge effort.

@heycam
Copy link

heycam commented Mar 1, 2016

I think long term I would rather all places (like DOM, HTML, etc.) that create and return elements to explicitly enqueue the callback. Having a hook in IDL that can be invoked for every IDL-to-JS conversion feels like opening a big hole that we don't really need.

I'm fine with @domenic's suggestion to define something in Custom Elements for now.

@domenic
Copy link
Collaborator

domenic commented Mar 1, 2016

Can you explain? The plan of record was to use [CallsCustomElementCallbacks] or something on attributes and methods, instead of inserting a prose step at the bottom of all getter/setter/method definitions. IDL seems perfect for automating these kind of prose-gen things; it's certainly how implementations will be doing this.

@heycam
Copy link

heycam commented Mar 1, 2016

Sorry, I misread Anne's comment and skipped over the "add syntax" bit and thought the suggestion was to have a prose hook. Defining an extended attribute in Custom Elements to monkeypatch the IDL-to-JS conversion sounds OK.

@domenic domenic closed this as completed in 62c038f Mar 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants