[...] In fact, in most cases, the things we considered best practices were leading to the bad outcomes we sought to avoid. I realized (unpopular though it might be), that we couldn’t make it work out well by trying harder. Each time we start a new project, we think “this time, I’m going to keep the code clean. This time the project will be a shining example of what can be done with CSS.” And without fail, over time, as more content and features are added to the site, the code becomes a spaghetti tangle of duplication and unpredictability.

I was linked to this in the comments of my previous post and a lot of the points in this article rang true to me.

Web (front-end) developers are constantly trying to walk a tight-rope between semantic purity, standards compliance, writing flexible, maintainable code and just getting the job done in time.

I will try to explain the most common problems I see every time someone shows a code sample or I see a project written using any of these languages/pre-processors.

I’ve documented my love for LESS on this very blog many times, but it’s good to see someone pointing out the potential dangers of using them: excessive code duplication and the performance hit associated with over-specific selectors[1]. Be sure to read the full article first, then come back if you want.

Done? Good. Now I’ll ask you: are these problems with pre-processors, or with how people are using them?

If your only programming experience lies with CSS or HTML, then by all means do yourself a favor and stay away from pre-compilers. I know from experience how easy it is to get carried away with a new language. If you’re not careful you could quickly end up shooting yourself in the foot by overcomplicating things.

But if you have a good grasp of plain CSS, you know some object-oriented programming and you understand how your LESS/SASS code will compile to CSS… Why the hell not? You should never see potential abuses by some as a reason to dismiss an entire concept for everyone. Pre-compilers don’t write bad CSS, bad programmers do!

[1] Although unless you’re writing the next Google, Facebook or some other mammoth web-app, I don’t think over-specificity means all that much for performance unless you’re desperate to eek out a precious few milliseconds, of course. It has its effects certainly, but I see it more as a problem hindering efficient code re-use, than with performance. If you find it helps you organize your code so you can more easily find your way, I think it’s a fair trade-off: After all, CPUs will only become faster, while programmer’s brains are pretty much stuck at where they are now. You can always optimize and refactor afterwards, if need be.

A lot of the debate about semantic value and using the correct HTML is kept alive by people who have been around for a long time and seen browsers fail in more ways we care to remember. Valid markup and sensible structure was our only chance to reach maintainability and make sense of the things around us. This was especially important in the long long ago. I remember using Lynx to surf the web.

What follows is a brief history of webdesign and he wraps up with some advice for the pragmatic use of HTML

• If you write a document by hand, use all the semantics you can add in. This is your handwriting, your code is your poetry and people learn from looking at what you did.
• If you need to write a hard-core application and every byte is a prisoner try to play nice with the semantics but follow your end goal of delivering speed. Make sure to tell people though that your code is the end result of conversions and optimisations and not for humans to look at.
• Regardless of what you build – when you can use new technology (maybe in connection with old, like <div class="section"><section></section></div>) use it.
• Remember that the web is not your browser and computer – add fallbacks for other browsers when using bleeding edge technology. When the others catch up you won’t have to alter your code!
• The main focus of markup and web code that is not optimised for edge case apps is to make it easy for people to maintain it. If people can see in the HTML what is going on – win. If what only works with JS is generated by JS- even better.
• More markup is not a crime when it is markup that adds value. Arguments that STRONG is worse than B because it means more code and slower loading pages are irrelevant in times of gzipping on the server
• We can only escape the chicken and egg problem of new HTML when we use it. Right now, if you ask for support in browsers for new elements the answer from most vendors is that nobody uses them so why bother. And when you ask people why they don’t use them they tell you because browsers don’t support them. One of us has to start changing that.

Recommended reading for those of us walking the tightrope between semantic purity and just getting the job done.

The template > slot > ad mental model is engrained both in advertisers, planners and web sites. Providing space for ads needs to be broadened into multiple spaces for one ad concept. This requires closer collaboration between advertisers and web sites, designers and marketeers and sales teams.

Mark Boulton offers some ideas for marrying fluid, responsive webdesign with the need for fixed-width advertising banner formats.

I’ve just been reminded of a very important lesson that I occasionally forget: test web fonts on Windows, because a lot of them look shit.

Elliot Jay Stocks on the science behind webfont hinting and what to look out for when designing your next site with @font-face.

Naturally, this didn’t work. Many influential webdesigners have already slammed the app’s many shortcomings – both technical and conceptual, so I won’t bother to repeat their perfectly valid criticisms. Suffice to say, I wouldn’t recommend it.

As far as I’m concerned, Muse’s biggest shortcoming is the absolutely attrocious quality of the HTML code it generates. But even if Adobe fixed that, by for example switching to a better layout framework and reduced the amount of code by 80%, it would still be a poor substitute for a skillful webdesigner and a text-editor. The reason for this? Semantics.

Jeffrey Zeldman wrote a post last year entitled “An indesign for HTML and CSS”:

But Nack’s “constructive” suggestion for Adobe, quoting Michael Slade, is to create “the modern day equivalent of Illustrator and PageMaker for CSS, HTML5 and JavaScript.”

Nack acknowledges that this will be difficult. I propose that it will be impossible. Says Nack:

As I noted the other day, “Almost no one would look inside, say, an EPS file and harrumph, ‘Well, that’s not how I’d write PostScript’–but they absolutely do that with HTML.”

Well, there is a reason they absolutely do that with HTML. PostScript is a programming language designed to describe page layouts and text shapes in a world of known, fixed dimensions (the world of print), with no underlying semantics. PostScript doesn’t care whether an element is a paragraph, a headline, or a list item. It doesn’t care if a bit of content on one page cites another bit of content on a different page. PostScript is a visual plotting language. And HTML is anything but.

HTML isn’t just a collection of blocks representing pretty pictures: it describes a document, whose content is meant to be consumable by just about anything. A properly written and formatted HTML document should remain human-readable even when viewing the raw source-code. This is an incredibly vital advantage of HTML over other technologies, and to just discard this like a used hankerchief, when the semantic web is right around the corner is hugely irresponsible on Adobe’s part.

Adobe is essentially lying to untold numbers of print-designers by telling them “Yes, you could – nay, should – be making websites, even if you can’t code”. And this my friends, could only lead to calamity: can you imagine handing Muse-generated HTML off to a back-end developer to integrate? He’d laugh you out of the room! For all Adobe’s claims to the contrary they are actually widening the gap between designers and developers with every new release.

Indesign can now export Flash sites, DVD menus and those god-awful iPad magazines that are nothing but 500MB zips of “interactive” Jpegs (magazines that, by the way, will look like absolute arse when Apple decides to release a retina-display packing iPad). I’m betting the only reason they didn’t release Muse as an Indesign plugin was because Indesign isn’t included in the Web-Premium Creative Suite.

Adobe’s philosophy that (print-)designers should never have to learn anything other than graphic design is hurting every single app in the creative suite today. Every release, more and more features no professional actually uses are added to already overly complicated and bloated apps.

“Look!” they’ll say, “without a single line of code I can use inverse-kinematics in Flash!” For a sales pitch that’s a pretty compelling feature. A feature noone uses of course, because full-on character animation is rare in a webdesign workflow – and the professionals I know still do it by hand.

But the feature’s there, and it’s taking up space in your tool-palette, memory, keyboard-shortcuts and even required a rewrite of the Flash IDE which means it now consumes 3 to 10% of your CPU (depending on how fast your machine is) at all times, wether you’re doing something or not. And I’m sure you can give exampes of similarly useless features across the entire suite.

Bloat and inefficiency aren’t even the worst side-effects of these additions: it’s the fact that with every year that passes, the barrier for creative people to get into these apps gets higher and higher. Flash went from being the easiest animation-tool ever to a hugely complicated development framework spread accross three different apps, and multiple programming languages. The animation-tool is still there of course, but it’s become so bloated, so slow and so unstable that I doubt it could ever enthrall newbies like it enthralled me all those years ago.

Same thing with Dreamweaver: I learnt a great deal about webdesign and hand-coding from toying with Dreamweaver’s design-view. I didn’t realize that tables for layout was bad, but then – noone really did back then. I just drew the layout and then switched to code-view to see how it’s done. I taught myself a great deal about then-contemporary webdesign techniques, and after a while I switched to hand-coding entirely, simply because it was faster that way. I’ve been teaching myself how to code better HTML and CSS ever since.

Muse doesn’t even have a code-view.

Thanks to Photoshop, Flash and Dreamweaver I taught myself how to design, how to animate and how to code, which now means that, given a copy of the Creative Suite (or any similar tool, honestly) and time, I could single-handedly build almost anything I can think of. I fear creatives growing up in Adobe’s vision of the future will never be able to say that.

Or “A perfect blend of best practices and developer comfort, using LESS CSS”

Mediaqueries are the new black. They really are, I checked. Ever since A List Apart’s article on Responsive Web Design it seems like every man and his dog are jumping on the CSS3 mediaqueries bandwagon. But as with all bandwagon jumping, enthusiasm can quickly get in the way of efficiency and common sense.

Mediaqueries are awesome, but come with a lot of gotcha’s.

Using mediaqueries doesn’t guarantee your site is optimized for mobile.

Optimization is more than just changing the layout. Mobile users have a high probability of having a slower than broadband connection, and so it isn’t a good idea to have them download images made to be viewed at resolutions far higher than their current device.

… but if you look at most sites displaying responsive layouts today, that’s exactly what they’re doing. The first layout they finalize is the standard desktop version, optimized for 1024×768, and they then use mediaqueries to twist and distort their desktop version into a mobile frame. Not only does this result in a coding nightmare where you’re constantly having to reset your own CSS rules, but it also misses the point of having a mobile site by having their users first download all the desktop-resolution art assets, and then download the smaller images on top of that.

So the best practice for making mobile sites is to build for the smallest screen size first, and then using mediaqueries to create ever bigger layouts as the screen-size goes up (Andy Clarke’s 320andUp boilerplate modification emphasizes and encourages this practice). Working like this means that the mobile browser won’t download any of the bigger images that you define in the higher-res mediaqueries. So the mobile version of a site won’t download the 1600×1200 background image you use in the desktop version, for example.

However, this technique, while being the best practice, is impractical for those of us living in the real world where not everyone (who’s not on a mobile device) uses Google Chrome on a Macbook Air in a trendy coffeeshop. I’m talking of course about the dreaded Internet Explorer.

Mediaqueries break in older browsers.

And by “older browsers” I mean of course IE6, IE7 and IE8. No other browser-manufacturer has upgrade schemes that are as broken as IE’s which means that we have to continue to support browsers that are literally *years* out of date. (Note: when’s the last time someone asked you to fix a browser issue with Firefox 2? Exactly my point.)

So anyway, IE right up until version 8 has absolutely no support whatsoever for mediaqueries. The above mentioned 320andUp uses the excellent respond.js script to force IE to recognize and respond to mediaqueries as a workaround to this issue, but I have several reservations against using this.

The first is that it doesn’t really improve IE users’ experience with the site. Instead of getting a responsive website, they’re constantly treated to a page that first looks broken, than flashes a bit and then looks okay. Not exactly the shining example of responsive webdesign we’re looking to serve these people.

Then there’s the fact that if Javascript is disabled, they’ll still be stuck with only the lowest-level mobile layout of the site. For IE6 I have no qualms whatsoever about this happening, as it’s really not that different from just serving them a universal IE6 stylesheet. IE7 and IE8 on the other hand are still shafted though, by having their already suboptimal experience becoming even more crippled.

And then the final reason for using respond.js being a bad idea is that, as a front-end developer on a strict deadline, having not just one, but 2, 3 or even 4 different layouts to debug in Internet Explorer isn’t exactly a fun thing to look forward to.

And it’d be mostly wasted effort as well, since most people using IE won’t expect (or need) to view your site in many different resolutions.

So why give yourself the extra stress? Click on to read my solution.

LESS is more

I’ve been using LESS CSS (lesscss.org) religiously for over a year now and I just keep finding new and better uses for it. For the uninitiated, LESS is a language built on top of CSS and adds a whole suite of extra features, such as nesting selectors, mixins, color operators and variables.

Using a command-line compiler (or client-side javascript, in the guise of less.js, which I’m not a fan of) it is then possible to compile your lean, mean and well structured LESS into regular CSS, combined, minified, stripped of comments and ready for deployment. If used correctly, it can radically transform the way you write CSS, up to the point where writing vanilla CSS now seems old fashioned and backwards to me.

Recently I’ve come up with a new way of working that allows you to use mediaqueries in a responsible, mobile-first way, without sacrificing Internet Explorer or requiring extra javascripts all the while saving you extra debug work by only having one layout to worry about for Internet Explorer users.

Tutorial

I’ll first show you the structure I’m using:

This structure works as follows: both style.less and IE.less import all the other .less files in the mediaqueries/ and libs/ directories, like so:

As you can see, inside the mediaqueries/ folder I have a single .less file for every layout I’m going to build and support. Global.less is the basest layout, which is essentially what we’ll be serving to mobile browsers as a baseline. All my mediaqueries are built up on top of eachother, so that a user browsing the site with a minimum desktop resolution of 1024×768 will get the rules of all mediaqueries right up until desktop.less, ignoring huge.less until the user resizes the browser window to be bigger than 1280 pixels. I do this by building my queries around solely a min-width requirement, like so:

Inside each of the size-specific .less files, I write all my styles wrapped inside a mix-in, with a pre-filled parameter, like so:

That funky shit you’re seeing are LESS’ support for parametrized classes. It’s more commonly used to create reusable mixins, to have variably sized rounded corners, for example, but I’m using it here to prevent LESS from just inserting the generated code in the parent file where the import statement is declared. So even though I’m importing the file at the top of style.less, the compiled output won’t include whatever code I’ve put inside that parametrized class. This is important for later on. Now, this is the final version of style.less:

When you compile this file, it will automatically expand the layout specific mixins inside the correct mediaquery blocks. In a perfect world where everyone uses a decent, modern browser we could call it a day at this point, but now we’ll make it so that Internet Explorer can only see one layout, namely the desktop resolution one.

In ie.less we put the following:

As I’ve mentioned before, all layouts inherit from each other, so that the desktop resolution layout re-uses rules defined in both the tablet, mobile and global layouts. Expanding all media-queries after one another means that IE will be served a cascaded layout that only works for the basic desktop resolution. Using conditional comments, we can now link both compiled stylesheets in the HTML, like so:

This way, all versions of IE from version 8 downwards will ignore the mediaquery laden style.css and load ie.css while all good browsers ignore ie.css and just use style.css.

Conclusion

I find that the end result is striking in both its efficiency and pragmaticism. We support mobile browsers in a responsible way (i.e mobile first, the rest second) and we maintain excellent support for internet explorer without the use of extra javascripts and without stressing ourselves out trying to support 4 different layouts for crap browsers.

I hope others can learn from this technique so that we can all move forward towards a truly responsive and beautiful web, untethered by the restraints imposed by older browsers.

Download the sources and try it yourself: LESSMediaQueries.zip or view a working example.

Jason Santa Maria - A Real Web Design Application

Prominent webdesigner Jason Santa Maria wrote an interesting article the other day about the pro’s & cons of current webdesign tools (such as Photoshop, Fireworks, etc…) and what a true webdesign application (if it were created today) would need. It’s an interesting read, so check it out at:

http://jasonsantamaria.com/articles/a-real-web-design-application/

The author raises a lot of valid points, notably the huge disconnect between designing static pixels in Photoshop & co. and the crafting of HTML markup, CSS styles and how to resolve cross-browser inconsistencies. Jeffrey Zeldman wrote a similar article a while back and makes the point that hand-coding HTML/CSS isn’t going anywhere anytime soon. I’m of a similar opinion.

In my current workflow, I use a myriad of different tools when designing for the web.

Some of my favourite webdesign tools

After wireframing I’d hop into Photoshop, design all the pages (keeping browser capabilities/limitations at the back of my mind at all times) and then use Layer Comps to review the flow of the site through all the different pages. Some web-designers have begun skipping Photoshop altogether and designing straight in the browser, but I’ve found that a hybrid solution is still the best option for getting the most out of your designs.

Once the client is satisfied with the static comps I fire up Coda, write the markup to be as efficient and semantically valid as possible. With the markup done I hop into CSS, boot up all the virtual machines and alternative browsers I’d like to support and then I’m off for several hours of writing a few lines of CSS, Cmd/Ctrl-S, and then tabbing between browsers while pressing F5 to make sure my layout works.

This is a hugely time-consuming process and is usually the cause of great frustration among beginning web-designers (or designers used to the consistency of the Flash platform) – but for all its faults, it’s still the best option. All the WYSIWYG (What You See Is What You Get) tools out there either sacrifice flexibility, browser compatibility or cleanliness of the markup. Or, in the worst case, all 3.

Writing semantic, search-able markup is one of the most difficult and multifaceted jobs out there. Most hand-coders even find this to be a difficult task, weighing the different semantic options, and choosing between either making alterations to the original design, or sacrificing markup brevity to stay true to the design’s visual complexity (i.e. adding more divs). For a machine to be able to do this, it would need not only to understand the different design elements, but the content you’re designing for as well.

If I was designing such a piece of software, I’d make it work as a block-based design tool: in the design phase, you just drag & drop all the different “boxes” onto a canvas. The design remains mostly static until you come to the export phase. Then your task would be to go through each block, assign a type to it (be it a div, section, header, footer, aside, whatever), give it an id or a class-name and then change the nesting order of the tags (within reason) while the rendering engine attempts to refactor the page’s CSS to work with the changed markup.

Of course, taking browser inconsistencies into account this becomes an almost mind-bogglingly complex task for a computer to handle. With HTML/CSS, to achieve any kind of style or effect there are as many options and techniques available as there are webdesigners and webbrowsers.

To create a simple header some would use 3 divs and an h1, where others could use just a single div, an h2 and a nested span tag. And that’s just the markup, adding the myriad of possibilities CSS offers the potential amount of ways you can go about to achieve a certain style or look become infinite. Any webdesigner worth his salt will know at least 3 or 5 different ways to accomplish something in CSS. He’ll try one way first, finds it works in most browsers except in one instance, and then tries the two other coding techniques until he finds something that yields the most predictable cross-browser results.

Because of the cascading nature of CSS, almost every single situation is unique and there is almost no way of knowing beforehand which technique will yield the best results, except maybe years and years of experience. Software could never be a full substitute for something like that.

As long as our markup is critical to our client’s business needs (S.E.O. is 80% about having good, clean markup), and web-browsers continue to display subtle (or not so subtle) differences we can never in good conscience use WYSIWIG editors. Perhaps one day, when all rendering engines adhere to the same strict webstandards (or a single engine gains such market dominance and quality that all others would strive to emulate its behaviour) such a design tool could become a reality, but until then you’re still better off learning to code by hand.

What all of these clients have in common, is that 9 times out of 10 they’ll all be lorded over by a restrictive and overly protective IT department, who only updates their software and hardware every other decade. Which means the client will be looking at your work through the shit-tinted goggles of IE6.

But you’re used to that by now. You know all the dirty tricks and hacks in the book, so you make the site. You know the client won’t be able to see modern web stuff, so you deliberately stay away from them. No round corners, no fancy fonts, little or no Ajax-techniques and no obvious transparent PNGs.

That’s not to say you’re making a bad site, on the contrary. Some of the best design is done within tight constraints, and a little restraint never hurt anyone. Also, most of these clients have pretty restrictive corporate identities and styleguides anyway. So you design your site, slightly boring, but ultimately functional and usable. Something, maybe like this:

A plain-jane website

The client approves the comps, and the finalized website is online soon afterwards. The client tests the site on their internal, locked-down network and sees exactly what he was promised in the comps, being rendered in IE6. The client also notes that the site feels snappy and loads quickly, even on their outdated hardware. A direct result of the site’s design being restrained and sober.

The client then drives home, and, feeling a little bit proud of the work he’s helped to achieve, decides to whip out his personal laptop and opens up the site in a more modern browser (Google Chrome, Safari or Firefox, perchance), so he can show his wife what he’s been doing all these weeks. At first, a shock.

Wait, what's all this then?

This site looks a lot better than it did a few hours ago in the office! What happened here? There’s subtle animations, tasteful rounded corners and the odd drop shadow here and there. The headings are rendered in a slick custom font that he never recalled installing and the entire site just oozes quality.

“Did I pay for this?”, the client wonders, “Who ordered these upgrades?”

First thing next morning he calls you, and asks where those upgrades came from, and why they’re suddenly gone again, now that he’s looking at the site back on his office machine sporting IE6.

“Well,” you start, “have you heard of ‘progressive enhancement’?”

Progressive Enhancement?

Progressive Enhancement is a web-design methodology that aims to provide the best user experience to as many types of browsers and users as possible. It does this by building the site for the oldest browsers, making sure it works great for them, and then adding enhancements for modern browsers on top of that framework, so people get a more enhanced experience, the more modern, or progressed, their browser is.

Some of the techniques you might use to enhance the site.

It is closely related to another methodology called Graceful Degradation. This works the other way around, where you build a website that has all the bells and whistles you can imagine (AJAX, CSS3, etc…) and then either hacking those to work with the older browsers, or making sure that those browsers fail “gracefully”, in other words, so that the site remains usable when certain features simply don’t work.

The advantage of PE over GD is that with PE, you’re always certain that most of your users wile have a great experience, and that their experience will only improve in time as they upgrade their browsers. With GD, you only hope that people stuck with older browsers won’t be freaked out too much, and that future browsers won’t choke on your ancient hacks.

For new, let’s go back to the hypothetical client. You’ve just given him the gist of what Progressive Enhancement is all about, but as I’m sure you can imagine, several different outcomes to this conversation are possible.

Best case scenario, the client “gets” it, and is thrilled to know that you’ve covertly built him a future proof website that scales beautifully, from the ancient, turn-of-the-century browsing dinosaurs to the latest CSS3-, HTML5-sporting Web 3.0 browsers.

Worst case scenario is that the client demands those same enhancements be recreated for IE6. But now you’ve got an arsenal of valid counter-arguments, such as:

• It’ll take a lot of extra time and money to get that kind of visual fidelity in older browsers.
• Updating or upgrading the site later on will take longer and thus will be more expensive.
• The site won’t run as fast as it does now, both on IE as well as on modern browsers.
• Etc…

So, unless your client is Satan himself and/or completely immune to reason or logic, you’ll have saved yourself a mountain of extra work, and earned yourself a contented, loyal new customer, one with a better understanding of what designing for the web entails.

And all it took, was a little

Managing expectations

We designers have a tendency to pull out all the stops when we’re mocking up a  website. We know what’s theoretically possible in all browsers, so we don’t skimp on the frivolous details. Technically, rounded corners and drop shadows and the like are all possible on IE6. They just require a lot of hacking, extra markup, extra images… all of them slowing down the rest of the site for everyone. So, what to do?

Well, it just requires adding just one extra step to your existing process.

First you design your site like you always do, pulling out all the graphical & typographical stops as you see fit. Then, when you’re happy with it – STOP. Don’t send it to the client just yet. Instead, duplicate your file and tone it down. Take out everything you know is difficult to do in IE6. Better yet, ask the guy who’ll be writing the CSS to do that for you. After removing all the frivolous eye-candy, give the comp a final spit & polish to make sure the design still *pops* and only then send it to the client.

After the usual bout of back&forth, and you finally get client approval for the “restrained” comp, build that, re-adding some or even all of the eye-candy by way of targeted CSS3 and AJAX, so those with modern browsers get the enhanced “special edition”.

It’s a difficult balancing act, sure, and it requires an intimate working knowledge of CSS and browser capabilities, as well as a keen eye for design, but the rewards for dealing with these “conservative” clients in this way are legion, and you’ll end up with:

• Smoother & quicker development cycles, as there’s little or nothing to hack.
• A site that just works and has no IE overhead.
• A client who might feel as though they got more than they bargained for.
• Happy users, regardless of what browser they’re using.

Now wouldn’t that be nice?

Addendum:
The example given is a mock-site for a mock-client. It was quickly thrown together as an example of what’s possible with progressive enhancement.