Frustrated with the Visual Studio HTML Editor changing your HTML

Generally, one of the first questions I get when I tell people I work on Visual Studio is "Why does it keep changing my HTML?" Well, that's the less colorful version of the question.

Mikhail Arkhipov posted the best public explination of this "feature" I've seen to date. Worth the read if you have this complaint with our editor.

Why VS 2003 keeps changing your HTML and what you can (and cannot) do to it.

Comments (17)
  1. Scott says:

    Yeah but he dances around my bug ( and doles out typical developer excuses.

    "May be a bug or, as I said, it might be one of the cases which is not covered in the VS 2003 and earlier formatting preservation. Strictly speaking, if one has to write a bunch of new code to fix an issue, it is dfficult to qualify it as a bug 🙁 "

    I know typical developer excuses when I see one, I am a typical developer. 🙂 I don’t care if you guys want to log it as a "bug" in your system or not as long as it gets fixed. Otherwise I’m not going to use the HTML designer to write HTML and I’ll advise others not to as well.

  2. Todd Spatafore says:

    Wait, that’s the public explination, does that imply that there’s a private explination?

  3. jledgard says:

    Poor word choice on my part. I have heard it discussed internally a bunch. What happened, internally, with this question, is whenever you see someone who works on you ask them "hey, why do people bitch at me because of your editor and when are you going to fix it". I guess I should say this was simply the best explanation I’ve heard.

  4. the designer doesn’t perform how ANYONE would like it and "don’t use it" is an extremely over-simplification of things, as is "if it’s a lot of work, we’ll pretend it’s not a bug". I wouldn’t call that "typical developer" thinking. That’s the thinking of someone who has gotten in over their head and now has to think of a way out of producing the promised product.

  5. jledgard says:

    Shannon: I think your comments might be a tad harsh. I was merely echoing Todds comment. Customers have choices when it comes to developer tools. I don’t think anyone would argue there are not bugs in the HTML editor in VS 2003/2002. I think your quote takes Mikhail out of context a bit. I don’t think he is implying that if a bug takes a lot of work to fix it’s not a bug. All that said, I would love to know what you think of Whidbey?

  6. jledgard says:

    Scott: I agree with your sentiment. If the product doesn’t perform how you like don’t use it. Have you been able to try out the whidbey alpha or tech preview? If so have we improved?

  7. I think my comments were at least a few degrees less harsh than this known bug deserves. I won’t argue over the validity of anyone’s claim that ASP.NET development should/can be done without VS.NET, sure, it’s possible, but so are a lot of things I hope to never have to do.

    And I don’t think that Mikhail’s quote can be taken out of context unless he stated his thoughts incorrectly. Of course, that lack of editor is a problem with blogs. It is entirely possible that he didn’t mean what he said, it has happened to me many times and surely will happen again. But the context is clear, I think. Are you saying that his reasoning makes it okay that this bug was not fixed with VS.Net 1.1? If not, then it is nothing more than making excuses for why the product was shipped before a huge bug from the previous version was not fixed. I find it hard to simply call it a "bug" myself, since it seems so close to the "showstopper" level of broken functionality.

    As for Whidbey, I have seen it demoed (badly, as the presented repeated "it’s only alpha code" over and over during hangs and crashes) at DevDays, have read about it, and have a copy on my desk, but haven’t installed and don’t have a time frame set for an install. I’m guessing in 6 months to a year, I’ll have an answer for you.

    [why are these comments out of order? the comment I referred to originally is after your response to me]

  8. Folks, when I said ‘it is a bunch of new code and may not qualify as bug’ I merely meant that Sustained Engineering team may not accept it because amount of changes involved and amount of testing requred is far beyond what they typically are handling. Therefore people will have to be pulled from teams which are working on Whidbey. Surely I expess your concern to my management. This is not a decision me or even my boss can to make since it is well beyound our chain of command.

    I feel that Whidbey Beta 1 should be reasonably good. I think we ironed out multithreading issues, so give it a shot, please.

  9. Michael Cook says:

    "I feel that Whidbey Beta 1 should be reasonably good."

    How does a Beta product which doesn’t have an official release date (to my knowledge) help us? It works? Great! I can’t use it for 6-? months! What are we supposed to do till then? How do we get back the lost hours of fixing code the designer mangled?

    All of that is besides the fact that I shouldn’t have to buy a completely new product to get a bug fix. I don’t care how much code it takes to fix it, it’s still you’re job to deliver a product that works as advertised.

    I posted some comments on Mikhail’s original explanation here

  10. Mikhail, if this bug were dealt with at the right time, the devs would not have been on Whidbey yet. This should have been fixed in Everette. I think it probably should have been fixed before VS.NET 1.0 was released.

    If you are saying that this issue has never been marked as a bug and that you would be submitting it to Sustained Engineering (whatever that is) for the first time, then there is no valid excuse for that. If you’re saying it has been repeatedly submitted and rejected since 2001, then I think I understand.

    MS has a long history of not releasing a "real" 1.0 release until the third version, so I guess Whidbey is the third version so this may be accepted best practice there.

  11. Cool. I didn’t realize that .Text keywords worked in comments.

  12. jledgard says:

    The comments are out of order because I deleted one of my own comments because of embarrassing spelling/grammar. (The content is the same.)

    I hear your frustration. (And the frustration of everyone else who chooses this question to ask me first.) It’s something we hope to get right in the next release. We can apply some pressure on the service pack train, but I do doubt that they will take a change of the magnitude required to fix this bug at this point.

    I, unfortunately, can’t offer you a great solution. In this case we clearly suck and I apologize.

  13. Scott says:

    re: Whidbey beta.

    I’ve only been able to play with the PDC bits but I haven’t been able to reproduce my problem. It appears to, finally, just leave the code alone. Choosing to warn me with a red squiggley line, which is fine. Great! 🙂

    Mikhail: understood but realize that not everyone knows how the bug resolution works inside of Microsoft or what teams are involved with what aspects of fixing bugs. Heck, the last time I knew anything about bug resolution inside Microsoft the bug tracking software was called "Raid" and I think it was Access based. I’m sure it’s all changed since then. 🙂

  14. Michael Cook says:

    "MS has a long history of not releasing a "real" 1.0 release until the third version, so I guess Whidbey is the third version so this may be accepted best practice there. "

    The thing is, Visual Studio is such a great platform for application and class development that the web side of things feels really unpolished, which is a shame because is an excellent web development platform and is really well rounded for being first gen.

  15. Absolutely. Like I said, I don’t plan on using any other tool for ASP.NET dev any time soon. But I also don’t think you can call Everette nor .NET 1.1 "first generation".

    And if ASP.NET is rough in VS.NET, that says a lot since most people who compare WebForms and WinForms (that I have read/spoken to) say that WinForms got the short end of the stick. Here is a quote from an MS Press book (Programming Microsoft .NET, Jeff Prosise. Chapter 4: Windows Forms. First Sentence) "The Microsoft .NET Framework is chiefly a platform for writing Web applications and Web services, but it supports other programming models as well."

    I can’t comment on it myself because I am 80% WebForms at this point so I am more than a little biased.

    From what I’ve read, most if not all of my gripes are gone in Whidbey. Please don’t introduce more. If you can’t make a feature work, just leave it out.

Comments are closed.

Skip to main content