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.

[magicDGS]

When I open this ticket I was doing some explorative work for the styling with and without key-sides; the problem that I have faced was that some styles were just applied differently when you activate or deactivate the sides, and that makes the css not really interchangeable when you enable the flag.

So I guess that adding the class just with key-sides activated is not really an option as it adds yet another difference when you are styling a version with and without sides together.

In any case, I am fine with a little more work on my custom css if you prefer not to bloat with many classes the SVG unless need it, but a solution from my POV is to have consistent classes that are independent of the key-side option. Maybe that is a different ticket than this one, so feel free to close this ticket, open a different one or rename this to be more explicit about the consistency on classes.