[...] 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.
Really handy tool to batch-validate an entire site’s HTML. It’s a very slow at the moment, but as it’s in beta I’ll assume it’s only going to get better.
Principal Developer Evangelist of the Mozilla Developer Network Christian Heilmann weighs in on the semantics issue:
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.
A few days ago Adobe released a public demo/beta of their new web-design tool: Muse. Modelled after Indesign (it’s made by the same engineers) it aims to allow print-designers to create HTML sites without writing a single line of code.
Naturally, this didn’t work. Many influentialwebdesigners 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.
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.
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:
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.
Indulge me, if you will, in a little hypothetical. Consider the following scenario: you’re asked to design and develop a website for a big client. It’s a large company, with probably thousands of employees. A bank, for example, or a large pharmaceutical company. Or maybe it’s a government contract, or a big public sector player, like public transport or the electric or gas company.
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. (more…)
