You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In Kibana, we're trying to implement designs for a form that can appear in the context of both a full page and inside a flyout. We want to design responsively for these two contexts, and make the flyout UI look almost identical to a breakpoint s full page UI.
EUI currently supports responsive design only for full-screen breakpoints. Applying the same design for both a small screen and a UI embedded within a flyout on a large screen requires the use of CSS @container queries in external SCSS files.
We can do this for now, but I'd prefer to have EUI dictate standard practices for doing this.
Describe the solution you'd like
Add a set of equivalent helpers like <EuiShowFor> and <EuiHideFor> which target containers instead of screen sizes
Add container-type: inline-size to outer wrappers for <EuiModal> and <EuiFlyout> to simplify responsive design within these contexts.
Possibly add container properties to other elements like <EuiPanel> or other EUI page components. This is probably more of an overall design question, to determine which parts of the UI should be containerized and which parts shouldn't.
Describe alternatives you've considered
We could continue specifying @container queries within SCSS files in Kibana, but that seems frowned upon and only as a last resort
Desired timeline
No rush, really. Workarounds exist for the time being.
The text was updated successfully, but these errors were encountered:
Hi @Zacqary! Thanks for reaching out and proposing solutions!
I completely agree; we should add support for container queries to EUI. We might start small and update our RWD helpers first, but accepting additional layout control props in EUI components is on our radar, and we will hopefully add them someday :D
I'll make sure to plan the work needed and will keep you updated to make sure our solutions match your needs.
In the work I've been doing I noticed there isn't currently an easy way in Javascript to determine which container an element is in, which could add some difficulty in adding equivalent ShowFor/HideFor components.
w3c/csswg-drafts#6205 for an element.matchContainer API is currently proposed but unresolved. Firefox and Chrome are working on implementing this but it's not yet finished.
A workaround until then could be:
Render an invisible helper element with a CSS class that responds to @container queries, with something like display: none; visibility: {visible or hidden depending on container size}
Use JS to determine if this helper element has visibility: visible or visibility: hidden
Is your feature request related to a problem? Please describe.
In Kibana, we're trying to implement designs for a form that can appear in the context of both a full page and inside a flyout. We want to design responsively for these two contexts, and make the flyout UI look almost identical to a breakpoint
s
full page UI.EUI currently supports responsive design only for full-screen breakpoints. Applying the same design for both a small screen and a UI embedded within a flyout on a large screen requires the use of CSS
@container
queries in external SCSS files.We can do this for now, but I'd prefer to have EUI dictate standard practices for doing this.
Describe the solution you'd like
<EuiShowFor>
and<EuiHideFor>
which target containers instead of screen sizescontainer-type: inline-size
to outer wrappers for<EuiModal>
and<EuiFlyout>
to simplify responsive design within these contexts.<EuiPanel>
or other EUI page components. This is probably more of an overall design question, to determine which parts of the UI should be containerized and which parts shouldn't.Describe alternatives you've considered
We could continue specifying
@container
queries within SCSS files in Kibana, but that seems frowned upon and only as a last resortDesired timeline
No rush, really. Workarounds exist for the time being.
The text was updated successfully, but these errors were encountered: