v4 [hidden] attribute

[CoralSilver]

The hidden attribute isn't supported in IE9 or 10. The comments say // Always hide an element with the hidden HTML attribute (from PureCSS). (instead of the old hidden class), but PureCSS includes a .hidden class along with the attribute.

[kkirsche]

For any unsupported browser you can easily add support by just including the following CSS:

[hidden] { display: none; }

This will work back to IE6, which doesn’t support the attribute selector.

In other words, basically: https://github.com/twbs/bootstrap/blob/v4-dev/scss/_utilities.scss#L35

With that said, the workaround is not universal as it only patches attribute behavior to sort of mimic property behavior. I personally don't see any benefit in having a class for this as well.

[cvrebert]

Closing per @kkirsche's comment.

[mdo]

Mentioned some of this in the docs in cf7819d, FYI.

[CoralSilver]

Thanks @kkirsche. So declaring display: none on the hidden attribute will patch default the attribute behavior. But the docs http://v4-alpha.getbootstrap.com/components/utilities/ say .hidden was removed due to conflicts with jQuery’s hide() function. [hidden] is set to display: none !important. What is the .hide() conflict? There is a conflict with .show(), since jQuery .show() doesn't use !important. So won't there still be the same jQuery conflict? Do people use .addClass() and .removeClass() now to get around it? Just trying to understand how this fixes this. Isn't toggling classes (attributes in this case) better practice than show and hide, or not ?

[kkirsche]

@CoralSilver in regards to why it was removed and conflicts I would need to defer to @mdo / @cvrebert and the rest of the team as that's not an aspect I am familiar with. Sorry!

[hnrch02]

#9237 & #9881 talked about removing !important from hidden, I don't know where we stand on this now tho, @mdo?

[mdo]

Unsure of the feasibility honestly, we'll have to check it out.

[CoralSilver]

Couldn't you remove !important if hidden was at the end of the stylesheet to override previous display: block? But then, this wouldn't work with any custom styles declared afterwards with display: block.

[cvrebert]

So, the two changes were made separately and not considered together.
(1) We removed .hidden because folks couldn't use it in combination with jQuery's very popular show()/hide() methods.
(2) We added [hidden] {display:none !important;} because the default HTML semantics for the hidden attribute (equivalent to [hidden] {display:none;}) kinda suck. For example, given:

<div class="x">Foo</div>
<div class="x" hidden>Bar</div>

.x {
  display: inline-block;
}

both "Foo" and "Bar" will be visible. This can be corrected by making the display:none be !important. Why HTML doesn't define [hidden] to be super-important in the first place is beyond me.

[cvrebert]

Isn't toggling classes (attributes in this case) better practice than show and hide, or not ?

Arguably yes, particularly considering the changes coming in jQuery 3.0 (see the "Simplified .show() and .hide() methods" section).

[CoralSilver]

Yeah, that is weird that [hidden] isn't important. So shouldn't it be mentioned in the docs that [hidden] won't work with show() and hide() either, and one shouldn't be using those functions to toggle visibility at all, especially given the coming changes you mentioned? So .hidden could still exist in that case? Or is there some semantic or accessibility reason to use the attribute instead?

[cvrebert]

It's certainly more semantic. The semantic meaning of [hidden] is defined by the HTML5 spec, whereas .hidden is just another class as far as the browser and assistive technologies are concerned. And there's no consensus on what to name the class; libraries variously use .hide, .hidden, .invisible, etc.

Yeah, the interaction with jQuery could stand to be documented.

[CoralSilver]

I think mentioning in the docs that .hidden was swapped for [hidden] because it is more semantic, rather than because of the show() hide() conflict (with a mention of the proper way to deal with it in jQuery), would definitely make the change more understandable.

[CoralSilver]

As .hidden wasn't deprecated in the last version, I would consider leaving it in (with a deprecation notice), so users that were using it with removeClass() will have time to switch over to removeAttr() (and not be forced to). Doesn't seem like it would make much difference with assistive technologies, no? They are already going to skip over something display: none.

[kkirsche]

@CoralSilver there's no reason for us to deprecate it in my opinion. V4 is a major update and as such we should probably not deprecate things as this is our chance per semantic versioning to make non backwards compatible changes. Keeping it as deprecated will keep it until V5 which while small starts this type of questioning about any and all classes which I think the core team would want to avoid. X-Ref: #17240

[CoralSilver]

Makes sense. Thanks.

[mdo]

We all good here or is there something else to tackle yet?

[cvrebert]

@mdo I got this.

[cvrebert]

Resolved by #17689.