4 ms·

I don't think I get the new grid system. <div class="col-12 col-sm-8 col-lg-8">.col-12 .col-lg-8</div> What's going on here? If I were to guess, I'm assum

I don't think I get the new grid system. <div class="col-12 col-sm-8 col-lg-8">.col-12 .col-lg-8</div> 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.

lvh 13y ago
Yes, that is exactly what that means. A little further down, there's examples: http://getbootstrap.com/css/#grid http://getbootstrap.com/css/#grid 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.
jvzr 13y ago
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 Handy.
- olso4052 13y ago
  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).
jamieomatthews 13y ago
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
amouat 13y ago
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.
- WickyNilliams 13y ago
  Or resize the window ;)
timdorr 13y ago
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 .container; @extend .alert; margin: 15px auto; border-radius: 0; .close { top: 0; } } .flash-success { @extend %flash; @extend .alert-success; .close { color: $successText; opacity: 1; } } .flash-error { @extend %flash; @extend .alert-error; .close { color: $errorText; opacity: 1; } }
- kbhomes 13y ago
  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?
  - timdorr 13y ago
    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.
- WickyNilliams 13y ago
  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-architecture/ http://nicolasgallagher.com/about-html-semantics-front-end-a...

lvh 13y ago

Yes, that is exactly what that means. A little further down, there's examples: http://getbootstrap.com/css/#grid http://getbootstrap.com/css/#grid 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.

jvzr 13y ago

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

olso4052 13y ago
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).

jamieomatthews 13y ago

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

amouat 13y ago

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.

WickyNilliams 13y ago
Or resize the window ;)

timdorr 13y ago

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 .container; @extend .alert; margin: 15px auto; border-radius: 0; .close { top: 0; } } .flash-success { @extend %flash; @extend .alert-success; .close { color: $successText; opacity: 1; } } .flash-error { @extend %flash; @extend .alert-error; .close { color: $errorText; opacity: 1; } }

kbhomes 13y ago
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?
- timdorr 13y ago
  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.
WickyNilliams 13y ago
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-architecture/ http://nicolasgallagher.com/about-html-semantics-front-end-a...