17 November 2008
To understand the basic principles of how to design for and use the new CSS Export feature, first read John Wylie's article, Exporting CSS and images in Fireworks CS4.
The World Wide Web Consortium (W3C), along with other groups and standards bodies, has established technologies for creating and interpreting web-based content. These technologies, which we call "web standards," are carefully designed to deliver the greatest benefits to the greatest number of web users while ensuring the long-term viability of any document published on the web.
— The Web Standards Project
For years, Fireworks has played a huge role in my workflow from design to finished page. However, there was an obvious gap where I had to manually write the markup and CSS after slicing and exporting the relevant images. The Fireworks CS4 team realized this obstacle and set out to address the issue with its CSS Export feature.
When it was announced that Fireworks CS4 would be capable of exporting designs as XHTML and CSS, I was excited but also a little sceptical. Although using CSS is a huge leap forward—and it is a very powerful buzzword in the industry today—it is not the answer to creating the perfect website. Many bad CSS websites exist today. The real answer is in web standards.
Web standards are the future. If you're not using web standards already, now is the time to start. Here are a few of the benefits from using web standards:
Unfortunately, my initial scepticism regarding the CSS Export was well-founded. Although an effort had been made to export CSS-based web pages, the semantics, accessibility, and simplified development had been overlooked slightly.
As a Fireworks and web standards evangelist, I decided to work with the Fireworks team to help produce an enhanced version of the CSS Export feature, which empowers you create better, standards-compliant web pages. Here is a list of the main things that have changed in this enhanced version:
There are many more bug fixes and enhancements too.
This article demonstrates how to use the enhancements to the CSS Export feature so you can create standards-compliant designs.
By writing semantic markup, you're on your way to using web standards. Semantic markup means using XHTML elements for their implied meaning, such as
<h1> for the first, most important heading in the document.
Once the semantic markup is done, you need to separate presentation from structure by using CSS to style these elements. It is also important to validate both the markup and CSS to ensure they comply with their standards. Although there are other standards to consider, for the purpose of this article, these will be considered to be the two most important ones.
Prior to designing in Fireworks CS4, layouts for websites were created with little regard for the semantic structure of the elements themselves. Sure, you'd visually create different sized headings, for example, but the actual elements to be used were usually decided upon after the design was completed, and during the process of building of the XHTML and CSS.
While this is an adequate workflow when the same designer designs and builds the web page, when another designer/developer resource is tasked with building the XHTML, their perception of the structure of the document could be very different than intended—resulting in a less semantic result.
With the updated CSS Export feature, you now have two methods of planning and realizing the semantic structure of a design within a Fireworks CS4 document, which not only helps you plan your design more effectively, but allows for anyone else to take over the project as well.
The two methods, tagging text and HTML component symbols, are discussed below, along with their pros and cons.
I'm sure every Fireworks designer regularly uses the Text tool to mock up text in their designs. For this reason, I realized that standard text objects offered an excellent opportunity to help define the semantic structure of the content.
I've enhanced the CSS Export feature to allow for the tagging of text objects to identify the corresponding XHTML tag on output, just by following a simple naming convention.
The elements that can be created from a text object are:
<span>. Specifying a tag other than these, or not specifying one at all, will produce a
To specify that a text object should use a specific tag, simply name it beginning with the tag name, like so: <h1>title .
Let's try it now:
Because you did not tag the text object in Fireworks, it has exported the content in a paragraph. Notice that it has given the paragraph a class of
lastNode and has wrapped it in a div with a class of
By viewing the related CSS file, you can see that the
lastNode class applies to paragraphs within an element that has an ID of "main" and resets their margin-bottom to 0.
The class of
Txt_Hello on the div is based on the name of the text object in Fireworks, and positions it where it needs to go, setting its font and color properties so that any paragraphs within that div are appropriately styled too.
This way, a user can add multiple paragraphs, both from within Fireworks or an external editor or CMS, and the paragraphs will always be styled correctly. Just remember that the final paragraph of any text block must have the
lastNode class applied.
So, let's try it now:
With the version of the CSS Export that ships with Fireworks CS4, only one paragraph would ever be created, with breaks (
<br />) creating the space between. The class of
Txt_Hello would also be applied to the paragraph and the div would not be created, meaning that new content could not be added without causing validation errors.
As you can see, this updated version of the script is already helping to create better standards-compliant pages.
Now try tagging:
As you can see, Fireworks respected that you wished for the "Hello world" to be an
<h1>. This time it created the space between the lines using breaks—paragraphs obviously cannot exist within headings—and gave the
<h1> a class of
h1_title to style it. A div didn't need to be created, as only inline elements could ever reside within an
As I mentioned earlier, you can now tag text objects to create twelve different XHTML elements.
It is important to remember that if you create an anchor
<a> this way, the styles created for it will apply globally for that element. You will not be able to specify different styles for the
:active pseudo-classes. Styling these pseudo-classes requires you to edit the exported CSS file manually.
There are three other important considerations when you use a text object:
Let's consider these observations by way of an example of a website breadcrumb, consisting of six point-text objects, four tagged with
<span> and two with
<a>. Notice how in Fireworks the bounding boxes are actually spaced six pixels apart to create the same space upon export, but the text in Fireworks actually appears as nine pixels apart (see Figure 4).
As well as supporting the tracking (letter-spacing), leading (line-height), (text-)alignment, (font-)weight, and (font-)style options, this enhanced version of the CSS Export also translates both the space preceding paragraph and the space following the paragraph as a relevant margin-bottom value in ems on paragraphs.
Introduced in Fireworks CS3, rich symbols are editable design and interface components that you can use and reuse for website designs, interface prototypes, or any other graphic design composition. They have been enhanced in Fireworks CS4 to allow for creating relevant XHTML markup and CSS on export.
It was the original intention of the Fireworks team to use HTML components to produce the required markup for all elements when using the CSS Export feature. With the introduction of tagging, however, I believe there will now be a reduced need for them, as they are less efficient to use—and, as the old adage goes, "time is money." Nevertheless, they definitely still have their place as part of your workflow, which is why I have taken the time to recreate new HTML component symbols, which are now included as part of the enhanced CSS Export.
Note: If you have already used the existing HTML components, your designs will more than likely error on export until the document's library is updated with the new components.
The HTML component symbols can be found in the Common Library panel (Window > Common Library) within the
HTML folder. The following symbols are included: Link, Heading 1, Heading 2, Heading 3, Heading 4, Heading 5, Heading 6, TextField, TextArea, ComboBox, CheckBox, RadioButton, and Button.
All of the form elements exist in both Windows Vista and Mac OS × default theme varieties. If you wish, you can easily create other OS themed varieties too. To learn more, read Aaron Beall's article, Using rich symbols in Fireworks, and Sarthak Singhal's article, Enhancing rich symbols in Fireworks CS3.
As with the rich symbols from CS3, the HTML components' properties are changed through the Symbol Properties panel while the symbol is selected on the canvas.
The Heading 1 through Heading 6 components have the following editable properties:
Although this list doesn't seem particularly limited when compared to what tagging a text object as a heading would allow, there are some notable differences:
In addition to this, the Common Library panel unfortunately retains some of its quirks from CS3, and now the Symbol Properties panel in CS4 suffers from some irritating (and known) bugs too:
As well as the reusable, swappable, and edit-once, update-many benefits of using symbols, another of their benefits is that they limit the font (family) choices available to a select list of the most common fonts found on users' computers. However, in their defense, using text objects will present a necessary warning if a nonstandard font is used.
If you are uncertain as to which fonts are safe to use on the web, I suggest reading Code Style's Most Common Fonts for Windows, Mac and Linux Font Survey Results which is updated regularly.
So, as you may have gathered, I don't necessarily recommend using the Heading HTML components. However, the remaining link and form element symbols can become very important in your workflow.
The Link symbol has the following editable properties:
Also editable are the same color, weight, and decoration properties for the
The Link symbol suffers from the same issues as the Heading ones, as I mentioned, but they are less of an issue in this instance.
Try using the Link symbol so you can become acquainted with it:
You can see that the link was exported to look exactly as it was in Fireworks and maintained all of the color, decoration, and weight properties for the pseudo-classes
If you open the accompanying CSS file in Dreamweaver, you will see that all of the relevant rules have been created similar to what appears in Figure 5. The order in which the CSS rules are produced for anchors is extremely important to ensure that the correct formatting is applied at all times, regardless of its state. The anchor's ID #Link has been generated from the object's name in Fireworks.
When I was approached to help make Fireworks produce more semantically correct markup, I made it a top priority that it could create unordered lists. This is why the new symbol is the cream of the crop.
Although it's called the List Item symbol, believe it or not, you will use it mostly to create links. Confused? Let me explain. Every website has some form of navigation, and if you think about it semantically, what is navigation if not a list of links? It's a perfect fit.
The List Item symbol has the following editable properties:
The "Node type" and "Is link?" properties are the most two important properties of this symbol. "Node type" determines how each list item will be represented in the markup, while "Is link?" dictates whether the symbol will also output an anchor, and allows you to style it appropriately, similarly to the the Link symbol.
The effects of the "Node type" property are as follows:
So by combining various List Item symbols, and setting their Node type correctly, you can export a full unordered list with children list items.
Let's explain their usage with an example:
The CSS Export process extrapolates the structure of the document by interpreting where the columns and rows of objects exist. Because of the float-clearing mechanism used for that, attempting to create an unordered list, arranged vertically, will result in invalid markup being produced (see Figure 7).
If you wish to have a vertical navigation, simply remove the float-clearing divs and assign the class of
clearFloat to each of the
<li> tags (see Figure 8). Attempting to visually divide the List Items in Fireworks with an object, such as a rectangle, line or text, for example, will also produce invalid markup in both horizontal and vertical lists.
Upon export, you will be manually required to move these dividers to within the <li> tags, and change their styles slightly if necessary to produce the desired output.
<form> elements have been overhauled the most in this enhanced version. Although both Windows and Mac versions of each element existed before, the Mac ones held the short straw with regard to actually being useful—or working at all!
Both sets of elements have now been updated to show a larger range of editable properties and to export correct and valid markup and styles. The HTML TextArea element has also been included.
The editable properties for form element symbols are as follows:
For Buttons, the Type property allows you to display and export buttons of type Submit, Reset, or Button. For TextFields, you can choose to export standard Text or Password inputs.
The State property varies among the symbol, but generally allows you to represent the element when it is hovered over, selected, or disabled—with disabled elements exporting as disabled.
When exporting a document that contains form elements, there are some considerations to maintain valid and standards-compliant markup:
<form>element wraps the entire contents. While this is fine for most situations, and is normal for anybody who develops in .NET, you need to manually modify the document's form structure when multiple, clearly separate forms exist—such as when a search and message posting exist in the same document.
<legend>elements are ever exported. As it is not possible to define a logical collection of
<form>elements within Fireworks, you will need to manually add them after the export process and unstyle them, where appropriate, to make them essentially invisible.
<label>element. If you require a visible
<label>in your design for other form elements, tag a text object as one. You will still need to associate the label to the relevant form control by adding a "for" attribute with a value of the form control's ID.
<label>tags, omit them from your design but remember to add them in the markup and then hide them through CSS after the export process.
There are a few other things worth mentioning when using form elements:
To support the CSS Export feature, Fireworks CS4 added the Background Image slice type—a fantastic enhancement. At its most basic, it provides the opportunity to slice sections of a design and export them as the background image of an empty div. However, its potential really shines when its background-repeat and background-position properties are used to create a tiling background of a div.
With this feature, seeing really is believing, so let's get straight to it:
What you see is a perfect representation of what you had in Fireworks, all produced from a single 1px background slice.
How could you use this technique for a real-world purpose? You could create the background of a div that includes other content, such as for a navigation bar or block-level heading:
This simple exercise demonstrates the power of the CSS Export feature and its goal of creating accessible, standards-compliant pages. As all of the font sizes are specified in percentages, it allows them to scale in every browser. This is crucial for improving the accessibility of any site.
You'll also notice that even where the background image stops, it still blends with the rest of the box. This is because the solid background color of the rectangle was set in Step 3. It is important to realize that even if an object has a gradient fill, its original solid color is still remembered. We utilized this in this enhanced version of the CSS Export.
If you return to Fireworks and change the rectangle to show a solid pink fill, apply a linear black-to-yellow gradient, and then re-export it, you would get a result like Figure 10. Additionally, the background slice type works in an identical manner with a horizontal gradient, repeating on the y axis.
A common element of web design is to show a panel that has a static top, a middle section for any amount of content, and a static bottom (see Figure 11). The CSS Export caters to this requirement by using the background image slice type, and what Fireworks calls the "3-slice technique."
By placing three background slices (one for the top, a repeating one for the middle, and one for the bottom) over the top of a rectangle, rounded rectangle autoshape, or path, the CSS Export feature automatically realizes what you're trying to achieve and produces the relevant markup using the 3-slice method. Consider the slice setup in Figure 12. You could also do it by including a heading where the top slice would be.
If you were to add the text to the image, the top slice would need to be exported again separately without the text visible and would also need its height extending to cater for text resizing (see Figure 13).
When combining the techniques covered in this article, you can produce professional, standards-compliant results, such as the sample project, called Smolder, which is a generic blog post template design. Download the archive containing the sample file:
and then open the file smolder.fw.png in Fireworks CS4 (see Figure 14).
The following describes how I planned this design, and what else you can do in Dreamweaver after exporting it to produce the perfect result:
Some of the objects, especially the Link symbols, are not aligned correctly. They mostly appear too high. This is because the export process does not take into account the elements' default line-height; their margin-top is too big. The workaround is simply to nudge the elements prior to export, as I did, or to adjust their styles manually in the CSS after exporting.
If you export the file as CSS and Images, you will see that it has been replicated almost perfectly (see Figure 15). I'm sure you'll agree that this is quite an accomplishment for Fireworks. Not only does it look the same, but it also passes as perfectly valid XHTML and CSS, when validated using the W3C validation tools.
To see how Fireworks performs in producing semantic markup, you can remove the style sheet (either manually or temporarily in your browser). The markup is almost perfectly semantic, nicely structured, and suitable to be used and restyled for any number of different browser devices (see Figure 16).
Now that you have exported it, how could you manually improve it in Dreamweaver? Here are some ideas I have, starting from the top of the document to the bottom:
To me, that's not really that much of an effort, knowing that Fireworks has already saved me several hours of good work.
The CSS Export feature does have some notable omissions. It is not yet a one-click web design and build solution for every web designer. However, there's no denying the amount of effort that was put into this feature, and its ability to increase the professional designer's efficiency with the initial design-to-HTML phase. No other product exists that can match Fireworks in this area.
As a professional web and user interface designer, I would say that my list of top issues to address with the CSS Export feature as it exists today are as follows:
Notice how I say "currently." Because the CSS Export feature is easily customizable, I would urge anyone who is interested to help improve it and share their updates with the community. Feel free to offer suggestions for improvements by contacting me directly or posting on the Fireworks support forum or Fireworks Guru Forum site. The Fireworks team, John Wylie, and myself could help assist you. We would definitely appreciate the effort!