The Semantic Grid System: Page Layout For Tomorrow
coding.smashingmagazine.com
coding.smashingmagazine.com
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.
Which is why we use gzip over the line.
> It also lacks reusable HTML components.
I don't get what you mean. They may not be baked in, but it makes it easy to implement them, doesn't it?
If you intend to have your site viewed on a phone, you probably don't want to send full-sized assets down the pipe only to have them sized at 25%.
[This applies particularly to photos or any images with small text in them.]
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.
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.
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 :)
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/
The comment about reinventing the CSS syntax is nullified by the not-so-new SCSS syntax by the way.
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.
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.
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.
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.