Feature request: add class to rect main key to enable css easier styling

[magicDGS]

When trying to style with css something like the following key:

<g transform="translate(28, 56)" class="key keypos-0">
  <rect rx="6" ry="6" x="-26" y="-26" width="52" height="52" class="key side"/>
  <rect rx="4" ry="4" x="-20" y="-24" width="40" height="40" class="key"/>
  <text x="0" y="-4" class="key tap">F1</text>
</g>

To style the middle rect on some nested selector you need to use a discriminator as follow:

    .key {
      ... /* general styling for the whole key */
      .key:not(.side, .tap, .hold) {
       .... /* specific styling for the rect that is not containing other selector */
      }
    }

It will be really nice in such cases to have a class such main (maybe there would be a better name) to avoid such complex selection. Maybe I am missing a better way of doing it, so feel free to close if that is the case. Thanks! 😊

[caksoylar]

Is this only a problem when the key sides option is used? Because otherwise, rect.key should only match the main rectangle, not anything related to tap/hold etc. I'd be OK with adding an extra qualifier of the sort to ease this if so.

[magicDGS]

I haven't checked all codepaths without key sides, so most likely is only related with that one
Basically I found it out when trying to style the sides + main to mimic low profile keycaps. I can also live with react.key:not(.side) by now, but I found it more fragile in case that new features require adding more rects.

[caksoylar]

It looks like when you enable key sides, you get key side for the outer (main) rectangle, and you get key for inner "top" area. If you don't enable key sides, you just get key for the main rectangle.

(While this didn't seem intuitive to me that the outer rectangle uses different classes in the two cases, it makes sense when we look at how the side and "top" parts are styled in the CSS.)

Given above, if we add main class to the "top" rect with key sides enabled, and the main rect with it disabled, does that make sense for your use?

[caksoylar]

@magicDGS do you have any thoughts on above? Alternatively, if you are happy with the not(.side) solution then we can close this.