iTwin / iTwinUI

A design system for building beautiful and well-working web interfaces.
https://itwin.github.io/iTwinUI/
MIT License
93 stars 35 forks source link

Menu item text color is not set #683

Closed JonasDov closed 1 year ago

JonasDov commented 1 year ago

After updating iTwinUI react from 1.23.2 to 1.37.1 menu item text color is not explicitly set. As we were wraping menu item with anchor, now we need to explicitly override anchor text color. Before: image After: image

mayank99 commented 1 year ago

Hey @JonasDov, thanks for creating this issue.

Your DOM structure seems invalid. <a> should not be a parent of <li>, it should be a child. Also, our menu-item styles were recently changed to either inherit text colors or set them for active variants (see demo).

So this does not look like a bug in itwinui-css. If it "worked" in a prior version, it was an unintended side effect and not a feature. If you need to look different, I would recommend adding some overrides on your end.

veekeys commented 1 year ago

Huh? Im not gonna raise the issue, that we do not provide ability to use menu item as anchor (they have no other way to make whole menu item clickable as anchor), but even if anchor was inner child, our color inheritance idea is wrong. Now it expects to inherit it from menu, which would be broken if there is anchor in any inner elements.

mayank99 commented 1 year ago

we do not provide ability to use menu item as anchor (they have no other way to make whole menu item clickable as anchor)

This is a separate issue (a valid one!) that should probably be opened in iTwinUI-react. I think we might want to expose a built-in way to use <li><a>...</a></li> with proper styles. We could add a prop to MenuItem or a new component like MenuItemLink.

our color inheritance idea is wrong

This was done for MenuExtraContent. See https://github.com/iTwin/iTwinUI/issues/368 for more context.

broken if there is anchor in any inner elements.

Anchor comes with its own styling so this is expected. I do not think this part has even changed between itwinui-react v1.23.2 and v1.37.1.

And I don't consider this "broken". To me it makes sense that the user needs to unset/override the color and text-decoration of <a> if those styles are undesirable.

veekeys commented 1 year ago

I know this change and I am saying, we might need to rethink the idea. From recent learning, I think all elements with text should have their color set explicitly. In this case, there is no situation we want our text to appear in different color in menu item unless user explicitly overrides it with css. Another example would be also connected with multiple themes: Imagine your whole page uses light theme, but you want your header to be dark. We change variables values to dark themes ones. Our typography elements do not have text color set explicitly (we expect those to be inherited). In this situation happens, that they inherit text color from body and body's text color is the light theme one even though in header context we do have other values assigned to the css variables. My question is, do we have the case, that having color on our elements with text would break something?

FlyersPh9 commented 1 year ago

@mayank99 can this be addressed in #718? Or should this be addressed sooner than iTwinUI-CSS 1.0?

mayank99 commented 1 year ago

i don't think this will be affected by the new variables or 1.0 at all, it's a problem confined to our component

FlyersPh9 commented 1 year ago

I meant with our changing of hover (shades of gray) and active (shades of blue) in #718 does it make sense to include this fix with that change, but I don't think that this fix needs to be tied with that change in 718. I'll submit a fix to main now.

FlyersPh9 commented 1 year ago

Fixed in #741.