-
Notifications
You must be signed in to change notification settings - Fork 842
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
[DRAFT] Consolidate EuiText and EuiMarkdownFormat styling #4145
Comments
One other thing to consider is how our baselines line up with our The Amsterdam (@hbharding) team has been discussing some line-height issues we're running into with the smaller Amsterdam font-size and that a Perhaps, we just ensure that our titles which are what tends to sit horizontally next to other components do always line-up with the |
This is a draft document meant to start discussion
Problem
EuiText
, which we technical suggest not doing, but has proved to be needed over the years. As an example, giving a<p>
a margin for everything withinEuiText
can often break a<p>
within another EUI component that has very specific sizing needs.Requirements
Boiled down, we have the following top level needs if we were to share a component for the various use-cases:
em
percentage styling in addition to defaults that are derived from$euiSize
variables. This is because markdown is used heavily in dynamic, user-created spaces like Canvas, which will require a backwards compatibility layer enforced through a parent font-sizing value of a parent container.size
prop onto the component similar to howEuiText
works today. This would effect the size of the variables used.$euiColor
variables. Again, needed for systems where the background color is different like canvas. This could be alternatively handled without opacity, and derived from a single font-color, but this likely wouldn't be achievable with CSS alone. The reason not to just use transparency for everything is that it can contribute to slowdowns in render painting. Usually we only need this alternative method in outliers where more targeted user-control exists.EuiText
.EuiText
magical have assuming that the child content is primarily naked HTML. There are pretty good times though when we want to includeEuiComponents
insideEuiText
and we need to make sure that the margins work correctly. If possible, this should be handled as magically asEuiText
normally operates, with some clever CSS beyond our current> *
methods.Relationship between EuiText and EuiMarkdownFormat
.euiText
selector.EuiText
as the styling mechanism for that HTML.Pseduo-code sass ideas
At the sass level we probably should have something like:
sizingMethod
acceptsem
orpixel
as options, which then cascades to the types of units used through the document.colorMethod
acceptssolid
ortranslucent
as options, which then cascades to whether to use the flat default coloring, or use transparency values for the various color settings.reverseColorsFromTheme
accepts true / false. This is needed to handle instance where the background might be flipped against what it usually is.fontSizeScale
takes anumber
value like.75
or1.5
and adjusts the font sizing and margins accordingly, usingem
orpixel
values as defined bysizingMethod
. For the pixel method, it would use mutlipliers against the$euiFontSize
base.Pseudo-component ideas
On the React side we might see something like:
Issues to solve
This method, since it's Sass heavy, will duplicate a lot of boilerplate selectors as written above. We might want to look at a more overwrite / cascade method to manage the compile size of the css.
The text was updated successfully, but these errors were encountered: