-
Notifications
You must be signed in to change notification settings - Fork 841
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
Add zIndexAdjustment prop to EuiPopover #1097
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -515,7 +515,7 @@ export function intersectBoundingBoxes(firstBox, secondBox) { | |
* relative to the `target` element; if no z-index is defined, returns "0" | ||
* @param element {HTMLElement|React.Component} | ||
* @param cousin {HTMLElement|React.Component} | ||
* @returns {string} | ||
* @returns {number} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you want to count this as a breaking change? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This function is only internal. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I hear ya, just thought I would ask because technically consumers can access it like this: import { getElementZIndex } from '@elastic/eui/lib/services/popover/popover_positioning'; Kibana is accessing the contents of other modules like this, which I'm not a fan of, but I'm not sure if our docs or conventions are clear about how to distinguish public from internal services. No big deal, just thought I'd mention it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ughhh; true. In response to Caroline's request I've reverted the changes to this function, but you're right with the deep-importing that could happen this would be a breaking change. |
||
*/ | ||
export function getElementZIndex(element, cousin) { | ||
element = findDOMNode(element); | ||
|
@@ -567,8 +567,8 @@ export function getElementZIndex(element, cousin) { | |
const zIndex = window.document.defaultView.getComputedStyle(node).getPropertyValue('z-index'); | ||
|
||
// if the z-index is not a number (e.g. "auto") return null, else the value | ||
return isNaN(zIndex) ? null : zIndex; | ||
return isNaN(zIndex) ? null : parseInt(zIndex, 10); | ||
}, | ||
null | ||
) || '0'; | ||
) || 0; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel strongly about this but I think I've seen "offset" used more often to indicate a value that's added to an original value, e.g. offsetX. Just tossing it out there if you feel it's more descriptive. I'm OK with "adjustment" too as long as it's used consistently for similar variable names elsewhere.