> It did - but the "different HTML" you refer to was HTML4 for IE5.5+ or HTML3 to browsers it didn't recognize. Even by 2001 that was a bad idea, and by 2004 Firefox was leagues ahead of IE6's support for HTML and CSS features yet ASP.NET WebForms defaults to rendering HTML3-era HTML to Firefox.
Intranet sites were run on highly locked down machines that were running IE. Don't pretend everyone was running their own browser on their machine. As I said it was intended for intranet sites, all the documentation and all the examples at the time clearly showed these user cases.
> ...and don't forget all of the problems inherent in user-agent sniffing. Users with too many third-party IE toolbars or shovelware on their computers would see things break (because said third-party software would frequently alter IE's default user-agent string to add their own product-names, which broke things).
So they were running third party things and it broke something else that had no knowledge of them. If someone runs hundreds of chrome extensions and it breaks my site, I wouldn't bother supporting them either. The situation isn't any different.
> It was a huge concern because it meant that web-application code could not be run by automated testing tools! That was one of the design-objectives when OWIN was introduced: for greater testability (for unit and integration testing). Otherwise the only way to test WebForms applications was by having a dedicated web-testing farm with web-browsers open on the desktop driven by custom-written automation tools - that just wasn't an option for smaller shops. And Visual Studio didn't add built-in unit testing support until 2005 (only for Enterprise edition), and 2008 (or 2010?) for everybody else.
Almost none of the shops were doing automated testing at the time. People barely do it now in the .NET space.
>Another problem was that in the days of WebForms 1.x (before .NET 2.0) the only way to run ASP.NET applications, even for development, was by having IIS installed - but IIS was not available for Windows XP Home Edition (ASP.NET 2.0 introduced the "Cassini" local development web-server, but it was severely lacking and did not faithfully recreate the IIS environment, and IIS Express wasn't introduced until around 2008). People doing hobbyist development at home had to either pay to upgrade to Windows XP Professional (to use the rather limited IIS "5.1") or apply a variety of crude registry hacks to trick the Windows 2000-era IIS 5.0 to run on Windows XP Home Edition.
So on an operating system that was intended for consumer use, they couldn't use advanced stuff like IIS that the home user wouldn't have any use for? Seriously?
> What works "quite well" is subjective. ViewState just doesn't scale and is unsuitable for public Internet websites because it balloons the rendered page-size (e.g. if you have an , used as-directed such that it's only loaded on the initial page laod) then the entire data-grid's data is persisted in ViewState, which practically quadruples your rendered page-size (due to all the hidden control state) - which was unacceptable in the days when 56K modem use was still widespread (even through to ~2006+). Disabling ViewState was essential for any public web-pages, which increased the amount of work required to get things to _just work_. I could go on...
None of this was intended for sites on the internet. I was specifically talking about the RAD tooling. Yet you seem to be talking about things it was never intended to do at the time.