F1R57 P057!!!!!

So I finally got around to making a blog. One of my friends tells me that this is a big responsibility, because apparently people do not like it when the blog is not updated often enough. I will endeavor for that not to be the case with me.

So what do I do? I am the person who works on the design view portion of the HTML/Webforms designer in Visual Studio. Right now we are coding up a storm for the Whidbey release, and everybody is excited about how cool the new version will be. As time goes on I will be writing articles about new and existing features in our product, and how they compare with other products. I love hearing feedback from real users about our product. If you have a suggestion or a gripe, please tell me about it. I may not do exactly as you ask, but your input will help shape what direction we go in, and I do take the input seriously.

Comments (6)

  1. Anonymous says:

    The main reasons I can’t/don’t use the design mode:

    – Can’t generate XHTML 1.1 Strict code

    – Can’t preserve formatting/indenting

    – Style is all barfed up inline instead of set into style elements.

    (please please please) ^ 32 focus on these. Some of these are at least partially the framework’s fault but some is the designer too. Clean/maintainable code is 1,000,000 times more important to our staff and our clients than whizzybang features. Thanks.

    Personally i’d like to see a <asp:Style> control that all controls set any appropriate display data in, instead of inline. This would work similar to the ValidationSummary control where other controls just kinda know about it without a specific reference.

  2. Anonymous says:

    Can you give some examples of where we generate non-XHTML 1.1 code in the designer? This would help. We have been working on XHTML generation.

    The formatting/indenting issue has been worked on. You will be pleased to see what has been done with this in Whidbey.

    Can you elaborate on the style element issue? Are you saying that whenever a style is applied to an element, a style element should be made instead of doing inline?

  3. Anonymous says:

    for example, if i am designing a form in gridmode, and i set the positions on a panel by dragging around, have those set in a <style> element instead of inline. this would be based on the id of the conrol so if the panel ID is "pnlContent" then in the <style> have

    #pnlContent {

    position: absolute;

    top: 200px;

    left: 200px;


    then the next step is if i have pnlContent at left: 200px, top: 200px; and pnlHeader at left: 200px, top: 0px, the generated style should be:

    #pnlContent, #pnlHeader {

    position: absolute;

    left: 200px;


    #pnlContent {

    top: 200px;


    #pnlHeader {

    top: 0px;


    … if you made it do this i’d be your best friend. 🙂

    also, here’s another gripe, but maybe not quite your area… the vs_targetschema meta tag… required on every page that i want decent intellisense on is a pain, plus the default insert doesn’t put quotes around the name attribute.

  4. Anonymous says:

    First let me say, thanks for giving some feedback.

    I see what you mean now. The devil with a feature like this is in the details. If we changed the product to always do this, some people would not like it. This needs to be based on user preferences.

    Then there is the question of what to do with existing inline styles – do we move them into a style block, or do we just add new stuff to the style block?

    And with your example above, what happens if the user grabs the content panel and moves it around? What I would expect is for the content panel to move and for the header to only change its left attribute. But what would other people want?

    I agree that this would be a really cool feature and a big time saver for people working on CSS rich pages. But if the details of this were not done right it could make things worse, I think.

    One thing I was wondering was if people would like a command in VS for moving inline styles into a style block in design view. Having this, and having the designer leave CSS where it found it would bring things most of the way to what you want, would it not?

  5. Anonymous says:

    BTW – I should clarify that the other two items on your list (XHTML1.1 generation and not mangling your code) are definitely done in Whidbey. I encourage you to try out the Beta when it comes out to see how much of a difference this makes.

    What do you mean about the quote generation? There is an option for generating quotes on new content in Whidbey, and the vs_intellisense attribute is not required any more – the schema is one of the settings in tools -> options and applies to all pages. This sounds like it will fix your problem.

  6. Anonymous says:

    I am already frothing at the mouth in anticipation of the beta. I will be on the beta the day it is released like a pack of rabid dogs. I have even considered installing the alpha but have decided to hold off since I figure there will be significant changes between the alpha and the beta.

    In regards to the command to move inline CSS styles to a style block… sounds cool! It would almost be like refactoring for HTML/CSS. Would be nice in this regard: I’m designing a page lazily adding the style inline since its faster to type it there than to jump to the top of my page and add it but then when i’m all done I can hit a button and whizz-zing it up to the <style> element auto-magically.

    I guess it would probably only be able to do it on elements with an ID or class defined but that’s cool, as most of the times I’d use this feature, I would have IDs on the appropriate element.

    Added coolness would be if when pressing this "CSS Refactor" button it would give me the option of putting the style in the head of the current document or to put it in an external css doc in the project.

    PS: Last I heard the beta is slated for a "Spring 2004" release. Has the release date been refined at all? Are we talking March/April or May/June?

Skip to main content