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

feat: footer component #3612

Merged
merged 3 commits into from
Dec 19, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 64 additions & 0 deletions docs/research/footer.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# DEV Research footer

## Overview

| Design System | Component | Comment |
| ------------- |:-----------------------------------------------------------------------------------------:|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| [Atlassian Design System](https://bitbucket.org/atlassian/atlaskit/src/master/) | ❌ | -- |
| [Bootstrap](https://github.com/twbs/bootstrap) | ❌ | -- |
| [GitHub Primer](https://github.com/primer/css) | ❌ | -- |
| [GitLab Pajamas](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com) | ❌ | -- |
| [HP Enterprise Grommet](https://github.com/grommet/grommet) | [footer](https://v2.grommet.io/footer) | Simple container with alignment, padding, fill... Does not offer any layout like columns. |
| [IBM Carbon](https://github.com/carbon-design-system/carbon) | ❌ | -- |
| [Material UI](https://github.com/mui/material-ui) | ❌ | -- |
| [MongoDB.design](https://github.com/mongodb/design) | ❌ | -- |
| [Porsche Design System](https://github.com/porsche-design-system/porsche-design-system) | ❌ | -- |
| [SBB Lyne](https://github.com/lyne-design-system/lyne-components) | [footer](https://lyne-storybook.app.sbb.ch/?path=/docs/elements-sbb-footer--docs) | Footer is a simple wrapper that provides a slot to add any layouts and components. Nice: the footer is often displayed with the sbb-clock component (a stylised, animated station clock). |
| [Shopify Polaris](https://github.com/Shopify/polaris) | ❌ | -- |
| [SNCF Design System](https://gitlab.com/SNCF/wcs) | ❌ | -- |
| [Telefonica Mistica](https://github.com/Telefonica/mistica-web) | ❌ | |
| [Telekom Scale](https://github.com/telekom/scale) | [footer](https://telekom.github.io/scale/?path=/docs/components-telekom-footer--standard) | Footer contains a Telekom logo. There are slots for a legal line and a list of links. |
| [Washington Post Design System](https://build.washingtonpost.com/) | ❌ | |

## Conclusion

Most design systems do not offer a footer component. The few footers are rather simple, styled (background colour, centring) wrappers that offer one or more slots for any lists and components. For example, to display several links.

The assumption here is that footers are often very individually structured, so that overly strict specifications on the part of the design system would be too **restrictive**.

## Thoughts on implementation

### Mobile Accordion

🧠 _Link lists are summarised in an accordion on mobile so that the footer appears shorter and tidier._

❓Links within collapsed accordion items are not read out by screen readers, only when the item is expanded. The page search does not find these links either. **Presumably this is not a11y compliant.**

### data props versus component driven

🧠 _Should the contents of the footer be transferred exclusively as data per property? Or are the contents mainly assembled "manually" via various (sub)components?_

#### data props only
**Pro**
- easier to use for devs
- the integrity of the footer is guaranteed. a standardised look is maintained.

**Contra**
- not consistent with the approach of existing components
- not very flexible
- links cannot be customised, which may be necessary depending on the framework

#### (sub)components only
**Pro**
- flexible in use
- standardised use within the DST
- structure of the footer is represented in the template

**Contra**
- devs must strictly follow the docs to build a footer
- there are no active guides, such as code completion or type checking, when using the footer component
- potentially more errors are possible
- devs need to write more code in the template



Loading