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

Establish a table pattern and Table component #157

Closed
4 tasks done
lyzadanger opened this issue Jul 29, 2021 · 0 comments · Fixed by #174
Closed
4 tasks done

Establish a table pattern and Table component #157

lyzadanger opened this issue Jul 29, 2021 · 0 comments · Fixed by #174
Assignees
Labels
component concerning a UI component that is part of the package API pattern library concerning the build, structure, styling or components for the pattern library

Comments

@lyzadanger
Copy link
Contributor

lyzadanger commented Jul 29, 2021

Create a common table pattern and Table component based on the Table component and its styling from the lms project. This work is needed to smooth out some UI issues in the LMS project, but a generic and flexible table pattern seems useful in general.

The Table component should have as near an API and implementation as possible to the current Table component in LMS. The table pattern should be based on the existing component styling, but adapted per conventions.

By implementing this in a common way, we can pull out any non-table-related concerns from the styling, bring it in line with other patterns, and be able to see it in play in the pattern library with different content and in various contexts.

An area of focus is on adaptive height constraints and scrolling within overflow/scrolling containers, especially in Dialog contexts.

An aside on position:sticky, scrolling contexts, etc.

Table’s current styling provides some headers that are position:sticky such that they will “stick” to the top of the nearest ancestor scrolling element. However, the current Table implementation also wraps the entire <table> element with a wrapper <div> that is set overflow:auto. That defines the scrolling context for the sticky headers—but it’s not the correct scrolling context for certain use cases.

For example, we have a use case in which a Table is used within a Modal dialog, but is not the only content in the modal. The modal itself wants to assert a content area that is overflow:auto (to bound the modal content’s height), and the Table should scroll itself—and sticky-position its headers—relative to that scrolling context. But unfortunately its own overflow:auto wrapper gets in the way (again: position:sticky will position relative to the nearest scrolling ancestor).

My recommendation is to remove the wrapping div with the overflow rule, and instead allow parent components and elements to define any scrolling context.

Sub-tasks

  • Establish a scrollbox pattern
  • Establish a table pattern
  • Establish a Scrollbox component
  • Establish a Table shared component
@lyzadanger lyzadanger added pattern library concerning the build, structure, styling or components for the pattern library component concerning a UI component that is part of the package API labels Jul 29, 2021
@lyzadanger lyzadanger self-assigned this Aug 4, 2021
This was referenced Aug 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component concerning a UI component that is part of the package API pattern library concerning the build, structure, styling or components for the pattern library
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant