CSS

16
Dec/10

How to create a 3-column layout with CSS

by Roger Johansson under CSS, Feeds, Web Design

One of the most visited pages on this site is the Simple 2 column CSS layout tutorial, where I explain how to create a basic 2-column CSS layout with floats. Many readers have asked for a similar tutorial on how to create a three-column layout, and I’ve been meaning to write one for a few years.

Well, I finally took the time to do it. Three-column CSS layouts have been explained many times, in many different ways, by many people already, so there is nothing (or at least not much) new here. It’s also something that I’m pretty sure that most regular readers can do in their sleep. Regardless, there are many people looking for this info, and it’s convenient to be able to refer to an explanation of how I normally create 3-column CSS layouts with a method that I find robust.

Read full post

Posted in .


Leave a Comment more...

6
Dec/10

Using the LESS CSS Preprocessor for Smarter Style Sheets

by Dmitry Fadeyev under CSS, Feeds, Web Design
Advertisement in Using the LESS CSS Preprocessor for Smarter Style Sheets
in Using the LESS CSS Preprocessor for Smarter Style Sheets  in Using the LESS CSS Preprocessor for Smarter Style Sheets  in Using the LESS CSS Preprocessor for Smarter Style Sheets

As a Web designer you’re undoubtedly familiar with CSS, the style sheet language used to format markup on Web pages. CSS itself is extremely simple, consisting of rule sets and declaration blocks—what to style, how to style it—and it does pretty much everything you want, right? Well, not quite.

You see, while the simple design of CSS makes it very accessible to beginners, it also poses limitations on what you can do with it. These limitations, like the inability to set variables or to perform operations, mean that we inevitably end up repeating the same pieces of styling in different places. Not good for following best practices—in this case, sticking to DRY (don’t repeat yourself) for less code and easier maintenance.

Enter the CSS preprocessor. In simple terms, CSS preprocessing is a method of extending the feature set of CSS by first writing the style sheets in a new extended language, then compiling the code to vanilla CSS so that it can be read by Web browsers. Several CSS preprocessors are available today, most notably Sass and LESS.

Less-css in Using the LESS CSS Preprocessor for Smarter Style Sheets

What’s the difference? Sass was designed to both simplify and extend CSS, so things like curly braces were removed from the syntax. LESS was designed to be as close to CSS as possible, so the syntax is identical to your current CSS code. This means you can use it right away with your existing code. Recently, Sass also introduced a CSS-like syntax called SCSS (Sassy CSS) to make migrating easier.

If It Ain’t Broke…?

By now you might be thinking, “So what? Why should I care about these things, and how exactly will they make my life as a Web designer easier?â€� I’ll get to that in a moment, and I promise it will be worth your time. First, let me clarify the focus of this article.

In this tutorial, I’ll be using LESS to demonstrate how CSS preprocessing can help you code CSS faster. But that doesn’t mean you must use LESS. It’s my tool of choice, but you may find that Sass fits your workflow better, so I suggest giving them both a shot. I’ll talk a bit more about their differences at the end of the article.

I’ll start off by explaining how LESS works and how to install it. After, I’ll list a set of problems that large CSS files pose, one by one, and exactly how you can use LESS to solve them.

Let’s go!

Installing It

There are two parts to any CSS preprocessor: the language and the compiler. The language itself is what you’ll be writing. LESS looks just like CSS, except for a bunch of extra features. The compiler is what turns that LESS code into standard CSS that a Web browser can read and process.

Many different compilers are actually available for LESS, each programmed in a different language. There’s a Ruby Gem, a PHP version, a .NET version, an OS X app and one written in JavaScript. Some of these are platform-specific, like the OS X app. For this tutorial, I recommend the JavaScript version (less.js) because it’s the easiest to get started with.

Using the JavaScript compiler is extremely easy. Simply include the script in your HTML code, and then it will process LESS live as the page loads. We can then include our LESS file just as we would a standard style sheet. Here’s the code to put between the <head> tags of your mark-up:

<link rel="stylesheet/less" href="/stylesheets/main.less" type="text/css" />
<script src="http://lesscss.googlecode.com/files/less-1.0.30.min.js"></script>

Note that I’m referencing the less.js script directly from the Google Code server. With this method, you don’t even have to download the script to use it. The style sheet link goes above the script to ensure it gets loaded and is ready for the preprocessor. Also, make sure that the href value points to the location of your .less file.

That’s it. We can now begin writing LESS code in our .less file. Let’s go ahead and see how LESS makes working with CSS easier.

1. Cleaner Structure With Nesting

In CSS, we write out every rule set separately, which often leads to long selectors that repeat the same stuff over and over. Here’s a typical example:

#header {}
#header #nav {}
#header #nav ul {}
#header #nav ul li {}
#header #nav ul li a {}

LESS allows us to nest rule sets inside other rule sets, as a way to show hierarchy. Let’s rewrite the above example with nesting:

# header {
  #nav {
    ul {
      li {
        a {}
      }
    }
  }
}

I’ve omitted the content from the selectors for simplicity, but you can see how the structure of the code quickly changes. Now you don’t have to repeat selectors over and over again; simply nest the relevant rule set inside another to indicate the hierarchy. It’s also a great way to keep code organized because it groups related items together visually.

Also, if you want to give pseudo-classes this nesting structure, you can do so with the & symbol. Pseudo-classes are things such as :hover, :active and :visited. Your code would look as follows:

a {
  &:hover {}
  &:active {}
  &:visited {}
}

2. Variables For Faster Maintenance

We usually apply a palette of colors across an entire website. Any given color could be used for multiple items and so would be repeated throughout the CSS code. To change the color, you’d have to do a “Find and replace.”

But that’s not quite it. You could also isolate those values into separate rule sets; but with this method, the rule sets would keep growing as you add more colors across the website, leading to bloated selectors. Here’s what I’m talking about:

#header, #sidebar .heading, #sidebar h2, #footer h3, .aside h3 { color: red; }

To make a simple color change, we’re faced with long selectors, all dedicated to that one color. It’s not pretty. LESS allows us to specify variables in one place—such as for brand colors, border lengths, side margins and so on—and then reuse the variables elsewhere in the style sheet. The value of the variable remains stored in one place, though, so making a change is as simple as changing that one line. Variables start with an @ and are written like this:

@brand-color: #4455EE;

#header { background-color: @brand-color; }
#footer { color: @brand-color; }
h3 { color: @brand-color; }

In LESS, variables also have scope, so you could use variables with the same name in various places; when they’re called, the compiler would check for the variable locally first (i.e. is there anything with that name where the declaration is currently nested?), and then move up the hierarchy until it finds it. For example, the following code:

@great-color: #4455EE;

#header {
  @great-color: #EE3322;
  color: @great-color;
}

…compiles to:

#header { color: #EE3322; }

3. Reusing Whole Classes

Variables are great, but we often reuse more than single values. A good example is code that’s different for every browser, like the CSS3 property border-radius. We have to write at least three declarations just to specify it:

-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;

If you use a lot of CSS3, then this sort of repeating code adds up quickly. LESS solves this by allowing us to reuse whole classes simply by referencing them in our rule sets. For example, let’s create a new class for the above border-radius and reuse it in another rule set:

.rounded-corners {
  -webkit-border-radius: 5px;
  -moz-border-radius: 5px;
  border-radius: 5px;
}
#login-box {
  .rounded-corners;
}

Now #login-box will inherit the properties of the rounded-corners class. But what if we want more control over the size of the corners? No problem. We can pass along variables to the “mixin” (these reusable classes are called mixins) to get a more specific outcome. First, we rewrite the original mixin to add the variable we want to manipulate:

.rounded-corners(@radius: 5px) {
  -webkit-border-radius: @radius;
  -moz-border-radius: @radius;
  border-radius: @radius;
}

Now we’ve replaced the values for a variable, and we’ve specified the default value inside the parentheses. To give mixins multiple values, you’ll just need to separate them with a comma. Now, if we want our #login-box to have a border radius of three pixels instead of five, we do this:

#login-box {
  .rounded-corners(3px);
}

4. Operations

Variables let us specify things such as common palettes of colors, but what about relative design elements, like text that’s just a bit lighter than the background, or an inner border that’s one pixel thicker than the outer border?

Rather than add more variables, we can perform operations on existing values with LESS. For example, we can make colors lighter or darker or add values to borders and margins. And when we change the value that these operations depend on, they update accordingly. Take the following:

@base-margin: 25px;
#header { margin-top: @base-margin + 10px; }

This gives the #header element a top margin of 35 pixels. You can, of course, also multiply, divide and subtract, and perform operations on colors like #888 / 4 and #EEE + #111.

5. Namespaces and Accessors

What if you want to group variables or mixins into separate bundles? You can do this by nesting them inside a rule set with an id, like #defaults. Mixins can also be grouped in this way:

#defaults {
  @heading-color: #EE3322;
  .bordered { border: solid 1px #EEE; }
}

Then, to call a variable and a mixin from that particular group, we do this:

h1 {
  color: #defaults[@heading-color];
  #defaults > .bordered;
}

We can even access values of other properties in a given rule set directly, even if they’re not variables. So, to give the sidebar heading the same color as your main h1 heading, you’d write:

h1 { color: red; }

.sidebar_heading { color: h1['color']; }

There’s not much difference between variables and accessors, so use whichever you prefer. Accessors probably make more sense if you will be using the value only once. Variable names can add semantic meaning to the style sheet, so they make more sense when you look at them at a later date.
A couple more things to mention: You can use two slashes, //, for single-line comments. And you can import other LESS files, just as in CSS, with @import:

@import 'typography';
@import 'layout';

To Conclude

I hope by now you’ve got a pretty good idea why CSS preprocessors exist, and how they can make your work easier. The JavaScript version of the LESS compiler, less.js, is of course just one way to use LESS. It’s probably the easiest to get started with, but it also has some downsides, the biggest one being that the compiling takes place live. This isn’t a problem on modern browsers with fast JavaScript engines, but it might work slower on older browsers. Note that less.js actually caches the CSS once it’s processed, so the CSS isn’t regenerated for each user.

To use the generated CSS instead of LESS in your markup, you can compile your files using the various other compilers. If you’re on OS X, I suggest trying out the LESS App, a desktop app that watches your LESS files for changes as you work and automatically compiles them into CSS files when you update them. The Ruby Gem has the same watcher functionality but is trickier to install if you’re not familiar with Ruby (see the official website for details on that). There are also PHP and .NET versions.

Finally, LESS isn’t your only option for a CSS preprocessor. The other popular choice is Sass, but there are still more options to check out, such as xCSS. The advantage of LESS is that it uses existing CSS syntax, so getting started is just a matter of renaming your .css file to .less. This might be a disadvantage if you dislike the CSS syntax and curly braces, in which case Sass would probably be a better choice. There is also the Compass framework available for Sass, which is worth checking out if you go with Sass.

(al) (sp)

© Dmitry Fadeyev for Smashing Magazine, 2010. | Permalink | Post a comment | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: ,

Leave a Comment more...

2
Dec/10

Name One Thing About Web Development You Never Saw Coming

by Robert Bowen under CSS, Design, Feeds, Javascript, Web Design
Advertisement in Name One Thing About Web Development You Never Saw Coming
in Name One Thing About Web Development You Never Saw Coming  in Name One Thing About Web Development You Never Saw Coming  in Name One Thing About Web Development You Never Saw Coming

Not that this is universally true, but some people look haphazardly into a field before deciding to dive in. We do the odd bit of research, investigating the ins and outs, slowly developing expectations about this new arena of work. Expectations are not necessarily bad to have; they can be a powerful motivator. But sometimes our expectations are shattered by a development that we never saw coming.

“Shatter” sounds a bit dramatic, but a situation can certainly get derailed. Regardless of whether this changes the course of your career, it can still knock the wind out of you. Perhaps worst of all, you can’t really prepare for something that you didn’t expect. That is where this post begins. What’s past is prologue, and many of you are bound to have reflections on how those twists and turns of yesterday can help guide your development today.

Shattered Glass in Name One Thing About Web Development You Never Saw ComingWhen we’re hit by something that wasn’t on our radar, our expectations can shatter. (Credit)

Once again, we turned to our social media friends and followers for examples of unforeseen changes in the design and development world that tripped them up. Hopefully, by going over some of these pitfalls, we can be better prepared for the next ones — or at least be prepared for their fallout. With the way communities are constantly developing, changes are bound to surprise us, but if we are aware of how quickly they can occur, we might just be better able to adapt to them.

A Better IE

“Did someone say ‘standards-compliance’? Well, it couldn’t have been Microsoft. Oh, it was?”

A chill ran over the World Wide Web as we heard the news — and saw the proof — that Internet Explorer was going to comply with the standards that the rest of the Web had been adhering to for a while. And it took only the ninth iteration of its browser for Microsoft to finally reach the shore from which the rest of us have been waving to them.

Distantshore in Name One Thing About Web Development You Never Saw ComingYears after setting sail on the cyberspace waters, IE finally lands on the shore we have been occupying for years. (Image credit)

Many in the design and development community have long given up on the Microsoft crew, and many had vowed to stop catering to the IE crowd by not adding the extra code and tweaks that previous versions of IE required. So, when Microsoft announced that IE9 was bound for the market, you can imagine that the community was waiting with less than baited breath. Then news filtered to the public about the bells and whistles it would have, and people became shocked at the prospect of IE becoming compliant.

Lesson Learned
So, what did we learn from this development that we never saw coming? With enough pressure and time, suckage can end. There was a time when Microsoft was setting the agenda and didn’t have to comply to anything. It was on top, and no one could challenge its grip on the market, so it saw no need to change. But all that is past. It is finally stepping up to the plate.

What our Friends and Followers Said

  • IE9 is remotely good!
  • Internet Explorer is supporting open standards.
  • IE9 as we know it now.
  • An excelling IE9.
  • Internet Explorer becoming a fairly standards-compliant browser.
  • IE9 being pretty awesome!
  • IE to support recent fancy stuff like HTML5 canvas, video, audio, clean CSS3 and more to come with IE9.
  • Microsoft’s commitment to Web standards in IE9.
  • Internet Explorer actually getting better (IE9 looks promising… let’s just hope).
  • Yes, IE9, and especially its download manager!!

Mobile Web Explosion

“A Web you can take anywhere? Are you talking sci-fi?”

Not exactly, although we weren’t exactly prepared for this by Back to the Future 2. The mobile Web has been a game-changer for the design and development community, and it caught many of us by surprise. It doesn’t seem to be slowing down either. Quite the opposite: the market is growing by leaps and bounds. What some assumed to be a fad has forged an entirely new direction for the market.

For the longest time, the trend was to expand our viewable spaces. Designers planned for a larger Web, breaking out of the standard 960 grid, believing that the Internet would be grandiose and viewed on large screens. Things took a turn, and the Web was narrowed to much smaller mobile devices. The mobile Web exploded and seems to have created a virtual black hole that is pulling countless surfers in. People have fallen in love with the idea of taking the Web wherever they go, and they aren’t looking back.

Lesson Learned
While increasing the size of viewing areas is still a trend in its own right, few of us expected so many people to opt for a compact Web. Convenience outweighs presentation at times, and many want constant access to the Internet. Basic often beats bulk.

What our Friends and Followers Said

  • A mobile revolution.
  • The explosion in mobile Web and applications!
  • Designing for browsing on mobile devices (cell phones mainly).
  • Designing for cell phones! When I started in Web design, I’d never have guessed that.
  • Web browsing on small (mobile) devices.
  • I definitely didn’t see mobile browsing being at the level it is today (Thanks, Apple!).

Social Media Dominance

“Why would anyone care about a blogging platform that limits you to 140 characters?” “Who cares about social networking? We’re running a business, not a high school.”

I wonder how those words tasted when they were eaten? Social networking dominated the Web almost as soon as it hit the scene, and it continues to attract more users than most of us could have imagined. The many social media outlets and groups out there have brought us connectivity as well as insight into the communities that use them. Who saw that coming?

Dozens of social media networks are gaining traction, creating new avenues for marketing in the process. They are attracting not only veteran Web users, but also millions of people who previously saw little or no use for the Internet. No wonder these networks are dominating the market: they satisfy a need that so many didn’t realize they had.

Lesson Learned
What have we learned? That most people think in 140-character bursts of thought? Not exactly. Rather, we’re seeing the power of this connectivity and the way the Web can provide a global fabric of social communication. Many of us miscalculated the appeal of a socially interactive Internet, but now we see that it is unstoppable. You can’t stop the signal, as Joss said.

What our Friends and Followers Said

  • Twitter! I thought micro-blogging and other social media arms would be a passing fad. Boy, was I wrong.
  • The omnipotence of Facebook.
  • More than half a billion people using a website (Facebook).
  • Facebook advertising around the ground at Old Trafford against Liverpool on Sunday. Mad!
  • Facebook addiction.
  • Massive social media sharing on every pixel online.
  • Social media overkill.
  • With that, the herd of Social Media “experts.”
  • Twitter proving to be popular/useful.
  • Twitter. I still don’t see any redeeming value to it, even for reciprocal linking.
  • Social media integration.
  • Hundreds of thousands more people trying to earn XP and levelling up (Farmville).

Overall Market Stability & Growth

“You mean I can make this my job? What are you smoking?”

So many people never really saw the design and development fields growing so rapidly into a stable and secure job market. Thousands have committed to a career in a field that was once considered better suited to supplementary income or a lucrative hobby. The market now provides an endless supply of work opportunities and continues to evolve.

Everyone knew the Web would be big, but not everyone recognized the need for professional designers and developers to make the most out of people’s experience on it. This stability and growth came as a surprise, albeit a welcome one. The broad and helpful community that has populated this market might explain both the stability and growth. The community has built a solid foundation for the coming generations.

Lesson Learned
Is there a lesson here in our underestimation of the market — aside from what it tells us about our self-esteem (although that’s part of it)? As with the mobile Web and social media, perhaps the lesson here is not to dismiss an emerging market before considering its full implications and potential applications.

What our Friends and Followers Said

  • Just about unlimited opportunities.
  • Here in my country: the respect!
  • Now it’s actually a real job!
  • To actually earn my living with website development.
  • The growth of the now enormous Web dev community and its amazing generosity. Couldn’t have become the designer I am today (being self-taught), and the better designer I hope to be in the future, without it.
  • Well, I was going to say HTML5, but then when you really look at it as a whole, I guess you can infer that all of us never really saw a big market for virtual goods (in this case Web design and development). I was very surprised to see how it kept on growing to this day, and I have high hopes for the future.

Farewell XHTML — Hello HTML5

“What is this nonsense about the return of straight HTML? XML-based code is the wave of the future!”

Or so we thought. As we’re seeing, things don’t always work out the way we expect. When the coding standard went from HTML 4.01 to XHTML, many abandoned ship and cut down this x-citing new path. Some even called XHTML the future of HTML, doubting that HTML would have a significant version after 4.01. They believed the Web had gone the way of the X.

Crossroads in Name One Thing About Web Development You Never Saw ComingNo one expected us to retreat from the path of XHTML. (Image credit)

After nearly a decade of XHTML ruling the Web, HTML5 promises to change all that. We might have to say farewell to the X after all these years. Cue the dropping jaws and shocked expressions. Evidently, XHTML had not taken as strong a hold as we had thought. The standard is now revisiting its roots.

Lesson Learned
Is the lesson here never to give up on the source mindset? Or that the original will persevere in the end? Or better yet, that we should learn to move forward without putting all our eggs in one basket? If we learn that, we will have learned something valuable from this detour.

What our Friends and Followers Said

  • The end of XHTML.
  • Leaving the XHTML path (HTML5).
  • HTML5 form validation. Or rather HTML5 itself.

Bargain Bin

“No one goes bargain hunting for design and programming. Quality always wins out over cheap and quick… right?”

Apparently not. This is another of those dynamic and well populated fields that many people never expected to face. Lo and behold, as in almost every other business market out there nowadays, you will come across people who want bargain-bin pricing from their designers and developers. Some even expect bells and whistles with their bare-bones pricing.

When the economy nosedived a few years back, many people could no longer afford top-shelf design and development. This sad truth, coupled with the slice of the public that undervalues the contributions of these professionals, opened a segment of the market that not only tolerates this undercutting but practically encourages it. Bargain-bin services have cropped up all over the landscape to capitalize on a demographic that is in crisis and, for lack of a better word, cheap.

Lesson Learned
The lesson here is obvious, though perhaps not to those who were caught off guard by this trend. There will always be people who undervalue work that they themselves cannot do, either because they do not really understand what is involved in the process or because they are just dismissive. And there will always be those among us who are willing to satisfy these demands to turn a profit.

What our Friends and Followers Said

  • That there are people out there willing to do it so cheaply.
  • Those free downloadable templates! Now anybody can just get a nicely designed template, eliminating the need for a custom Web designer.
  • Build-your-own-website-for-free website services. People will simply click, drag and add content, and they now have their own website!

Apple vs. Flash

“This idea of community will steer the market, and collaboration between the major players will be the way forward, right?”

Not if Apple has anything to say about it. Talk about shockwaves: many of us never saw Apple’s battle with Flash coming. Potentially deep-sixing a major player on the Web before its prime was a bold move. The field of battle has become anything but friendly as both houses make their play to shape the future of the Web.

Flash has long been a favorite of many designers and developers, while being disliked by just as many. So, it was inevitable that the day would come when we would have to choose whether to commit to or abandon this technology. That day came sooner than we expected; once Apple dominated the mobile Web and app market and turned on Adobe. Flash is not supported on the iPad or iPhone, to the chagrin of some critics, and Steve Jobs made some rather unflattering statements about Flash’s stability and usefulness in the wake of HTML5.

Lesson Learned
The market can change unexpectedly when its leaders suddenly decide to turn the tables. Expect the unexpected is particularly apt here. As one company gains dominance in a market segment, it can effectively twist and turn us however it likes.

What our Friends and Followers Said

  • Flash going away.
  • Apple’s failure to support Flash on iPhone/iPad.
  • The death of Flash.
  • Adobe and Apple hating each other!
  • Apple not adopting Flash!
  • Steve Jobs saying ‘No’ to Flash.

Jumping on JavaScript

“Oh, please. JavaScript is a flashy fad. Give it time; it’ll fade into the ether.”

A fad it is not. In fact, as pointed out by one of our social media friends quoted below, JavaScript has become so prominent in so many applications both on and off the Web that it has become a near necessity. For years, it has been enhancing the experience of millions of users, creating a more dynamic Web.

In the beginning, some designers and developers saw little use for this technology beyond a bit of dazzling. Others saw its raw potential and took the reigns, working hard to elevate our experience of the Web and beyond, and making JavaScript a go-to language for so many developers.

Lesson Learned
In discounting JavaScript so quickly, perhaps we should learn to be not so hasty in judging the usefulness of every new tool that comes along. We should instead devote adequate time to examining the technology and exploring its potential applications.

What our Friends and Followers Said

  • JavaScript becoming essential. I ignored it for years, thinking it was just good for flashy effects.
  • The rise of JavaScript.
  • Server-side JavaScript.

The Persistence of jQuery

“JavaScript is a complicated language, and we just have to accept that in order to use it. There’s no getting around it.”

Well, that argument might have held up until 2006. But then one tool hit the scene to change all that. jQuery arrived and sent waves rippling through the community. Suddenly, this cross-browser JavaScript library was barreling through the ranks to become the most popular library.

Numberone in Name One Thing About Web Development You Never Saw ComingjQuery didn’t take long to cement its status as number one. (Image credit)

In a matter of years, jQuery was created and used on nearly a third of the most trafficked websites. Clearly, there was no stopping it. Opening doors for developers in so many areas, jQuery became another one of those wonderful gifts to the community. Couple that with its open-source licensing, and it is easy to see how it has scaled such heights in so short a time.

Lesson Learned
Looking at the ingenuity of those responsible for the success of jQuery, we can draw a lesson about how we as a community can come together to build better access to popular languages, such as JavaScript. Never underestimate our desire to cut out as many steps from a process as possible and make life easier for ourselves — not to mention the momentum such efforts can generate.

What our Friends and Followers Said

  • jQuery to an extent.
  • The possibilities! Thanks to jQuery and the brilliant minds behind it.
  • jQuery.

An Animated CSS

“CSS is impressive, to be sure, but it’s all about styling. Leave the animation to JavaScript!”

Well, not so much anymore. Since about 2007, Webkit devotees and others have been developing the means to enable elemental animations via CSS. And with CSS3, what many in the community thought would remain a dream is becoming a reality.

CSS is a powerful and popular language for styling websites, and no one ever doubted its adaptability, but the emergence of an animation module still surprised a few of us. Despite the crude animations generated in the early days of CSS, these more fluid JavaScript-like transitions are still quite an interesting development. Another shining example of the leaps and bounds by which the design and development community grows, ever moving forward.

Lesson Learned
Any new lessons we can learn from this? Not really, other than touching on some of the ideas already discussed. Here again, we see that we cannot underestimate the inventiveness of people in this industry. It it one of the main reasons for the dynamism and growth that have brought such stability and scope to the market.

What our Friends and Followers Said

  • CSS3 animation.
  • CSS transitions. But oh, what a joy they are!
  • CSS3 animation!

More From our Friends and Followers

Before turning the discussion over to you in the comments section, we wanted to share a few more comments from our friends and followers about surprises that caught them off guard. Thanks again to all of those who participated in this dialogue and to all those about to contribute!

  • Photoshop CS5 Content Aware.
  • The death of the Web.
  • Chrome was a complete shock when it got released. Really don’t know how they kept it so quiet.
  • Clients from hell.
  • 1. Google doing Web fonts. 2. How easy they are to implement!
  • Flash actually being used.
  • The enjoyment I get from building shifty out-of-date-code HTML email campaigns. Seriously. A/B testing them and seeing an increase in conversions is awesome.
  • Wait… you’re serious??
  • Custom-colored scroll bars are not so hot anymore.
  • In-browser location detection.
  • The number of “professional” Web designers who can barely string together some HTML/CSS.
  • Seeing websites in 2010 that are still being made with HTML tables… Argh!

Related Posts

(al)(ik)

Leave a Comment more...

25
Nov/10

Beware of -webkit-text-size-adjust:none

by Roger Johansson under CSS, Feeds, Web Design

The other day I came a cross a website with text too small for me to read it comfortably. I hit Command-Plus a couple of times to make Safari bump up the text size a bit… and nothing happened. What?

After some investigation of the CSS used on the site the culprit turned out to be the following CSS (don’t use):

body {
    -webkit-text-size-adjust:none;
}

What that does is prevent WebKit-based browsers from resizing text. Not even full page zoom resizes the text. Now, how can preventing your users from resizing text be a good idea?

Read full post

Posted in , , .


Leave a Comment more...

11
Nov/10

Tips for creating enterprise-level HTML, CSS and JavaScript

by Roger Johansson under CSS, Feeds, Javascript, Web Design

Do you feel that your front-end code isn’t quite up to enterprise standards? Want some good tips on how to take your HTML, CSS, and JavaScript to the next level? Go to Enterprise CSS, Enterprise HTML, and Enterprise JavaScript for loads of useful tips and best practices.

Note: To eliminate any risk of misunderstanding I think it’s best to add that this is a joke – most of the tips are actually anti-best practice. The sad thing is that the front-end code of many “enterprise-level� sites and content management systems really do look like many of these “tips� have been taken seriously.

Some of my favourite tips are these:

Read full post

Posted in , , .


Leave a Comment more...

  • Categories

  •   

  • Recent Posts

  • Archives

  • Pages

  • Meta

    • Copyright © 1996-2010 BlogmyQuery - BMQ. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress