proposal: State declarations

[barak007]

Proposal Description

Today when we declare custom state for a part, we use -st-states followed by one or more a state declarations.

.root {
    -st-states: loading(enum(with-spinner, with-blocking-layer));
}

This approach is very simple and straight forward but it limits the reusability of states only to inheritance.
Also today all the states share the namespace of the stylesheet and you cannot cerate an internal part with it's own states.
e.g .btn:loading vs .root:loading

The proposal

• Treat states like any other symbol
• Namespace it with the declaration location in mind?
• Provide a way to declare states
• Import states between different stylesheets.
• Use imported states in -st-states

For example we can use the @st-state at-rule to declare a states (This syntax open for change and is for the demonstration purposes only).

styles.st.css

/* validation */
@st-state loading enum(with-spinner, with-blocking-layer);
/* mapped */
@st-state opened "[data-opened]";
/* boolean */
@st-state closed;

app.st.css

@st-import [state(loading, opened, closed as close)] from "./styles.st.css";

.root { -st-states: loading; }
.root:loading(with-spinner) {}

.part {
    -st-states: opened as open, close;
}
.otherPart {
    -st-states: open, close;
}

In regard to our existing -st-states, this feature is not going to replace them. Because of that we can have declaration collision that we need to report on.

Example for collision:

@st-import [state(loading)] from "./styles.st.css";

.root {
    -st-states: loading(string);
}

We can think about the declaration inside -st-states as a syntax sugar for declaring states with @st-state.
This way we can resolve the collision like any other symbol collision. This will also hint the way for the exports of the states to stylesheets and js modules.

Additional Context

No response

[plisovyi]

Precisely what I'm looking for 👍🏼