View > Style Rendering > Display Styles
This allows you to quickly view the semantic structure of a page. It's also helpful when marking up or editing content inside elements that are not accessible in Design View for whatever reason.
Originally, this setting persisted until changed. But, many users turned off this setting without knowing what it was, and later would go crazy trying to figure out why their styles weren't rendering. So starting in CS4, this setting is always reset to ON when DW is restarted (which is a natural action to take when things don't make sense).
You can change it to default to OFF as follows:
1. Place the following code in a file called myStartup.htm :
<html> <head> <script language="JavaScript"> dw.cssStylePalette.setDisplayStyles(false); </script> </head> <body> </body> </html>
2. Place a copy of this file in the Configuration/Startup folder so that it gets executed every time you start DW.
Notice that I gave it a generic name in case you want to add any other commands to be executed at every startup.
]]>The exception to this is that background colors are not printed. Code printing recognizes the "Syntax Coloring" Code View setting in the:
View > Code View Options
menu for turning off coloring.
The "Line Numbers" setting is also recognized when printing.
First of all, read this excellent article by Garrett Dimon (that I found on John Nack's blog) about suggestions for making feature requests. As someone who regularly reads Feature Requests, this article hit the mark on every point.
Then use the Adobe Feature Request Form to submit your request to the appropriate Adobe product team.
Thank you in advance for keeping the great feedback coming!
http://www.youtube.com/view_play_list?p=D46F0582FED3D64E
And yes, this decision was directly geared toward those of you who might be shying away from Adobe TV.
Have fun!
]]>http://tv.adobe.com/#pd+Dreamweaver
Use the settings on the right to narrow down the list for your interests according to Release (CS3, CS4, Other), Skill Level (Beginner, Intermediate, Advanced), and Topics (Tutorials, Demos, Tips and Tricks, and Inspiration).
Also, use the dropdown list at the top to sort the videos By Date, Alphabetically, Highest Rated, or Most Popular to help sift through the list.
We wanted to finish up the form validation widgets that we started in CS3. So for this version we added:
-Spry Validation Password
-Spry Validation Confirm
-Spry Validation Radio Group
We now provide form validation for all the main input types.
The Password widget works in conjunction with a password text field.
This widget if for users that are creating a new password and you want to ensure that it is following the strength rules.
You can use the widget to specify:
-Min and Max characters
-Min and Max numbers or letters
-Min and Max special characters
-Min and Max upper case letters.
The Password Confirm widget is used in the scenario where you have the user enter the password twice to confirm the first one.
Simply bind the Confirm widget to another text entry field and it will validate that they are equal.
The Radio Group rounds out the form widgets by allowing users to validation a radio group. The widget determines if the field is required and can check for empty and/or invalid values.
The last Spry widget we added is the Spry Tooltip. This allows users to add a tooltip to any element on the page.
We add a hook to the 'trigger' and then provide a DIV in which developers can add any content they want to act as a tooltip. The dev can then specify where and when the tooltip shows and can edit the default style sheet to tweak the appearance.
The one hidden thing about this feature is a menu item to hide and show the tooltips. Since they show by default for editing, it will get in the way of the basic design.
You can go to View > Show Spry Tooltips to show and hide all the tooltips.
Hope you find these new features helpful.
Thanks for reading,
Don
The extension may have already been written by someone else, so first, check the Adobe Exchange. Also, search the internet because there are many third party extensions that are not uploaded to the Adobe Exchange.
The easiest way to create your first extension is to open the History Panel (Window > History), select 1 or more steps, right-click and select "Save as Command…". This creates a Command in the User Configuration folder Commands sub-folder which on WinXP is usually something like:
C:\Documents and Settings\[username]\Application Data\Adobe\Dreamweaver CS4\en_US\Configuration\Commands
Note that the "Application Data" folder is hidden by default, so you may need to enable displaying of hidden folders in the Folder Options of the File Explorer.
Next, look around in the Application Configuration folder for code samples. On WinXP, it's usually here:
C:\Program Files\Adobe\Adobe Dreamweaver CS4\en_US\Configuration
Some tools provide an interface for users to extend it, but don't actually use it themselves. Dreamweaver uses it's own extensibility layer extensively (warning: pun attempt), so you'll find an example of almost all thousand or so JS API calls.
DW extensibility UIs are written in HTML, CSS, and JavaScript, so you already know how to do it. They are rendered with our proprietary rendering engine, so not all HTML/CSS/DOM is supported, and the rendering maybe different from current browsers, so you have to play around with it a bit.
Some aspects of the extensibility UI rendering is controlled by the DOCTYPE. Our proprietary rendering engine (note to wikipedia: it's not Opera) has evolved over the years, so be sure to target the desired DW version number in your DOCTYPE. So, to create a Property Inspector to target Dreamweaver Version 8 and above, use:
<!DOCTYPE HTML SYSTEM "-//Macromedia//DWExtension layout-engine 8.0//pi">
Note that starting with version 10, the DOCTYPE was changed to use "Adobe":
<!DOCTYPE HTML SYSTEM "-//Adobe//DWExtension layout-engine 10.0//dialog">
There are online Extending and API docs here:
http://help.adobe.com/en_US/Dreamweaver/10.0_Extending/index.html
http://help.adobe.com/en_US/Dreamweaver/10.0_API_Ref/index.html
Finally, be sure to upload your extension to the Exchange if you'd like to share it with others.
In DW8 and later, for overflow:auto/hidden/scroll elements where the content does not fit in the containing element, Design View displays what content it can (and truncates the rest) in the element in a view-only fashion. This means that, if you try to set the selection inside the element, the entire element is selected, so the whole element itself can be edited, but not any of its contents. For this case, right-click on the element and use Element View > Full (shortcut is to double-click) to temporarily see the entire element. Use Element View > Hidden (or F5) to revert to the default view. Note that this may disrupt the layout.
Since display:none elements do not take up any space in the flow layout, Design View does not display them. Starting with CS3, you can use the Element View feature to edit display:none elements. You may need to go to Preferences > Invisible Elements and turn on display:none elements. This will show an icon in Design View that you can select to use the Element View feature. Note that just displaying the icon may disrupt the layout, so that's why it's off by default.
Design View also hides visibility:hidden elements, but only if they are position:absolute (AP) elements. Use the AP Elements (formerly known as Layers) Panel to toggle the visibility of these elements. Design View always displays all non-AP visibility:hidden elements for the sake of editing. They take up the same space in the flow layout, so this does not affect the layout of the page.
You can also override any CSS using in a Design-time Style Sheet if you want to always see particular elements in Design View.
Starting with CS3 (or in DW8 with an extension), another technique is to turn off rendering of CSS styles using:
View > Style Rendering > Display Styles
This causes all content of your page to be displayed in it's glorious unstyled semantic form. Ever wonder what someone visiting your page with a Screen Reader "sees"? This is a good approximation.
Of course, you can always switch to Code View and edit :)
Take a look at the Configuration/CodeColoring/CodeColoring.xml file. At the very end of the file, you'll see some <tagGroup> tags that specify a list of one or more tag names in the tags attribute. The name field is what gets displayed in the Code Coloring Preferences Styles list so you can use the "Editing Coloring Scheme" dialog for setting the color of the group of tags.
In this, the latest post on new features of CS4, I will be talking about the CSS Property Inspector (CSS PI).
With CS4 we continue to improve (hopefully) the CSS editing experience. We continually try to meet the needs of design pros, who know the code and want to be efficient, and those that are learning CSS, and need to understand what they are creating.
The new CSS PI is a good step towards that goal.
First, why the CSS PI? A couple of reasons:
We, and you, have been pained by 'style1,style2' for a few releases now. We knew we had to get rid of that. (For those of you that don't know, those are the names of DW auto-generated classes.)
We wanted to make the distinction between editing the HTML and editing CSS properties. In the old PI, those properties were mashed together (Format wrote HTML, Size wrote CSS).
So now the text PI has 2 buttons on the far left. The HTML button shows the properties that write or change HTML: Link, Class, Format, etc.
The CSS button shows those properties that will change CSS properties: Font, Size, etc.
But in the past, DW would blindly make that change and fester the page with style1, style2. Not only that, it didn't educate the user on what was being created on the code level.
So the PI now prompts for and helps to determine intent. If you set a Size property, DW will open a dialog that prompts for a class name. It assumes a class in this instance, but in the dialog, you have an opportunity to set an ID or contextual selector.
The Size property is added to this newly formed class and that class name shows up in the Targeted Rule field. No more style1. Hopefully, this will help new users learn about classes, IDs, CSS properties and how to properly harness the abilities of CSS.
There are many ways to design features like this and we hope we have struck a good balance between experienced user efficiency and new user education.
And yes, even we panicked a little bit when we looked at the PI and didn't see the Link field. Hopefully the change is workflow is worth it.
Let us know either way.
Thanks,
Don
DTSS are implemented as "User" style sheets. More info here:
http://www.w3.org/TR/CSS21/cascade.html#cascade
"By default, rules in an author's style sheet override those in a user's style sheet. However, for balance, an '!important' declaration takes precedence over a normal declaration. Both author and user style sheets may contain '!important' declarations, and user '!important' rules override author '!important' rules."
http://www.w3.org/TR/CSS21/cascade.html#important-rules
So, give your DTSS properties the !important modifier to always override what's on your page.
You might not have found it because a button was not added to the toolbar with the Code, Split, and Design buttons for the sake of avoiding confusion. The good news is that the markup to add the button was left in the Configuration/Toolbars/toolbars.xml file, but simply "commented out". So, you can "uncomment" the markup if you'd like that button on your toolbar.
In DW8 and above, the IECC support "level" can be changed. I wrote an extension for doing this:
http://www.adobe.com/cfusion/exchange/index.cfm?event=extensionDetail&loc=en_us&extid=1564018
Note that the IECC Support Level affects which markup is seen by the DW DOM, so it affects all related features. So, while it fixes the file path fixing and dependent file problem, it also affects Design View rendering. Live View is not affected.
Today I am going to continue the discussion on the new features in CS4. Today's topic is Web Widgets.
We introduced Spry widgets in DW CS3 and they were well received. But we noticed many many other widgets out there, some more complicated than others, and wanted a way to let DW users easily get and insert these widgets into their pages.
Web Widgets is a couple of things. First: It is a set of widget extensions from 3rd party developers that can be installed into Dreamweaver, much like Spry widgets. Second: It is the ability to create these widget extensions.
When CS4 was released, we introduced a set of 15-20 Web Widgets from Yahoo, jQuery and Phatfusion. This allows you to install these extension into DW and insert, say, a YUI Calendar directly into a page.
These Web Widgets can be downloaded for free from the Dreamweaver Exchange. There is a new menu option in DW CS4 that takes you right to the Web Widgets Exchange. Check the gear icon to the right of the Help menu. (Note that these widgets are for CS4 and higher.)
The second big part of the Web Widgets world is the Widget Packager. The Packager is an extension that installs into DW. This then consumes a Widget Descriptor File (WDF), which is an XML file that describes all the properties of the widget. The WDF file follows the spec of the Open Ajax Alliance.
When a WDF is run through the packager, DW will create all the files needed to create a new widget object, and then it will wrap it up into an extension (and install it into DW if you wish). This extension can be uploaded to the Exchange and distributed to the world. We tried to make it easy for people to create widget objects for Dreamweaver and share them with the community. You don't have to be a widget developer to make a Web Widget. If you can write XML, you can easily package up an existing widget (following all licence agreements of course).
So we hope that users will see the benefit of a wide range of widgets for DW and take the initiative to create and upload widgets.
The Widget Packager is available for free on Labs here.
Thanks for reading,
Don
A few years ago, the number of uploads and downloads of DW extensions on the Exchange slowed to a crawl because the web site was, uh, a bit challenged. OK, it sucked. But the web site has been redesigned, so please give it another look. I currently see 1,408 extensions for DW.
Also, there are many Dreamweaver extensions written by third party developers that do not get uploaded to the Exchange, so be sure to search the web for more. There are too many good developers to list them all here, and I don't want to play favorites :)