Bootstrap: HTML hidden attribute not working on input elements

[Willem-Siebe]

Hi, only tested it for input elements, using the HTML hidden element is not working:

<input type="text" class="form-control" placeholder="Name" id="name" required data-validation-required-message="Please enter your name." hidden="">

As you can see the display:none is not working because of the display css from .form-control.

Kind regards,

Willem

[cvrebert]

Hmm, apparently Chrome's native [hidden] { display: none; } rule is less specific than a class selector, hence why .form-control { display: block; } wins.
Seems like the hidden attribute is not very useful as currently implemented by browsers; see http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Apr/0094.html
I suppose [hidden] { display: none !important; } is an option, but that's kinda aggressive.
X-Ref: https://github.com/necolas/normalize.css/pull/164

[kellygrape]

Maybe .form-control[hidden] as a workaround?

[cvrebert]

To be consistent, that'd seem to require also adding _an awful lot_ of [hidden] declarations for a lot of other classes.

CC: @mdo

[peterblazejewicz]

This is perfectly legal behavior (as per specs), maybe not expected but not a bug per se I think:

Changing the display CSS value of an element with the hidden attribute overrides the behavior. For instance, an element styled display: flex will be displayed on screen regardless of the hidden attribute being present.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#hidden
https://html.spec.whatwg.org/multipage/interaction.html#the-hidden-attribute

[Willem-Siebe]

@peterblazejewicz , it's not a bug, it's a Twitter Bootstrap CSS issue.

I think we all agree about what the hidden attribute is for? Since this attribute is typically implemented using CSS, the user agent has done his job by using display:none.

However, when we are going to add our own CSS styles, we have to do a correct CSS implementation as well that respects the hidden attribute, since:

if something is marked hidden, it is hidden from all presentations, including, for instance, screen readers.

Now, that Twitter Bootstrap is using display:block on (in my example) .form-control is NOT because Twitter Bootstap want to override the display:none, this is CSS intented for elements that are not hidden. So you can call this behaviour 'legal', but it is not intented.

Twitter Bootstrap should formulate CSS in such a way that when using a hidden attribute, that element is really hidden, then we did a good job respecting the hidden attribute in the same way a user agent does it already.

[peterblazejewicz]

@Willem-Siebe I still think it is not a bug - just something not yet taken into account. Bootstrap uses hidden attribute reset correctly:
https://github.com/twbs/bootstrap/blob/master/less/normalize.less#L77-L80
taken literally from Normalize project:
https://github.com/necolas/normalize.css/blob/master/normalize.css#L77-L80a
but approach similar to one used in Pure CSS can be used:
https://github.com/yahoo/pure/blob/master/src/base/css/base.css#L11-L17
which is documented by the way in their docs:
http://purecss.io/base/#extras

Add the hidden attribute to an HTML element to hide it from the screen via display: none !important;

[mdo]

We can tackle the [hidden] { display: none !important; } in v4. It'd be a new feature to v3, so we won't be adding it there. Really neat thing to account for btw—love it.

[Willem-Siebe]

@peterblazejewicz Thanks for the nice wrap-up with links, I already agreed with you it's not a bug :-).
@mdo Don't know exactly how you organize things here in Github, but I understand this will be added to v4. Is it normal then that this ticket is already 'closed'. I also wondered, since it will be added to normalize.less, if we need to bring it under attetention of Normalize as well, you write:

Please do not open issues or pull requests regarding the code in Normalize (open them in their respective repositories).

[cvrebert]

@Willem-Siebe Yes, we are closing tickets targeted at v4 at this point and adding notes about them to a separate private document. The !important is what will make the change useful, but it's not what plain HTML5 specifies, so Normalize probably won't add it. Thus, any change will most likely need to be at the Bootstrap level.

[mbrevda]

Just wondering about the workflow and why the closed tickets are going in a _private_ document. Trolls? Wouldn't adding a milestone tag be more transparent?

[mdo]

Transparency in a dev process where things are added and removed on a whim serves little purpose. The v4 prep work is being done with a small set of developers—the core team. Then it'll be open for feedback. Too many cooks in the kitchen otherwise.

[darshan-jain-29]

Hmm, apparently Chrome's native [hidden] { display: none; } rule is less specific than a class selector, hence why .form-control { display: block; } wins.
Seems like the hidden attribute is not very useful as currently implemented by browsers; see http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Apr/0094.html
I suppose [hidden] { display: none !important; } is an option, but that's kinda aggressive.
X-Ref: necolas/normalize.css#164

{ display: none} worked for me

[patrickhlauke]

{ display: none} worked for me

and as the issue you decided to comment on is almost 4 years old, it's unsurprising that things have changed in the meantime...