I don't think this is particularly useful. The end result CSS is going to be bloated with large amounts of repeated styles. It also lacks reusable HTML components. The article references Bootstrap, but Bootstrap still produces a grid that is based on using reusable HTML classes - a better approach.
When you're looking at modifying the grid at different viewport dimensions, this grid system looks like it will require you to redeclare every selector that applied the `.column()` mixin.
I hate abhor mobile formatted sites that only send me an image reduced to 25% of the size. I can zoom in and see full detail on that full sized image when I want to, but only if you send it to me. At least allow me to tap a reduced image to grab the full asset on my phone.
[This applies particularly to photos or any images with small text in them.]
I don't disagree with the case you described, but as a counter-argument in favour of sending customised resources by default, modern sites frequently use things like image carousels or video. In such cases, you are unlikely to benefit from downloading the full-size resource every time, and the difference in file sizes for reduced-resolution resources can make a big difference to costs and caps for both host and visitor (since mobile plans typically have much lower data transfer caps and/or bandwidth compared to fixed line broadband).
Also, if whoever is rendering the original material can send you an intelligently customised low-res version, you can still have well-chosen, pixel-perfect presentation instead of relying on your phone to get the aliasing right when it scales an image down without context and showing the whole image at reduced resolution rather than perhaps clipping it more tightly but preseving some important detail.
I'm a fan of LESS. It's great. I'm a bigger fan of SASS (and I means .sass not .scss), but that's because of the syntax.
Whenever someone is evangelizing LESS they mention how it's better because it can be compiled on the browser via javascript. However they will also often mention that you wouldn't want to do this in production (I agree) which means setting up server side compilation (run time by the server) or design time compilation (thick client / command line).
So... what's the value in browser based javascript interpretation / compilation if you shouldn't be using it in production anyways?
I would even argue it's a negative in that it could encourage the bad practice of browser compilation.
Our product (CMS) supports on-the-fly LESS compilation in development because it was easy to add to our existing node.js setup. We're looking to add SASS but it's not such a trivial addition.
Nobody smart enough to use LESS is dumb enough to compile in the browser on a production site.
It's a development tool. I didn't dive into LESS because I didn't want to deal with the compilation step during development. Finding out that it can be compiled by JS solves that problem.
Much like traditional C compilers can perform static analysis at compile time, I wanted to craft a language that would facilitate some correctness analyses of your design.
What I ultimately wanted was a language that would verify I was doing something dumb with div widths and warn accordingly -- again, static verification for web design. It's still pretty basic and I haven't thought out much, but seeing LESS should spark some ideas for a better syntax :)
The real page layout for tomorrow will be the CSS Template Layout Module imo, which has now been rolled into the CSS3 CSS Grid Layout module that should ship with IE10. (Yup, IE10 will be the first browser with a proper CSS layout system.) http://dev.w3.org/csswg/css3-grid-align/
In the mean time, the slightly older Template Layout Module is available as a jQuery plugin that would make an excellent basis for a truly semantic, separate, and A/B test-able grid system: http://code.google.com/p/css-template-layout/
I'm surprised there's no mention of http://compass-style.org/ anywhere. Compass has much more of those features(variables, mixins, support for other frameworks like 960 and blueprint, css3 mixins, etc)
The comment about reinventing the CSS syntax is nullified by the not-so-new SCSS syntax by the way.
I've used semantic.gs during the beta test period and love the fact I tell my html it's grid based using css and not the other way around. Declaring grids in HTML always felt like doing table based layouts but even more obfuscated.
Grid systems require that Web designers add .grid_x CSS classes to HTML elements, mixing presentational information with otherwise semantic mark-up.
This is a pretty shallow problem analysis because total separation between presentation and semantic mark-up isn't possible nor even relevant. Also, why is it that lots of developers argue in favor of semantic markup but fail to explain exactly why and how it matters? What's the measurable difference on header/footer/article instead of nested divs? Seems that many devs just assume that semantics equals "better" code without taking the time to really understand if, why and how.
Semantic tags simply carry meaning in themselves whereas div-tags don't. There was a campaign to use standardized attributes to convey meaning (the campaigns name escapes me at the moment), but that's just a hack.
Just an example, if you want to scrape a website for the first 100 characters of its articles, you can just look for <article>-tags. If the website used <div>-tags you would have to figure out how to identify the articles (perhaps the author used the class .article or .main_article, etc.), and you'd have to do it for every website you want to scrape.
Screen readers would be another example of software that profits from semantic tags.
These are the common arguments I also believed, but I dug into them for a book project and found they are pretty shallow.
The HTML5 spec is such a mess when it comes to the new "semantic" elements that they are nigh on useless for anything. They're so broad (e.g. check out how broad the definition of "article" is) it's like calling a knife, a spoon, a plate, and table all a "fork" -- too broad to be useful. Div's are fine. They're all ignored equally by machines.
Screen readers also pay zero to no attention to these tags -- heading tags are, however, very much used, but HTML5 intends to supersede that in a completely botched way too. It's not pretty. Also, you would imagine strong and em were useful as opposed to b and i. It turns out most screen readers ignore all of them entirely.
Re the parent comment - as for the usefulness of true separation between presentation and content, I find it very promising for A/B testing layout, and therefore a worthy goal, but CSS really needs an actual layout system.
> These are the common arguments I also believed, but I dug
> into them for a book project and found they are pretty
> shallow.
I am someone who does HTML/CSS for living, not just dog for one project, and these arguments are solid.
Also CSS has a bunch of tool you can produce layouts with.
I think this is a good approach, but the preprocessors really need to be improved. Take a look at the examples of "Compiled CSS" included in the article, where declarations are repeated over and over. You'd get unnecessary bloated end results using this method, but a good minifier or preprocessor _should_ be able to solve it for you.
If you use the [LessFramework](http://lessframework.com/) (now v4) you'll find yourself doing these calculations and I'm pretty sure that if your using Less, Sass, or Stylus you've got width/col mixins too.
The big benefit for me is not having to revisit the markup to change a class from grid_4 to grid_5 and such. You just leave the markup as is, and all the work to change the layout stays in the style sheets, as it should be.
When you're looking at modifying the grid at different viewport dimensions, this grid system looks like it will require you to redeclare every selector that applied the `.column()` mixin.