The Chicago JavaScript Meetup Group spurred more than 50 of its members to brave harsh weather Thursday night for the group’s fourth free get-together since its founding last October.

Organizer Vlad Didenko led the charge with an in-depth look at Firebug, while assistant organizer Justin Meyer contributed a discussion of Ajax fundamentals.

Pizza, soda and an O’Reilly book giveaway helped fuel the event, which also included time for conversation and networking. Kudos to the organizers for overcoming a last-minute, gas leak-related scheduling snafu and relocating their event from DePaul to the CBOE.

Thursday’s event marked my first opportunity to attend one of these meetups. I was impressed with the turnout and the quality of the presentations despite a fairly basic target skill level. In its current configuration, the Chicago JavaScript Meetup Group probably best serves developers with at a beginner or intermediate level looking to explore the Ajax world further.

Based on the discussion taking place on the group’s Meetup.com page, I’m not the only person who’s eager for some more advanced topics at future installments. It looks as if the organizers are leaning toward a multi-track approach to accommodate all skill levels. Assuming that happens, count me in.

Didenko has posted a screencast of his Firebug talk online. Anyone can join the group, which requires only a Meetup.com registration for your troubles.

Share/Bookmark

I’m as geeked about jQuery’s 1.3 release as the next developer. But I’m even more excited about the new API browser developed by Remy Sharp and available here.

For as long as I’ve been a jQuery user – going on 18 months now – I’ve been frustrated by the slow speed and sometimes intermittent availability of the jQuery documentation site. Now we’ve got a blazing-fast API browser that presents jQuery Core and jQuery UI side by side in the same cool interface. Better yet, it’s available as an Adobe AIR app for offline viewing. Sweet!

I could quibble about the lack of bookmarkable URLs and the occasionally sparse documentation of corner cases. Instead, I’ll just remain upbeat about this huge step in the right direction. No matter how intuitive jQuery’s API, it’s a powerful library whose roster of methods continues to grow. Nothing speeds up development faster than quick, persistent access to quality API documentation.

Share/Bookmark

jQuery celebrated its third birthday Wednesday with the release of the brand-new 1.3 version. This latest release includes a bunch of cool new stuff which has already been discussed to death elsewhere. To me, however, the most interesting aspect of jQuery 1.3 is the movement of former plugin functionality to the core library.

Live events are a new twist on the venerable, and indispensable, Live Query plugin, while the upgraded, more granular effects queues were previously tackled by add-on authors. IMHO, this kind of migration is A Good Thing, providing greater parity with other core JavaScript and effects libraries (such as Scriptaculous’s FX queue) while offering compelling feature differentiation (event binding throughout the full lifecycle of an Ajax page).

Share/Bookmark

My most recent Pathfinder project calls for a pretty typical Ruby on Rails web application with two interesting additional components: a Facebook application and an iGoogle gadget. Though a Rails Facebook plugin was easy to find, Rails development tools for iGoogle weren’t as thick on the ground.

First, a bit of background: iGoogle, Google’s personalized-homepage service, offers developers two methods of application development:

• build a native gadget by wrapping custom HTML, CSS and JavaScript in an XML wrapper.
• build a sandboxed gadget by wrapping an externally hosted web application in an iframe.

Because of cross-domain security issues, gadgets that require authentication must be built using the iframe sandbox method. As it turns out, this method’s a lot easier. Instead of building a whole new interface, you can just tart up your existing app with an iGoogle-optimized user interface. Why replicate your existing view logic with a bunch of iGoogle-specific JavaScript when you can just reskin and call it a day?

As it turns out, though, reskinning a Rails app for iGoogle isn’t as simple as it might seem at first glance. I can think of three options. All have drawbacks:

1. Serve up your existing application using all the same controllers and actions. Just build a new iGoogle layout that works well within the small viewport of an iframed gadget. Of course, you’ll need a mechanism to distinguish between iGoogle requests and normal requests. Your gadget could initially call up a one-off iGoogle controller that sets a session flag (session[:igoogle] => true) so that all subsequent requests get the iGoogle layout. The only problem is that visits to your normal application in the same browser will get polluted by the iGoogle flag. The iGoogle interface that works so well in a tiny iframe renders your main application almost unusable in a full browser window.
2. Use the same approach as above, but use a URL flag or a URL rewriting scheme to differentiate between iGoogle and normal requests. This keeps your normal application from having its layout accidentally toggled to the iGoogle one. But it’s a lot of work. Accepting requests with an iGoogle flag is easy, but it’s much harder to make sure that every link or form submittal within your application propagates that flag.
3. Build out a complete iGoogle controller that replicates every action from your normal application that you wish to expose to the iGoogle gadget. Depending on the number of actions and the complexity of each, this could require a lot of duplicated controller code. Of course, smart use of partials would reduce the amount of view-layer effort. Still, you’ve now got a ton of essentially identical controller actions that have to be maintained in two places.

None of these solutions is ideal, so let’s hear from you, readers. How do you build Rails apps that lend themselves to efficient re-use within iGoogle or other sandboxed “gadget” contexts? Let us know in the comments.

Share/Bookmark

When your http://localhost/~username/ sites go haywire, it’s time to dig into your Apache config files

As Rails pros know, Phusion Passenger allows you to serve multiple Rails apps on the same Apache webserver instance with few configuration or deployment headaches. When you install it in your local Mac dev environment, you can easily work on a bunch of Rails projects simultaneously without having to manually start and stop individual server instances all the time. The OS X Passenger preference pane makes deployment even easier. Just add a project, give it a custom local URL, and point it at a directory. You’re good to go.

But what happens if you’re already using OS X’s built-in Apache webserver to dish up local content such as PHP applications or static HTML? When I first got Passenger up and running, all of my local sites in /Users/<username>/Sites/ stopped working. It took a bunch of digging, but I eventually realized that something in my Apache configuration had gotten messed up during the Passenger installation process. I was missing the configuration file for my OS X user account. OS X generates this file the first time you enable web sharing for any individual user. It’s responsible for mapping your /Sites subdirectory to localhost URLs, so that http://localhost/~<username>/myapplication/ points to /Sites/myapplication/index.html.

The file should live here:

/private/etc/apache2/users/<username>.conf

If it gets blown away, all you need to do is replace it and populate it with meaningful instructions. The contents should look like this:

<Directory "/Users/<username>/Sites/">
	Options Indexes MultiViews
	AllowOverride None
	Order allow,deny
	Allow from all
</Directory>

Once you’ve created and populated the file, just bounce Apache by turning Web Sharing off and then on again in the Sharing prefpane of System Preferences. Voila, your http://localhost/~username/ URLs should start working again.

Just in case you want a little more background, here’s how this file gets executed by Apache:

• The root Apache config file is here:

  /private/etc/apache2/httpd.conf
  

• It includes the userdir module for serving local user content:

  LoadModule userdir_module libexec/apache2/mod_userdir.so
  

• Further down, it includes a separate config file for user directories:

  # User home directories
  Include /private/etc/apache2/extra/httpd-userdir.conf
  

• Inside that file, you should see code like this:

  # Settings for user home directories
  #
  # Required module: mod_userdir
  
  #
  # UserDir: The name of the directory that is appended onto a user's home
  # directory if a ~user request is received.  Note that you must also set
  # the default access control for these directories, as in the example below.
  #
  UserDir Sites
  
  #
  # Users might not be in /Users/*/Sites, so use user-specific config files.
  #
  Include /private/etc/apache2/users/*.conf
  

• Finally the line Include /private/etc/apache2/users/*.conf calls the <username>.conf file we created above.

Share/Bookmark

If you read one or more of the Pathfinder blogs in our web interface, you may have noticed some tweaks to our navigation and top-level categories. Our goal in making these changes was to help different audiences drill down to the specific content that interests them. Instead of just a few top-level categories, we now boast around 20, though many posts appear in multiple categories. To subscribe via RSS to any specific category – or to our entire feed – just visit our Feeds page.

Share/Bookmark

Rosenfeld Media contacted me after I published my review of Luke Wroblewski’s “Web Form Design: Filling in the Blanks.” They offered Agile Ajax readers 10% off “Web Form Design” or any other purchase at rosenfeldmedia.com. To redeem, simply enter the code PATHFINDER at checkout.

Share/Bookmark

Usability and design guru Luke Wroblewski knows that web forms suck. More importantly, he knows why – and how to make them suck less.

For the past few years, the Yahoo! product design exec has been presenting his ongoing research into the humble HTML form at conferences and on his blog, Functioning Form. I attended Wroblewski’s presentation at An Event Apart Chicago 2007 and came away super-impressed. His persuasive mixture of case studies, existing research and newly commissioned usability studies helped shed light on the patterns and anti-patterns that determine whether users successfully complete your forms or give up in disgust.

All of Wroblewski’s preparation came to fruition earlier this year when he published “Web Form Design: Filling in the Blanks” (Rosenfeld Media). After finally taking the time to read the book cover to cover, I’m mad at myself for waiting so long.

Written in clear, neutral prose and bolstered by numerous real-world examples, “Web Form Design” mixes low-level implementation advice with high-level analysis of the role forms play in ecommerce and Web 2.0. As the author himself puts it:

Web forms are often the last and most important mile in a long journey. Despite their importance, the design of forms is often poorly thought out and conceived. Your organization may have already invested heavily in opening a relationship with its customers through high-quality marketing, site design, and search engine optimization. But now it is time to “close the deal” by making sure those customers can complete your forms.”

To that end, Wroblewski divides his examination of web form construction into three sections: “Form Structure,” “Form Elements” and “Form Interaction.” The first provides the theoretical underpinnings, while the second and third provide nuts-and-bolts advice. Sidebars from additional experts provide complementary viewpoints or delve further than the main text into technical details. Individual topics include the following:

• the proper visual treatment and interaction design of error and success messages.
• the breakdown of long forms into individual pages.
• the optimal amount of spacing between form fields and labels.
• the use of subtle graphical design elements to group related inputs logically without generating too much visual noise.
• the proper use of color, contrast and icons in error, success and help messages.
• the best ways to offer contextual help messages.
• the use of intelligent defaults in some situations and the improved usability of default-free inputs in other situations.
• the proper use of top-, left- or right-aligned form labels depending on context and form length.
• the elimination of unnecessary form fields.
• the proper placement and design of marketing questions and other optional form fields.

While examining these topics in detail, Wroblewski always assesses the relative strengths and weaknesses of a wide range of solutions. He offers an impressive amount of usability data, including detailed eye-tracking studies and form completion statistics conducted and compiled especially for the book.

In many cases, the author stresses that context determines the best solution to any given user-input scenario. Readers looking for one-size-fits-all solutions may come away disappointed. But I believe Wroblewski succeeds in his goal of forcing readers to think as deeply about the design of web forms as they do about other parts of their applications.

Among the many design patterns Wroblewski evaluates, many draw upon the interaction conventions of Ajax and Web 2.0. Autosuggest, visual transitions, inline validation and dynamic hide/show behaviors all play their part in the book’s suggested solutions. Yet the author’s viewpoint is always that of usability and consumer satisfaction; bells and whistles are but means to an end. In one example, Wroblewski points out that popup date pickers on travel websites were originally triggered only by explicit user interaction; it was only after their use had redefined user expectations that they began to auto-launch upon focus of the relevant form fields.

The book takes a deliberately non-technical approach to the material. Wroblewski assumes at least a basic familiarity with the HTML elements that make up web forms, but this isn’t a book about markup, CSS or JavaScript. Instead of showing how to code a set of selection-dependent inputs using Ajax or stylesheet mojo, Wroblewski focuses on the information architecture, interaction design and usability of such components. The result is a book as useful to product managers and business decision-makers as it is to back-end programmers, UI engineers and designers.

“Web Form Design: Filling in the Blanks” is available in paperback or PDF format from the publisher. Wroblewski, proprietor of LukeW Interface Designs, previously published “Site Seeing: A Visual Approach to Web Usability” (Wiley, 2002).

Update: You can now purchase this book directly from the publisher for 10% off.

Share/Bookmark

Welcome to “Ask a UI Guy,” an occasional new feature in which we tackle JavaScript, markup and CSS questions for an audience of server-side developers. Today’s topic: strategies for organizing your style rules into reusable components.

CSS doesn’t impose much structure on its practitioners. Individual developers must build their own structure if they wish to escape the trap of poorly organized, inefficient code.

If a project kicks off without a clear shape to its stylesheets, subsequent developers are likely to plop additional styles down wherever is convenient. It’s hard to build reusable components if every style is a one-off tied to an element id. Stylesheets with a strong skeleton and frequent signposts encourage conscientious code that’s easier to maintain.

And let’s face it: CSS tools hasn’t come as far as JavaScript ones. Sure, Firebug can help you track down why element X looks the way it does. But without a clear picture of a project’s overall CSS architecture, it’s hard to alter that element’s style properties with confidence.

Every stylesheet should tell a story

In my projects, I use a few simple tricks to encourage what I call narrative CSS. My premise is that every stylesheet should tell a story. In other words, developers should understand the structure of an application’s markup just by looking at the CSS – and understand exactly where a specific declaration can and will be used without having to grep through the entire codebase.

This tenet is based on my observations of how people make changes to existing projects: They look at the few lines of markup affected by their change, then they find the style rules that affect that markup. If the context of those style rules isn’t immediately apparent, then it’s difficult to make changes without introducing bugs or creating inefficiencies.

To accomplish this, I use the following guidelines:

• Start with a good reset.css. I recommend the Eric Meyer version.
• Use signpost-style comments to create a superstruture in the stylesheet.
• Use normal comments to create a substructure.
• Order those signposts and comments – and the rules that appear between them – from general to specific; elements to classes to ids; baselines to overrides:
• Create id-based style rules only for page-level containers: headers, footers, sidebars, main content areas. Use element- or class-level rules for everything else.
• When creating reusable utility classes that could go anywhere on the page, scope them only to a class name unique enough to prevent common namespace collision.
• When creating components that belong in a specific page-level container, scope them to the id of that container.

All of that theory sounds, well, theoretical. How does it play out? Let’s look at the skeleton of a typical narrative stylesheet:

1. Basic HTML elements

   Your first section should include baseline style rules for all common HTML elements. I sometimes mix in a few class overrides on those element-level rules so I can get fine-grained control on, for instance, input elements, which vary wildly depending on their type attribute.

   /************************************************************
   	base element declarations
   ************************************************************/
   
   body{
   	background: url(/sites/pfd/img/chrome/bg.png) top left repeat-x #000;
   	color: #fff;
   	font-family: Verdana, Arial, Helvetica, sans-serif;
   	font-size: 12px;
   	line-height: 1.5em;
   }
   
   h1,h2,h3,h4,h5,h6 {
   	font-family: Helvetica, sans-serif;
   	font-weight: bold;
   	line-height: 1.4em;
   }
   h1 {
   	font-size: 20px;
   }
   h2 {
   	font-size: 16px;
   }
   h3,h4,h5,h6{
   	font-size: 14px;
   }
   
   /* links */
   
   a {
   	color: #08c;
   	text-decoration: none;
   }
   a:hover {
   	color: #444;
   	text-decoration: underline;
   	cursor: pointer;
   }
   
   abbr,
   acronym {
   	text-decoration: underline;
   }
   abbr:hover,
   acronym:hover {
   	cursor: help;
   }
   
   /* standard text tags */
   
   b,
   strong {
   	font-weight: bold;
   }
   i,
   em {
   	font-style: italic;
   }
   
   /* forms */
   
   input,
   textarea,
   select,
   .button {
   
   	border: 1px solid #999;
   }
   /*
   	you must give classes to input elements
   	to work around limited CSS 2.1/3 support
   	in some browsers
   */
   input.radio {
   
   }
   input.checkbox {
   
   }
   
   label {
   	display: block;
   	font-weight: bold;
   }
   .button {
   	background-color: #ddd;
   	font-weight: bold;
   }
   .button:hover {
   	cursor: pointer;
   }
   

2. Reusable utility classes

   Your next section should include class-based rules for reusable components that aren’t tied to a specific area of the page: pipe-delimited lists, tabs, menus, definition lists, etc.

   /************************************************************
   	reusable utility classes
   ************************************************************/
   
   /* pipe-delimited list */
   
   ul.pipeDelimitedList {
   
   }
   ul.pipeDelimitedList li {
   
   }
   ul.pipeDelimitedList li.first-child,
   ul.pipeDelimitedList li:first-child {
   
   }
   
   /* tab navigation */
   
   ul.tabGroup {
   
   }
   ul.tabGroup li.tab {
   	display: none;
   }
   ul.tabGroup li.tab.activeTab {
   	display: block;
   }
   ul.tabGroup li.tab h1 {
   
   }
   

3. Page layout based on the ids of major page-level containers

   When building the superstructure of your page, use ids and scope them within each other to make the markup patterns explicit. Overkill? Maybe. But the goal here is CSS that reads like a blueprint.

   /************************************************************
   	page layout
   ************************************************************/
   
   #container {
   
   }
   #container #header {
   
   }
   #container #main {
   
   }
   #container #main #content {
   
   }
   #container #main #sidebar {
   
   }
   #container #footer {
   
   }
   

4. Module layout, one page-level container at a time

   Now we get to the heart of the stylesheet: The specific components that can appear within a given area of the page. The navigation in your header? The search box in your side navigation? The shopping cart interface? Think of each one as a reusable component that exists within the context of a page-level container.

   /************************************************************
   	section: header
   ************************************************************/
   
   /* global navigation */
   
   #header .navigation {
   
   }
   #header .navigation ul {
   
   }
   #header .navigation .logo {
   
   }
   #header .navigation .logo a {
   
   }
   
   /* boilerplate */
   
   #header .copyright {
   
   }
   #header .byline {
   
   }
   
   /* shopping cart */
   
   #header .shoppingCart {
   
   }
   #header .shoppingCart ul {
   
   }
   #header .shoppingCart ul li {
   
   }
   #header .shoppingCart ul li.total {
   
   }
   

   /************************************************************
   	section: main content
   ************************************************************/
   
   /* module: article */
   
   #content .article {
   
   }
   #content .article h1 {
   
   }
   #content .article p {
   
   }
   
   /* module: product benefits */
   
   #content ul.benefits {
   
   }
   #content ul.benefit li {
   
   }
   #content ul.benefit li a {
   
   }
   

   /************************************************************
   	section: sidebar
   ************************************************************/
   
   #sidebar .section {
   
   }
   #sidebar .section dl {
   
   }
   #sidebar .section dl dt {
   
   }
   #sidebar .section dl dd {
   
   }
   

   #footer {
   
   }
   #footer .copyright {
   
   }
   #footer a {
   
   }
   

5. Specialty code tied to float-clearing, JavaScript behaviors, or image scripts such as IEPNGFix

   Finally, deal with style rules likely to contain a grocery list of selectors, such as containers that need their floats cleared or images that need to have their alpha transparency set via script in IE. Since you’ll add selectors to these grocery lists over time, it’s convenient to have easy access without searching the entire file.

   /************************************************************
   	utilities: float-clearing, png-fixing, javascript, etc.
   ************************************************************/
   
   /* float-clearing */
   
   /* IE6 */
   
   * html #head,
   * html #content,
   * html #content .article,
   * html #rail,
   * html #nav{
   	height: 1%;
   	overflow: visible;
   
   }
   
   /* IE7 */
   
   *+html #head,
   *+html #content,
   *+html #content .article,
   *+html #rail,
   *+html #nav{
   	min-height: 1%;
   }
   
   /* good doggies*/
   
   #head:after,
   #content:after,
   #content .article:after,
   #rail:after,
   #nav:after{
   	clear: both;
   	content: ".";
   	display: block;
   	height: 0;
   	visibility: hidden;
   }
   
   /* IE6 hacks for image transparency */
   
   img,
   #content #rail .railBlock .header,
   #content #rail .railBlock ul.icons li {
   	behavior: url(/css/iepngfix.htc);
   }
   
   /* styles used exclusively by our jQuery plugins */
   
   .curvyCorners {
   
   }
   .someAjaxPlugin {
   
   }
   

Does this make sense? Have a better solution to CSS organization? Let us know in the comments.

Share/Bookmark

Welcome to “Ask a UI Guy,” an occasional new feature in which we tackle JavaScript, markup and CSS questions for an audience of server-side developers. Today’s topic: the deceptive allure and subtle peril of inline styles.

When you’re first cobbling together a new feature or content page, inline styles can seem like a great idea. You’re already editing an ERB, JSP, PHP or ASP template, so why not just write your CSS code in the same file? Throw a few style attributes into your HTML tags, populate them, and voila: instant look-and-feel.

What seems good in theory, however, quickly falls apart in practice. Many seasoned CSS developers employ external stylesheets for even the most roughshod of skunkworks. They do so with a fervor approaching that of TDD adherents carefully writing tests before even thinking about tackling actual code. People have been arguing against the use of inline styles in production code for close to a decade now, but I argue against their use at any stage of a project. Here are some of the reasons why:

1. Inline styles break the look and feel of your site: If every page gets styled in isolation, it’s difficult to achieve a uniform look and feel. Small differences in the inline styles of different components will accumulate over time, creating a look that’s either subtly or dramatically “off.”
2. Inline styles are unmaintainable, turning even small site-wide design tweaks into huge chores: The promise of CSS is that you can re-skin your site without ever editing a single piece of markup. That’s true – as long as you don’t utilize inline styles. When your design director decides your site needs more white space, it’ll be a royal pain to find every element with an inline padding declaration. Let’s hope your RegEx skills are up to snuff.
3. Once you’ve written inline styles, you’ll forget to move them to an external stylesheet: Most folks know styles should eventually live in an external stylesheet. Those who employ inline styles think they’re doing so on a temporary basis. But let’s face it, once you’ve got something working, how likely are you to carefully cut, past and reformat a bunch of code to a new location and file format just to satisfy an abstract ideal such as “all styles belong in an external stylesheet”? We all start coding with the best of intentions, but real life intervenes. If you never put those styles inline to begin with, you’ll never have to move them – or feel guilty months later when you come across your code and realize they’re still stranded inside style attributes.
4. If you do move your styles, you’ll have to come up with the proper selectors: With inline styles, you don’t need to write selectors, just rules. The tag in which your rules are declared is the selector. Once you move the styles, you’ll have to examine your markup to figure out how best to target that element. Will you add a class? Add an id? Declare your styles on the base HTML element itself? It’s no fun having to think about that hours or days after you wrote the rules themselves.
5. CSS rules won’t work the same once you move them to an external stylesheet: CSS stands for “Cascading Stylesheets.” The cascade is determined by not only the type of declaration, but also the location of the declaration. Inline styles trump rules in external stylesheets. Assuming you actually do eventually move your inline styles to an external stylesheet, you’ll almost certainly have to tweak them to get them to work with the new cascade weight they carry in their final location.
6. Inline styles are confusing to debug: When you’re working on an existing application with well-established and -populated external stylesheets, your use of inline styles can generate cascade confusion. Individual elements will be controlled by both inline and external styles. Sure, Firebug can tell you which rules are affecting which elements at any given time, but the mixture still makes it harder to debug a visual issue.
7. Inline styles violate the DRY principle: You can’t create compound declarations with inline styles. You can’t, for instance, use a single rule to cause all p children of div#whatever to have a padding of 5px and a left float. Instead, you have to include those rules in the style attribute of each individual p element. When and if you actually move these styles to a stylesheet, they’ll either be horribly inefficient or you’ll have to rewrite them. Either way, that’s a lot of extra typing. And of course, as long as the styles remain inline, if you want to change how three sibling p elements look, you’ll have to change your rules in three places. Invariably you’ll remove, say, a float: left from two of them but not the third, then scratch your head wondering why your layout is broken.
8. Inline styles are hard to read and edit: Most CSS authors write external stylesheets with one rule per line; when placed inside HTML elements, they’re part of a jumble of markup, content, scripts and styles. It’s not hard to see the enhanced readability of the second example below:

   <p style="color: #fc0; font-weight: bold; display: none; position: relative; left: -50px; top: 200px; float: left;">Lorem ipsum dolor sit amet, consectetur adipiscing elit. <a href="http://www.google.com" style="text-decoration: underline; display: block; padding: 20px; background-color: #930; color: #fff;">Quisque nisl</a>. Quisque velit leo, <span style="font-style: italic; color: #ffc;">ultricies nec</span>, lobortis quis, iaculis ac, est.</p>

   p {
   	color: #fc0;
   	font-weight: bold;
   	display: none;
   	position: relative;
   	left: -50px; top: 200px;
   	float: left;
   }
   a {
   	text-decoration: underline;
   	display: block;
   	padding: 20px;
   	background-color: #930;
   	color: #fff;
   }
   span {
   	font-style: italic;
   	color: #ffc;
   }

9. Inline styles encourage poorly structured markup and CSS: When you’re moving your inline styles to a stylesheet, you’re likely to replace every style attribute with a class or id attribute so you can apply your rules to the correct elements. This apparent time-saver will keep you from unlocking the real power and elegance of CSS: the cascade. You’ll think of every element on the page as a one-off, to be styled individually. You won’t think about how to organize your selectors to apply common rules to base HTML elements while saving special styling rules for classes and ids. The result will be verbose, poorly factored CSS that’s difficult to maintain.
10. Inline styles won’t get much sympathy or help from your friendly neighborhood CSS expert: CSS experts employ a variety of tricks to minimize the pain of debugging. Religious devotion to external stylesheets is often the first line of defense. When you turn to your UI gal for help on a vexsome visual issue, she may well tell you to move all of the CSS to external stylesheets before she’ll even look at it.

So if inline styles cause cancer and destroy lives, why are they part of the spec in the first place? As with any tool in our technological arsenal, inline styles do have a purpose. They’re best used to help you override your stylesheets in truly exceptional circumstances.

One example: Page elements to which visual effects will be applied with JavaScript. Many JavaScript animation frameworks perform even basic hide/show operations by manipulating the properties of individual DOM elements rather than classes. For your markup and styles to play nicely with such frameworks, you may well need to declare a small subset of style rules inline.

CSS experts: Are there any arguments against inline styles that I’ve missed? Are there any exceptions that I overlooked?

Developers: Have I converted you to the cause, or have you got convincing arguments to the contrary? And what other client-side questions can I answer in future installments?

Share/Bookmark