Skip to content

Tweak .visually-hidden to use display:inline-block instead of absolute positioning #41474

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented May 18, 2025

Description

Use display:inline-block instead of position:absolute for .visually-hidden

Motivation & Context

While tried and tested, the regular .visually-hidden styles have unintended consequences in certain scenarios, such as inside responsive tables - see #31885

As the position:absolute is used essentially to force the element to accept explicit width/height/clip even when it's currently inline, this new approach should have the same end result, but without causing any more accidental spacing.


See the redone example from #31885 (replacing the old .sr-only with .visually-hidden), with overrides that mimic the end result of this PR: https://codepen.io/team/bootstrap/pen/azzxqBZ (removing the overrides in the Pen's CSS shows the current broken behaviour: make the viewport/browser window narrow, and notice how - just like in the original #31885 issue - the visually hidden content in the last cell of the first row leads to whitespace to the right of the table that then results in a page-level horizontal scrollbar)


Suggest extensive testing of this, to make sure the change doesn't now cause other unintended consequences elsewhere. Suggest also testing on devices that are notoriously flaky ... like "does it work as expected on iOS/Safari with/without VoiceOver running".

Marking as a breaking change because it has the potential to break things if an author did heavily rely on the old styles for some reason.

Type of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Refactoring (non-breaking change)
  • Breaking change (fix or feature that would change existing functionality)

Checklist

  • I have read the contributing guidelines
  • My code follows the code style of the project (using npm run lint)
  • My change introduces changes to the documentation
  • I have updated the documentation accordingly
  • I have added tests to cover my changes
  • All new and existing tests passed

Live previews

Related issues

#31885

@ffoodd
Copy link
Member

ffoodd commented May 26, 2025

I think this needs various test cases for when a visually hidden element is a flex or grid child, for example.

Absolute position ensures context and flow would not be impacted, but I think switching to display could lead to layout changes.

I'll try to pack some cases.

@patrickhlauke
Copy link
Member Author

thanks @ffoodd that'd be super helpful ... hoping that there won't be any unforeseen side effects here...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Needs review
Development

Successfully merging this pull request may close these issues.

2 participants