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

Updating Popovers to use Panel Padding vars #229

Merged
merged 30 commits into from
Dec 21, 2017
Merged

Conversation

cchaos
Copy link
Contributor

@cchaos cchaos commented Dec 20, 2017

Takeaway

Popovers with titles no longer require padding to be manually added to the popover's child that follows the title.

Solution

The panel's padding is still applied to the entire popover. Based on the panel padding class applied to the popover, ie .euiPanel--paddingMedium, the title has negative margins to expand to cover that padding amount.

The popover's title also adjusts the horizontal padding to match so that the content and the title align horizontally.

The popover's title always has some padding and only the content's padding is affected by the "none" padding property on the panel.

Design

I, personally, feel that borders around shading are duplicative and noisy, so I also removed the bottom border from the title. I can easily change back if others disagree.

Screenshots

screen shot 2017-12-20 at 19 25 37 pm

screen shot 2017-12-20 at 19 25 43 pm

screen shot 2017-12-20 at 19 25 47 pm

screen shot 2017-12-20 at 19 25 51 pm

@cjcenizal
Copy link
Contributor

@cchaos Could you please add a screenshot of the new popover?

@cchaos
Copy link
Contributor Author

cchaos commented Dec 20, 2017

I guess there is still a question about whether all of the title's padding should be affected or just the horizontal padding?

Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good and I think you're right about the bottom border. I would scan through the src-docs JS files for "padding" though to make sure you got all instances where padding was applied. Noticed one stray one in forms...

image

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! This is a clever solution. I just had a few suggestions.

* - Popover
*/
$euiPanelPadding: (
"Small": $euiSizeS,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this pattern! I think we can make it a little easier to grep for the modifier if we use the full modifier name as the key (and use the term "modifier" in the variable names to make it clearer we're not defining an actual padding value):

$euiPanelPaddingModifiers: (
  ".euiPanel--paddingSmall": $euiSizeS,
  ".euiPanel--paddingMedium": $euiSize,
  ".euiPanel--paddingLarge": $euiSizeL
) !default;

.euiPanel {
  @include euiBottomShadowSmall;

  background-color: $euiColorEmptyShade;
  border: $euiBorderThin;
  border-radius: $euiBorderRadius;
  flex-grow: 1;

  @each $modifier, $amount in $euiPanelPaddingModifiers {
    &#{$modifier} {
      padding: $amount;
    }
  }

  &.euiPanel--shadow {
    @include euiBottomShadow;
  }

  &.euiPanel--flexGrowZero {
    flex-grow: 0;
  }
}

What do you think?

Copy link
Contributor Author

@cchaos cchaos Dec 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see where you're going with this in that it simplifies the (at)each statement and the popover doesn't need to hard-code the reference to the class. However, I still see too much duplication, ie. .euiPanel. Also I'd like to keep the selectors at the child level so it's obvious they're modifiers. How is this for a compromise:

$euiPanelPaddingModifiers: (
  "--paddingSmall": $euiSizeS,
  "--paddingMedium": $euiSize,
  "--paddingLarge": $euiSizeL
) !default;

.euiPanel {
  
...

  @each $modifier, $amount in $euiPanelPaddingModifiers {
    &.euiPanel#{$modifier} {
      padding: $amount;
    }
  }

...

}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

too much duplication

What problem are we solving by removing the duplication? For example, does duplication make it more difficult to read? To maintain?

keep selectors at child level so it's obvious they're modifiers

I don't understand, could you clarify? I would think the use of -- makes it clear the class is a modifier because it's a BEM convention.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a bit of both.

To me, it seems to read easier having .euiPanel duplicated in the actual selector versus in a map. Also, I'm not sure that we want to start going down the road of storing full class names inside of variables. Could be a slippery slope to too many variables.

@@ -1,3 +1,13 @@
/** Padding map eferenced in:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit, but for consistency can we separate the opening comment block token from the first line?

/**
 * Padding map referenced in:
 *  - Popover
 */

Also small typo: "eferenced" -> "referenced"

// ensure the title expands to cover that padding and
// take on the same amount of padding horizontally

@each $size, $amount in $euiPanelPadding {
Copy link
Contributor

@cjcenizal cjcenizal Dec 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$euiPanelPadding is only available here because panel occurs before popover and we're importing components in alphabetical order. I think it would be more explicit and robust if we extract the $euiPanelPaddingModifiers variable somewhere more global to make it clear that it's consumed by multiple modules. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, if we can I'd rather we don't make more global variables. In the back of our head we should always consider that we're going to pull our components CSS away from each other one day and the less global settings we rely on the better.

We might want to consider directly importing required variables from file to the other rather than just adding it to the global scope, similar to how JS would handle it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Importing the variables SGTM. What do you mean by pulling our components' CSS away from each other one day?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cjcenizal If we were building this outside of Kibana's necessities for multi-framework solutions we likely would have built out separate CSS files per component rather than a giant monolith file that needs to be imported (which would be replaced with just a single reset / core file). Importing the one component into another would bring along all the styling you need on a layout per layout basis. One day (not anytime soon) I think we'll end up there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would @import '_panel' not duplicate the panel styles?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I thought there was a way to do sass compilation that order of the imports in the manifest doesn't matter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it does not duplicate. I'll add the import

padding: $euiSizeM;
border-top-left-radius: $euiBorderRadius - 1;
border-top-right-radius: $euiBorderRadius - 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we leave a comment here to explain why we do this?

<EuiText>
<p>
Popover content
Popover content with default padding
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we also update the text of the buttons to also reflect that each one demonstrates a different padding size?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're also missing an example of small padding, aren't we? Maybe we should just create a section dedicated to demonstrating the different padding options.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I'll just create a new section

@cjcenizal
Copy link
Contributor

Re horizontal vs. all padding, I think only horizontal padding should be affected. Adding the vertical padding too seems weird to me.

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! I had a couple last small suggestions.

&.euiPanel--paddingLarge {
padding: $euiSizeL;
@each $modifier, $amount in $euiPanelPaddingModifiers {
&.euiPanel#{$modifier} {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I see your point. Could we make one last change and put the -- here instead of in the map? This will be inline with how we're structuring this kind of pattern elsewhere.

@@ -1,3 +1,17 @@
@import '../panel/panel'; // grab the $euiPanelPaddingModifiers map
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move the variables into a panel/variables.scss file? Then it'd be clearer what we're importing, similar to the way we import a different component's mixins in https://github.com/elastic/eui/blob/master/src/components/context_menu/_context_menu_panel.scss#L1

@cchaos cchaos merged commit a594b92 into elastic:master Dec 21, 2017
@cchaos cchaos deleted the popovers branch December 21, 2017 01:03
snide pushed a commit to snide/eui that referenced this pull request Dec 21, 2017
Popovers with titles no longer require padding to be manually added to the popover's child that follows the title.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants