My request is to simplify the “New CSS Rule“ dialog box (see picture below) into 1 selector field without radio choices or drop downs.

It Confuses, Rather than Helps, the Newbie
I believe the original intent of the CSS creation dialog box was to teach or inform the user that they have selector choices. The problem here is that it seems to confuse the newbie more than it helps. 

HTML Tag Selector Drop Down
Some may argue that this is a nice feature, and one reason to keep the radio button choices. However, this feature quickly loses its flavor  once the user is overwhelmed by the number of tags. Its much easier to simply write the tag in manually. I understand the argument for a WYSIWYG program where the user does not need to know HTML, however, this drop down still requires them to choose the appropriate tag.

I think the suggested selectors that Dreamweaver supplies is enough, and with the addition of the make “More Specific” and “Less Specific,” (Dw v10 CS4 Beta) there is no end to how this can help the novice. 

Gets in the Way of the Professional
Once someone knows how to create and manage CSS, there is no need for these training wheels. In fact, they get in the way of production. I do not know how many times that Dw has chosen the last default radio button and I wrote some advanced selector only to be told that classes must begin with a period, or some other warning. 

There is a Workaround
You can always keep the Advanced radio button selected and Dw will let you write any selector. This still requires that you check to ensure that radio button is selected when generating a new CSS. 

Suggested Fix
Perhaps, at the very least, these training wheels can be turned off in preferences (like an advanced editing settings choice or something similar). Personally I think that anyone venturing into creating CSS through this dialog box will only need a single field where they can type whatever they desire. A help button in the dialog box could take them to the help pages regarding CSS creation in Dw. 

As it stands, there will always be a learning curve regarding CSS implementation. And Dreamweaver is not responsible for teaching this through its features, but rather its help menus. I do realize this is a balancing act, since Dreamweaver is also meant to do it ALL for the designer. But the current option does not help, but hinders the user, even if it is a good intention.

Still not working in CS4 commercial distribution. At least it still lets me close out of all open files and test the frameset. But you have to tell it to stop warning you, and test locally. Its a workaround. Testing frames should be possible from all angles.

I am at a loss on wether this should be part of my wish list, or a bug. When setting up a testing server (PHP & MySQL), Dreamweaver does not allow the previewing of Frames with the URL prefix.

Whenever I am teaching about testing servers this really throws the student for a loop. Not only are they trying to wrap their head around the idea of a testing server, but struggling to know why the lights do not turn on. If you press ignore, or publish it fails to add the URL testing Server prefix and the student ends up seeing the plain text instead of the resulting PHP page.

I have yet to understand why the Dw developers do not allow the author to preview frames on a testing server. I imagine because framesets rely on multiple files that would need to be published to the testing server to work, however, isn’t this the role of publishing dependent files?

Workaround
I have found that if you tell Dreamweaver to stop warning you about this you can get the frameset to preview in the web browser. However, you must close out of all open files and preview the file from the Files palette. I think that dreamweaver does not check to see that it is indeed a frameset file if the file has not already been opened.

This has been fixed. Yay!!!! It still does not resolve the unix colon at the end of the path, but it does something upon save of site definition. It is kind of odd how it writes the path now. When saved it uses the URL path folder/folder/file.php instead of the unix colons. But, if you browse for the folder it uses the unix colons. Upon selecting the folder, it still does not add the ending colon on the path. But, now when its saved (even without the ending colon) it still points to the testing server properly. I am happy as long as it works.

This has been an obstacle ever since I started using PHP & MySQL around Studio MX. When selecting a folder using the browse feature by clicking on the folder icon, Dreamweaver fails to add the UNIX colon on the end of the path. Works fine in the local category, but not the testing server. If the author is unaware of this, every time he/she goes to preview a file on the testing server, Dreamweaver will end up generating files and folders outside of the intended directory. Relative files may not be published, and things may appear broken when they are not.

If you are ware of this problem you can simply add the colon on the end. If you are new to testing servers this can really add to the confusion, not to mention generate files and folders that were never intended in the first place.

This was one of the first things I tested in the beta release of Dw 10, and it still has not been resolved.