States that allow CSS pseudo-states (hover, focus) and custom states

[taylornowotny]

Users will need a way to control CSS user action pseudo-classes, called "states" in Webflow. The big ones are hover, which provides some interactivity prior to our own "interactions" feature, and focus which is important for keyboard navigation and accessibility.

Webflow CSS states menu:

In Webflow, selecting a state from the above menu will "refresh" the style panel. Users can then make style changes and those changes will only show when the state is activated. So changing a text color while the "hover" is active will result in the text color of that element changing when hovered.

We need a version of this that fits with our token system.

[taylornowotny]

It may require a separate issue, but we should also have a way to control transitions. https://www.w3schools.com/css/css3_transitions.asp

The way Webflow handles this is very simple. Just a GUI to control the code. We could improve on this I'm sure.

One thing we will need to make this work is an easing manager.

[kof]

Additionally, the same UI could be used to define any states, so that to the user there is no difference if those are CSS native once or not.

This needs research and a design proposal.

[taylornowotny]

Another state that I use a lot is "Current"

Common use case: Navigation links change color when user is on the linked page.

[okonet]

current is a keyword for color property in CSS and has nothing to do with states actually. As for states, IMO this information should come from the SDK. I call such components interactive and each interactive component can have it's own set of states mapped to different pseudo-selectors, so we'd need to create an interface between SDK and UI and use the mapping under the hood when creating styles.

As for visualization, we can use a package I wrote: https://ui.component-driven.dev/#/Packages/with-selector?id=withselector but I think it could become a hook, actually.

[okonet]

Now that I think more about your use-case @taylornowotny, I think it should be a separate concern, since it doesn't have anything to do with (pseudo-)states of components but rather it depends on the router implementation. I don't know how we'll solve this yet but let's not mix those things here and let's create a separate issue for styling of links when you're on a specific page.

[taylornowotny]

Ok. The reason I grouped them is because they work the same in Webflow. I have no clue what’s going on under the hood, but styling the ‘current’ version of a link and styling the ‘hover’ state follow the same process. From the perspective of a user it’s really easy in Webflow.

Should we come up with a UX proposal for how this could work in Webstudio first and then revisit the issue?

On Wed, Jun 29, 2022 at 3:10 AM Andrey Okonetchnikov < @.***> wrote:

Now that I think more about your use-case @taylornowotny https://github.com/taylornowotny, I think it should be a separate concern, since it doesn't have anything to do with (pseudo-)states of components but rather it depends on the router implementation. I don't know how we'll solve this yet but let's not mix those things here and let's create a separate issue for styling of links when you're on a specific page.

— Reply to this email directly, view it on GitHub https://github.com/webstudio-is/webstudio-designer/issues/83#issuecomment-1169794259, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUT5FGBMQOA3U74UUTX5MHTVRQOJZANCNFSM5ZYOX55A . You are receiving this because you were mentioned.Message ID: @.***>

[okonet]

Feel free to make a proposal for sure. How did you imagine this would work?

[taylornowotny]

Will do, but after we figure out our components system, since this feature will need to work in that context. In Webflow 'states' are part of the class system, which we won't have

[okonet]

As I said, you can assume that some components will have "states" defined in them so the designer UI will know about them. There is nothing that should block you from making a UX proposal from my POV. Let me know what information is still missing to make a proposal.

[okonet]

Not sure what you mean by class system since "states" are pseudo-states. We also will use same pseudo-classes under the hood.

[taylornowotny]

This is what I'm talking about. In the Webflow UI these are called "states" and they are managed as part of their class UI. We will not have a class UI like this, we will have user components instead.

So first we need to figure out how our component UI will work, and then I can figure out how to manage "states" or whatever we call them.

Again, I have no idea what is going on under the hood so if I'm using terms that are not the technical terms then I'm sorry - my experience is with the Webflow UI

Components are priority 1 and this issue is priority 2 btw

[kof]

Webflow doesn't support custom states, so the states they have in classes are just pseudo-states from CSS. What we want (I assume we agree on) is that we can have any state, no matter how its technically implemented (pseudo state or not).

Consider it a higher level abstraction over state as a more general approach where pseudo states is one of its values.

[okonet]

Yep, that's what I'm saying. It doesn't matter how Webflow does it since it doesn't change the fact that we'll need this. So I'd start exploring how we can integrate this into the flow. Essentially, every state can be styled differently. I think of states as just variants that are pre-defined as pseudo-states. Like hover, focus, and disabled. Alternatively you can think of them as breakpoints: each breakpoint / state can have styles associated with them.

[kof]

Here is a hierarchy we are getting:

• Breakpoint
  • State
    • Style

So each state can be styled differently on different breakpoints 🙃

[kof]

Closing, has a separate issue