BenCon's WebLog : Web Developer

Good introduction to CSS Properties Window

BenCon — Tue, 13 Dec 2005 23:59:00 GMT

Mikhail has written a great treatise and guided tour of CSS Properties Window that shows what it can do and how it works.

CSS Properties window has shipped!

BenCon — Tue, 13 Dec 2005 01:10:00 GMT

The CSS Properties Window is something that I designed and implemented a lot of before I left the team earlier this year, and I am very glad to announce here that it has shipped:

http://www.asp.net/sandbox/app_sandman.aspx?tabindex=0&tabid=1

A lot of the CSS related feedback that I was getting on my blog was about editing CSS, and making sure that properties were set in the right place. A lot of people stated that they did not want to use inline CSS, but the standard toolset that we shipped does not easily allow you to view or edit styles in linked style sheets.

The CSS Properties Window was designed to help out with this somewhat. Initially I had much larger features in mind, but time for implementing this was limited (it started as a project in my spare time and grew from there). After I left the team Barry Tang took over the project, and he added some more cool features (like intellisense) and got an installer working for the product.

I encourage anybody dealing with CSS in Visual Studio 2005 to follow the link, read about the plug in and install it. I always envisioned this project as being something revolving around customer feedback - that is how it started and that is how I would love it to continue. Part of me wishes I could still be as involved with it as I was, but I have moved on to other things.

Unfortunately we were not able to get this add-in shipped in the main Visual Web Developer box, which is why it is a free download and why it is unsupported. But the folks who work on Visual Web Developer (and I) would love to hear your feedback to help design future versions of the product.

Table editing feedback

BenCon — Sat, 16 Oct 2004 04:07:00 GMT

For lack of anything better to post, I would like to get an idea of what people think of the table editing in the HTML/ASPX designer in whidbey.

I spent a lot of time trying to improve this area. After VS.NET 2003 I rewrote some parts of this code, hoping to create something that was more powerful and easier to use. For example:

Selecting rows and columns is hopefully easier now with the selection widgets that we added.
Selecting cells should be easier now (you can hold down CTRL to get an Excel-style cursor, and selecting text that covers more than one cell automatically selects multiple cells).
All cells (no matter what the spanning) belong to one column and one row. This makes table operations like insertion and deletion more predictable.
Accessibility is improved. You can tab/shift-tab between cells, or arrow around them. Space/esc allow you to move deeper or shallower with nested text areas.
Resizing now shows you a watermark over the column/row/cell being resized, so that you know what you are resizing, and what size is being written there.
You can resize columns and rows through dialogs now, if using the mouse is not to your liking.
Inserting tables should be easier. Specifying whether you want certain attributes is clearer now, and the cell and table properties are separate.
Everything uses CSS now instead of attributes.

We know that people spend a lot of time in tables, because HTML documents are normally very heavy in them. That is why this area got so much attention in Whidbey. Did we go far enough? Do you like the features?

Edit: For some reason two copies of this were put up. Not sure why. The first one was deleted.

Responding to feedback - Auto Position feature has been added to the designer

BenCon — Wed, 29 Sep 2004 00:22:00 GMT

After hearing a lot of support for the idea of automatically positioning controls, I got the go ahead to implement the feature. The fact that we are able to respond to what customers ask for is very encouraging - I hope that this and other examples (such as Mikhail's) will help to create a positive feedback loop where we implement more suggestions, so people are more likely to communicate with us, and therefore we get more data, which allows us to even better implement suggestions, and so on.

Here are some screenshots of the feature - one shot shows the new menu item that allows you to quickly go to the options page where autoposition settings are made. The other shots show you what this new options page looks like.

I hope that this provides good discoverability for users - anybody who positions something the first time will notice that there are options, and if they decide that they want everything positioned from now on they can choose to do so.

What we tried to do with the feature was give back automatic positioning in a similar way to what we had in previous product versions, but to do it in a way that did not go against how CSS works. This feature does not rely on any custom attributes, and it is turned off by default. So if this feature sounds like something that you hate, don't worry, because if you never click the switch in the options then you will never be affected by it. Even if you turn it on it will not generate anything that will not validate (it only uses CSS attributes).

The way that this automatic positioning works is by looking at whatever is pasted/dropped onto the design surface, and automatically doing one of the following (depending on your settings):

Nothing (if you turn the feature off)
Making it absolutely positioned
Making it relatively positioned
Making it statically positioned
Removing all positioning

The setting only affects new stuff that is added to the page (it does not change anything that you already added to the page).

We also added some snapping functionality back. There is still no grid (because CSS has multiple coordinate systems, a grid that did the right thing would have been too costly for us at this stage), but turning on the snapping allows you to still have behavior similar to previous versions where the size/position changes in jumps of 8 pixels (or whatever you set it to). Again, because of time constraints this will only work on elements that have sizes in pixels.

So let me know what you think!

Design view grid is gone

BenCon — Tue, 03 Aug 2004 04:56:00 GMT

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.

To
BenCon — Thu, 06 May 2004 01:23:00 GMT

One of the little things about a HTML editor is the way that block formatting works. Most users probably don't realize when they run into these kinds of problems, but they do.

The reason why editors have a hard time is because they are trying to emulate a word processor with some things. There are simularities between HTML and word processing documents - both have paragraphs, headings, bold, etc. But there are important differences as well. Forcing things too much into a mold with word processors can hurt you.

One thing that we got feedback about, and that I did not like myself, was that VS.NET 2003 always seemed to add <P> tags everywhere. Even if you have a document with just a body in it, if you press enter while in design view, you get a <P> tag. Delete everything, get a <P> tag if you didn't have one.

What I didn't like, and what a lot of other users didn't like, is that they got a <P> tag when they didn't ask for one. It makes sense to split a <P> tag if you actually have one and are inside of it. But if I have no <P> tag, adding one just so there is something to split seems to be thinking a bit too much.

So the way whidbey works is this: If you press enter inside any block format tag (other than DIV) then the block will split around where you pressed enter. If you press enter at the end of some of these tags (like the heading tags) then a new <P> will start.

If you press enter inside of a DIV, or a table cell, or the body, then we insert a <BR>. If you hold down shift+enter, you always get a <BR> no matter where you are.

If you really want a <P> tag, the format dropdown on the formatting toolbar will create one if you are inside of a non-block tag and you select <P> from the list.

I think that this design works better for most people. If you already have paragraph stuff we respect it and handle it. If you never use paragraph formatting we never put it there for you unless you explicitly ask for it.

Feedback wanted - how do you set column widths in your HTML tables?

BenCon — Tue, 13 Apr 2004 06:28:00 GMT

My PM asked this question once in the forums but we did not get many replies - lets see how many we get in the blogs.

How do you set the width of your table columns in HTML tables? Do you:

Set a width on one of the cells in the column and clear the width from all other cells.
Set a width in all of the cells in the column.
Use the <COL> tag.

To put it another way, what would you expect the designer to do if you grabbed the edge of a cell and started dragging? Would you expect:

The cell you grabbed to have the new width written to it.
The cell you grabbed to have the new width written to it, and all other cells in the column to have widths cleared.
All cells in the same column as the cell you grabbed to have the new width written to them.
A <COL> tag is generated for you if it is not there already, all cells in the column have widths cleared, and the <COL> has the new width written to it.
Something else.

Feel free to express multiple preferences rather than pick one.

For example, my preference is to set the width on all cells (Option 2 in the first list), and I expect the editor to keep that or change tables to look like that when I edit them (Option 3 in the second list). Why do I set on all cells? Because I like the redundancy I suppose. But I know other people have other priorities, which is why I ask this question here.

The button tag

BenCon — Sat, 28 Feb 2004 00:43:00 GMT

One of the more interesting tags that I have seen is the <BUTTON> tag. Most people have never seen this, and when they see how whidbey lets you edit them like a normal container, the first instinct is to say "What is up with that?".

Well, these buttons can have content inside them. You can put an image or a table in them if you want to. And this lets you do cool things like this:

<BUTTON>
<TABLE>
<TR><TD><IMG /></TD></TR>
<TR><TD>Button Text</TD></TR>
</TABLE>
</BUTTON>

Isn't this cool? I like it. And rather than typing it out, in whidbey you can just click into an empty <BUTTON>, do insert -> table, and edit everything right there. And <BUTTON> is XHTML compliant, too.

Has anybody out there used these buttons much? What do people think of them?

P.S. This post was written using the Whidbey HTML designer.