Question

For years, Visual Studio.NET has offered “absolute positioning” for ASP.NET, whereby you can drag controls onto the designer canvas wherever you want them to be. However, there has always been strong advice not to use that feature. Instead, the common wisdom said you should use “Flow layout”, because if you were to use VS.NET’s “absolute positioning”, your screen would not render correctly for users whose screen resolution was different from yours.

However, that’s old advice. A while back, CSS came out with the ability to perform “absolute positioning” in a standards-compliant way, and most or all browsers caught up with CSS and have implemented CSS positioning correctly (or well enough at least).

So the current recommended practice is to position elements using CSS absolute positioning.

Question is: What is it that CSS does correctly about absolute positioning, that Visual Studio does wrongly? How can CSS absolute positioning be OK even for users who have different screen resolutions, while Visual Studio.NET cannot?

UPDATE: The responses here have cleared the matter up for me. Here’s how I summarize it:

1. Ages ago, VS.NET defaulted to using
   absolute positioning for everything.
   This is how VB worked from its
   beginning (meaning, Windows apps
   before the web even existed), and
   VS.NET was made to feel similar to
   VB.
2. However, using absolute positioning
   for everything on a web page is a
   very bad idea. See one of the
   responses below for some concrete
   examples of why.
3. Since using absolute positioning for
   every single control on a web app
   page is such a bad idea, all that
   advice about using “Flow layout”
   sprung up. It was a way of working
   with VS.NET without absolutely
   positioning everything.
4. Now that CSS is so mature and widely
   supported, and is the preferred
   mechanism for positioning and
   appearance, it is STILL CRAZY to
   absolutely position everything, and
   for the same reasons. Most items
   should be allowed to position
   themselves “in the flow”. However,
   for some elements here and there,
   absolute CSS positioning might make
   sense.
5. The mechanism VS.NET has always used
   to perform absolute positioning is
   actually inline CSS styles.

Great to have all this cleared up. Thanks.

Answer 1

Absolutely positioning all of the elements by default — as Visual Studio used to — do is a terrible way to design a site. It was a bad idea then, and it still is now.

The issue with absolutely positioning has nothing to do with standards or rendering correctly in browsers (IE5 an NN4 both supported CSS absolute positioning, which was what Visual Studio.NET used to position elements).

The problem with Visual Studio’s approach was that it stripped out all of the power and elegance of HTML and CSS for the convenience of having a drag-and-drop interface. It was designed to allow developers who didn’t know any HTML or CSS to develop web apps.

Even trivial changes in HTML/CSS become a nightmare when all of your elements are absolutely positioned. Some of my specific gripes:

• The general alignment shuffle — Whenever adding, removing, or resizing an element you had to manually make sure all of the controls were still evenly spaced and that controls didn’t overlap. If they did… you just lost the next five minutes of your life to the general alignment shuffle. Nudging controls into place and making sure that everything lined up.
• Select-all and move — If the new company logo was 10px taller then the previous one you would end up selecting all of your controls and moving them down 10px… but wait… you somehow managed to miss that one control. Another five minute penalty as you wrangle that control into place.
• Dynamic content hell — You placed the description box right below the title… which works most of the time. But now the title has wrapped and is overlapping with the description @#$#%. God forbid you should actually attempt any page with a large amount of dynamic content.

Absolutely positioning a few of your elements isn’t bad, but unless you’re porting a VB6 app to a webform, there’s no reason to absolutely position all of them.