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