It is atomic. Do you mean node creation and setting attributes need to be coupled somehow into a new operation?

I thought the way this was going to work was that we'd use the "created" callback from custom elements, which would be handled a tad later and therefore there would be no problem with when attributes are set.

I use terminology like "When the element is created..." a lot. How would this work in a "created callback"-style world?

Dimitri, if we are to explain existing elements in terms of components, how would you answer the question in comment 2?

(In reply to Anne from comment #3)
> Dimitri, if we are to explain existing elements in terms of components, how
> would you answer the question in comment 2?

For custom elements, you're exactly right. Creating an element and running its created callback occur at two different quantums of time, so yes, when the callback runs, the attributes will be already set.

For existing HTML elements, it's a darn good question. If we look at the way browsers implement them, we'll see the need for more immediate/synchronous invocation of these callbacks.

Right now, I am playing with of extracting the time shift between creation and callback invocation into a barrier abstraction: https://github.com/dglazkov/html-as-custom-elements#callback-barriers

The idea would be that we impose this barrier on author-created custom elements, but let HTML elements' callbacks be invoked immediately.

The correct long term fix here seems to be for DOM to have a set of hooks:

* created
* inserted
* removed
* adopted
* base URL changed
* attribute changed

And then to write element specifications in terms of these hooks. Perhaps even as a dedicated section per element. That would make things crystal clear.

Domenic, will your custom elements work solve this, or is there more work needed after that is done?

It's not clear to me what the actual bug is here. As you say in comment #1, cloning is atomic. As for comment #2, I don't believe any "When the element is created..." instances in the spec applies to any custom elements.

So I think the actual bug here in DOM would be HTML and browsers having different behavior between these two cases:

* An element is created with one or more attributes
* An element is created, one or more attributes are set

I forgot which element might have this kind of thing and whether that is still an issue. Does anyone know?

FWIW, customized built-in elements are like this:

createElement('div').setAttribute('is', 'foo-bar')

does not create a customized built-in element; parsing

<div is="foo-bar">

which sets the attributes "at once" does create a customized build-in element. This is why createElement needs the ElementCreationOptions.

Wearing my Blink implementer hat, we have separate code paths for parser-set attributes and author set ones. Different behavior arising out of that is a possibility.

So https://dom.spec.whatwg.org/#concept-node-clone does handle customized built-ins, but doesn't handle any other cases we might have.

Ideally for anything else implementations have the same setup as we advice to authors of custom elements. Namely that when constructing the element you don't depend on any attributes and instead use the attribute callbacks for that.

Is there any way we can find out for which elements such a setup would be unworkable?

I took a look through Blink source; here are the special cases:

- style: setting style attributes by cloning is allowed; otherwise CSP may disallow it.
- is: customized built-in elements
- something for input type parsing, but I think it is just an optimization

I would like to know if the CSP behavior for style attributes is a feature or a bug. It seems like that would a bug if you have accidentally clone a user-controlled node and thereby end up applying the styles that were previously blocked.

If it's feature, we could add some kind of hook for it in DOM/CSP.

Moving this to https://github.com/whatwg/dom/issues/613.