Bootstrap 4 Alpha 6 Released (blog.getbootstrap.com)

In my experience, it's really one or the other. There's unfortunately going to be a lot of duplicated overwriting code if you want to update it in the future. I'd love to know of better methods though.

Use the Bootstrap Sass files. In particular, overwriting the variables as much as possible instead of just overriding the compiled css will give you flexibility, as they try to preserve those across versions. If you've minimized the amount of overriding css that you've written, then rewriting it will be easier.

If you need to extend it, just extend it with your own includes. If you need to modify it, stick to editing variables. If you have both of those, then updating minor versions should be easy.

I tend to keep the source in the bower_components directory and copy/modify only the includes.

The issue is that the project is changing, you will have to wait for an RC if you really want stable code.

This tutorial [0] / [1] (using LESS) worked well for me. I recently did the upgrade from 3.3.6 - 3.3.7.

You create a directory just outside bootstrap and reference that from `bootstrap.less` inside the bootstrap core to override the bootstrap variables. Then you just have to modify `bootstrap.less` in the core bootstrap directory after upgrading.

  [0]: https://www.smashingmagazine.com/2013/03/customizing-bootstrap/
  [1]: https://github.com/thomaspark/bootswatch/

The way I prefer to do this is we have our own SCSS files which get compiled along side bootstrap, and they are all more specific than the Bootstrap SCSS so they get precedence.

For example, we might want our default alerts to all be purple or something. We can add a class "my-namespace" to the body, or to a closer parent of the alert and then add the following to our "my-namespace" SCSS. If I wanted to change the "alert-info" background to orange I could also include a rule for that.

Hopefully in production you'd be using color variables instead of hex codes, but:

    .my-namespace {
        .alert {
            background-color: #aa00aa;

            .alert-info {
                background-color: #dd8800;
            }
        }
    }

Now you're overriding Bootstrap without touching Bootstrap's SCSS. I far prefer this method than the method I see a lot of folks using where they just go mucking around in the Bootstrap SCSS directly.

It depends on how deep you plan to extend Bootstrap, obviously. I had one project I worked on that did a lot surgery to the Bootstrap files in a branch of fork of the main Bootstrap repository. I don't recommend that if you can avoid, and it was late in that project that I got better at being able to do overrides of the LESS files (as this was Bootstrap 2/3) in other LESS files without needing to edit the Bootstrap sources. There ends up being more duplication by doing it in separate files you control, but it makes it easier to deal with "merge conflicts" from upstream.

From that approach, one useful example I have seen is the infrastructure of the Bootswatch project. [1] Perhaps unsurprisingly for how many themes Bootswatch maintains, their GitHub repository is quite well laid out, easy to learn from, and even easy enough to fork as the basis of your own project.

[1] http://bootswatch.com/

This is last alpha. Next release in pipeline will be first Beta.

Also I would cut BS folk some slack. They are maintaining most popular OS project on Github. The maintenance burden for previous release was unimaginable and terrific, effectively pulling them down until they decided to make harsh decision of ceasing work at Bootstrap 3 and focusing at BS4 exclusively.

Off topic from OP but do you guys have a work-around for this issue in Safari that's still present to this day? https://bugs.webkit.org/show_bug.cgi?id=137730 (test: https://people-mozilla.org/~dholbert/tests/flexbox/compat_te...) It's been fixed in all other browsers and it's really killing the ability to go full blown flexbox

You're showing an arbitrary HTML snippet here, not Bootstrap's grid system. Add the grid markup and make sure your image is responsive, and you'll get https://jsfiddle.net/q39rq6eu/6/.

Not true, see here: https://jsfiddle.net/2om8t67a/3/ Images act a bit weird in flex though, so it might be true for img elements as direct children of flex containers, but for normal content it's not.

> what is the compatibility store for third party components/themes based on bootstrap.

I can't speak to components, but for themes there's already a migration guide, and I'd expect to see tools that help with the conversion since they're conceptually similar.

https://v4-alpha.getbootstrap.com/migration/

> will these third party components need to be re-written and support multiple bootstrap versions?

They'll need to be updated, but it's a one way trip. It wouldn't surprise me to see popular themes maintain Bootstrap 3 and Bootstrap 4 versions in parallel for a while.

Out of curiosity, is there anything significant other than flexbox that's not in IE9 but is in IE10/11?

I sincerely hope BS4 is the last nail in IE10's coffin

Folks seemed to expect the `!important`s to always ensure the utility classes are applied properly. https://twitter.com/mdo/status/684261888046190594

Purism sounds nice in theory, but in practice I have yet to come across a project where at some point an `!important` (or 2) NOT becomes necessary, where it then NOT seems utterly acceptable and in fact fully in line with "the proper natural purpose of !important" (subjectively+situationally perceived, of course) and moreover the only solution to not spend 1-2 weeks refactoring the entire project's very own ad-hoc CSS philosophy/entirety-of-interactions..

(In a framework, different matter quite possibly. Don't they use only-their-own-class-names anyway? Nevermind..)

Contrived example, but one that probably accounts for a LOT of the !importants are utility classes, say .bold. If you put on that class you want to be sure it's getting applied, regardless of the styles which may come before or after it.

It is, but CSS is also fundamentally broken so whatever

Yes and by far

Hear, hear. This is a common issue for me as well. I have several forms in my web apps where I would like to use space more effectively by placing short fields (e.g. Start Date / End Date) next to each other under longer fields.

At the moment, I have to do the dance of creating a new "row" class and two "col-lg-6" DIVs to manually arrange these while still keeping things responsive (i.e. so the shorter fields appear under each other on smaller devices).

Would be nice if we could switch "form-inline" in and out easily on a normal vertical form, for sure.

Bootstrap 3 launched with a handful of low-contrast default colours. Those got fixed a while ago, but that makes Bootstrap 3 adhere to WCAG etc. I don't know.

At any rate, the colours are parameterised, so supply your own.

When the world expects GridViews..

+1. As a small development company with limited resources (read: one developer and no designated front end designer), Bootstrap gives me the opportunity to create a really nice looking web app without having to get bogged down with CSS details.

Plus the fact that there is a really rich ecosystem around Bootstrap with third party templates that are VERY well written and documented. I am not too proud to say that I routinely go to wrapbootstrap.com to purchase a template for ~$20 and use it as the basis for my web apps. Users love it, and I save having to hire or contract a dedicated front end designer.

Safari supports Flexbox without caveat in versions 9 and 10 (versions 6-8 have varying degrees of support for the first version of the flexbox spec). I work on a decently large global web property (~5m sessions/mo) and Safari < 9 is about 0.3% of our total traffic, so reduced compatibility there sounds OK to me.

Thankfully the bulk of Safari users (unlike IE users) update to newer versions pretty quickly when they're available.