[RESEARCH] Desktop ready general solution for hover state

[RasmusKjeldgaard]

Describe why and what should be researched

As part of the work of making the Kirby Components Desktop Ready, it would make sense to research if it is possible to make general solutions for various interactivity states, before beginning implementing component specific solutions. This issue is concerned with hover/cursor (pointer/hand/mickey-mouse-thingy).

Considerations

The following is worth considering when researching

Design:

• [ ] Background color?
• [ ] Border?
• [ ] Shadow?

Implementation:

• [ ] Investigate differences between components, to see if we can make a generalized solution.
• [ ] Prioritise general solution in html and css (directives will have to be rewritten later when moving to web-components)
• [ ] cursor: pointer is part of this solution, make sure to set this on the element.

Other

• [ ] No

Describe the goal

To unearth problems and consider if it is possible to come up with a (potentially partially) general solution for implementing the interactivity state. If possible also a POC of the solution.

[MadsBuchmann]

Timebox: 3 days

[jkaltoft]

💡 Findings

• The hover() mixin is the only place we use :hover { ... }, except
  • Calendar:
    • .day.selectable:not(.selected):hover { ... }
    • Cookbook specific styles
• We only utilize the hover() mixin in two places:
  • Button
  • Chip

I'll pursue the following ideas to see if they hold:

1. Never use :hover directly in Kirby components
2. Use the hover() mixin everywhere you would use :hover

---

On the other hand, the hover() mixin uses a content block (@content). We probably need a utility that will apply whatever styles we declare for hover, e.g.:

// Utility
@mixin apply-hover() {
    @include hover() {
        // Declare styles for hover in general
    }
}

// Usage
button {
    @include apply-hover();
}

Optionally apply-hover() could take an argument that determines how "loud" changing interaction state should be, e.g. @include apply-hover(700) or @include apply-hover(400) or similar - kind of like the attention levels. The numbers indicate the "loudness" using a scale similar to CSS font-weight.

Another detail to consider is: Should the existing hover() mixin be extended to not apply to disabled elements?:

@mixin hover {
    &:not([disabled]):hover {
        @content;
    }
}

[jkaltoft]

📝 Tasks

Refactor usage of hover() mixin - use apply-hover()

1. Create new utility/mixin apply-hover()
2. Refactor components - use apply-hover()
   • Button
   • Chip
3. Look for other components where we should use apply-hover()
4. Consider removing hover() mixin completely

This may require decomposition of hover as a concept, e.g. into:

• Cursor
• Elevation
  • Background
  • Border
  • Box shadow
• Typography
  • Text color
  • Text weight (bold, light etc.)
• Opacity/transparency
• Translation (positioning)
• Transition/animation
• Tactility (probably not)
• Audio (probably not)

We could create multiple - possibly private/non-exposed - utilities/mixins for this, e.g.

@mixin apply-elevation {
    // declare background color
    // declare border
    // declare box-shadow
}

@apply-hover() {
    @include apply-elevation();
    // include other mixins and properties that defines what hover means in Kirby
    cursor: pointer;
}

[jkaltoft]

A slightly different approach has been decided. Create a solution based on Material Design's state layers (#1935). See PoC Codepen.