What is the problem with Visual Studio.Net's "absolute positioning", and how is that problem fixed by CSS's "absolute positioning"?

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

As a general web development point absolute positioning is frowned upon. It has some rare uses but not many in a good css design.

Visual studio acheived this layout by using inline css styling, but it was still css absolute positioning.

The best way to develop a web layout is to start with the content rendered into valid HTML elements. Then look to improve the layout using CSS by applying proper cascading rules to those elements. Then add classes to individual elements which need to layout differently from the standard elements.

Lastly to add any whizz bang features you can use Javascript like Jquery to visually enhance the look and feel of standard html controls.

This way your site can "degrade gracefully" with browsers which are less capable.

Answer 2

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.