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.

They FIXED this in CS4 Comm Dist.

When creating a new style and an external stylesheet the file is named as untitled.css, instead of the name provided in the save stylesheet as dilog box. The “URL” field appears to ignore the name provided by the author in the “Save As” field. Thankfully the untitled.css is used for both the saving of the file, and the link created in the HEAD of the document.

When I click on the “URL” field, it actually puts my ”Save As” field back to untitled. 

Current Workaround: If you have your site cache enabled in the Dw Site Definition, you can use its update feature to change the name of the file in the files palette. or you can manually change the file name and the path in the HEAD of your document.

Also found, through my students, that you can supply the name of the file in the URL field, and it should update the save name and save it properly. Still buggy, and needs to 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.

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.

They fixed this in CS4 Comm. Dist. Yay!!!!!

Since CS3 this window will popup for the primary browser if you use the shortcut method (command + f12), even if you check the box that says “Don’t show me this message again.” Option + f12 work fine for the secondary browser forcing me to swap my primary with the secondary (workflow).

This is perhaps more of an annoyance than a bug, but should be resolved.

They Fixed this in CS4 Comm. Dist. Yay!!!!

Pasting and saving untitled.xxx
I love the idea behind the new pasting images (roundtrip) feature with “save for web” compression options. However, when you paste from the clipboard and create a file name and press save Dreamweaver generates “untitled.xxx” instead of the suggested name.

Uses the same name and writes over
What is nice is that it consistently uses the untitled.xxx name, so a change in the file name using Dw site cache will fix the image and the link. But if you do not change the file name and then try to paste a new image, it will write over the original untitled.xxx file.

Why it should be fixed?
So that we do not lose work from overwritten files, and to speed up productivity. If I am writing a tutorial with screenshots, for example,  it takes a lot of time to paste a series of images in by following the above fix method.

Workaround
Appears that you can supply the name in the “URL:” field (instead of the “Save as” field), and it will save the file properly. 

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.