Udostępnij za pośrednictwem

Design view grid is gone

  • Artykuł

Today we cut a couple of options from the product, but we felt that the ramifications of these cuts warranted talking to the community about it and letting people know about it. I will explain why we decided to do it and talk a little bit about the surrounding area. We want to see what customers think.

The features cut were two options (which are also menu commands). These are "Snap to Grid" and "Show Grid". Along with this the option for setting the grid size also had to go (obviously). What these controlled was showing a grid of a predefined resolution rendering over the top of a document and whether or not this grid affected resizing and moving of controls.

The reason why we cut these features is because they do not mesh well with the philosophy of CSS. CSS has multiple units of measurement, and allows for the resetting of the positioning origin. CSS also allows the use of right and bottom to position objects as well as left and top. Having a grid drawn relative to the top left of the body, in only one unit (pixels), was not working well with CSS.

As you may have noticed, we have changed the CSS positioning model somewhat in Whidbey. I was behind that - what I wanted to do was to create a way of doing CSS positioning that was easy to use, but outputted HTML that was standards compliant. VS7 and VS7.1 output various attributes that are not part of any W3C schema, and they force you to create containers that only hold either text or positioned entities. They did this because at the time we wanted to create an environment comfortable for people used to form designers, and form designers typically have grids and grid snapping.

Rather than try to fit a square peg into a round hole, I made the call to get rid of these features so that we could fix some bugs and get things working with more compliance. This is not a case of us not caring about people who use CSS positioning - this is a case of us wanting to do CSS positioning in a standards compliant way. After I have made the most recent changes, here are some of the positive differences that Whidbey will offer over previous versions:

  • Preservation of units when resizing, moving or formatting controls. Some formatting commands (such as align left) will sometimes modify units on some controls in order to do their job. For example, to align everything to a control with left:30px, other controls need to be set to left:30px. But in general, units are not changed unless absolutely necessary.
  • If you are resizing in only one dimension, then the other dimension will not be touched at all. For example, if you grab the width resize handle of a control and resize, then a height value will not be written there or modified. This makes a difference when editing data controls, because some of them you don’t want to have height but you do want width.
  • We preserve what attributes you use to position controls. If you use bottom and right to position something, then you can move it, resize it, even use formatting commands on it. If it is possible to preserve what attribute you used then we will.
  • We will respect RTL and LTR conventions. If you are in RTL flow and you position something, we use right instead of left to create a position.

Overall, the driving philosophy behind these changes was quality and standards adherence. With the time that we have before shipping, the grid features could not be made to fit into this philosophy, so we cut them.

One thing that some people have mentioned on www.asp.net is that we no longer allow you to automatically position controls, and indeed we do not. This is because we no longer have grid areas like we used to, and they use to let us infer that you wanted positioning on something. If you want autopositioning, let us know. If there is enough demand for it we will figure out a way to put it into the product.

Please let me know whether you like or dislike these changes. I am writing this posting because we care what people think about this, and we want to do the right thing for people who use the product.

Comments

  • Anonymous
    August 02, 2004
    The comment has been removed

  • Anonymous
    August 02, 2004
    I'd also vote for keeping auto-positioning. Yes CSS is more flexible than (somewhat) static grid size, but the convenience offerred by grid-layout is definitely worth keeping especially in an intranet environment where IE is the standard.

  • Anonymous
    August 02, 2004
    There are ways of doing auto positioning without having a grid. If we do add an auto positioning feature (and I am not promising anything here) then it will not bring back any grid snapping features.

  • Anonymous
    August 02, 2004
    I think this is kind of sad ... Grid style positionning was one of the features that made the difference.

    I'd rather like to have the option between a standard compliant mode for internet dev and a grid base IE only mode for intranet, inhouse applications that need to be done quickly.

    I guess if you chose to cut one for the other you always end up hurting one segment of your users.

  • Anonymous
    August 02, 2004
    I think this is a good move. The grid bugs me. Sounds like other people like autopositioning - I'm interested in they ways of autopositioning without the grid that you aren't promising. ;)

  • Anonymous
    August 02, 2004
    Good riddance! People need to quit trying to force Windows designs onto the Web. While most browsers do allow for absolute position now, it is not something that should be the default used by those who just don't know better. Designers should really have a good reason to force any absolute position scheme on web users, and in such cases you still do support it, and even better than before since the new standards compliance will make it far easier for those with accessibility issues to work with such pages. In the meantime, these developers that are still used to the grid model need to go back and look at why web users do NOT want it. The flow model not only far better supports accessibility, but it also better supports different browsers, different screen resolutions, different sizing of the browser window, different browser settings (like font size and color preferences), and things like easier templating/skinning, etc. I've heard all the arguments for the grid layout, and they always come down to what someone making decisions is comfortable with since they themselves have never explored all the other rich options provided by browsers. It reminds me of a boss I had that made me go through ridiculous hoops to center the title of all windows when Window 95 first came out simply because he was used to them being centered in Windows 3.1. :)

  • Anonymous
    August 03, 2004
    Keep it... great for rapid design

  • Anonymous
    August 03, 2004
    I definetly think that absolute positioning has its place, but an easy way to define which one is important too. Also standard compliance is important as well.

    How about the Overall page defaults to flow layout (we still have the DIV elements that allowed for absolute and flow positioning) with a selection like we had before? The grid thing is not really necessary, but the option like before is good.

  • Anonymous
    August 05, 2004
    I prefer flow layout. If I want to absoultely position something, I'd use the appropriate css attributes.

    Besides which, I've never been a fan of fixed width; fixed position controls etc can make going from one screen size to another a nightmare in scrolling!

  • Anonymous
    August 19, 2004
    While the CSS compatibility issue is important for some (or many), it is not critical for others (often within an intranet). I would hope that the "Option" to do grid layout with the convenience of 7.0 and 7.1 would be added back to the product. It does not have to be the default but make it an easy option for those who prefer it.

    bill burrows

  • Anonymous
    July 30, 2006
    I surely do miss autopositioning.
    It was great.
    Is there a tool that can do such a job ? [bencon: If you want things to be positioned when adding from the toolbox, then please see this post]

  • Anonymous
    August 16, 2006
    Grid layout and snapping to grid should absolutely still be an option, although maybe not the default. For quick development on an intranet, where the standard and target browser is IE, snapping to grid made it easy. Especially when building for users who do not care what the design is. [BenCon] - I have not worked on the web design aspect of things for quite a while now. My old boss still does though, and if you look at his blog (http://blogs.msdn.com/mikhailarkhipov) you can see what is happening with the products and make suggestions right at the source).

  • Anonymous
    October 29, 2006
    I agree with Tom. For me having a grid layout is aboslutely great and robust the designing part. I was so surprised when I heard you guys did that....please put it back!!!