This responds the same as before in CS4 Commercial version.

In the latest version of Dw CS4, they have introduced relative file management (Related Files). Breadcrumbs style links that show which pages are being used for quick and easy access. This is a great feature, but has added an obstacle during development.

In the Dw preferences there is a check box to open CSS file when modified. With this unchecked, the changes should be saved to the file right away.  The downside to this is a loss of the history of changes for multiple undos. But this speeds up productivity tremendously and ensures you do not have any unsaved css files remaining in the background when you test in the web browsers.

With the new Related Files bar feature, and that check box turned off, the file remains open and unsaved. When using the preview in browser command, it does not ask to save the changes to the file. You have to manually click on the css relative file or choose the “save all files” before previewing.

In a normal workflow I like to be able to see my changes on the fly, without having to perform a save all, or go to the file and save. 

My suggestion would be to offer this as part of the preferences. The open CSS when modified, I believe, was intended for this workflow. Dreamweaver is essentially opening, writing, saving, and closing the file in the background when this is checked. So it does not seem like it would be much of a leap to have dreamweaver automatically save the file when you have finished making changes in the CSS dialog editor. Perhaps Dw would offer the following preference/checkboxes instead.

• Save externally linked CSS files after each edit in the CSS Palette

This would only include css files that were modified but not currently open or included in the relative files bar. If the CSS file was open as a stand alone edit, it would remain unsaved as expected.

It would be great to be able to select a series of css selectors and duplicate them. I do not know how many times I have written:

• #id a:link, #id a:visited {}
• #id a:visited, #id a:active {}

This pattern shows up in several modular sections of each site I build. To be able to select both selectors, duplicate, and modify their names would be a real time saver.

Current workaround: Either duplicate one at a time, or copy and paste from code view. Surprisingly, Option + click and drag works on multiple selections, sweet.

Still responds the same in CS4 Comm. Dist.

When using the Duplicate style command Dw places the duplicate at the bottom of the css. While this is not such a big deal when you have 3-4 selectors, when you have a large site it can get lost in the mix. organization of selector order it extremely useful for managing the styles.

When creating a new CSS rule (dialog), it places the new selector under whatever selector you have selected. This is great, and should preform the same way when you create a duplicate.

Current Workaround: Option + Click and Drag the selector puts it where ever you want, works on multiple selections too. Copy and paste from within the code.

I love that when you paste an image you can optimize and save the image. However, the process is very time consuming when you are trying to add a series of images. For example, if I am creating a Dreamweaver tutorial most of the screen grabs are going to be of the same default file type and quality (e.g. jpeg 80%).

I would love to see Adobe add a paste image with default compression, folder, and serialized options. Kind of like a paste special, that we can assign to a shortcut key. It would also make sense for the defaults and serialized naming conventions to be configured in the site definition profile, as it would be a site by site change.

This feature request would also require that the untitled.xxx bug be fixed.

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.

There have been several times that I have been working on a series of files and wished that I could publish all currently open files. This would be a major time saver for revisions and regular workflow.

Just like the FTP all open documents, it would be great to preview all open files in a web browser of my choosing.

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.