For example, should it be

const el = document.querySelector('div')

// suppose el is <div has="foo bar baz">

el.behaviors.add('click-logger')
el.behaviors.remove('foo')

// now el is <div has="bar baz click-logger">

which means .behaviors would exist on Element.prototype, or should it be something like

const el = document.querySelector('div')

// suppose el is <div has="foo bar baz">

elementBehaviors.of(el).add('click-logger')
elementBehaviors.of(el).remove('baz')

// now el is <div has="bar baz click-logger">

It seems like a global map would be easier to optimize, rather than increasing the size of the prototype of all elements by default. ?

Hi,

First of all, thanks for this library. I really love the concept and it is a nice, logical extensions of custom elements.

However, I found that the behaviors do not work if the element is added before the library load. The scripts we are using are automatically added as "defer" scripts to load in a non-blocking way (we do not have control over the loading mechanism of the scripts).

Is this a known issue of the library? Unfortunately if that's the case I likely won't be able to use the library, but I hope this will give some ideas to browser implementers :).

I like the has="" attribute but I'm wondering if it doesn't make sense to go for "data-has". In the example with the player's position this makes even more sense to me. That way you can drop the dependency on custom attributes.

Hi :)

I was taking a look at the spec and was wondering how easily I could migrate my code to the spec should it land.

For example, with most my Web components I use a mixin pattern. It's pretty similar with how the behavior systems.

Some mixins are rather simple, but some can get complex and even chain. For example, I have:

• AriaReflectorMixin
• AriaToolbarMixin
• InputMixin
• ControlMixin
• FormAssociatedMixin
• KeyboardNavMixin
• TextFieldMixin
• ThemableMixin
• StateMixin
• ResizeObserverMixin

Each mixin takes a the custom element's class and extends it. It then goes to work. But some mixins will mixin another mixin before extending. For example, ControlMixin will mixin FormAssociatedMixin. InputMixin will mixin ControlMixin. That's pretty transitive. I imagine it's a matter of class ControlBehavior extends FormAssociatedBehavior.

But some mixins expect another mixin to have been applied first (dependencies). For example, my most complicated setup, I have three CustomElements:

• XInputElement
• XTextAreaElement
• XSelectElement

They all reference TextFieldMixin which serves as branching point for mixins. Both XTextAreaElement and XSelectElement will use the ControlMixin, but XInputElement will use the InputMixin. They each also have a host of other mixins (like StateMixin).

This is mostly dealing with component definition, though runtime behaviors would definitely help with a mixin I have called TooltipTriggerMixin which I just apply to IconButton by default. It's better if it's done at runtime for any component.

Question 1:

What happens if a redundant behavior is listed?

<x-custominput has="themable state input textfield resizeobserver">
<x-custominput has="themable state control input textfield resizeobserver">

Question 2:

Do behaviors load after or before an element is defined? (I assuming before, or else how would observedAttributes work.)

Question 3:

Can behaviors be defaulted for elements? (Can behaviors be used to simplify Web Component design/definition). Once a component is finalized with its behaviors, I don't expect authors to have to include them each time.

Thanks for sharing your work with the public. If you're interested in taking a look at the mixin structure I'm talking about, I added links above. (The .mixin() and .extend() are just aliases which I find help write more declaratively, but everything can be rewritten in class/extend structure).

When connecting an input element I wrap the tag in a span and this causes the input element to be attached again in an infinite loop.

A temporary fix to this that I did was to change the code around this line:

with the following code:

if (!Behavior || (this.ownerElement._attached || []).includes(name))
        return;
const behavior = new Behavior(this.ownerElement);
if (!this.ownerElement._attached) {
  this.ownerElement._attached = []
}
this.ownerElement._attached.push(name)

Maybe there is a better solution? I don't know. But it works for now.

It is interesting to note that the version used in the code pen example in the docs doesn't have this behavior. It only occurs in the latest version.