Add .visible (visibility:visible) and .hidden (display:none) utility classes

[Mevrael]

1. Right now there is .invisible utility class to set visibility: hidden, however, some elements might be hidden by default and it would be helpful to have also a .visible utility class to make visibility: visible;
2. In bs4 and not only in bs4 there are elements set to display: none by default, however, there is no option to make element visible again. Since there is no way to restore back HTML tag's display property I am suggesting adding some utility classes like .display-block, .display-inline-block, .display-inline.
3. I am not sure but looks like in bs4 there is also no .hidden class to set display: none; There are only hidden up/down for breakpoints.

[cvrebert]

(1) [...] it would be helpful to have also a .visible utility class to make visibility: visible;

Sounds reasonable enough.

(3) I am not sure but looks like in bs4 there is also no .hidden class to set display: none; There are only hidden up/down for breakpoints.

We got rid of .hidden since it's redundant to .hidden-xs-up (or .hidden-xl-down). Just use .hidden-xs-up instead.

[cvrebert]

(2) In bs4 and not only in bs4 there are elements set to display: none by default, however, there is no option to make element visible again.

Regarding the BS4 case, there are classes that make the hidden-by-default widgets visible (unless the hiding entity's sole purpose is to hide the element, or unless it'd be pointless):

• .dropdown-menu is shown via .open
• .tab-pane is shown via .active
• .carousel-item is shown via .active
• .collapse is shown via .in
• [hidden]'s raison d'être is to hide its element
• The .hidden-* classes' raison d'être is to hide their element at certain viewport widths
• Showing .tag:empty seems pointless
• .modal is shown via JavaScript; doesn't seem to have been a problem
• The @media print stylesheet hides .navbar; this is more debatable, but you can always just disable Bootstrap v4's print stylesheet if you're creating fancier print styles & need more control

Regarding non-Bootstrap widgets, it's worth considering alternate approaches which use an explicit display: none class (or the HTML5 [hidden] attribute), which you can then remove when you want to show the widget. This allows your CSS to be completely generic with respect to the widget's "normal" non-none display value.

(2) [...] I am suggesting adding some utility classes like .display-block, .display-inline-block, .display-inline.

I note that responsive versions of such classes were rejected in #18410. Not the same as what you're suggesting, but similar enough to be worth mentioning.

[Mevrael]

Just use .hidden-xs-up instead.

Not obvious and small .hidden alias would be just 3 short lines.

(or the HTML5 [hidden] attribute), which you can then remove when you want to show the widget.

Widget uses display: none; so I don't have hidden attribute at all and can't remove it. bs4 also doesn't use HTML5 hidden attribute.

.dropdown-menu is shown via .open
.tab-pane is shown via .active
.carousel-item is shown via .active
.collapse is shown via .in

Why making new class name for each case instead of making one class name for all cases? And if you mentioned HTML5 hidden attribute why not using it instead?

.modal is shown via JavaScript; doesn't seem to have been a problem

Using jQuery in 2016 is problem. If you at least will start using document.querySelector() instead of $()[0], element.classList.add() instead of $().addClass() etc. you could at least make some js components without any dependencies.

And instead of writing ES6 "class" syntactic sugar use factories and Object.create(); You can find many articles and videos online explaining why it is bad practice.

I note that responsive versions of such classes were rejected in #18410. Not the same as what you're suggesting, but similar enough to be worth mentioning.

Not similar at all. I agree that there is no need in making responsive classes for each breakpoint, however, at least basic helper class to set display: block; would be perfect. I would suggest making single one, let say, .shown { display: block; } and you could use it instead of .open, .active, .in etc.

[cvrebert]

I am suggesting adding some utility classes like .display-block, .display-inline-block, .display-inline.

To be clear, I'm personally not opposed to adding those.

---

Not obvious and small .hidden alias would be just 3 short lines.

• It would raise the question of what something like <div class="hidden hidden-md-down"> would mean
• Since we already have both .hidden-xs-up and .hidden-xl-down for uniformity reasons, it would add yet a 3rd way to express the same thing
• If you later decide you want to hide the element in a responsive manner, it's easier/smoother to transition to e.g. .hidden-md-down from .hidden-xs-up than from .hidden

---

Why making new class name for each case instead of making one class name for all cases?

No idea. I agree that it seems like settling on a single one would be better.

Widget uses display: none; so I don't have hidden attribute[/class] at all and can't remove it.

FWIW, you probably don't need(/want) to toggle the classes directly; all the Bootstrap widgets have JS APIs to handle opening/closing them, which in addition to twiddling the classes also fire useful events, etc.

bs4 also doesn't use HTML5 hidden attribute.
[...] And if you mentioned HTML5 hidden attribute why not using it instead? [...]

Partly historical reasons. The v3 code didn't use it, and using it would have required a little extra CSS that we only started including in v4 to use it properly. And generally I think there was less awareness of its existence in the past.
And except for Collapse (for which there's an open issue), none of the widgets need to be generic with regard to non-none display, so it hasn't been a critical need thus far.
At this point, I suspect using [hidden] would get shot down on the grounds of being annoying, in that it'd have to be included in the markup of nearly every instance of the relevant widgets (since they're seldom initially open/shown).

Using jQuery in 2016 is problem. [...]

JS architectural advice is getting off-topic. My point was that .modals are currently shown via inline style rather than adding/removing CSS classes; i.e. there's no .modal.active or similar; and that this hasn't led to any issues which I can recall. Whether the style is edited (or hypothetical classes are twiddled) via jQuery or via raw DOM APIs is an orthogonal concern.

[Mevrael]

It would raise the question of what something like <div class="hidden hidden-md-down"> would mean

It is the same as asking a question what <div class="hidden on navbar card footer"> means. Nobody will mix hidden with hidden-md-down and will use only those classes they need.

FWIW, you probably don't need(/want) to toggle the classes directly; all the Bootstrap widgets have JS APIs to handle opening/closing them, which in addition to twiddling the classes also fire useful events, etc.

Even since bootstrap 3 many developers, teams and companies were using Bootstrap only as sass/less framework. Because of jQuery dependency we now have bootstrap.native, angular, react and other versions of bootstrap js API rewriten from scratch for better perfomance and compatability with JS frameworks.

Obviosly in Bootstrap 4 this trend will be the same and even bigger. There will be angular bootstrap 4, react bootstrap 4 and whatever else bootstrap 4 repositories.

I am using vanilla JS, ES6 and importing only modules I need, that why I can't use bootstrap official JS API. There will be also many plugins for bootstrap 4 like we had bootstrap 3 datepickers and everything else.

However, it is still not too late to make native bs4 JS API so I and anyone else could do in his project using any JS framework something like

import { Tab } from 'bootstrap/src/es6/tab';

big form has steps/tabs
on form validation
if invalid input in another tab
switch tab
Tab.changeTab('tab-pane-ID')

...

Tab.onChange('tab-pane-ID', function() {
  ...
});

Simple example about those custom APIs and widgets. I was not able to make a simple bs4 autocomplete widget without making custom styles. You are making a bootstrap 4 class based and that's very good, let then make bootstrap 4 best scss framework ever and give tools and abilities to build absolutely everything including styles used by 3rd party JS libraries and frameworks.

My point what I want to say is if bootstrap won't have default options for common cases then there will be again custom APIs and many plugins with custom styles and when time comes to maitnain a big project it becomes to a real pain. Bootstrap css, bootstrap js, custom theme, jquery, jquery plugins, custom plugin A css, custom plugin A js, ... custom plugin Z css/js, micro-framework, template engine, somewhere project's own codebase, bootstrap class overrides etc.

Most jr. developers are learning form frameworks and their coding styles, standrads and software design patterns. More options you give, better the whole Internet and easier life for developers you make.

P.S. even if my time is very limited, I am always happy to contribute. If you need help somewhere you can always mention me with @ in comment, even if just opinion required.

Btw, I would recommend making a slack room for project where anyone could discuss features, internal development and ask any questions.

[RyanZim]

I'm all for .display-block
Since .center-block was removed in favor of .m-x-auto in #19102, there should be a utility that sets
display: block to facilitate centering images.

[cvrebert]

Btw, I would recommend making a slack room for project

See 3rd bullet point of https://github.com/twbs/bootstrap#community
There's also IRC 😄

Nobody will mix hidden with hidden-md-down and will use only those classes they need.

Having followed this issue tracker for quite a while, I'm not so optimistic / don't share your level of faith in humanity at this point.

[cvrebert]

Split the display utility classes request into a new issue: #19343

[cvrebert]

Opened a new issue regarding the suggestion to use 1 uniform class name for opened/expanded/shown widgets: #19344

[cvrebert]

Also, now that I look, I see we specifically killed .hidden in v4 because it conflicts with jQuery's $().show() and $().hide() methods, which are very popular.
X-Ref: #9881 (which had several duplicates and a fair number of commenters), 07ef67d
So personally I hope we keep that can of worms firmly sealed.

[cvrebert]

CC: @mdo for opinion regarding the remaining .visible { visibility:visible; } and .hidden requests.

[cvrebert]

@mdo Need you to weigh in here. ^^^

[mdo]

#22113 redid all these utilities, I think we're set here now.