Tweak .visually-hidden
to use display:inline-block
instead of absolute positioning
#41474
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Use
display:inline-block
instead ofposition: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 #31885As the
position:absolute
is used essentially to force the element to accept explicitwidth
/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
Checklist
npm run lint
)Live previews
Related issues
#31885