Re: [w3c/webcomponents] Add custom states and :state() pseudo class proposal (#832)

domenic approved this pull request.

Looking great, with some nits!

> +## Example
+
+```html 
+<!DOCTYPE html>
+<body>
+<script>
+class LabeledCheckbox extends  HTMLElement {
+  constructor() {
+    super();
+    this._internals = this.attachInternals();
+    this._checked = false;
+    this.addEventListener('click', this._onClick.bind(this));
+
+    this._shadowRoot = this.attachShadow({mode: "open"});
+    this._shadowRoot.innerHTML =
+      "<style>\

You can use multiline strings instead of adding \ at the end. https://jack.ofspades.com/multiline-strings-in-es6-javascript/


> @@ -0,0 +1,105 @@
+# `ElementInternals.states` and the `:state()` pseudo class
+
+Author: @rakina, @domenic
+
+## Introduction
+
+Built-in elements have certain “states” that can change over time depending on user interaction and other factors, and are exposed to web authors through pseudo classes. For example, some form controls have the “invalid” state, which is exposed through the `:invalid` pseudo class.
+
+Like built-in elements, custom elements can have various states to be in too, and web authors might want to expose these states in a similar fashion as the built-in elements. With the proposed `ElementInternals.state`  property, custom element authors can add and modify custom states for the custom elements, and allow them to be selected with the `:state()` selector.
+
+### Goals
+
+-   Give a way for custom element authors to expose varying states of the custom elements to custom element users
+-   Allow styling of custom elements that differ according state
+-   Allow styling of custom elements that differ according to state even when they are only accessible via shadow parts. That is, `element::part(x):state(y)` should work if `::part(x)` selects a custom element with state y..

```suggestion
-   Allow styling of custom elements that differ according to state even when they are only accessible via shadow parts. That is, `element::part(x):state(y)` should work if `::part(x)` selects a custom element with state y.
```

> +}
+  
+class QuestionBox extends HTMLElement {
+  constructor() {
+    super();
+    this._shadowRoot = this.attachShadow({mode: "open"});
+    this._shadowRoot.innerHTML =
+      "<div><slot>Do you agree?</slot></div>\
+      <labeled-checkbox part='checkbox'>Yes</labeled-checkbox>";
+  }
+}
+customElements.define('labeled-checkbox', LabeledCheckbox);
+customElements.define('question-box', QuestionBox);
+</script>
+
+<style>

It's probably worth adding an example of `:state()` without `::part()`, e.g. by using `labeled-checkbox` by itself.

> +<question-box>Continue?</question-box>
+</body>
+```
+## Proposal 
+
+Add a `states` property to the [ElementInternals](https://html.spec.whatwg.org/multipage/custom-elements.html#elementinternals) interface to contain a list of states for the corresponding custom element, and a new `:state(x)` pseudo-class that can select custom elements that contains `x` in its `ElementInternals`' `state`. An example implementation of a custom element that uses this is shown above.
+
+## Alternatives considered
+
+### Just use attributes or class names on the custom element
+This is bad because the custom element user might use clashing attribute names, causing problems.
+  
+
+### Exposing this on shadow host
+    
+ Since this is not really related to exposing things from within a shadow tree, it does not make much sense to add states to shadow hosts. [Initial discussions](https://github.com/w3c/webcomponents/issues/738) suggested such an API shape, but that was before we came up with the ElementInternals concept for manipulating state on custom elements.

```suggestion
 Since this is not really related to exposing things from within a shadow tree, it does not make much sense to add states to shadow hosts. [Initial discussions](https://github.com/w3c/webcomponents/issues/738) suggested such an API shape, but that was before we came up with the `ElementInternals` concept for manipulating state on custom elements.
```

> +
+### Just use attributes or class names on the custom element
+This is bad because the custom element user might use clashing attribute names, causing problems.
+  
+
+### Exposing this on shadow host
+    
+ Since this is not really related to exposing things from within a shadow tree, it does not make much sense to add states to shadow hosts. [Initial discussions](https://github.com/w3c/webcomponents/issues/738) suggested such an API shape, but that was before we came up with the ElementInternals concept for manipulating state on custom elements.
+    
+
+### Allowing custom states to use the same syntax as built-in ones, e.g. `:foo` instead of `:state(foo)`
+    
+This causes compatibility issues if we ever want to introduce new CSS pseudo-classes in the future that could apply to the element.
+    
+
+### Different syntax choices for custom states, e.g. :`--state`

```suggestion
### Different syntax choices for custom states, e.g. `:--state`
```

-- 
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/pull/832#pullrequestreview-283055772

Received on Tuesday, 3 September 2019 14:58:29 UTC