Arguments against responsive/adaptive web design

[sdt76]

Yes. Which means you mostly have to already have the basic idea of which content goes where and much navigational structure already, otherwise you have nothing to start with (and this is sketches on paper and whatnot, though I know there are some very expensive wireframing programs out there as well).

So you have an idea of the ideal source order, and you start throwing examples of it into HTML (even if it's just divs, but ideally you have enough real content to use appropriate tags), and then with CSS you just do real quick outlines: use borders or background colours to show sizes and positions, and really nothing more.

The benefits of this are: this basic setup will already work cross-browser, because you built it that way. It also gives you examples you can show on screens of various sizes, so assuming the content is not supposed to be radically different for mobile, you can show right there and then what these boxes will do on "mobile" size screens. Or TVs. Or whatever.

Throw it up on a server and the client can see it as well. If you choose garish colours then nobody will wonder if that's the real colourscheme (we've all heard web companies say sometimes their clients think the lorem ipsum is the real text and "we don't speak Latin here"!). Colourschemes and fonts and spacing and whatnot come later.

I would think that this would be when you bring in the designer. They have a skeleton they can see and play with on a screen, and then they can do whatever mockups they want to show the clients. If they either know CSS themselves or work with the front-ender, that's ideal. The Designer can come up with ideas and the front-ender can implement them, and at some point the basic layout is stable enough that the designer can go make a "mockup" for the client to look at. There, the client is approving fonts, colours, spacing, shadows, whatever. All that extra stuff.
And after the the client okays that and the front-ender has a go at implementing it, time for more user testing! Those colours sure are perdy, but are they readable?

One of the biggest mistakes charity web sites make is not making it clear how to donate! for example. Some of those sites look great! They were done by professional designers. But the content didn't come first (and that may not have been the designers' fault, but whoever thought up the content-flow of the site, or the lack of usability testing).

To me, the idea that you draw for clients a picture of how their website might look in Safari 5 on a 27" Cinemac monitor, and then several more, and then have the client pick one... sounds like an idea fit for vanity sites like luxury products (who even today are mostly Flash). Those aren 't really web sites, they're large web-based advertisements, works of art on their own. They aren't supposed to do much except look pretty. They aren't supposed to work on a wide scale of screen sizes.

But I also realise that's how much of the business works. Client expect to see several, full-scale and almost-complete-looking mockups, because yes, they don't know what they want til they see it. That's pretty much endemic in humans. Also, when several companies are bidding for a project, the winner is often based on who makes the prettiest mockup. But if you're starting with the design they pick and then trying to stuff the necessary content inside, I personally believe that makes usability problems where none should have started. It means that drawing of a website on a 27" monitor now needs a whole new idea for the "mobile" version.

View this page* in a small (less than 400px wide) browser. That's actually what I started with (minus the colours and stuff). I wrote that design first, in CSS (layout-wise). Later I took that HTML and made a "CSS mockup" of what it would be the main page on desktop, so the boss could see and okay it (or not). He wanted changes with the buttons and whatnot, it was shuffled around a bit, but he never saw the mobile base (maybe by now he has). Since the mobile base was *mostly* done, it was pretty easy to hang stuff on it for the "desktop" version, and you see in the mobile style just background colours... I made the actual images like the logo and the textured stuff later.

*the markup is only partially mine. Every time I show that site, I also cringe and want to point to my actual code and say "see??" but, meh. I need to learn to deal with dirty paws on my code and grow up.

If I am not mistaken, I believe this is why the grid systems were invented, like YUI, blueprint and 960.gs, to quickly mockup sites without the intention of actually using them in the final product since they are not semantic.

[capescafe]

View this page* in a small (less than 400px wide) browser. That's actually what I started with (minus the colours and stuff). I wrote that design first, in CSS (layout-wise). Later I took that HTML and made a "CSS mockup" of what it would be the main page on desktop, so the boss could see and okay it (or not). He wanted changes with the buttons and whatnot, it was shuffled around a bit, but he never saw the mobile base (maybe by now he has). Since the mobile base was *mostly* done, it was pretty easy to hang stuff on it for the "desktop" version, and you see in the mobile style just background colours... I made the actual images like the logo and the textured stuff later.

Nice. Is there a reason why you used HTML 4 instead of HTML5? I was thinking since I have to do mostly everything from the ground up I may as well start with HTML5. But I was just curious why you're using HTML 4. I see it's strict so there's probably no need to change it right? But if redesigning a site and starting from the ground up do you suggest using HTML5?

[sdt76]

BTW, I haven't gotten a chance to completely read everything, but this seems to say it provides to solution to the loading of big images on adaptive sites.

Creating responsive images using the noscript tag | Head

[adh32]

Is there a reason why you used HTML 4 instead of HTML5?

I know that you were asking that to Stomme poes, but it could be because HTML 4.01 just plain works and is actually a standard.

[capescafe]

I know that you were asking that to Stomme poes, but it could be because HTML 4.01 just plain works and is actually a standard.

True and I understand that. So what are the reasons then for jumping into HTML5? Is it simply because of some of the new features that people are starting to use it? What should we be using? Does it matter?

[adh32]

Impatience? Irrational desire to do whatever X does because that must be the new right way? Not stopping to think that HTML4 works perfectly adequately, is virtually device-agnostic, and is actually set in stone as a standard that isn't at risk of changing while you're looking elsewhere. Certain new features make some sense in some cases, as long as one can be sure that they degrade gracefully.

[capescafe]

So can CSS3 be used with HTML 4.01 Strict?

[adh32]

Yes, of course! The two are completely independent standards. The same caveats about graceful degradation apply, naturally.

I use a lot of CSS3 in my site, but not served to IE8- and not used in a way that could cause issues if it fails.

[deathshadow60]

So you do all your layout in CSS? Do you use Photoshop (or other paint programs) still after that? For me I'm having a hard time realizing how you design the site though without a layout in mind. Could you explain your process of how you do it?

As I said before, the paint program is still involved, but I call upon it LAST to make things like border images, gradients, backgrounds and other presentational affectations that may or may not apply to all media targets. Background images and gradients for example have no business wasting people's ink when sent to media="print", so you change those all to background:none; -- as a rule for print I usually just display:none menus and "read more" links, set it to black text on white background, and use just text for all the content elements...

The process is thus: First thing I ask is "what's going to be on every page of the site?" -- simple question, usually it's the topmost heading (site logo/name under which all other headings are subsections), the main menu, and the page footer typically with a disclaimer in it. I plug these into HTML using semantic markup, typically inside a div#pageWrapper to set any widths, heights or other desired layout on. I then take a sample page -- like the home page, and repeat the question; what's going on it? First thing would be the "main content" area like news posts and intro text to tell people where the devil they are. (SO many websites fail miserably at the latter -- assuming you have any clue what you're looking at). I usually put them in that order inside div's... like say div#subSection... and since most of the time content goes into a two or three column layout with content being the dynamic, I'll toss in a double wrapping div#contentWrapper, div#content just because on 99% of websites that's how they're laid out. Heading tags as appropriate making sure I have a valid and proper heading cascade (for people who navigate via headings like the blind), toss in a few horizontal rules for CSS off users and to semantically say where sections started by major headings end.

I also rarely would ever use images larger than 256px wide or 32K pixels total as they are too large to be deployed on a website IMHO.

I also maintain on my sites a set of 'targets' for size of everything combined -- that's HTML+CSS+SCRIPTS+IMAGES -- 70k in 16 files is the ideal, 140k in 32 files is the maximum I'll allow on any page with the possible exception of a gallery page.

In any case, once I have nice semantic markup of the content (or a reasonable facsimile) I start making the screen layout using CSS. By making the elements be placed and sized by CSS, the content and layout can dictate what images to use dodging the bullet of ever having to worry about shoe-horning content into images they don't fit. I set the outermost wrapper, I set the column widths, I toss in some attractive paddings and margins (usually working in multiples of 2, 4 or 8 since the math is easier AND it's easier for the computer to work with on rendering)... set the background and foreground colors to something attractive and accessible... and poof, screen layout. Goes very quickly and it's easy to move things around accurately -- MANY times easier than dicking around with layers in photoshop. Client asks "can this text be bigger" you go "sure" change one line of CSS and the whole layout adapts. "Make this brighter" -- edit one line... "space these out more" -- add padding to one element target, poof they all reposition.

Only at the end do I even THINK about what I want to hang on the layout for images -- sometimes I'll screen-cap the page so I have a color and size reference -- then do a paintover keeping in mind that some things need to grow in width, EVERY major content text element should be able to adjust it's height as the maintainer adds/removes/edits content OR when the user is using large fonts/120dpi or larger settings (something around 80% of sites designed in photoshop fall flat on their face in regards to).

Used to be I used a script I call quickswitchy (which was way simpler than mcSwitchy) to swap a class based on width -- I still do this feeding people without scripting a crappy little stripe. Now with media queries I've expanded that for phone support too.

To give you an example, this is a template for an upcoming re-launch of one of the websites I maintain... which is in a holding pattern right now waiting on the CMS it's going to run on to be completed (right now a three man project).

Index of /cbt4Template

That was built on exactly the process I describe in about two hours. View the page with images disabled. Try it with CSS disabled and images on. Try it CSS off images off... Change the screen width and watch the entire layout shift to fit... Admittedly it loses some of the presentation IE8 and lower -- but big deal, the layout is still FUNCTIONAL in those browsers. Unfortunately it DOES exceed my size target, being 190k in 24 files -- but that's still better than the current website chock full of nasty web rot, half assed coding techniques, and other vomit that I slapped together 7 or 8 years ago before I understood any of this stuff -- which tops out at 160k in 64 files under normal circumstances -- but I have to smack the news maintainer around with a wet trout as the news page is now an ungodly 11 megabytes and bloats the home page out to 2 megs... Time to dig out this handy tool.

Sad part is that's a step up from the DHTML nightmare that preceeded it, or worse the "slapped together in a wysiwyg" before that. It's kinda comical that with each iteration the page looks better and gets smaller.

Admittedly said layout is not the graphical gloryland your PSD jockeys sit around wanking each-other off over -- but neither are any of the major Internet successes. Facebook? E-Bay? Amazon? Google? Not exactly a graphical tour-de-force which is why your artsy-fartsy crap is rarely seen outside personal blogs, local companies who don't realize their website is a money pit instead of revenue generator, and your art trend gallery websites like "zen garden" -- which may be very attractive -- and most always ultimately USELESS from an accessibility standpoint with their crappy fixed widths, crappy absurdly undersized px metric fonts, illegible grey on grey or tan on tan well below contrast minimums, serif fonts combined with the small sizes making text even MORE illegible, and most always desiged with the "designer first, who gives a rats posterior about the content." attitude. (zen garden's home page alone is proof enough of that)

Again, often very pretty, but ultimately useless if it interferes with reading the content, adding/removing content, or getting your content out to people...

In other words, treat text like the first class citizen of the web it is. Whoever said "a picture is worth a thousand words" lost sight of the fact that you often need one explicit word to get the job done...

Let's say we were trapped on a beach and didn't speak the same language. I held out a hot cup of coffee and said "tchukala" -- what did I say? Drink? Hot? cup? Coffee? Here? Have some? Want some?

I know, I know... don't gimme that smegging Star Trek crap, it's too early in the mornin'

After all, there's a REASON constructed speech supplemented (as heiroglyphs) then eventually replaced pictographs. Roman lettering and Arabic numerals FTW.

[Stomme poes]

Is there a reason why you used HTML 4 instead of HTML5?

It's an update of an older site. Here's the old shell still sitting on another, releated site (ugly, huh..., that design predates me by several years!). I just kept the doctype. No reason not to... other than, when I use (legal) ARIA attributes, HTML4 doctype makes the validator whine. HTML5 doctype, it doesn't, however ARIA, like CSS3, has nothing to do with which HTML doctype you're using, so you can just ignore.

I actually validate with the XHTML strict doctype (just tell the validator to substitute), so that I can get caught where I'm not strict enough while keeping whichever crusty doctype I actually have... since, again, browsers don't actually read doctypes... they just check that they're complete.

HTML4 also whines about negative tab indices, but I'm using those pretty much for IE6 to work, and sighted keyboarders don't tab onto empty nothingness. Oh well.

However on my own, local copy, I have added some HTML5 goodness: new form input types on the forms pages ("Direct Afsluiten" is basically a page that's all form), some of the new attributes like "required" (and also the ARIA versions, and watch out! HTML5 boolean attributes are true when they exist and false when they don't! ARIA "booleans" can always exist in the markup but be set to ="false" or "true"!).

Turns out, browsers who know any of the new HTML5 junk really don't give a rats what doctype you use, so I discovered I could update the stuff that might help users on mobile (new input types on *some* phones offer more targeted keys on the touch screen) without having my colleague change teh doctype. Which is fine by me.

What should we be using?

Only the stuff that works today, degrades in all browsers without needing a crapload of scripts, and is accessible (cough cough canvas cough cough). Don't use <canvas> for anything other than changing the colours of pixels on a screen, becuase that's all it does today (Doug Scheppers? is working on an idea to combine canvas with svg so there are working objects in the canvas that AT can latch on to... but I'm not holding my breath.) No building GUIs in that thing, that's retarded. Use svg : )

Many of the new form input types only add awesome (color is a huge, obvious exception to this) and degrade to type=text otherwise.
Leaving types out of your <link>s to CSS files and your <script> tags... why not? Browsers have been ignoring them all along anyway.
The meta charset="utf-8" works because apparently so many people had been getting the correct version wrong for so long (putting quotes in teh wrong order) that browsers understand it even though "charset" is not and never was a valid "attribute" of the meta tag. Shrug.
I'm staying away from most of the new elements simply because today they are still tripping up screen readers... I'm giving it a few years. Plus IE needs Javascript (sure, it's small, but...) just to see the tags, and that goes against my Tim Berners-Lee hippy ideal of teh interwebs.

But... it likely depends on your audience and just keep in mind that any of it could be revoked at any time (look at <hgroup> jumping in and out of the spec...) and that there are, in fact, two competing specs, who disagree with each other in various areas.

Admittedly said layout is not the graphical gloryland your PSD jockeys sit around wanking each-other off over -- but neither are any of the major Internet successes. Facebook? E-Bay? Amazon? Google? Not exactly a graphical tour-de-force which is why your artsy-fartsy crap is rarely seen outside personal blogs...

I will argue that while I'd prefer a working, ugly site, there is little reason why someone who is good at design can't take something that's well-built and also make it the very best art-fart-ness has to offer. That's what designers are good at, and you can take any functional site and make it more eye-candy-licious with a good designer (a good designer is one who understands the web and is aware of device, browser differences and keeps an eye on total filesize).

[Stomme poes]

If I am not mistaken, I believe this is why the grid systems were invented, like YUI, blueprint and 960.gs, to quickly mockup sites without the intention of actually using them in the final product...

So far as I know, they are used in the final product. Jeff Croft, inventor of one of the first grid systems (Blueprint), wrote an explanation of why he used retarded names like gs70xthpb for classes and later more elaboration on what he meant (and reading the comments is good, since there's even more explanation there).

Basically, people who use grids use them because, in their particular work environments, they believe non-semantic names are a small enough price to pay for quickly whipping out stuff that's very flexible (can be used for multiple clients) with multiple developers who maybe don't understand CSS at the same level and have clients who insist on "make that box blue" when "that box" doesn't have the same type of content in it and is only "blue" because the client wants it to be. Because blue is his wife's favourite colour or something. A dream he had after eating too much bacon and narwhals. Whatever. There's no reasonable way to give bluebox a semantic name, and certainly no way of knowing when looking at the CSS or JS why that box is called what it's called, because it's called that based on someone's whim. Not for content reasons, and not for semantic reasons, so giving that element a content-based or semantic name is very difficult.

I feel very lucky that I don't work in such an environment, because I find that type of code to be smelly (codesmell) and of lower, cookie-cutter quality. If I worked somewhere where that's what they had to do, I'd be forced to write like that too, and a small piece of my soul would die every day. Then eventually I wouldn't care about code anyway, just grind out another page and make someone on XP using IE with a mouse and JS happy and go home and drown my sorrows in the whisky and wonder if I should get up the next morning.

Oh man I can just see a prospective employer using grids reading that and crossing my name off the list. Yoink!

[deathshadow60]

Nice. Is there a reason why you used HTML 4 instead of HTML5?

Because it's still in DRAFT? Draft being a word which means "not ready for real world deployment!" ... that it loosens the structural rules to the point that any sort of validation is damned near meaningless letting people mix code willy-nilly, who cares if it's impossible to maintain and highly likely to break? Or that if you look at it really from a markup standpoint it adds nothing but bloat and is one of the most nonsensical train wrecks of a specification since HTML 3 made FONT and CENTER officially part of the spec? That last part is particularly true if you bother understanding elements like numbered headings, lists, paragraphs, and even horizontal rules.

Though the folks around here can tell you, I could go on for hours with reasons that HTML 5 is best avoided until 90% of the new bloat is deprecated for HTML 6. I call 5 the new HTML 3 for a reason!

Personally, I have no plans to go past XHTML 1.0 Strict, as nothing I've seen of 5 from a markup standpoint offers me any benefit over that... which again <broken record>makes me suspect that's why they're slapping all the new javascript, CSS and other "gee ain't it neat" stuff under HTML 5's banner, as without those things it's useless bloated rubbish that frankly I'm shocked ANYONE is dumb enough to want to even TRY to use!!!</broken record>

There are times I feel like John Adams, and Dickinson just said "To enjoy its protection and share in its benefits..." -- as to me that's about how much HTML 5 offers in terms of reasons to use it. To be frank: JUST like XHTML 1.1 and the proposals for 2.0 -- neither of which offered any tangible benefits I could see either apart from making things massively bloated and needlessly complex.

[deathshadow60]

Oh man I can just see a prospective employer using grids reading that and crossing my name off the list. Yoink!

Depends on the 'employer' -- freelancing you just had the suits line up at your door. Going to work for the Keebler elves of web design shop where they crap out 20 pages a day so they can take the money and run looking for the next inexperienced nube to rape -- then sure, good luck even getting in the door.

But as I've said a lot lately, don't look for ethics in web design, where the average porn site has more core ethics than the majority of SEO, Design and Marketing for normal businesses online COMBINED.

[Stomme poes]

Creating responsive images using the noscript tag | Head

The noscript tag is a bad idea if you have users with js-blocking plugins.

Any plugin that blocks Javascript means the browser may have Javascript on itself... meaning it will not render noscript tags, which are only rendered when the browser itself actually doesn't support Javascript.

So using NoScript or the Web Developer Tool Bar I don't tend to see noscripts since my browser does support JS. But the idea could still be used.

After a quick Google we discovered that it works because children of the <noscript> tag are not added to the DOM.

Hm. A problem indeed.

Filament group has some good stuff out there, I've noticed.

[Stomme poes]

Hm. Was responding to another thread when I realised that

images who are backgrounds and loaded in the CSS with :hover are not downloaded from the server... until that :hover event.

I can maybe see some way of having JS call some kind of hover-like event for at least background images after it runs, assuming it's only running because the user's screen is wide enough that the script was loaded...

[deathshadow60]

Maybe some other psuedo-state might work -- preferably one that once set stays on? :visited for example?

[Stomme poes]

Yeah! I've never tested with :visited... I wonder how hacky this would be or if it could be something viable...

[oddz]

Nice. Is there a reason why you used HTML 4 instead of HTML5?

The important thing to understand that several technologies (seemingly unrelated but that is another topic) are under the umbrella or HTML5. There are several things under that umbrella that I would consider great and others are not. In particular all the new tags such as aside, section , etc – fail in my opinion, I just don't use them. However, the new input types introduces – awesome especially email with how most mobile browsers handle it. The same can really be said for most the new form stuff introduced besides for the required attribute, which I think frankly sucks because its now very flexible – browser default style or nothing which is quit crude in ff5. Lets see… some of the other things oh… video handling – great, finally no need for flash, who wouldn't like that. In regards to JavaScript enhancements under the "HTML5" umbrella geo location is sweet ( especially with mobile devices) and local storage seems pretty useful though I have yet to actually use that one, just read about it. So there are actually many things under the HTML5 umbrella that are pretty cool mainly its the new tags that are worthless.

My work flow over the past few months has been write HTML4, use the good things under the HTML5 umbrella that I need, then switch the doctype.

There is to much confusion of what quantifies something as "HTML5" really nothing is "HTML5" its all HTML in the end. There is no way to actually quantify the document as HTML5 besides for looking at the doctype and even that doesn't necessarily quantify it as HTML5. People just like to say HTML5… that is really all it is.

[Stomme poes]

besides for the required attribute, which I think frankly sucks because its now very flexible – browser default style or nothing which is quit crude in ff5.

It's pretty much an on/off thing, though for where I've used it it's been nice: we have some form inputs that people consistently missed filling in (and I am tempted to blame the ajax for this, since after someone fills in their postal code, the street and city are automatically filled in for them... but not their house number. And they don't notice it sitting there because the rest was filled in for them... I even use Javascript to highlight it until it's filled in, but "required" stops newer browsers from even going through the submit process if it's empty).

It doesn't seem to work with pattern though. Meh.

Autofocus however is a pox. At least until users can easily turn it off in their browsers, which so far they can't.

Lets see… some of the other things oh… video handling – great, finally no need for flash, who wouldn't like that.

Most examples I've seen still had Flash... in teh object inside the video tag as a fallback (and then with a download the video link inside that as a fallback)... tho it may depend on if you're maybe writing for like an iPhone or something where you know a) Flash is pointless there and b) they have a video-ready browser.

Some of the updated DOM stuff is pretty cool. It's about time they had a getElementsByClass() (and yeah, that one is part of the HTML5 spec), along with querySelector and querySelectorAll. The data-foo attributes are also nice, especially since they don't actually rely on the browser understanding them. Browser can ignore them. data-foo is just for us to do local junk with.

then switch the doctype.

I'm too lazy to bother. The shorter doctype is nice to start new pages with simply because then I'm not copy-pasting, but otherwise... you can keep your old one if you want.

[oddz]

I'm too lazy to bother. The shorter doctype is nice to start new pages with simply because then I'm not copy-pasting, but otherwise... you can keep your old one if you want.

I only start with HTML 4.01 strict for validation purposes.

The data-foo attributes are also nice, especially since they don't actually rely on the browser understanding them. Browser can ignore them. data-foo is just for us to do local junk with.

Yep, no more completely relying on tags, ids, and classes for JavaScript selection – which is nice.

[capescafe]

So about the doctype...I'm still using XHTML 1.0 mostly but because of some of the form attributes HTML5 had I used those on one of my forms pages and then switched the doctype to the HTML5 doctype. So in order to use any of the HTML5 features or specs I guess, you'd have to switch the doctype right? Because if you left the old doctype the page wouldn't validate correct?

[Stomme poes]

So in order to use any of the HTML5 features or specs I guess, you'd have to switch the doctype right? Because if you left the old doctype the page wouldn't validate correct?

You don't have to change the doctype unless you work somewhere where they insist on validation-for-validations-sake (some places do).

The point of the validator is to tell you where you've screwed up, but it's not a smart tool and for example if the w3c validator claims my aria-attributes are invalid because I'm using an HTML4 doctype, I the developer ignore those, because they are not true errors. Same with vendor prefixes in the CSS validator.

Remember you can also tell the validator to override the doctype. In other words, if you would like it to test your page as if it were HTML5, you can choose that in the options on the validator, and then other than the warning that there's a doctype override, you would in theory get validation results as if you had an HTML5 doctype.

You can also try validator.nu which by default is an (X)HTML5 validator. It might use WHATWG rules while the W3C one uses W3C rules, but anyone using something where two specs disagree with each other (and yes, they are not the same spec!) should be totally cool with validator disparities. It's all draft still anyway.

And the validator is the only thing you need to worry about: browsers who support various HTML5 things or have an HTML5 parser only look to see that you are sending the document as text/html.

This means that nasty autocomplete is by default "on" in HTML5 browsers and this is retarded. The idea that I would have to update hundreds of older forms just to keep stuff like credit card numbers from being automatically filled from some user's cache is kinda evil.
I've ordered stuff from public computers. I try to avoid it because they're often not safe but, I've done it. Now the browser has my info in its cache. I know how to flush the cache but I don't expect every other user to know that.
Autocomplete should default to "off" and those who want it on should then have to add it in manually... opt-in rather than opt-out. There are too many e-commerce forms floating around out there who don't have someone to go around adding attributes to them because browsers have changed.

[Stomme poes]

To get more back on topic, the Sass site has an article, SASS vs SCSS, which syntax is better which has some of the warnings (for example, the possibility of two much nesting if you don't watch yourself) and whatnot

[capescafe]

To get more back on topic, the Sass site has an article, SASS vs SCSS, which syntax is better which has some of the warnings (for example, the possibility of two much nesting if you don't watch yourself) and whatnot

Yes, sorry for getting off topic. Just had to find out about that in regards to redesigning my sites responsively.
About the SASS vs SCSS I seem to remember that being mentioned somewhere in this thread but I can't find it anywhere. What is that again? I read a little on that site you posted to link to...but I was trying to find in this thread where it was mentioned and how it relates to this topic on responsive web design.

[Stomme poes]

Whoops, I'm retarded. I'm having trouble seeing what I'm subscribed to, that was for the LESS/SASS thread. Lawlz.