This is awesome work, well done to the Bootstrap team.
Bootstrap 3
71–80 of 86 posts
Re: Bootstrap 3
#72Is 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.
Re: Bootstrap 3
#73The 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.
Re: Bootstrap 3
#74Is 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.
The Bootstrap 3 pull request has a lot of details about what is changing: https://github.com/twbs/bootstrap/pull/6342
Re: Bootstrap 3
#75It'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.
Re: Bootstrap 3
#76Man, 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?
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.
Re: Bootstrap 3
#77I don't think I get the new grid system. .col-12 .col-lg-8 What's going on here? If I were to guess, I'm assuming it's going to be 12 columns if its a mobile, 8 if a tablet or a desktop. In what situation would that be useful? It looks like you'd end up with some pretty complicated mark-up quickly like that.
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 do stuff like this in SASS %flash { @extend .contai…
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 :)
[1]http://nicolasgallagher.com/about-html-semantics-front-end-a...
Re: Bootstrap 3
#78Personally, 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
I love that button, think it looks awesome.
Re: Bootstrap 3
#79Is 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.
The Bootstrap 3 pull request has a lot of details about what is changing: https://github.com/twbs/bootstrap/pull/6342
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
Re: Bootstrap 3
#80Earlier quoted context omitted.
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 do stuff like this in SASS %flash { @extend .contai…
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.