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: add default value for activeid to Tabs #6455

Closed
KingOfTac opened this issue Oct 14, 2022 · 3 comments · Fixed by #6606
Closed

feat: add default value for activeid to Tabs #6455

KingOfTac opened this issue Oct 14, 2022 · 3 comments · Fixed by #6606
Labels
area:fast-foundation Pertains to fast-foundation bug A bug community:request Issues specifically reported by a member of the community. status:needs-investigation Needs additional investigation

Comments

@KingOfTac
Copy link
Collaborator

🙋 Feature Request

When Tabs does not have the activeid attribute explicitly set by a developer, the active indicator jumps beyond the next tab that is clicked on before settling into the correct position. By setting the activeid this behavior does not happen.

🤔 Expected Behavior

If the active indicator is enabled, the animation for selecting tabs should function smoothly.

😯 Current Behavior

The active indicator jumps beyond the first tab selected by a user before settling on the selected tab if the activeid is not set.

💁 Possible Solution

Since Tabs assigns ids to its child tab elements in the event that page authors don't provide ids to the tabs, it should probably also set the activeid to the first non-disabled tab.

💻 Examples

This behavior can be seen in both the now archived fast-components package https://explore.fast.design/components/fast-tabs and the vNext storybook example.

@KingOfTac KingOfTac added the status:triage New Issue - needs triage label Oct 14, 2022
@EisenbergEffect EisenbergEffect added bug A bug status:needs-investigation Needs additional investigation area:fast-foundation Pertains to fast-foundation community:request Issues specifically reported by a member of the community. and removed status:triage New Issue - needs triage labels Oct 18, 2022
@EisenbergEffect EisenbergEffect added this to the FAST Foundation 3.0 milestone Oct 18, 2022
@chrisdholt
Copy link
Member

@KingOfTac as noted in our quick poll of the collaborators channel the other day I think we'll remove this in Foundation with an expectation it'll exist in the CLI. Should we move this to that repo to track the addition of the active indicator? I'm also thinking of creating an issue to track creating an example for active indicator support since it won't exist in Foundation. Thoughts?

@KingOfTac
Copy link
Collaborator Author

@KingOfTac as noted in our quick poll of the collaborators channel the other day I think we'll remove this in Foundation with an expectation it'll exist in the CLI. Should we move this to that repo to track the addition of the active indicator? I'm also thinking of creating an issue to track creating an example for active indicator support since it won't exist in Foundation. Thoughts?

I'm good with either result. I can see value in both tracking for adding through the CLI and an example of manually adding it for folks who opt out of using the CLI.

@yinonov
Copy link
Contributor

yinonov commented Jan 4, 2023

here's another related issue, the initial transition should be avoided -

Screen.Recording.2023-01-04.at.10.12.01.mov

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:fast-foundation Pertains to fast-foundation bug A bug community:request Issues specifically reported by a member of the community. status:needs-investigation Needs additional investigation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants