I didn't like the shading/3d effect of everything in v2 and the excessive roundness. I think this looks better. But yes, some light shading on the buttons would be nice.
The actual reason that all the styles are "flat" right now? One of the main project authors removed them temporarily while he focuses on fixing other issues in the current pull request for Bootstrap 3.
mdo commented: Gradients and other embellishments have
temporarily been removed while I focus on other things.
It has nothing to do with skeuomorphism or anything
like that.
It would be pretty neat if all the "gloss" was an additional, optional "module" that you could add in at your discretion.
People who want something they can work with straight away can then add that in and get their gradients, drop shadows etc. People who want something more basic that they can augment with their own styles can then choose to not include this "module", and save themselves having to jump through hoops to undo the default styles (which is a pain, as anyone who has had to do this knows)
Man, I feel weird. I used BS2 temporarily, but then stripped it out for a straight reset and grid system. Old habits die hard, I guess, and what I Want from a UI doesn't always match Bootstraps ideas... I'll give this another shot for my startup prototype, but I have a feeling the same will happen.
Is anyone else like that, or am I now old-school at the ripe age of 22?
If you're just using it for the minimal things, then you might look at the highly underrated Skeleton (http://getskeleton.com). It's got a reset, grid, forms and typography, but all are fairly minimalist, easy to override, etc.
I'd recommend Foundation as an alternative too, but that one's already been suggested. It's also very good, but slightly heavier-weight than Skeleton.
Fine question. It still works perfectly either way. As it stands, its minimalism doesn't need a whole lot of maintenance, but it may not be actively maintained any more.
I have no use for it myself. If I need a simple Bootstrap design, I can just copy some of the elements in plain old CSS and have a much simpler setup. If I need something complicated, Bootstrap is limiting - you end up rewriting it all anyhow.
And the idea of keeping up with Bootstrap versions is just plain crazy to me.
I checked it out for that reason. Then I found a number of social images and began wondering why a lightweight CSS framework needed images for facebook, twitter, etc...
If you want something lightweight, I wouldn't go for Foundation either. Even after stripping out the unnecessary stuff, I found it overly obnoxious to style.
I ended up with the Skeleton framework after struggling with both Bootstrap and Foundation for a few days. It was a much better decision. I've also been eyeing Bourbon Neat lately as well.
Which reset and grid system do you use? I have the same experience, and I end up un-checking every option except one or two on bootstrap's customization page for most of my projects.
I used it at my startup, but there's absolutely no reason for me to upgrade to BS3. I think bootstrap is great for giving people a quick framework to build off of, when writing up a grid system doesn't make sense. For our next major release, I think we're going to migrate away from BS entirely. I'd rather control it all in house than play catchup with their releases. For me, it's not even the UI but the ability to control exactly what we're doing.
I agree that it can bloat, and often customizing components takes as long as simply starting from scratch. However, I really like LESS, and bootstrap is full of some great less utilities. Customizing bootstraps less is a perfect example of why I love it, and how it saves me time
At the ripe age of 22, you'll like undergo a number of pivots in your career between embracing frameworks and tossing them out. There is no right answer; sometimes they help, and sometimes they hurt. We can't always predict what the right level of abstraction will be for future problems; today's popular frameworks can either become tomorrow's cruft-laden disasters or its stone-age embarrassments. Likewise, the definition of minimalist changes with the times (see jQuery), and minimalism itself goes into and out of fashion.
I happen to like Bootstrap, because I've seen a lot of projects descend into mess and cruft due to poor maintenance; it takes effort to maintain clean conventions, and if a framework dictates those conventions to me, that's one less set of decisions that I and my team have to make. But Bootstrap feels undeniably heavy, and perhaps I'll regret its use later. But for now it makes me faster, and I choose it knowing I'm making a tradeoff.
I guess it goes to show front end design is one of the most controversial topics on HN. On GitHub, Bootstrap has maintained an almost permanent position in the daily top ranked repos.
In order to reduce complexity like this, you should avoid using Bootstrap classes in your HTML directly.
Instead, use semantic class names for your app and use the new &:extend() directive in LESS 1.4 or @extend in SASS (if you're using bootstrap-sass). You'll end up with much more readable HTML and CSS, and will insulate yourself from future changes in Bootstrap.
I'll politely (and completely) disagree with this. I much prefer the HTML convey semantics (to the dev, not to the user) than having magic happening behind the scenes with CSS.
By having the classes in the HTML, you know at a glance what is going to happen. Whereas using extend there's an extra layer of indirection, you end up having to look at the HTML, see there's a class called something like "sidebar". Then you have to look at the SASS, find the sidebar class to see there's an extend directive, then and work out what's going on in there. That's an extra step i'd rather avoid.
People usually follow this approach to get "clean" or "semantic" markup, but there's some falsehoods in that thinking. The "markup looks ugly", or is "non-semantic" are misguided: no user agents infer semantics from classes, and the ugliness you describe is purely aesthetic, the real beauty is in the semantics the developer can infer from having clear and obvious classes in the HTML. Another classic argument is it makes the markup bloated. This may be true on the surface, but when you factor in GZIP, it is completely negated as more repetition == better compression.
A great read on the topic is Nicholas Gallagher's article "About HTML semantics and front-end architecture"[1]. Reading that article for the first time was one of those moments of clarity, where your previous perceptions are completely shattered. Hopefully you guys will feel the same :)
I'm not sure I follow. You're basically arguing for including style attributes throughout your HTML. CSS classes are always a layer of indirection, regardless of whether they are semantic or functional. As such, you shouldn't be forcing style and layout directives into the structure of the document.
The main benefit of what I'm describing isn't actually semantics. It's allowing CSS to do what it does best: cascade.
Say I've got an application where I've got several pages with unique layouts and the designer has come up with a new form style that has all the labels inline instead of on top of each input and has a new dynamic tour system that needs some area on the right of each form.
If you were using Bootstrap classes directly, you'd have to go to all of your forms and add .form-inline and change the column size classes. You wouldn't want to redefine what those classes are because that may have effects on other areas of the application. This may also break some of your Javascript, as it was dependent on those class names.
If you were using semantically-named classes, you'd simply change the width and add @extend .form-inline to your main form placeholder (which is in turn @extend'ed by any specific form class). Your HTML would stay the same, meaning any Javascript dependent on those classes wouldn't break.
No I'm not arguing for style attributes, that's a maintenance nightmare waiting to happen (with very little waiting needed!). They are a layer of indirection indeed, but which of these do you think conveys more information/semantics to the developer (these aren't bootstrap specific classes, just illustrative):
The second one is way more verbose, but at a glance you know exactly what is happening (assuming my class names are obvious enough). The classes convey information that an amalgamated class you get from @extend simply cannot.
First let me say that a lot of what I'm talking about is optimal for building large-scale web sites with lots of page variants. Your mileage may vary for smaller sites, the principles can still be applied, but you might not need adhere to them as strictly.
There's been a movement in recent years, Object Oriented CSS (OOCSS). This ethos urges the developer to write CSS as they would other code, using the hard lessons that have been learnt in other language. We should be thinking in abstractions, utilising the single responsibility principle, favouring composition over inheritance, loose coupling, and self-documenting code. I'll go through these one at a time, because the benefits of each flow throughout one another.
Abstractions - using a single class like "sidebar" to contain all your styling for the sidebar is not thinking in abstractions. The sidebar may need specific styling (say a different BG colour) but it also has a lot in common with other parts of the page. For instance, it's nothing more than a grid column, so why bundle all styles into one class instead of using the grid abstraction to "decorate" the sidebar with this? This is equivalent to breaking a system into reusable classes. See Nicole Sullivan's article on the Media Object [1] and Harry Roberts on the open/closed principle in CSS [2]
Single-responsibility principle - Do one thing and do it well. A class should have a single-responsibility so that it can be composed into larger "blocks" of styling. A class that does everything is monolithic and difficult to work with as soon as a design needs to change. Overly broad selectors in CSS can also break the single responsibility principle - suddenly your styling is relying on the coincidental placement of elements inside one another. Harry Roberts cover this [3]
Loose-coupling: Can parts of your code base change without affecting others? By @extending grid classes you're tightly coupling yourself to the implementation details of the grid system. Now you can of course override styles in your sidebar class, but overriding styles from previous classes is a code smell. If you're "undoing" what another class has done, you've applied a style too early. You suggest changing the CSS and leaving the HTML the same when a change is required. I always prefer changing the HTML because it has a far more limited scope for far reaching changes. If you change one segment of HTML you know it's not going to affect other parts of the site beyond itself (and possibly it's children), but if you change some tightly-coupled CSS its effects could ripple throughout the whole site. The previously mentioned article on the open/closed principle [2] touches on tight coupling in classes.
Favour composition over inheritance - In OO languages we've learnt that we should favour composition of granular, single-purpose classes over deep inheritance hierarchies. Why? Inheritance is a fundamental tenet of OO, just as the cascade is in CSS, but we still frequently eschew it. The reason for this is because we can compose infinitely more flexible pieces of functionality from granular building blocks than we can from inheriting traits from "super classes". And now that we're thinking in abstractions (as outlined above) using the single-responsibility principle, we can put multiple classes on an HTML element to compose them as you wish into large blocks. Harry Roberts (CSS Wizardry) covers this nicely [4] and also when talking about grid systems [5]
Self-documenting code - From the HTML I ideally want to know exactly where each bit of style is coming from. With one monolithic class all I know is that it's a sidebar, which doesn't really tell me much that I can't work out visually. Multiple classes tell me exactly how it will behave at a glance. This means your classes should be as descriptive as possible. Classes should not describe the content of the markup they are applied to (sidebar is definitely content-centric) but rather their intent. And small, abstract, single-responsibility classes convey more information than a monolith can, and they ease understanding of the system. Someone familiar with bootstrap could quickly get to grips a site using the plain bootstrap classes, whereas @extending all over the place necessitates digging into the CSS to gain an understanding of the system. This is covered in great depth in the original article I linked to.
Finally, you should never use as a JS hook a class whose purpose is visual styling, then the whole mess you outlined is avoidable. Either use data-* attributes (as most bootstrap widgets do) or a class which conveys intent and a single responsibility e.g. "js-date-picker".
Now my incoherent ramblings are probably lacking in a number of points, I had to leave out a lot so this didn't balloon even further (e.g. I didn't talk about specificity or BEM methodology). I urge you to read all the articles I've linked to, as hopefully you've already read the original one. You might also want to read this article which kinda covers everything in one post: http://engineering.appfolio.com/2012/11/16/css-architecture/ Most of the principles I've outlined here are actually used in bootstrap.
PS. if you want to continue the conversation, hit me up on twitter (@WickyNilliams) or something, I always forget to check back on HN comments for replies.
I can see the benefits of using @extend to clean up the HTML, but wouldn't this pull the .container, .row, .span*, etc. CSS rules into each and every rule that extend from those? Wouldn't that have a hit on performance and file size?
I'm not sure how LESS handles it, but it adds your class to the selectors for that ruleset. If you do .myclass { @extend .container; }, you end up with .container, .myclass { // container styles }. It only adds minimal overhead.
I agree with jvzr, I think it goes hand in hand with a true "mobile first" design.
Most likely, you want to use the full width for your most important stuff going on in your site, and then as the screen gets bigger, maybe you include some extra stuff
They suggest that it doesn't end up awfully complicated. I could see how you could use it to make something complicated, but it seems to me that if you use it sparingly at the top-most level of markup, it shouldn't be too bad.
Exactly that. It's useful if you want that particular content to span the whole width on mobile, but only 60% of the width on desktop (and make room for a sidebar, for instance).
|----col1------| on mobile
|----col2------|
|--col1--||col2| on desktop
Ya, I actually had that problem with BS2 when viewing it mobile. I ended up redesigning the site anyway, but this may be a big plus for Bootstrap. As others have said, a lot of times it's simpler to just build everything yourself and grab some CSS or whatever from Bootstrap, but when it comes to mobile viewing, Bootstrap is going to save a ton of time (at least for me).
Took me a minute to figure it all out. If you're using chrome, you can change your user agent to mimic various viewports and the examples become a lot clearer - hit ctrl-shift-i then push the cog in the bottom right and select overrides.
Meh, at some point they should start to realise that you can't change everything every release and expect everyone to keep up. It feels like it's becoming more of a chore than the real initial win it was able to deliver on first release.
You don't need to stay up to date with this kind of frameworks. It isn't like every update has security fixes.
The company I work for uses several versions of Bootstrap 2 and we have no issue dealing with it. Newer projects will use BS3, but we don't need nor feel the need to update every project.
There is an image gallery plugin that I use that secretly downloads its own latest version of bootstrap, which can conflict with the one you have loaded, breaking everything :(
Is there actually a changelog somewhere or will that be written up with the full official release? I can't see anything detailing what's changed
Also, it's a damn shame they're still using pixels for everything (from a cursory glance). Fluid grids (i.e. %-based) and ems (for font-size and media queries) are much better. They are infinitely more flexible and much more easily adaptable to any layout.
Thanks, that's really comprehensive (perhaps too low-level for the end-consumer to care about).
Reading through that PR it seems they are actually using percentage-based grids now, but the grid containers are fixed width (and probably defined in px). That's definitely better than completely fixed width grids, though I'd much prefer having max-width on my containers instead of an absolute value, and relative values used throughout
While simple, I believe Panel and Listgroup are new components; nice to have those nicely implemented and styled in the framework. Will be handy for me. In many ways I think Bootstrap helps the most with the little things like this. I am very appreciative of this terrific framework being made available for us to use.
I think it's flat because it's easier to add CSS and build up widgets as opposed to having a stylized widget, then trying to override the CSS to re-customize each widget. Foundation, the original front-end framework which Bootstrap emulates, works the same way.
Foundation doesn't isn't completely flat though. Buttons, for example, hint at being intractable by giving a tiny bit of depth using the line at the top of the object.
Exactly. In BS 2 it was such a pain to remove the gradients from buttons, the box-shadows from inputs and all the other extra UI effects that you didn't want to use.
It's interesting to see that the references to twitter are basically gone now, presumably this means we'll see more things from `Bootstrap` in future, perhaps a company since it already has a lot of mind-share.
I'm on Firefox 22, and the same thing happens here. Mouse over download button, click it, download pop-up appears, click cancel on the download, button disappears. It re-appears upon giving focus back to the page.
Personally, I think the "Download Bootstrap" button is too ambiguous. Why is the default color the same as the background color, it is just confusing and ugly
It's really unfortunate to see all the haterade being spilled over the comments. The efforts to take Bootstrap to version 3 were pretty significant, at the minimum they deserve a pat on the back for that alone.
Here are some important concepts I think a good portion of people are missing.
Upgrading - Don't upgrade for the sake of upgrading. If you have a fully functional site right now which uses or extends a previous version of Bootstrap your incentive to upgrade at this point is probably minimal.
At some point you had conceded that version X of Bootstrap was the right front end framework for your project. If that has changed you need now concede you have some work ahead of you.
Identify and evaluate the features introduced in Bootstrap 3 that are lacking from your current project. Scope out the markup and stylesheet refactoring required for any of the "must haves" and setup a schedule to integrate. Realize that this doesn't necessarily mean you are bringing Bootstrap 3 into your project, more so you may just be adapting your existing front end assets to model Bootstrap 3 features/patterns.
This is really no different than an existing site that doesn't use Bootstrap now wanting to bring the framework into their project. If you've identified that you need Bootstrap 3 for your project, you would expect there is work to be put in.
Usage - I see a number of comments critiquing design and usability. Is Bootstrap really intended to solve those problems for you?
In my opinion this is a framework intended to bootstrap your front end assets and development efforts. It prescribes conventions for common component markup and their respective selector naming conventions.
Think about that for a moment how valuable that is to your project (especially those with a large number of contributing developers). How many projects previous to one using Bootstrap did you have such well documented markup, style and naming conventions?
Bootstrap standardizes and documents front end patterns for rapid adoption and implementation into your project. That's pretty damn special. If what they promote doesn't align with your needs or development practices, well, don't use it.
Style - Bootstrap wasn't designed for your site, your users or even to keep up with the latest design trends. The styling, while in the view of many is decent, seems to have been intentionally minimalistic and not overly opinionated.
It provides basic structure and basic styling. It's your starting point. You can get to your destination now a bit quicker without needing to reset their style rules.
Having such minimalistic styles probably serves to be good motivation to get creative. If you want custom and don't have the design ability to get there, rest assured there will be a companion stylesheets to extend bootstrap coming soon to at a market place near you.
Inspire - If the Bootstrap shoe fits, wear it. If Foundation, Pure or any other front end framework fits the need, use it.
To me the great benefit of all these popular frameworks is they bring to light many well thought out development approaches to the front end. Not everyone will agree with them. They aren't always bullet proof. Though at the end of they day though they invoke developers to take a look at their individual assets and recognize areas of improvement.
Find the framework or approach that best aligns with your needs and personal preference and customize the hell out of it.
