Re: [whatwg/dom] Attributes not ready on element construction? (#522)

> the constructor should be used to set up initial state and default values, and to set up event listeners and possibly a shadow root.

That one sort of conflicts with `The element's attributes and children must not be inspected`. I would consider default attribute values as default values. So for now, I am using a MutationObserver (the one in custom-attributes) to wait for attributes and, if the one that I want to have a default value doesn't exist, to create the attribute with default values so that default Custom Attribute effects can be triggered.

As long as I properly document this in my Custom Element documentation, I don't really see this sort of thing as a problem. F.e.,

> If you don't supply the `foo` attribute, it will have a default value of `"bar"`.

In my case, I've got Custom Element for rendering WebGL (similar to A-Frame, but more general purpose not specifically for AR/VR). We can write this:

```html
<i-scene experimental-webgl="true">
    <i-mesh has="sphere-geometry basic-material" receiveShadow="true" size="5" position="..." rotation="...">
    </i-mesh>
<i-scene>
```

but in order to make things simpler to get started with, without having to figure out all the things that are required to have something appear on the screen, the user can write

```html
<i-scene experimental-webgl="true">
    <i-mesh position="..." rotation="...">
    </i-mesh>
<i-scene>
```

in which case the `has=""` attribute will be created with a default value of `"box-geometry phong-material"` and will be lit by default lighting. Element inspector will show `has="box-geometry phong-material"`.

The `has` attribute can be changed later without any problem. 

Sidenote: Think of `has` as an "entity component system" but I'm caling it "Element Behaviors", as [detailed here with examples](https://github.com/w3c/webcomponents/issues/662#issuecomment-327945806). Each listed behavior is like a Custom Element, with similarly-named callbacks that receive the element instance. These behaviors react to attribute changes. It's much much nicer than the troubled `is=""` attribute, and allows for more than one class to be associated with an element (like jQuery allows too, but imperatively rather than declaratively).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/522#issuecomment-339164612