replace .visible-{size} with .visible-{size}-{display}

[cvrebert]

Adds .visible-{screen size}-block, .visible-{screen size}-inline, and .visible-{screen size}-inline-block classes (and also a corresponding trio for .visible-print). Also deprecates the .visible-{screen size} classes.

Proposed fix for #8869 pursuant to #9397. Includes docs updates.

There is most likely a way to refactor this to be less repetitive & more concise by using some more sophisticated Less features, but this should be okay for the time being.

/to @mdo for review.

[juthilo]

Perhaps make it more clear in the docs that you can now use any of these classes to toggle table elements?

[mdo]

This is really verbose. Why not use new mixins for just the inline and inline-block variations? How often will you see any table related element go from inline to table, or table to inline? Don't see those mixing that often.

[mdo]

I think I'd rather wait to do this until v3.2 given we've only a few days left for v3.1.

[cvrebert]

@mdo This has now been revised accordingly to exclude the table-related special casing.

[mdo]

Nice. Are we deprecating the generic classes then? Should we mention that in the docs and downplay that?

[cvrebert]

Are we deprecating the generic classes then?

Yes; at least, that's what I'm proposing.

Should we mention that in the docs

Yes, fair point. I'll further tweak the PR.

[cvrebert]

Okay, the deprecations are now mentioned in the docs.

[juthilo]

Don't the hidden-xs, -sm, -md, -lg, and -print classes need to be deprecated as well, as .responsive-invisibility() will be deprecated?

[cvrebert]

IMHO, no. We'll merely be able to simplify those classes to not be defined using the mixin in v4, but their semantics should be unaffected except possibly in some very obscure edge cases.

[juthilo]

I see and agree, thanks for explaining.

Is this perhaps suitable for inclusion in 3.1.0 after all? Seems it's all set except for a rebase? Don't wanna rush anything though... :)

[cvrebert]

Rebase complete :-)

[juthilo]

⭐⭐⭐⭐⭐ ;)

[cvrebert]

Okay, the unrelated fix that made the classes chainable also made my changes not merge anymore, but I've now pushed a revised version.

[mdo]

Word, I'll peep this again soon.

[mdo]

@cvrebert Is there something to update here regarding recent or conflicting changes?

[cvrebert]

@mdo No conflicts, but I've just rebased this again so that Travis will turn green. Just needs QA+review.

[mdo]

Thinking ahead more, I have two questions:

• What about table displays? Tables, rows, cells, headers, etc. Where do we draw the line?
• What about that other issue that asks for breakpoint and below classes? For example, hide on medium and below? Does this then balloon out if we have to support those classes as well?

[cvrebert]

IMHO FWIW:

• "size X and above/below" seems more common and makes more sense than "at only size X".
• having both "show" and "hide" classes seems unnecessary since they're symmetrical; only one kind is really needed
• if possible, it'd be best to use a technique that's generic with respect to the non-hidden display value, so as to minimize the number of classes (WRT your point about table-related displays)

(This PR doesn't comply with all these goals.)

[alexislefebvre]

@cvrebert: I have a menu where I display normal texts on xs and lg screens, and short texts on sm and md screens. So I needed to use both show and hide classes.

[DaSchTour]

can't the .visible-{screen size} be left as it is and only the -inline and -inline-block be added.
Normally it works as it should and I think many people wouldn't like to replace all their .visible and .hidden just for some who need and inline visible/hide.

[alexislefebvre]

What about adding a class for setting the display:inline-block;?

For example: <div class="visible-sm visible-inline-block">...</div>.

And the CSS:

@media (min-width: 768px) and (max-width: 991px) {
  /* current class */
  .visible-sm {
    display: block !important;
  }
  /* new class */
  .visible-sm.visible-inline-block {
    display: inline-block !important;
  }
...

I'm pretty sure no one will need to display a block as inline or inline-block in 2 different sizes. So the combination of the 2 classes should be sufficient.

With this class, backwards compatibility won't be broken.

[mdo]

@alexislefebvre We avoid chained classes in Bootstrap whenever possible.

[mdo]

💎💎💎💎💎💎💎💎💎💎🚢💎💎💎💎💎💎💎💎💎
💎💎💎💎💎💎💎💎💎🚢🚢🚢💎💎💎💎💎💎💎💎
💎💎💎💎💎💎💎💎🚢💎🚢💎🚢💎💎💎💎💎💎💎
💎💎💎💎💎💎💎🚢💎💎🚢💎💎🚢💎💎💎💎💎💎
💎💎💎💎💎💎🚢💎💎💎🚢💎💎💎🚢💎💎💎💎💎
💎💎💎💎💎🚢💎💎💎💎🚢💎💎💎💎🚢💎💎💎💎
💎💎💎💎🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢💎💎💎
💎🚢🚢💎💎💎💎💎💎💎🚢💎💎💎💎💎💎🚢🚢💎
💎💎🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢💎💎
💎💎💎💎🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢🚢💎💎💎

[hnrch02]

After ASCII art now comes Emoji art; It's great, I love it!

[Shane32]

I would like to point out another solution (below). It maintains existing syntax and works with any type of element, as it does not change the CSS display property except when hiding the element. However, it requires IE9+, so may only be useful when IE8 compatibility is dropped.

@media (max-width: 767px) {
  .visible-sm:not(.visible-xs),
  .visible-md:not(.visible-xs),
  .visible-lg:not(.visible-xs) {
    display: none !important;
  }
}
@media (min-width: 768px) and (max-width: 991px) {
  .visible-xs:not(.visible-sm),
  .visible-md:not(.visible-sm),
  .visible-lg:not(.visible-sm) {
    display: none !important;
  }
}
@media (min-width: 992px) and (max-width: 1199px) {
  .visible-xs:not(.visible-md),
  .visible-sm:not(.visible-md),
  .visible-lg:not(.visible-md) {
    display: none !important;
  }
}
@media (min-width: 1200px) {
  .visible-xs:not(.visible-lg),
  .visible-sm:not(.visible-lg),
  .visible-md:not(.visible-lg) {
    display: none !important;
  }
}