The thing I hate most about bootstrap 3 is changing the class names of the grid. "span3" and "offset1" were much better than "col-lg-3" and "col-offset-1".
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.
First thing I thought was that this was the reason why I abandoned YUI grids. That and the subdividing boxes thing.
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.
+1.
span12 and span6 makes much more sense as a class name, than a col-lg-3 or a col-sm-6.
If they are stealing from the foundation, and if differentiating large and small grid was the cause for changing identifiers, then I'm against it.
Other than that, I'm liking it already.
My thoughts exactly. Foundation has always had a superior responsive grid layout, if for no other reason than it is embed-able within itself. To say nothing of their push and pull column classes.
I always wondered: why use a grid system when it's essentially a table, which is already implemented in browsers and fits the purpose of grids perfectly?
Is it just because it's not semantically correct? Neither is a grid system.
Well grids aren't essentially tables. I'm surprised by the comparisons here, it seems like many people have worked with either tables or grids, but not both. I frequently use both grids and table layouts along-side each other.
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.
Grids would generally be worse - no semantic info like 'thead' or 'axis' in grids/divs. That said, I'm a bootstrap span fan and don't like this extended naming from the article - reminds me of YUI grids from several years ago.
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.
I didn't last too long there, and thankfully I wasn't on that team directly. Yeah, pointing out things like 'facts' with 'evidence' doesn't make you a 'team player' very often. Yes, there's the issue that I'm the new guy, but really... there are some things that are objectively true. HTML tables have never been 'deprecated', have their place, and are perfectly fine. DIV-based layouts are fine too, but knowing when to each is key, and displaying hundreds of pages of spreadsheet-style data with inlined styles for each div is... just insane. They had to do inlined styles on each div because some version of IE didn't handle the formatting they wanted properly - some alignment issue - when I pointed out that table cells already supported that formatting... I think that's when I was no longer required to be involved in that project.
Because you want to split your page content and main structure from your design. If you really don't care about that, mainly because you will never change the design in the future and it's a small project, then do use table.
(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).
The grid is supposed to guide the visual layout and structure of the page. There's no real reason that it has to be encoded into the markup as we see it in the article except that it's much simpler to implement it that way.
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.
A grid isn't essentially a table, and only the twisted history of web design could ever make someone say that. Imagine a discussion about book layout or poster design that made reference to grids and someone saying "oh so it's basically a table of data!".
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.
Let's say I want a two column layout that takes up the full width of my page with each column taking up half the space. Using tables and no grid, I'd have to do something like:
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):
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:
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.
I'll tell you what I really like about this. If you have a setup where information in the right column is providing clarifying information about what is on the left (NOT vice versa)...
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.
My one desire for Bootstrap is to have more than 12 columns. That's too coarse-grained IMHO. Why not 24? I know you can do this yourself but in my experience it results in weird bugs.
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.
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.