For several years now, I have been consistently impressed with how Microsoft’s developer division gathers feedback and proactively responds. Nearly every time that I’ve participated in a survey or otherwise provided feedback (solicited or not), someone has followed up with me about my specific concerns. In my experience with how other large companies gather feedback, that’s not common.

So, when I answered a recent survey about ASP.NET development in Visual Studio 2010, I wasn’t surprised when I received a follow-up email from a friendly fellow at Microsoft named Xinyang. In the optional comments section, I had mentioned my concern that CSS and JavaScript editing are becoming second class citizens in Visual Studio. In response, Xinyang asked me to provide more detail on that comment.

As I composed a lengthy email reply to him, it occurred to me that a post here would be a much more effective way to refine my feedback and potentially gather more responses from you at the same time.

So, here are a few of my ideas for improving client-side development in Visual Studio 2010, separated into CSS and JavaScript specific feedback. Xinyang and some of his colleagues will be reading this and your comments, so if you agree, disagree, or have other ideas yourself, be sure to chime in.

CSS

Visual Studio 2010’s CSS editing experience is workable, but that’s about the best I can say about it. There aren’t any bugs that I’ve encountered, per se, but it’s Spartan.

I think a few simple features could improve the CSS editing experience dramatically.

Working with color

Displaying color swatches along with CSS color codes is a handy feature that’s been filtering into development editors lately. Whether the swatch is displayed in that line’s margin or elsewhere, having a visual representation of RGB and hex color codes is helpful.

This is how JetBrains’ WebStorm handles that, for example:

Taking that a step further, it would be great if clicking those color swatches would open a color picker. I’ve been using the Firepicker addon to Firebug to achieve similar functionality in-browser for several months now. Try it; you won’t know how you lived without it before.

I haven’t had an opportunity to try it myself yet, but DevExpress’s CodeRush apparently includes an implementation of both those features in the meantime.

Property ordering

Alphabetically sorting CSS properties is considered a best practice by many (including myself), but it’s tedious to manually rearrange properties that fall out of order. It would be great if formatting the document could automate that task, so that this:

.myCssClass { 
  margin: 0 auto; 
  border: 1px solid #000; 
  width: 960px; 
  height: 42px; 
}

Would become this after formatting:

.myCssClass { 
  border: 1px solid #000; 
  height: 42px; 
  margin: 0 auto; 
  width: 960px; 
}

Condensing properties

Similar to property ordering, I’d like to see the editor automatically condense overly verbose style definitions. For example, this:

div { 
  border: 1px 1px 1px 1px solid #000; 
  margin-top: 0; 
  margin-left: auto; 
  margin-right: auto; 
  margin-bottom: 0; 
}

Could be condensed, without changing its effect, to this:

div { 
  border: 1px solid #000; 
  margin: 0 auto; 
}

Respect existing formatting

One thing that nearly CSS editor I’ve used has failed at is respecting existing formatting choices. For example, if a style only includes a single attribute, I usually prefer to use the most compact syntax:

a:hover { color: #444; }

The one-liner is just as readable as the three or four line alternatives, but takes up much less space on the page.

However, once there are several attributes, I prefer to expand the declaration:

a { 
  color: #333; 
  display: inline; 
  text-decoration: underline; 
}

Currently, if I’ve mixed those two formats in the same file, I must avoid allowing the document to be formatting, because it will homogenize the formatting.

Even better would be if I could set a threshold. Styles with less attributes than the threshold would use “compact” formatting and the rest would use “semi-expanded” formatting.

Respect hierarchical indenting

In the same vein as respecting my formatting choices, it would be great if formatting a CSS document would avoid discarding my indentation choices. Indenting CSS declarations based on their “depth” is a great way to improve the readability of CSS, but is unfortunately something that most CSS editors don’t play nice with.

For example, if I have this CSS:

#Container { … }
  #Container a { … }
    #Container a span { … }
    #Container a strong { … }

Visual Studio will flatten it any time the document (or that section) is formatted:

#Container { … }
#Container a { … }
#Container a span { … }
#Container a strong { … }

It would be a great relief if the editor would respect my indentation choices. Currently, my CSS editing experience is overshadowed by the fear of an accidental Format Document.

This would be especially important if alphabetizing properties were added to the automatic formatting. I would ideally like to apply that feature to an entire document or large selection, but couldn’t if it would flatten the document’s indenting at the same time.

Automate hierarchical indenting

While we’re at it, respecting manual indent levels would be nice, but it would be even better if the editor could infer and automate that indenting. For example, let me throw this CSS at it:

#Content { … }
#Content a { … }
#Content a span { … }
#Content blockquote { … }

And have it format it like this:

#Content { … }
  #Content a { … }
    #Content a span { … }
  #Content blockquote { … }

I don’t know how feasible it is to implement that as a general solution, but it would be a phenomenal addition if possible.

JavaScript

These days, I spend at least as much time editing JavaScript as I do editing C#. As the Microsoft <3 jQuery story continues to unfold, I think (hope!) that this will also be the case for an increasing number of other developers using Visual Studio.

However, the JavaScript editor needs some work before it pays proper respect to the growing importance of JavaScript in modern ASP.NET development.

Automatic outlining

If you aren’t familiar with the term, this MSDN page describes outlining in Visual Studio. Automatic outlining is the experience you’re used to in most of the files that Visual Studio edits, like C# and VB.NET, where conditional and structural blocks automatically have outlining applied to them when you open a file.

In Visual Studio 2008, editing a JavaScript file looked like this:

It didn’t have automatic JavaScript outlining, but the hard left margin made the lack of outlines less noticeable.

Here’s the same file in Visual Studio 2010:

Notice how the lack of outlining translates to a lack of a hard left margin in Visual Studio 2010. That’s tough to deal with. At a glance, my code is lost at sea, visually unmoored from the line beginnings at the left.

Looking at how other JavaScript editors display that same code puts this deficiency in stark contrast. Here’s how Notepad++ handles it, for example:

Beyond the obvious outlining in the left margin, I really like how it also drops vertical guidelines directly below each logical block. In fact, Notepad++ strikes an almost perfect balance between visual utility and distracting over-embellishment.

For another perspective, here’s the same code in JetBrains’ WebStorm:

WebStorm’s default may take this all a bit too far by outlining, highlighting, and otherwise accentuating so many different elements of the code. Emphasizing so much of the code diminishes the effect of each individual display hint.

On the bright side, there’s a Visual Studio 2010 extension that adds basic outlining to JavaScript files: JSEnhancements. I’ve been using it for a couple weeks now and it does make a big difference.

Something this basic really should be built-in though. Too many developers will needlessly struggle with this deficiency and never know about the extension (or not be allowed to install it).

Object literal outlining

In addition to offering outlining for logical blocks of code, it might also be helpful to include outlining to condense JavaScript object literals. Common as they are in any jQuery work, support for automatically outlining them may prove useful.

Something like this:

I’m on the fence about the real-world utility of this one, but decided to throw it out there anyway. What do you think?

JavaScript code navigation

The lack of code navigation in and across JavaScript files leaves a lot of room for improvement. I’ve already spent enough time hitting CTRL-F in JavaScript files to last a lifetime.

Probably the most glaring omission is “Go To Definition”, but it’s also a shame that Visual Studio 2010’s fancy new “Navigate To” feature also overlooks JavaScript files.

There’s not a lot to say about this one. What’s missing should be obvious, and it’s a very painful omission for those of us working heavily on the client-side. Improvements will be welcomed.

Parenthesis spacing

Visual Studio 2010 introduced one new formatting behavior that I really don’t understand: a forced space between the function keyword and its opening parenthesis.

For example:

// This: 
function foo() { … }
 
// Becomes this: 
function foo () { … }
 
// This:
function() { … }
 
// Becomes this:
function () { … }

I tried in vain to manually fight against that automatic formatting at first, but eventually gave up. The automatic formatting was being invoked too frequently for me to keep up with it.

Until Visual Studio 2010 started formatting my code that way, I can’t remember having ever seen that style of spacing in JavaScript function declarations. Whatever the motivation for this change, the kicker is that the new behavior isn’t even optional.

Please fix.

Intellisense

I like the idea of JavaScript Intellisense to some extent. The jQuery VSDoc files are a good example of JavaScript code completion that really does offer enhanced discoverability and increased productivity.

However, I’m concerned that the editor is lacking basic features like code navigation because too much effort is being spent on the unattainable goal of perfect code completion in a dynamic language. I hope I’m wrong about that, but it bears mentioning.

As you get acclimated to JavaScript, Intellisense for your own code really isn’t necessary. It can be neat when it works, but fails often enough that you learn not to count on it. Worse, you eventually learn not to trust it.

That’s not so bad anyway. The JavaScript language is not large or complicated; in fact, Crockford boiled it down to the “Good Parts” in less than 150 pages. There is much less need for comprehensive Intellisense when working with a smaller language.

JavaScript Intellisense on external APIs is where Intellisense really shines. Trying to infer what “this” refers to in the anonymous function callback I just wrote? Not so much.

Your turn – Leave a comment with your feedback

People in the position to make these sort of suggestions a reality are reading this and I believe they’re eager to hear your feedback. If you’ve been using Visual Studio 2010 for ASP.NET development, this is a great time to provide constructive criticism and/or your ideas for improvements early enough to make it into 2010 SP1 or v.Next.

Update: When writing this, I assumed that any of these formatting features would be optional if implemented. Just a few more checkboxes in Options > Text Editor > CSS|JS > Formatting.

Considering one of my points in this post was that my paren-spacing cheese got moved without an option to fix it, I probably should have been more clear about that. So to be clear, any of these ideas should only be added as an optional formatting choice, not something that’s forced.