[css-houdini-drafts] What if we could define custom, pseudo-classes? (#1008)

CITguy has just created a new issue for https://github.com/w3c/css-houdini-drafts:

== What if we could define custom, pseudo-classes? ==
There are a handful of use cases where it'd be useful to register a custom pseudo-class for simplification or even extension of CSS capabilities.
## Use Cases

### `:visible`
Target visible elements (i.e., non-zero `height` _and_ `width`, non-zero `opacity`, not `visibility: hidden;`, not `display: none;`, etc.). 

Example: [applying margin between non-text button children](https://codepen.io/CITguy/pen/gOrGaOd)


### `:touched`
Target elements that have emitted a `blur` event.

Useful to apply `:invalid` styling to form controls, but only _after_ the user has interacted with the control (i.e., the user had the opportunity to enter a valid value, but left it invalid).

Example: 
```css
input:invalid { 
  /* 
    Don't apply invalid styles!

    Newly rendered inputs that don't pass validation (e.g., input[required] without a value)
    should not be displayed as invalid.  This results in a suboptimal user experience, because
    a user will see invalid inputs immediately after the page loads (before they've had a chance
    to interact with the form).
  */ 
}

input:invalid:touched { 
  /* 
    Apply invalid styles!

    The user has entered the field (focused) and left it (blurred) in an invalid state.
  */ 
}
```

### `:changed`
Target a form control whose current value differs from its initial value. 

* Display an icon next to fields that have been modified, but not persisted/saved.
* Display a notification banner, communicating unsaved changes in a form.


## Compatibility
Naturally, you'd want to avoid conflicts with pre-existing pseudo-classes.

As such, custom pseudo-classes...

1. require a prefix
    - similar to how custom elements must have a dash/hyphen in their name
2. may not be defined more than once
    - avoid overwriting third-party custom pseudo-classes, but allow browser vendors to define their own prefixed pseudo classes through the same API

There may need to be some sort of mechanism for prefix registration, so that library authors can:

1. open a prefix/namespace registration
2. define custom selectors within that prefix/namespace
3. close registration (commit changes)
    * once the namespace has been closed, further modification should be impossible, to prevent external modification/tampering

Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1008 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 2 September 2020 00:38:57 UTC