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

Resolve .hide/.hidden/.sr-only redundancy/confusion #10446

Closed
cvrebert opened this issue Sep 4, 2013 · 6 comments · Fixed by #10769
Closed

Resolve .hide/.hidden/.sr-only redundancy/confusion #10446

cvrebert opened this issue Sep 4, 2013 · 6 comments · Fixed by #10769

Comments

@cvrebert
Copy link
Collaborator

cvrebert commented Sep 4, 2013

.hide & .sr-only both have the same final effect.
.hide & .hidden have confusingly similar names, but do slightly different things.

Visibility table:

Visual user Screen reader Class Implementation summary
No No .hidden // Hide from screenreaders and browsers
No YES (usually) .hide display: none !important;
No YES .sr-only // Only display content to screen readers
@ckundo
Copy link

ckundo commented Sep 4, 2013

@cvrebert
Copy link
Collaborator Author

I propose deprecating .hide in favor of the other two (the appropriate replacement depends on which semantic the developer actually intended). We can then see about renaming .hidden to .hide in v4 (and probably also rename .sr-only to something better).

@ckundo
Copy link

ckundo commented Sep 23, 2013

You might consider using aria-hidden with a CSS attribute selector instead of a class name when the result is screen reader specific.

W3C's aria techniques:

It is recommended that authors key visibility of elements off this attribute, rather than change visibility and separately have to remember to update this property. CSS 2 provides a way to select on attribute values ([CSS]). The following CSS declaration makes content visible unless the aria-hidden attribute is true; scripts need only update the value of this attribute to change visibility:

[aria-hidden="true"] { visibility: hidden; }

@cvrebert
Copy link
Collaborator Author

We generally have a policy of avoiding attribute selectors when possible, for performance reasons.

@ckundo
Copy link

ckundo commented Sep 23, 2013

I see, besides standardizing markup I thought maybe attribute selectors might be a performance boost, per this post: http://stackoverflow.com/a/18116119

One of the hidden benefits to using attributes over classes is a performance gain in JavaScript. Instead of having to check for the presence of a class on an element (which is remarkably easy to get wrong), browsers have supported getAttribute, hasAttribute, and setAttribute for a long time.

@cvrebert
Copy link
Collaborator Author

We meant the performance of the "style engine"/renderer, not JS.

cvrebert added a commit that referenced this issue Sep 23, 2013
mdo added a commit that referenced this issue Sep 24, 2013
@cvrebert cvrebert mentioned this issue Oct 7, 2013
stempler pushed a commit to stempler/bootstrap that referenced this issue Apr 11, 2014
stempler pushed a commit to stempler/bootstrap that referenced this issue Nov 4, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants