Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to override style of a floating <OverflowMenu>in v9 #2876

Closed
s100 opened this issue May 29, 2019 · 14 comments
Closed

No way to override style of a floating <OverflowMenu>in v9 #2876

s100 opened this issue May 29, 2019 · 14 comments
Labels
severity: 3 https://ibm.biz/carbon-severity status: inactive Will close if there's no further activity within a given time type: enhancement 💡 version: 9 Issues pertaining to legacy Carbon

Comments

@s100
Copy link
Contributor

s100 commented May 29, 2019

Summary

I would open this issue against [https://github.com/carbon-design-system/carbon-components-react] but apparently this is the new place...

In Carbon V9 (specifically, carbon-components-react@6) it is not possible to override the styling of an <OverflowMenu floatingMenu /> to e.g. make it wider. Specifically, the options themselves. As with nearly all Carbon components it is possible to pass a className prop into the component, which can then be targeted to alter rendering. Unfortunately, when the menu options are floating, they appear at a completely different location in the DOM from where the injected className goes. So all we can do is alter the rendering of the menu icon.

Justification

This would be useful for making the floating menu bigger, so that longer menu options are easier to read.

Desired UX and success metrics

Something like: when a <OverflowMenu floatingMenu optionsClassName='x' /> is opened, the <ul> which gets appended to the DOM should have class='x' on it.

"Must have" functionality

That's about it!

Specific timeline issues / requests

Soon as you like, really. This is a simple request so if this isn't likely to appear in the next week I may be able to put together a PR myself.

Available extra resources

I'll try to patch this myself if I have to...

@asudoh
Copy link
Contributor

asudoh commented May 29, 2019

Hi 👋 thank you for reporting - While your optionsClassName may make sense, one thing that may be worth mentioning is that overflow menu looks through ancestor nodes of the trigger button in DOM for one with data-floating-menu-container attribute and puts its menu body in there. <body> is the last resort. That said, you can add CSS class to that container and create override style for menu body with it. Hope this helps!

@dakahn dakahn added priority: low severity: 3 https://ibm.biz/carbon-severity labels May 30, 2019
@s100
Copy link
Contributor Author

s100 commented May 30, 2019

@asudoh That may actually be useful, thank you!

@s100
Copy link
Contributor Author

s100 commented May 30, 2019

@asudoh Actually this proved more troublesome than I was expecting because something in <OverflowMenu>'s layout calculations is computing offsets (top and left) for the absolutely positioned menu body under the assumption that it is being absolutely positioned relative to <body>. In fact the menu body is absolutely positioned relative to its nearest positioned ancestor, which defaults to <body> if there are no positioned ancestors, but in my case is a different element. So, if the NPA is at (200px, 400px), the menu itself renders at roughly (200px, 400px) relative to that element, or (400px, 800px).

I have not yet figured out what the specific problem here is, the code is complex. Currently I am working around this by passing in a replacement getMenuOffset prop which carries out the right calculations.

@dakahn dakahn added the version: 9 Issues pertaining to legacy Carbon label May 30, 2019
@asudoh
Copy link
Contributor

asudoh commented May 30, 2019

Currently I am working around this by passing in a replacement getMenuOffset prop which carries out the right calculations.

It's the right way to go. BTW if you have some demo code that shows the layout challenge you have, we may consider taking the non-<body> floating menu container's bounding rect into account.

@s100
Copy link
Contributor Author

s100 commented May 31, 2019

@asudoh Small demo of the issue I was seeing:

<!DOCTYPE html>
<html>
  <head>
    <title></title>
    <link rel="stylesheet" href="https://unpkg.com/[email protected]/css/carbon-components.css"></link>
    <script crossorigin src="https://unpkg.com/react@16/umd/react.development.js"></script>
    <script crossorigin src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>
    <script crossorigin src="https://unpkg.com/[email protected]/prop-types.js"></script>
    <script crossorigin src="https://unpkg.com/[email protected]/dist/carbon-icons.js"></script>
    <script crossorigin src="https://unpkg.com/[email protected]/index.js"></script>
    <script crossorigin src="https://unpkg.com/[email protected]/umd/carbon-components-react.js"></script>
    <script crossorigin src="https://unpkg.com/@babel/standalone/babel.min.js"></script>
    <script type="text/jsx">
      const { OverflowMenu, OverflowMenuItem } = CarbonComponentsReact

      window.addEventListener('load', () => {
        ReactDOM.render(<div
          data-floating-menu-container
          style={{
            width: '500px',
            height: '500px',
            backgroundColor: 'yellow',
            position: 'relative',
            left: '100px',
            top: '100px'
          }}
        >
          <OverflowMenu className='overflow-menu' floatingMenu>
            <OverflowMenuItem itemText='Menu item 1' />
            <OverflowMenuItem itemText='Menu item 2' />
          </OverflowMenu>
        </div>, document.querySelector('.root'))
      })
    </script>
  </head>
  <body>
    <div class="root"></div>
  </body>
</html>

image

Note how the vector from the top left corner of the screen to the bottom midpoint of the menu icon is the same as the vector from the bottom midpoint of the menu icon to the tip of the arrow in the menu body. This indicates that the menu body is being positioned relative to its nearest positioned ancestor (the yellow <div>) but the calculations for its position assume that it is being positioned relative to <body>.

@s100
Copy link
Contributor Author

s100 commented May 31, 2019

Should I raise this relative positioning bug as a separate issue?

@asudoh
Copy link
Contributor

asudoh commented Jun 1, 2019

@s100 Yes it will be great - Thanks!

@s100
Copy link
Contributor Author

s100 commented Jun 3, 2019

@asudoh: raised #2907.

@s100
Copy link
Contributor Author

s100 commented Jun 10, 2019

@asudoh: Do you know when a new version of carbon-components-react@6 containing #2389 will be available?

@asudoh
Copy link
Contributor

asudoh commented Jun 10, 2019

@s100 #2389 seems a different issue - Any other issue you are referring to?

@s100
Copy link
Contributor Author

s100 commented Jun 11, 2019

@asudoh Ah, sorry, I was referring to carbon-design-system/carbon-components-react#2389, which closes this issue (#2876)

@s100
Copy link
Contributor Author

s100 commented Jun 14, 2019

@asudoh Do you know when a new version of carbon-components-react@6 containing carbon-design-system/carbon-components-react#2389 will be available?

@stale
Copy link

stale bot commented Jul 14, 2019

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

@stale stale bot added the status: inactive Will close if there's no further activity within a given time label Jul 14, 2019
@stale
Copy link

stale bot commented Jul 17, 2019

As there's been no activity since this issue was marked as stale, we are auto-closing it.

@stale stale bot closed this as completed Jul 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity: 3 https://ibm.biz/carbon-severity status: inactive Will close if there's no further activity within a given time type: enhancement 💡 version: 9 Issues pertaining to legacy Carbon
Projects
None yet
Development

No branches or pull requests

3 participants