Re: [w3c/webcomponents] accessibility considerations: states and behaviors (#567)

@domenic

If you’ve read my entire proposal, you’d see that I suggest an imperative way to manipulate states as well:

> Any of a `constructor`, a `connectedCallback`, an `atrributeChangedCallback` or a `disconnectedCallback` property of the “behavior options object” would take a function that’d be called immediately after (or immediately before) the corresponding life‐cycle callback function of the element the behavior is applied to. Within these functions, the `this` object would be a special “behavior object”. This “behavior object” exposes an `element` property (returns the element the behavior is associated with), and a `setState(string, boolean|null)` method, which sets a state for that behavior to true or false; `null` would mean “use the defined `matches` string for that state”.

That is, I could create a toggleable behavior like this:

```Javascript
customElements.defineBehavior("my-toggleable",
{
    constructor()
    {
        let t = this;
        t.active = false;
        t.element.addEventListener("click", ()=>
        {
            t.setState("active", t.active = !t.active);
        });
    }
    active:
    {
        matches: ":not(*)"
    }
});
```

----------

> Functions are not a global string indexed registry, because you can declare them in more than one scope.

Wat do you mean?

---------

@WebReflection

The idea is to allow custom elements to act as built‐in elements without depending on them. That is, all built‐in elements would be reproducible by using built‐in behaviors, and all built‐in behaviors would be reproducible by custom behaviors.

This would make the platform feel much more regular, by making built‐in elements feel like they are made with the same features available to authors.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/567#issuecomment-247070731