Move away from * { box-sizing: border-box } to play nice with 3rd party scripts

[staaky]

The snippet below can be found in bootstrap.css:

*,
*:before,
*:after {
  -webkit-box-sizing: border-box;
     -moz-box-sizing: border-box;
          box-sizing: border-box;
}

Using this global css reset is fine as long as someone uses Bootstrap exclusively. Once third party scripts come into play this global reset to border-box starts messing up layouts.

For example, a lot of bug reports I'm getting for my (lightbox and tooltip) scripts concerning layouts being off end up being caused by this practice in Bootstrap. I'd say it's not something that belongs in a framework, unless it's meant to be used without third party scripts.

Foundation used to have this problem. It was fixed very elegantly in 5.0 by using a mixin to add the box-sizing reset to just the components that need it. By not defining it on * third party scripts remain unaffected and work out of the box. They can rely on the default box-sizing content-box being in place without anyone having to make css adjustments to reset things back to default.

I'm hoping something similar can be done in Bootstrap.

[mdo]

We won't be changing it.

[jayphelps]

@mdo No explanation? I think this is a very legitimate complaint and deserves more than a quick "won't fix-closed".

[cvrebert]

Because border-box is just plain better? http://www.paulirish.com/2012/box-sizing-border-box-ftw/
And, to my knowledge, third-party widget compatibility has never been a primary design goal/consideration for Bootstrap.

[mdo]

Sorry for the brevity, folks. Here's a better explanation.

• We don't support third party plugins or frameworks. Bootstrap is a huge project, but it's actively maintained by four people. Can't always help everyone despite wanting to.
• As @cvrebert mentioned, border-box is better for sizing components and folks all over are switching to it. Perhaps these other libraries should upgrade to support it. It's as easy/difficult for us to do it as it is for others. It's intrusive, but it's smarter and more durable development.
• Repeating the same mixin for every component and sub-component sounds like a nightmare to maintain.
• Perf wise, this code kinda sucks, but we've already improved it some in master. More on that in a blog post soon.
• Lastly, changing this now would like introduce a lot of bugs for folks. We can't realistically revisit this until v4 due to backward compatibility, and that May or may not be a long ways away.

Hope that helps. I'm not in front of my computer right now, so I'm doing this from my iPhone in a Starbucks. I'll check back in on this as any further comments come in.

Apologies again for the asshole-ish brevity. Not my intention to crap on your heart and make folks regret using open source.

<3<3<3

[jgornick]

@mdo If this were to be implemented, I would prefer a build option for no-conflict.

Just spitballing, but by doing a no-conflict build it would produce output that would remove any global normalize rule sets and merge global rule sets into the related bootstrap rule sets.

To add more complexity, it would be nice if bootstrap specific selectors could be prefixed. This would avoid conflicting with existing legacy selectors. This can already be done by using https://github.com/faucamp/bootstrap_namespace_prefixer, but I feel there is a better way of manipulating the selectors other than using regex.

This would also introduce a number of selectors that would have to be specified in the class list for the element. For example, hr { ... } with prefix would become .twbs-hr { ... } or hr.twbs { ... }. It's implementation then would be <hr class="twbs-hr" /> or <hr class="twbs" />.

Yes, there are plenty of negatives by providing this option, but for legacy codebases that want to start migrating to bootstrap, this is a good start.

[carasmo]

I would leave it as is. I have found it no issue to go into the third party css and adjust the math to include padding and borders, it's actually easier and works better. I've done this with about 15 different third party css files for sliders and fancyBox.

[renaudleo]

I would also leave it as is. It's not such a huge pain to go back to content-box when using third party scripts:

.fancyPlugin,
.otherPlugin {
  *,
  *:before,
  *:after {
  -webkit-box-sizing: content-box;
     -moz-box-sizing: content-box;
          box-sizing: content-box;
  }
}

[staaky]

Thanks for clarifying, it's good know to know Bootstrap isn't meant to be used with third party plugins, helps explain this practice to my users. Hopefully Bootstrap 4 will catch up with Foundation and realize that this practice, while being more work on the Bootstrap end, is better kept within its own namespace.

[carasmo]

Bootstrap is js, html, and css. A simple bit of css used by @renaudleo makes it work with third party plugins.

[staaky]

@carasmo we know that, the idea here is that with some changes to Bootstrap, nobody has to bother with fixes to make things work.

[hnrch02]

I fail to see why any third party would choose the default box sizing over box-sizing: border-box

[cvrebert]

@hnrch02 Possibly to support IE7? (Bootstrap doesn't officially support IE7.)

[hnrch02]

@cvrebert If support for IE7 is critical a polyfill could be used.

[staaky]

@hnrch02 Third party scripts not choosing automatically get box-sizing: content-box since that is the default. By resetting the default to border-box globally Bootstrap removes the option to do nothing and just go with the default, forcing everyone to either reset the Bootstrap reset or deal with it like you're doing. Ideally you'd want things to just work for everyone, that not being the case is the problem here, not people's opinion on which box-sizing to use.

[hnrch02]

@staaky As Paul Irish mentions in his post, box-sizing is one of the few CSS3 properties with (almost) excellent browser support and it makes working with dimensions in CSS so much easier, so I don't see why a developer would not choose box-sizing: border-box and resort to the default value.
This of course is just a personal view, I see that Fresco is advertising browser support for IE 6+, so any CSS3 properties are dangerous for your use case, but as this global property seems to just affect one part of Fresco I think it would be much easier if you would just add that three line rest to your CSS.

[staaky]

@hnrch02 @paulirish actually caused Foundation to define border-box for just their components instead of globally by posting his opinion on their bugtracker foundation/foundation-sites#2460 (comment)

So by mentioning that Bootstrap 3 avoided the global * bad practice he actually caused this to be fixed in Foundation 5, the only thing he didn't get right was Bootstrap 3 avoiding the practice. That's why I'm bringing this up.

[hnrch02]

Alright, I think @cvrebert's solution is sufficient for now, everything else would need to be deferred as @mdo mentioned above to v4.

[mdo]

@staaky For the record, Foundation 5 still universally resets box-sizing. There are no per-component settings for it. There's nothing to catch up to here.

Again, practicality beats purity here. Sure, being specific helps in the few instances of unexpected collisions, but the consistent behavior for easier sizing of all elements is a huge win. Nothing will change in v3 and I imagine not much will change in v4, unless another selector comes along.

[paulirish]

@staaky I think you're walking against the wind here. If you maintain a third-party widget it's your responsibility to make it robust and function well in all environments (except, perhaps quirks mode). Disqus among others have already dealt with this and baked in their own box-sizing rules to insulate their styles from the host page. I think that's going to be a far more effective route than trying to change the rest of the world.

[staaky]

@paulirish Can't the same be said for frameworks? Shouldn't they try to do things in a way that conflicts with the least amount of third-party widgets? The reason I'm pointing this out is not to get Bootstrap to move away from box-sizing, just to get them to use it more effectively. What I'm seeing is that people are monkey patching third-party scripts to work with Bootstrap, ideally they shouldn't have to. I could simply deal with it on my end but I'm not sure if Bootstrap would be better for it.

[carasmo]

Framework is the foundation and when the foundation uses box-sizing:border-box the rest of the architecture should adapt to use the the better, forward solution. You can't simply make fluid, responsive layouts with borders with content-box sizing. And since it takes moments to add the the LESS written earlier, and since, hopefully, you're adjusting the background, font, and colors of the widget, this is an odd request.

[staaky]

@mdo Keep border-box in, that's not my issue, it would be nice though if Bootstrap could keep its use within its own namespace to avoid conflicts. I see why doing that is not as practical as having a global selector, but avoiding the global reset would make things better.

The docs showing how to monkey patch third party code moves the problem to third parties and people using their code, it won't cover every usecase, but I guess that'll have to do for now. Maybe one day we can have a nice conflict free solution and get rid of those docs.

[joelbyrd]

Hey guys - can't you just use the updated box-sizing technique that doesn't interfere with 3rd-party code? @paulirish actually updated the technique in his article (http://www.paulirish.com/2012/box-sizing-border-box-ftw) in August of last year based on this article: https://css-tricks.com/inheriting-box-sizing-probably-slightly-better-best-practice. The new code looks like this:

html {
  box-sizing: border-box;
}
*, *:before, *:after {
  box-sizing: inherit;
}

[cvrebert]

@joelbyrd (1) See #14172 & #14173 (try searching a bit more next time). (2) Avoid commenting on year-old issues; nobody is watching them anymore. Open a new issue instead.