Hacker News new | past | comments | ask | show | jobs | submit login
Bootstrap 4 Alpha 6 Released (getbootstrap.com)
199 points by eddywashere on Jan 6, 2017 | hide | past | web | favorite | 61 comments

I'm really looking forward to Bootstrap 4, it's been one of those key productivity boosters in my arsenal of skills. So, many thanks to the Bootstrap team, you've made the world a better place (if anything, certainly my world).

Though, one thing I noticed going through the docs, the first thing I always look at is the "forms" section. For most apps, forms are probably the most important aspect (at least, for me they are).

I noticed that there are still two type of forms, normal ones and inline. However, when I work on larger apps that require more sophisticated input I often require a mix of both normal and inline forms. Maybe when you're working on SPA's it's easier to have multiple forms on a page and treat them as a single form but for old-school traditional page submit apps it's a little bit more difficult.

Anyhow, I wished they'd make the "form-inline" style more a form group thing rather than a form element thing. Currently the forms have a "form-group" which only contains a single control. To me (and correct me if I'm wrong), "form-group" should actually be named something like "control-group" so that "form-group" could be used to have both a normal and inline style form within the same form, maybe the ability to apply "form-inline" to a <fieldset> or something. If that makes sense..

Anyhow, I'm rambling. Love Bootstrap. Keep it up!

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.

I hear you two. I'll look into it for the beta. Opened an issue at https://github.com/twbs/bootstrap/issues/21581 — feel free to chime in with any specific examples or requests.

Your link is broken. I think you meant this: https://github.com/twbs/bootstrap/issues/21581

It's these sorts of tight feedback loops that makes HN great. Thanks for all of your hard work!

Complex forms, that's exactly why I switched from bootstrap to grid forms (http://kumailht.com/gridforms/) then to material design (http://forms.viewflow.io/demo/bank/)

CSS was the one thing I dreaded before doing web stuff. I'm a PC/Console dev for many years, and never was able to get stuff to look 'decent' when trying my hand at HTML/CSS/WebApps. The 'default' look of most web widgets is dreadful in a browser ... and I'm not one to kit pick at visual design!

Bootstrap abstracts that whole bit (CSS mostly) and allows me to concentrate un functionality knowing that : A) It's at least going to look as good as Bootstraps default template (which is quite good for me!) B) It's also going to be responsive ... brilliant!

Kudos to the Bootstrap team!

I'm not sure that mdo and the rest of the team get enough credit or thanks for all the work they put into Bootstrap, so here's another:

Thank you!

I'm loving the changes made in v4, especially switching to 100% SCSS. Bootstrap itself has had such a huge impact on getting projects off the ground.

> Automatic equal-width grid columns (e.g., two columns are automatically 50% wide)

This is not entirely accurate and I know it as the developer of Picnic CSS ( http://picnicss.com/ , which has been using flexbox for a while).

The columns will only be equal width with the same content or some smaller content, similarly to how table works. Case in point:


If the columns were equal-width, we'd see in the example that the one on the right starts in the middle of the screen.

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.

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

Remove 100% height, add "display:flex" to "containingBlock" and "content"

What is the best way to extend bootstrap without loosing an ability to update it in the future and also do not have a ton of duplicated code?

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.


I've upgraded bootstrap styles using "Less" which is being replaced by "Sass". It takes a little bit to get set up (the jet brains phpstorm app builds it), but once its done its pretty great.

You can also customize your download leaving out the parts of bootstrap you don't want. (I originally did that for and older version bootstrap, while keeping some of my page styles). The customizer seems to now give you a json file, so you can download updates with the same settings as your original download, I have not tried this though.


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.

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/

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/

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.

We built our (niche B2B) app on Bootstrap and keep getting compliments from customers about how good it looks. I don't mind that lots of graphic designers hate it; Bootstrap has provided tremendous value for us. I bought the templates just as a way to thank them :-)

+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.

When the world expects GridViews..

You snark, but that is what the world expects - a grid gives the user a simple, tidy, and consistent layout across the whole of the app. It might be "boring" and it might result in an "all apps look the same" world, but it's hard to challenge when users claim they enjoy, and are willing to pay for, apps built with it.

Also, the whole "every app looks the same" opinion is only true if you're a developer or a serial startup beta tester. Most actual users who'll pay for your product don't see that many SaaS apps, so they don't realise so many apps use Bootstap. Their opinion counts for a lot more than a typical HN reader who might see it several times a day (obviously this isn't true if your market is HN readers).

Plus, is it really a problem that every app looks the same? I consider that a feature. If i run a program on windows i expect it to have the same type of buttons as every other program. Why should i have to relearn what a button looks like just because someone feels that their app has to be unique.

To everyone contributing, congrats on shipping. Looking forward to beta.

Any idea on what is the state of the react-bootstrap project ?

I see that the project is active on github, but for a long time, its been marked as under "active development".

Why is there over 1000 !important's in bootstrap.css? I always thought 1 !important was a big no no.

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.

Could that be avoided if the design of the framework would of kept specificity in mind or does that not matter in that case?

It is, but CSS is also fundamentally broken so whatever

Impressive amount of changes between two alpha versions, it almost feels like a complete rewrite. Good job team!

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

one of the things I love about bootstrap is being able to google "bootstrap <some component>" and get something that works and looks nice.

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

> 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.


> 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.

«It wouldn't surprise me to see popular themes maintain Bootstrap 3 and Bootstrap 4 versions in parallel for a while.»

I recall that happened with the Bootstrap 2 and 3 transition with some components maintaining versions for both for a while.

That's been the case for the most part on WrapBootstrap. Items that are very active are pushing out new BS4 versions while keeping the 3.x-based versions in the package. Some items that haven't seen an update to newer versions of the 3.x branch are jumping straight to 4.

The jump between 3 to 4 isn't as great as the jump from 2 to 3. With the jump from 2 to 3, many items never made the transition. I don't think that will be the case this time around.

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

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

According to http://caniuse.com/#compare=ie+9,ie+10 there's a bunch of the HTML5 form stuff, reliable use of CSS calc(), web workers, WebVTT (subtitles for video), classList, etc.

Whole bunch of stuff: http://caniuse.com/#compare=ie+9,ie+11

CSS Transitions is probably the biggest one, but there's a lot, and a ton of javascript improvements too.

I'm pretty sure IE9 does not support CSS transitions or CSS animations in general. There is also a lack of support of most CSS gradients. Websockets and web workers aren't supported either. A lot of HTML5 form elements are also missing.

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

Is Bootstrap still the most popular CSS framework?

Yes and by far

I spent some time on a UI prototype project using Bootstrap 4, and I really liked it. I've been a big fan of ZURB Foundation for some time, and I still prefer it for content rich sites, but if I were starting a project that's principally an app UI, Bootstrap 4 is a no-brainer. Well done team!

Another Alpha? Am I correct in feeling like the fanfare for BS4 was a little premature?

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.

It's also worth noting that the lead maintainer, Mark Otto, is also simultaneously heading design at GitHub as well. Not entirely two small things to deal with in your life, ha. :)

I'm really digging BS4, but I wish they had an official off-canvas menu. The slide-down menu is nice, but I think off-canvas is better in many scenarios.

So everything is flexbox now? How about Safari compatibility then?

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.

I think you happen to not have encountered the bugs described here:


1. Minimum content sizing of flex items not honored (only fixed in Safari 10)

9. Some HTML elements can't be flex containers (not fixed)

11. Min and max size declarations are ignored when wrapping flex items (seems to be fixed only recently)

14. Flex containers with wrapping the container is not sized to contain its items (not fixed)

I am not updated so just asking: did they solve the problem related to not passing even low values needed for color accessibility tests?

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.

thanks to all for making this happen!

All about that flexbox. Web design went from enigmatic version of Buckaroo to Tetris with just the square and straight tetrominos.


This site crashed my mobile chrome 3 times :(

Did they get smaller?

I'm using BlazeCSS right now because it's very small.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact