About

I'm Mike Pope. I live in the Seattle area. I've been a technical writer and editor for over 35 years. I'm interested in software, language, music, movies, books, motorcycles, travel, and ... well, lots of stuff.

Read more ...

Blog Search


(Supports AND)

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

Quote

If you have always done it that way, it is probably wrong.

Charles Kettering



Navigation





<April 2025>
SMTWTFS
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Categories

  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  

Contact Me

Email me

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 4/4/2025

Totals
Posts - 2656
Comments - 2678
Hits - 2,735,401

Averages
Entries/day - 0.33
Comments/entry - 1.01
Hits/day - 344

Updated every 30 minutes. Last: 1:11 AM Pacific


  06:09 PM

At PDC2008, Jeff King demonstrated features and improvements that his team is proposing for the next release Visual Web Developer. Among them are lots of tweaks to HTML editing. This got me thinking about my own use of Design view and Source view, and when and why I use each.

From one narrow perspective, the history of the Visual Studio tools for creating Web pages -- starting with Visual InterDev (remember him?) through Visual Studio 2008 SP1 -- has been a history of improving Design view. If you remember that far back, in Visual Studio .NET (for versions 1.0 and 1.1 of ASP.NET), the page you edited in Design view and the page in Source view were related but separate; when you switched views, each view recreated the page from scratch. Lots of people did not like how switching views could hose up your formatting. Plus the editor inserted some Visual Studio-specific (and of course non-standard) attributes into the page to give itself some formatting clues, and that likewise was not popular in certain quarters.

In Visual Studio 2005 and beyond, it was a priority to make sure that when you switch views, Source view formatting is maintained scrupulously. And (AFAIK) thus it is: what you do in Design view is persisted in Source view, and in addition any custom formatting you've done in Source view is retained. We don’t mess with your markup. (Selection is maintained between views as well.)

And yet I spend most of my time in Source view. Partly this is because Source view itself has gotten more and more capable. You can drag from the Toolbox and you can use the Properties window. IntelliSense now works with pretty much everything. You can set options for how the editor formats tags and code.

I thought about it, and here's when I do use Design view:
  • Data binding. Specifically, I use the Design-view wizards to initially configure a data source control. For controls like GridView, if I'm already in Design view, I use the Task Pane to select a data source and set some initial properties (e.g., EnablePaging).


  • Template editing. I'll usually at least start template editing by using the Task Pane menu. I'll generally tweak thereafter in Source view.


  • Control property builders. In GridView or ListView, if I have to create TemplateColumn objects or some other non-default column or item type, I'll use Design-view builders.



  • Previewing pages. Of course, Design view does not provide true WYSIWYG; by default, there's a lot of detritus such as non-visual controls, borders for div element etc.[1] But because the page reflects current CSS settings, it's good for a quick look. For a real preview, tho, I run the page.


  • Creating handlers. I will double-click controls to create skeleton handlers for default events, and I'll often use the Properties window to create a handler for non-default events.



  • Adding a CSS style sheet to a page. It doesn't get any easier than dragging a .css file onto the page.
Here's what I don't use Design view for:
  • Dragging controls around to locate them to absolute x and y coordinates. Two reasons. One is that I rarely use absolute positioning, oops. The second is that I find that it can sometimes be dang hard to select an individual control within, say, nested div elements.


  • Setting most control properties, unless: a) I already happen to be in Design view, or b) I'm dealing with complex properties for which a builder might be handy. Even then, for relatively simple complex properties many times I'll create (e.g.) ListBox items in Source view by hand.



  • Table editing. The table editor in Design view got a big overhaul in Visual Studio 2005, I think it was, and it's much better. Even then, I rarely use it. It never seems to do quite what I want.


  • Setting any kind of attribute on any kind of non-ASP.NET markup. I do pure HTML almost exclusively in Source view.


  • Working with styles. CSS editing facilities made huge progress in Visual Studio 2008. Indeed, if I remember to use the CSS editing windows while I'm in Design view, I'm always impressed. Still, I do CSS in Source view, which has been made easier by IntelliSense.


  • Master pages.

What do you use Design view for? When do you explicitly avoid it?


[1] Configurable, I realize. I haven't set up a macro to allow me to easily switch, tho. (Plus VWD Express doesn't support macros.)

[categories]  

[2] |