The new Bootstrap 3 grid system
williamghelfi.com
williamghelfi.com
Seriously... there are several places in the docs (and I often do this myself) where a non-grid-related element uses a "span2" or whatever to float itself left and size itself equal to a 2-width column. Example: the input field for a search box. When input-medium/small/mini/large/xlarge doesn't cut it, or just because you want something to fit in a column.
So now we're gonna have "col-lg-2" etc plastered throughout our html? I don't see that as an improvement. The elements that get used the most should have simple names... that's what made bootstrap great as it was a common-sense standard for lots of common html/css techniques. "hide" for display:none, "muted" for color:#999, etc.
I've gotten great mileage with unsemantic[0], and purely by an accidental google, I stumbled across semantic[1]. The latter is particularly interesting to me, but our firm has been burned by CSS preprocessors in the past and making a case for LESS is going to require a sell.
[0]: http://unsemantic.com/ [1]: http://semantic.gs/
Tables were great in that they were a solid grid system, and a responsive one ( if you didn't try too hard to make them break your layout ).
But tables are for displaying tabular data, and they have some unwanted fat (th elements and the like) in regard to using them for a layout.
Now we are at grid systems. So much better!
But what we really want is native CSS support for complex layouts ( maybe in a couple of years... )
I'm sure I'm not the only one who sees tables as a logical approach to layout, and sees css grids as weird hacks.
Is it just because it's not semantically correct? Neither is a grid system.
Is it better for responsive designs?
But hey, "they're' not tables - tables are evil!", right?
RANT: I worked with some people ... sheesh - almost a decade ago that proclaimed "tables are depreciated" (I'm pretty sure they meant 'deprecated') and spent days having a team of people convert tablular data from Excel spreadsheets in to bloated DIV-hell for IE5 and NS4 browsers. That's been my worst experience with table-haters, but it stuck with me.
For what it's worth, I tried searching for "semantic grid system" and found http://semantic.gs. I don't really know if it's any good but I like the idea.
And since it isn't a table of data, the grid is more semantically correct. Not because the grid has any semantics itself, but because you're not misusing other semantics.
<table width="100%">
<tr>
<td width="50%">Column 1</td>
<td width="50%">Column 2</td>
</tr>
</table>
I'd also have to adjust the border spacing and cell padding in CSS or as an attribute on the table because the default style for tables in every browser I know of adds them by default.Compared to using a grid system (12 columns for the sake of example):
<div class="container">
<div class="span6">Column 1</div>
<div class="span6">Column 2</div>
</div>
One less nesting level, but no big deal. Now, let's say I want to have a responsive design whereby if there isn't enough room to display the columns side by side, the second column will reflow to be below the first. With my grid, all I have to do is add a media query to my CSS: my markup can be left untouched.With the table, well, you're out of luck. The table markup determines layout, and you can't reflow table columns to make them table rows using CSS. I suppose you could use some JavaScript to rewrite the table on the fly, but just using a grid in the first place seems a lot easier.
Another benefit of a grid is that if you do care about semantics, you don't have to use meaningless divs: you can use any block-level element. This would work just as well as the grid example above:
<body class="container">
<article class="span6">Column 1</article>
<aside class="span6">Column 2</aside>
</body>
With a table-based layout, if you want to take advantage of semantics, you'd have to nest those inside each of the tds.A third example: let's say you have the two column layout, but you want to dynamically add or remove the second column. If you're using a grid, no problem: the second column can be hidden or shown without affecting the first column's width.
If you're using a table, the first td will reflow because table columns will take up the entire width of the table. To get the same effect, you'd either have to adjust the width of the table or remove the contents of the second column's td instead.
The above also applies if you just want to change the width of the second column: if, say, you wanted to make the second column 25% width and leave the first at 50%, it's no problem with a grid: just change the second column's class to "span3". With a table, if you change the second column's width to 25%, the first column will expand to take the rest of the table's width. You'd either have to add a third td as a placeholder or resize the table itself.
There are a lot of use cases like these where having a grid winds up being a lot simpler than using a table. The benefit of a table-based layout was that creating a cross-platform grid was hard, and there wasn't a whole lot of prior art, so a lot of times you might have to start from scratch. But if you already have a grid-based system available, there's not much point to forgo that and use a table.
Tables are especially helpful for creating a horizontal list of elements that are evenly spaced, but of uneven/unknown width. You can't do that with a grid. Since grids are floated, it's easy to adjust the number of elements in a row (by either changing the width or the row or the width of the items). You can't do that with a table, since each row has to be delineated in the markup.
I don't use table elements for layout of course, I use display:table. Using a table element for non-tabular data would be unsemantic, unlike using a div which carries no semantics.
(Look at HN's code source)
Also it's worth noting that most codes using Foundation or Bootstrap are considered bad code for the reason I just told you : You're not supposed to have elements of design in your html page.
The correct way of using Foundation/Bootstrap would be to use mixins directly in the .scss files of your site (if you're using foundation, bootstrap should use LESS files and I have no idea how it works).
Isn't that a bit of big change? In the past, I don't think we could get two equal size cols filling up a 9.
Pros: you can nest the hell out of your layout without putting your brain on fire.
Cons: didn't find one, so far.
* You have mandatory #container div
* you can nest rows by default (previously you had to use fluid-row)
* they got rid of "span" and use the more natural "col".
* offsets
* push & pulls
Foundation still have more : "ending cols" for number of cols not reaching 12 and centered "cols".
I'm liking it. I would have gone for Foundation 4 but I'm wondering if I should try this new Bootstrap for my next project.
Based on the responsive design of the grid, if you resize the window smaller, it puts the "context" directly underneath and you can offset based on color. That's at least based on a 2 column system. I haven't tested it on multiple sets yet but it works for what I need it for.
I also agree that span3 and offset2 are/were better names.
Still, Bootstrap is awesome, even in spite of the ASI BS it's authors maintain.
If you need to display 24 items in a row, then you shouldn't have to mess with the foundations. Use CSS or tables.